Yes, ML is pretty good at those underlying principles; yes, you can use it to write code that's compact, safe, and fast; but it's not going to replace Java because #1 and #2 make Java easy for "ordinary programmers" doing ordinary businessy programming in a way that ML isn't and probably never will be.
(For the avoidance of doubt, I am not arguing that anyone who is comfortable in ML should use Java instead.)
There is the industry acceptance part that java has and then the runtime has been pretty well vetted and improved. I'd bet money that ML runtimes turn up with "issues" as larger more demanding applications are built.
And what exactly is going on with SML these days?
http://caml.inria.fr/pub/docs/manual-ocaml/manual038.html
"The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes."
Ocaml is a nice replacement for ANSI C, not for Java.
That's pretty much how I use it. Ocaml is a great systems language.
The other big problem is the underlying OS. Java lives on the JVM, Ocaml lives on Unix. Unix isn't a substitute for the JVM and vice versa.
However, F# might be an ML based competitor to java. I don't know enough about the MS stack to say.
You're strongly suggesting that a Java replacement has to compile on some standardize byte-code… Might be a prerequisite for proprietary software, but otherwise looks unnecessary. Besides, what do you mean by "lives on UNIX"? Ocaml runs on Windows too…
As far as I know, F# is currently unsuitable: that would be escaping the claws of Oracle to fall in the jaws of Microsoft. Now if Microsoft fully frees .NET, or at least abandons all patent claims regarding it, F# might do.
What I mean by "lives on UNIX/lives on JVM" is a fuzzy statement about the Right Way of Doing Things. The Java way is to build a large system, integrated with the rest of the world via one or more public interfaces, potentially accessed via RMI. You'll talk to the database via JDBC. There are highly configurable enterprise tools for almost everything. This is an ecosystem you need to replace if you want to replace java.
The Ocaml way is to write a program that takes command line input and processes a stream of text (which can come from a file or stdin). To write a daemon, you double fork. Most of your interaction with the outside world is simply via a posix interface.
That's not to say you can't write command line unix utils in Java, or gigantic enterprise daemons in Ocaml. But you'll be going against the grain.
There was such a successor before Java even existed: ML. It is safer, and current free implementations are at least as fast (and they have a C FFI). The catch is, programmers need to recognize that "OO" is little more than a brand, then see that despite it's "FP" branding, ML implements the underlying principles just as well (if not better).