The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js.
Monitoring tools similar to VisualVM will come.
Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.
It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. Those problems are sometimes obscured by the novelty and promise of the shiny alternative, and take a while to be felt among those who always opt for the new thing, but they are invariably discovered later on, and by that time something newer comes along, whose problems are yet unapparent. The problems are there because unlike Java and the JVM (and Fortran, COBOL, C and Rust), those platforms were not developed after careful consideration of the industry's needs (Erlang/Elixir is a different story, and, indeed its fundamental problems are more environmental than technical).
In addition, in smaller/less-critical projects, Java was an accidental leader in a short period of time where the competition disappeared and Java itself was novel, but it was never "supposed" to be there to begin with. VB and Delphi were very popular choices early on. I'd estimate that even when Java was the shiny new thing, VB, Delphi and other rapid-development languages had a larger share of the market than Go, Node, Ruby, Python, Haskell and OCaml combined today. And frankly, I don't see companies developing en masse large-scale applications in C++14. Unless you have very specific needs, there's just no reason to go there and pay a higher development cost, and if you do have those needs, you're probably already there.
In large corporations (including trendy ones, like Google, Amazon, Netflix, Twitter and many more, let alone more conservative ones) the JVM still reigns supreme, with competition lagging far, far behind. I'm not saying it won't eat into the JVM's market share -- although they're mostly cannibalizing one another -- but I don't see any potential leader in the pack. It's possible that there won't be one, with many sharing the cake.
So I think that (again, with the notable exception of .NET) the non-JVM market is composed of novelty-seeking organizations and a share that wasn't Java's to begin with, but accidentally was for a short while (the two segments intersect).
>All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM.
The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time.
Programming language history sometimes seems pretty random. If Java hadn't hinted at the fantastic possibilities of the now completely defunct Applet technology, Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that.
It's ironic that Applets failed because of unsolved problems with the JVM that remain largely unsolved to this day (such as insane memory usage and laggy startup).
And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists.
And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity.
I wouldn't dare to predict which flavor-of-the-month will fade and which one will dominate. It seems to be random and largely dependent on fantasies about future platforms unrelated to technological merit.
We could have stuck with Lisp and Fortran and we wouldn't be any worse off than we are today. There is very little progress in our industry when it comes to programming environments.
> The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time.
Perhaps, but they're not solved by any of the languages/platforms mentioned.
> Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that.
Except that they were the same VMs (HotSpot was a Smalltalk VM). Smalltalk didn't lose; it just got repackaged as Java.
> And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists.
With that I agree, but JS has its own issues, and the other languages mentioned don't have it any easier in that regard.
> And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity.
Except that the JVM is by far the leading platform not only in conservative enterprises, but also among the thought-leaders and biggest technological innovators. I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software. As I said, for less-serious/smaller applications, Java and the JVM were not meant to be the first choices. We had VB and Delphi, then Python and Ruby, and now Node and whatever. It's the same market share, and I don't see evidence that the JVM is slipping.
>Perhaps, but they're not solved by any of the languages/platforms mentioned.
Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Go also solves the value type issues that cause the JVMs excessive memory usage. Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is).
>Except that they were the same VMs (HotSpot was a Smalltalk VM)
Yes, but HotSpot is from 1999 whereas Java is came out in 1995 if I remember correctly. The initial Java VM was a bit of a throwback.
>I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software.
> Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM.
Nope. Tooting my own horn here, but the Quasar library on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game.
> Go also solves the value type issues that cause the JVMs excessive memory usage
True, but not only is that solvable, it is actually being solved on the JVM as we speak, and will be released long before Go will have caught up. OTOH, Go has some serious issues that are unlikely to ever be solved (its reliance on source-code instrumentation and lack of support for dynamic code manipulation; this has been demonstrated to be of great value for many server software systems).
> Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is).
This isn't any worse than any language that isn't JS. On the JVM you have Kotlin, Clojure and Scala, all also compile to JS, and those are just the leading options.
> How do you define "serious"?
Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade. .NET is pretty much Java's only serious competition there.
> True, but not only is that solvable, it is actually being solved on the JVM as we speak
I am looking forward for it, but with Brian Goetz speaking about Java 10+ (note the plus) and Oracle not having a programming language culture, I am not sure they will ever happen in the near future.
IBM also doesn't talk any more about Packed Objects and I don't know if anyone is really paying attention to Gil efforts promoting object layout.
Even the Scala guys are now researching into Scala Native.
>Tooting my own horn here, but Quasar on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game.
If that is so then kudos to you.
>it is actually being solved on the JVM as we speak
Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid.
>This isn't any worse than any language that isn't JS
Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon.
>Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade.
Many platforms have that covered. Your arguments in favor of the most widely used platform seem a bit tautological at times. By that standard, Java could never have gotten to the place it is in now.
> Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid.
Three or four, most likely. That's not a long time at all.
> Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon.
I agree. If I were to pick the biggest threat to the JVM, it wouldn't be .NET or Go, but the JS ecosystem -- including wasm, which, although low-level at this time and more resembling LLVM, may grow to be a universal high-level VM one day.
> Many platforms have that covered.
I think almost none do.
> By that standard, Java could never have gotten to the place it is in now.
Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players, so it pretty much puts OCaml, Haskell and other academic languages out of the race. This leaves JS, Go, Erlang and .NET. Go seems unwilling to really study the market, so it will achieve success among the novelty seekers, who will then move on to the next thing; Erlang -- which has an amazing, inspiring design -- has no advantage over the JVM, and is at such a huge disadvantage in terms of resources, that the chance of it ever catching up is close to zero. This leaves .NET and JS, both with plenty of resources and a lot of industry involvement, and they are the only candidates that at this time appear to be able to unseat Java.
>Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players
I can't detect even the slightest influence of careful analysis on the rise and fall of technologies. If the creators of Java were planning anything, then it certainly wasn't what actually happened. Java failed completely in all areas it was originally built for (at least until Android, which happened very late in the game and is under threat).
If I had to come up with a formula for success, it would look something like this:
10% novelty-seeking and merit + 10% corporate backing and tenacity of the creators + 10% platform advantage + 70% historical accident.
In Java's history, that 70% historical accident was the web. No one planned for that to happen. All careful planners were taken completely off guard by the web.
Looking at my formula, I would say Swift has a shot at going somewhere. But there are huge wildcards like WebAssembly, the future of Java on Android and of course all the unknown unknowns that are probably going to disrupt all careful analysis including mine.
> But there are huge wildcards like WebAssembly, the future of Java on Android and of course all the unknown unknowns that are probably going to disrupt all careful analysis including mine.
With that I can completely agree. I can't predict when and how the demise of the JVM would come about, but I can see that it's not happening just yet.
I do wonder about one meta-question, though: What effect does the trendy SV tech-marketing-speech has on developer technologies? Ruby was a huge SV hit and now it's ebbing, all without ever leaving a big impact on the software industry at large (sure, it was adopted by the odd "enterprise", but nothing on a grand scale). Now we see something similar (on a smaller scale, I think) with Haskell, Go and Elixir. Will there be a serious impact, or is it a passing SV fashion?
I don't know, but one thing is for sure. All dominant technologies that turned out to have a great impact once started out as something that many thought was a passing fad.
Also, there are some languages that dominate significant niches seemingly forever, like Python as a frontend for math, science and machine learning or R for statistics.
It's very sticky even though I never quite understood why you would want such a huge language barrier between those who implement interesting algorithms in C/C++ and those who use them. I would have thought that there is more overlap between these two groups. I can imagine a similar role for Go in Unix utilities and backend infrastructure.
> All dominant technologies that turned out to have a great impact once started out as something that many thought was a passing fad.
Absolutely, but all fads started out as something many thought was lasting...
> It's very sticky even though I never quite understood why you would want such a huge language barrier between those who implement interesting algorithms in C/C++ and those who use them.
I'm not sure what you mean. My field is distributed/concurrent algorithms, and especially distributed databases, where Java has a significant lead over C/C++ where interesting algorithms are concerned.
I mean things like Theano, Caffe, TensorFlow, torch, mxnet, etc, basically all the leading deep learning frameworks. It's similar in several other math/science related fields. Not that Java doesn't exist in these fields, but it's an also ran.
First of all, that's a very small domain. I can similarly say that C++ is an "also ran" in business server-side applications. Second, I don't think that Watson, Spark and H2O qualify as merely "also ran".
>I can similarly say that C++ is an "also ran" in business server-side applications
Absolutely you can, because it's true. C++ usage has declined dramatically in the last 10 years. It's no longer used as a mainstream language for business applications (something it was never good at).
>Second, I don't think that Watson, Spark and H2O qualify as merely "also ran".
Spark and H2O don't even qualify as also rans in the space I'm talking about. Watson may be an also ran, and significant parts of it are written in C++. I have no inside information, but it's not too difficult to imagine which parts that would be.
It's pretty simple to see what's happening. Just look at Google. Google is a very Java friendly company. They do a lot in Java, just not their core AI stuff. Data shovelling and integration in Java. Core algorithms in C++. That's the pattern.
So yes C++ is used in smaller domains. But these are the most interesting, most innovative and fastest growing domains. Those who really specialize in these areas overwhelmingly use C++.
And it's entirely clear to me why that is the case. I tried to use Java for it (and Go). It doesn't work. I have to be able to load a ton of data into memory without constantly fighting a garbage collector, and I have to be able to specify exactly how that data is laid out in memory.
pjmlp reminded us of IoT. Another up and coming field where Java isn't going to be the first choice. Same with games, video processing, etc. Java is falling back in most new application areas.
Interestingly, web browsers seem to be a pretty good yardstick for many other completely unrelated tasks. Can you write a web browser in it that is up there with the best of them? If the answer is no, then that language is not going to be viable for a lot of other tasks as well.
One reason they do that (that's what leading Java people at Google told me), is that their core libraries need to integrate with all their codebases, some are in Java, some in C++, and some in Python. Another is indeed "intrinsic", but:
> But these are the most interesting, most innovative and fastest growing domains. Those who really specialize in these areas overwhelmingly use C++.
I generally agree (as an algorithms and C++ guy myself, although I now use Java for tricky algorithms, too, because I do concurrent data structures, and those really benefit from a GC), but the languages the algorithms-people use have often been distinct from what the industry at large uses, and that's what we're talking about.
> It doesn't work.
Well, I guess H2O would beg to differ. As to data layout, you're right that's being addressed as we speak.
> Java is falling back in most new application areas.
Those application areas have always existed, Java has never been a leader in those sectors, they're not growing, and Java has still been the most successful language ever. Look, we're not talking Java vs. C++ here. We're talking Java vs. Haskell, Erlang, Go etc.. Those alternatives have even less success than Java in all the areas you mention.
> If the answer is no, then that language is not going to be viable for a lot of other tasks as well.
That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of computing. We're not counting each type of task equally, but multiplying each task by the number of people involved in doing it.
>That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of computing.
I should have been clearer about what I think browsers are a good yardstick for. They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum.
Browsers are an interesting instance of such a product, because they need complex in-memory data structures, they use a ton of memory, they need low level access to hardware and they are soft realtime systems.
But that's by no means a contradiction to Java (and very similar languages) being the most popular language on earth. I see no reason why that should change any time soon.
The only thing that the JVM really lacks compared to C#, Go and Swift is value types. If that's being worked on, I hope it's being worked on fast because it is a big deal.
> They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum.
Absolutely. HotSpot is indeed the wrong platform for memory constrained environments, as are most GCed runtimes (although JVMs, including versions of HotSpot are used in embedded devices quite a lot, for applications that don't require the best possible use of resources).
I myself have used a real-time version of HotSpot (realtime Java -- RTSJ -- has support for scoped and nested arena-allocated memory) in a hard-realtime, safety-critical missile defense system. It ran on large servers, but current work on RTSJ also targets embedded devices (see https://www.aicas.com/cms/en/rtsj). I don't think this would be a great hit, but there aren't great hits in that market, anyway.
> If that's being worked on, I hope it's being worked on fast because it is a big deal.
Most of the HotSpot team (and not just them) are dedicated to value types as part of Project Valhalla[1], and some resources are directed towards Project Panama[2], that's supposed to be a fast bridge between JVM and native code (essentially replacing JNI with something that's both faster and much easier to write). Java 9 is already feature-complete, but value types are scheduled for Java 10 (maybe panama, too).
Well if applications of future are to be developed and delivered as it is today Java will very likely remain primary choice. But with containerized deployment Java solutions looks rather heavyweight. Oracle/IBM/SAP know this. I think that's why work on Java EE 8 is kind of stalled.
Java GC/ memory shortcomings become visible when companies like Netflix push it to limit e.g
> ... The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.
Go's advantage when it comes to GC is very temporary. HotSpot's GCs are more advanced, and Go has the upper hand only thanks to value types, which are coming to Java. Go will not come close to catching up by then. I think that containerized deployment is likely to evolve and change at a much faster pace than development platforms, so it's really hard to tell which approaches would fit where.
Java release cycle is ~3yrs so Java 10 will be roughly expected in 2020/21 time frame. And at that point larger ecosystem like Apache etc will start taking advantage of value type. So it is like 6-8 years from now which I would not characterize as very temporary. Also this is assuming Go committer from now onwards just sit and do nothing about performance improvements which again seems quite unlikely.
Java has 15 year head start on Go and if a newer Go GC beats very mature hotspot GC it could either mean Hotspot advantage is largely in theory or it has reached its peak performance and there is not much scope to improve further.
Go's GC doesn't beat HotSpot's GCs. It just has less work to do, and this is being fixed in Java. In any event, I think the biggest potential threat to Java isn't Go (which has some fundamental issues that are very hard to fix) or .NET, but the JS ecosystem, which may become the universal VM.
Also Go's GC doesn't move objects, which makes the whole problem a lot easier as long as heap fragmentation doesn't end up biting you badly in the end.
You are forgetting about the native desktop, IoT and mobile space, where besides Android's fork of Java, the language has lost its market.
We have zero customers using Java, besides Android and legacy Swing applications on those areas.
Otherwise customers are asking us instead for Qt/C++, .NET, Swift, Objective-C and Cordova/Ionic.
With Microsoft adoption of Docker, and their Go sponsorship on Visual Studio Code, I have started to see some Java consulting companies on my area to add Go on their services list.
Most Java deployments that I have to deal with on server side are still on Java 1.5 - 1.7, RichFaces and the occasional Websphere.
But Java was never "meant" to be a leader on the desktop; VB, Delphi and plenty of others have always had the lead. Whatever market share Java is losing, it is market share that it got due to market failure, and only held briefly. You're absolutely right about mobile, but the fragmentation there is such that no language/platform is the clear winner. Java's uncontested hegemony was short-lived, but even without it, it is an order of magnitude ahead of its closest competitor on the server side (with the exception of .NET). Everything else is just too fragmented to pick out a winner. Go is indeed an interesting challenge, but it has some fundamental issues that are serious roadblocks, while the JVM doesn't.
Let me put it this way: the war on server-side development is the JVM's to lose. Right now, it has some challenges (memory usage etc.) that are all solvable, if the important ones are recognized and addressed. Maybe they won't be, and someone else would step up and grab the lead. Maybe it'll be .NET; maybe it'll be Go; maybe JS. But right now, all alternative platforms are cannibalizing one another and competing for market share that has (almost) never been Java's much more than grabbing significant market share from the JVM.
I am curious to see what Oracle will do after Java 9 gets out of the door, specially now that they lost the case against Google.
In the hypothetical future they do like Sun and let the language stagnate after Java 9, given that Android Java is stealing their revenue, who do you think will bother to pick it up?
We are already seeing them silent on JEE and JavaFX, Kenai and Java.net got closed down, and it wasn't only the JEE evangelists that left Oracle, key JVM people like Monica Beckwith have also left.
I don't see IBM, Red-Hat or Google willing to pick the language and offer the resources and care to design it further.
And the type of research that Java GC and JIT require need deep pockets, not a few weekend pull requests.
> In the hypothetical future they do like Sun and let the language stagnate after Java 9, given that Android Java is stealing their revenue, who do you think will bother to pick it up?
Google (who is heavily invested; Google's OpenJDK team is about as big as their Go team)? IBM? Red Hat?
> We are already seeing them silent on JEE and JavaFX, Kenai and Java.net got closed down
We are seeing the exact same things happening at MS, yet there you interpret these events generously. Oracle is trying, like everyone else, to see where the wind is blowing. Kenai and Java.net are completely useless, and have been effectively abandoned for quite some time (more abandoned than Google Code).
I understand this tendency, though. When you're the leader and change things, you appear desperate. When you're an underdog, you seem visionary. But the fact is that Java isn't just the leader. It's competition (except for .NET on Windows only) is more than an order of magnitude behind. Java has also been eulogized time and again -- Ruby and Python were supposed to kill it last time around -- yet the JVM grows stronger, while the all the rest fiercely compete with one another on the distant second. I agree that JS is real and may actually change things, but there is so much new server-side code being written on the JVM -- significantly more than all other tech combined -- that the weakness on the client may kill it eventually, but it will be a while before the trend changes and we're at peak Java. There are huge companies like EMC that are just now moving projects from C++ to Java, and smaller companies like AirBnB that are moving from Ruby/Python to the JVM.
> I don't see IBM, Red-Hat or Google willing to pick the language and offer the resources and care to design it further.
Why not? Whatever other language/platform they pick will require even more investment than Java. There is no other language with that the industry is similarly invested in (except maybe C). Not even JS, which is still over 95% client-side code.
> And the type of research that Java GC and JIT require need deep pockets, not a few weekend pull requests.
Microsoft has a different problem, the startups of the 21st century rather use UNIX free clones than pay for OS licenses.
Google has proven more than once on Android how "committed" they are to the health of the Java ecosystem and how willing they are to write top performing JIT compilers for Java and keep their implementation up to date.
Where they are putting their language research money is on Go and V8.
IBM is the main company besides Apple now investing in Swift and last year they had a major project to make J9 JVM language agnostic as a portable runtime.
My career has shown me more than once that languages which aren't sponsored by OS vendors eventually fade, regardless how big their user base is at a given moment.
Oracle surely isn't an OS vendor as such, what they made to Solaris and their Unbreakable Linux aren't really things that many still care about.
What I know is that RFPs for Java projects on my little part of the globe are either Android or maintenance related.
I hope to be proven wrong, but I no longer search for Java projects as I used to.
> Google has proven more than once on Android how "committed" they are to the health of the Java ecosystem
Google's Android team and Java team seem to be completely distinct from one another. Throughout most of the trial, Google remained one of the companies most dedicated to OpenJDK.
> Where they are putting their language research money is on Go and V8.
I don't know what you mean by "language research money", but they're putting as much investment into OpenJDK improvement as into Go. Don't know about V8. They certainly wasted a lot of effort over Dart.
> last year they had a major project to make J9 JVM language agnostic as a portable runtime.
Yes, I was at JVMLS where they introduced it. Oracle Labs' Graal is much more "language agnostic" than that, and still very much Java. Graal may show the way to smooth (if not seamless) Java/non-Java interop.
> What I know is that RFPs for Java projects on my little part of the globe are either Android or maintenance related.
In that case, I think that your view may be very skewed. Android appears absolutely minuscule compared to Java where I'm looking. Of course, my view may be skewed as well, as I hardly look at front-end projects at all, and on the backend Java is so huge as to dwarf pretty much everything else.
This makes me wonder if IBM could now (post-Oracle v. Google) take over, or at least bite off a piece of, Java if it introduced value types and other goodies for JVM languages ahead of the official process and made a production version of J9 available at no cost.
The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js.
Monitoring tools similar to VisualVM will come.
Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.