Can anyone compare the JVM's technical merits with Microsoft's CLR? I always hear that the JVM compared to advanced alien technology, with its millions of engineer-hours, but not so much glowing praise about the CLR.
With Oracle remaining evil and Microsoft making waves in open source these days, I wonder how likely it is, for example, that a Big Data ecosystem like Hadoop/Spark/etc. could evolve around C# and .NET.
They’re honestly not quite miscible. I know that, when .NET came out, everyone responded with “haha they copied Java,” but the truth is that they make a pile of very different technical trade-offs. The CLR has explicit stack allocation, the JVM does not. The JVM is genuinely a JIT, the CLR is really all about AOT. The CLR has full support for low-level code (pointers and such), while the JVM does not. The JVM and its class library has been cross-platform from day one, the CLR in a meaningful sense has not. The CLR has a really simple FFI, the JVM traditionally has not. The CLR has reified generics, the JVM does not. The JVM has a much more advanced GC, the CLR’s use of value types and things like Span<> means that such an advanced GC is (at least arguably) not necessary, and so on.
I really love the CLR, and I think it’s just as much “alien technology” as the JVM. I suspect the lack of love for it likely has more to do with the official versions being Windows-only than anything else. But I think it’s also just true that, while they both fill the same niche in a grand way (they’re both high-level VMs), their details are sufficiently different that a direct comparison doesn’t honestly make a ton of sense.
that a direct comparison doesn’t honestly make a ton of sense.
I think a comparison of them as products/platforms and the way the combination of technical and business decisions have influenced their trajectories is still interesting and instructive. Microsoft's very belated recognition that they won't be able to extend their OS dominance to all things server also means they've mostly squandered the technical advantages of the CLR. Oracle can catch up with the missing bits technologically (and they are doing just that) whereas it's by now really hard for the CLR to catch up in marketshare. Which is a pity.
Since you seem to have a strong understanding of both JVM and CLR, do you know if it would be feasible to translate CIL bytecode to JVM bytecode without having terrible performance in the translated code? In particular, I wonder if Xamarin.Android could do this (of course, in that case the JVM bytecode would be further translated to Dex), to provide an alternative to the current hairy interop situation with JNI and two GCs.
I'm not sure, to be honest, but I'm a bit dubious. Some things would definitely be impossible to translate with good performance, such as unsigned types, checked arithmetic, and value types. Forgetting CIL translation, code that needs these things already runs very slowly on the JVM, even when translation isn't involved. (E.g., I think JGit is awesome, but the lack of unsigned values slows things down, as JGit has to promote integers or emulate types, depending.) But I don't know that these are so common that it'd generically be an issue. Other common things might be okay; Kotlin achieves C#-style generics by inlining all over the place, so I suppose a CIL translator could pull the same stunt. Likewise, while the JVM doesn't have a direct equivalent of stackalloc, I know the escape analysis has gotten pretty good, so maybe that'd work out okay anyway. IKVM had a comparatively easier job, since CIL is mostly a superset of the JVM bytecodes.
(Note though that I have zero idea how GraalVM impacts any of this. It might completely negate all the things I flagged above.)
Unsigned types should be possible to translate reasonably well. Addition is just the same, multiplication and division is performed via Integer.xxx methods and should be replaced by proper machine code by JIT.
IMO pretty much no other language run-time is directly comparable to the JVM simply due to the VM part. Building an entire VM into your run-time comes at a huge complexity cost but is necessary for its goal of running on different hardware seamlessly. It is simply not worth it for most run-times to try for that level of binary compatibility when simpler solutions like cross compiling work most of the time.
These days, more interpreted languages use VMs than not. One notable language runtime that does not use a virtual machine is the Chrome V8 JavaScript engine, which I believe compiles JavaScript directly into machine code and then executes it.
From my very shallow understanding of CLR/CIL it seems to me that CLR's object model is significantly closer to Smalltalk than JVM's, at least because IIRC CLR has send-like opcode since the beginning, while JVM for a long time had only bunch of specialized invokefoo, with "call n-th method of something" semantics.
"With Oracle remaining evil and Microsoft making waves in open source these days,"
I work with .NET and generally like it but .NET is still far, far away from the openness of Java. MS has open sourced a lot of stuff but it's still controlled by them. I also have my doubts for how long MS will sustain the move to open source. They have a long history of abandoning stuff like this after a few years and going back to business as usual.
Earlier this year I had to port a couple of small apps from .NET to Java, because the customer wasn't able to port all the necessary dependencies to .NET Core, while the existing Java counterparts from the same vendors had 1:1 feature parity with .NET Framework.
> They have a long history of abandoning stuff like this after a few years and going back to business as usual.
They also had a long history under gates, then ballmer. It may be that under nadella, these sorts of moves are (or are becoming) the new 'business as usual'.
There's .Net Core (standalone, open source, cross-platform), the .Net Framework (closed source, Windows-only), Mono (open source, cross-platform, implements significant chunks of .Net Framework standard libraries), and the UWP runtime (closed source, part of Windows). At least three of those four implement completely separate VMs. Which is important to you?
The VM interpreter is generated from assembly code snippets that calls this class when something complex need to be done.
Hotspot is written in C++ and objects shared by Java and the VM can be seen either in Java or in C++ because they have a Java header and a C++ header.
Classloading is done lazily in Java so you can not preload classes until the first time you see it. If you see a non loaded class in the JITed code, you have to jump back into the interpreter and re-generate the assembly code later.
OSR stands for on stack replacement which means that while you are interpreting a loop, you decide to JIT its body.
Biased locking is a way to implement monitor/lock if those locks are used only by one thread, you biased the lock to that thread, which is slightly more efficient.
The stack contains stack frames of different kinds Java, C, adapters (assembly stubs between the 2 JITs and the interpreter which obviously doesn't use the same calling convention) but you have a common way to iterate on them.
All Hotspot GCs are generational so you have to hold every pointers (Java reference) into Handles (box known by the GC) because the GC may decide to move the objects while the C++ code hold them.
Obviously, all this mechanisms make sense but managing the complexity of all of them working together is insane.
Oracle is as we all know, but at least they kept improving Java and sponsored the work being done at Sun Labs, turning it into Graal and Substrate.
If tomorrow they really completely loose interest in Java and let everyone go, are the same Java companies that let Sun fall now going to rescue Java and keep developing OpenJDK?
> With Oracle remaining evil and Microsoft making waves in open source these days
MSFT is not making as big a wave as you'd think. A lot of the hype is MSFT PR machine running rampant.
I use Visual Studio/.Net on windows and only on windows because it's what many corporations use. But I use linux and bsd + vim/etc at home.
A lot of MSFT software may be going open source but they also bring with it "spying telemetry" and I suspect eventually ads. It surprises me how little outrage there is over MSFT spying as there is with facebook. Windows is literally a keylogger and scanner all in one. It's pretty much spyware.
Wow! Amazing find. This is an amazingly well organized, detailed, useful resources.
It might be worth adding (2013) or JDK7 to the title. Off the top of my head the details about the permgen don't apply anymore and I believe this predates G1.
I recently attended a talk with Simon Ritter from Azul Systems that is developing Zing VM, and this VM is apparently gaining adoption among financial companies thanks to improved startup time and novel GC algorithms. Anyone with first hand production experience?
We use it at my job for our main api which needs lots of memory. I’m on the devops side and I don’t get into it much past the deployment of the app, so from my side it’s more of a hassle than openjdk since we have to deal with licensing.
Android started by copying Apache Harmony, as means of Google trying to avoid to pay Sun their rightful licenses, as confirmed by Andy Rubin emails.
Thanks to that, Sun lost what might have rescued from insolvency. Which Google, while thinking that they finally got rid of Sun did not bothered to try to save.
After the lawsuit and IBM's move to sponsor OpenJDK, Google was forced to migrate to OpenJDK.
Yet Android does not use 100% of OpenJDK, rather they are adding little pieces of it in each Android version.
Thus Android uses a forked version of OpenJDK, with everything that Google doesn't care removed from it.
The fact that they use ART is an implementation detail, some Java certified JVMs for embeded deployment also have tooling to convert to their optimized implementation instead of using .class files.
>Android started by copying Apache Harmony, as means of Google trying to avoid to pay Sun their rightful licenses, as confirmed by Andy Rubin emails.
The Apache Harmony code base is an open source, free Java implementation, developed by the Apache Software Foundation that is licensed under the Apache License 2.0. Google had every right to use the Apache project according to the terms of the license.
>Thanks to that, Sun lost what might have rescued from insolvency. Which Google, while thinking that they finally got rid of Sun did not bothered to try to save.
Sun is solely responsible for their bad business decisions due, in most part, to their incompetence. Issuing a license to Google would not have saved them from being acquired by Oracle.
>Yet Android does not use 100% of OpenJDK, rather they are adding little pieces of it in each Android version.
I wasn't aware that you had to implement 100% of an open source project if you forked it. Can you cite where that's a requirement?
>Thus Android uses a forked version of OpenJDK, with everything that Google doesn't care removed from it.
The Android SDK uses a forked subset of the OpenJDK. And why wouldn't Google remove things they didn't need like AWT, Swing, etc.
>The fact that they use ART is an implementation detail, some Java certified JVMs for embeded deployment also have tooling to convert to their optimized implementation instead of using .class files.
No it's not. There is no association architecturally or IP related between the JVM and ART. If there was then Oracle would not have lost every one of their JVM IP patent claims they asserted against the Android runtime.
> The Apache Harmony code base is an open source, free Java implementation, developed by the Apache Software Foundation that is licensed under the Apache License 2.0. Google had every right to use the Apache project according to the terms of the license.
Except it wasn't a TCK project licensed for deployment on embedded devices.
> Sun is solely responsible for their bad business decisions due, in most part, to their incompetence. Issuing a license to Google would not have saved them from being acquired by Oracle.
Says the Google employee.
Why did not Google buy the Java assets from Sun, given the deep investment on Android?
Because they hoped Sun would silently sink and stop being a thorn on Google's misconduct.
Instead Sun got bought by Oracle, so stop complained, had Google bought Sun instead this would have neved happened.
> I wasn't aware that you had to implement 100% of an open source project if you forked it. Can you cite where that's a requirement?
Ah now you state that Google did fork Java.
> The Android SDK uses a forked subset of the OpenJDK. And why wouldn't Google remove things they didn't need like AWT, Swing, etc.
Because OpenJDK is to Java like libc is to C, libc++ to C++, DOM APIs to JavaScript, ....
Forking while pruning the available API breaks the compatibility with existing code and fragments the eco-system.
Exactly what Sun managed to prevent with J++, whereas with Android Java they were a bit low on cash.
> No it's not. There is no association architecturally or IP related between the JVM and ART. If there was then Oracle would not have lost every one of their JVM IP patent claims they asserted against the Android runtime.
Whatever Oracle has chosen as attack vector is little relevant for the fact that I cannot take a random piece of Java code and be assured it compiles and runs on Android.
If Google really wanted to drive Java somewhere else, while breaking backwards compatibility, the solution was in reach of their bank account when Sun started looking for buyers.
>Except it wasn't a TCK project licensed for deployment on embedded devices.
It didn't require a TCK license because Apache never called it Java nor did Google need permission to use it on embedded devices.
>Says the Google employee.
What a petty response. You're blaming the failure of Sun on Google. When in reality the failure of Sun can clearly be traced to their poor business decisions and acquisitions. Sun had a lot of potential, but they were let down by incompetent leadership.
>Why did not Google buy the Java assets from Sun, given the deep investment on Android?
Did Sun offer to sell the Java assets to Google? I'm not aware of such an offer ever being made. If the offer was made then I agree that Google should have purchased the Java assets solely.
>Ah now you state that Google did fork Java.
The only thing I'm claiming is that Google did indeed fork the OpenJDK as they are allowed to do.
>Because OpenJDK is to Java like libc is to C, libc++ to C++, DOM APIs to JavaScript, ....
Forking while pruning the available API breaks the compatibility with existing code and fragments the eco-system.
The OpenJDK is an open source project that Google is allowed to legally fork and use just as long as they don't call the fork Java.
>Exactly what Sun managed to prevent with J++, whereas with Android Java they were a bit low on cash.
You're forgetting to mention a key difference. Microsoft called their extended version Java. Google does not refer to their fork as Java.
>Whatever Oracle has chosen as attack vector is little relevant for the fact that I cannot take a random piece of Java code and be assured it compiles and runs on Android.
Google doesn't call their implementation Java so I don't see why you would think you should be able to run any Java app on Android.
"The entire feature-set of the Android OS is available to you through APIs written in the Java language."
"compile Java sources into DEX bytecode, which can run on the Android platform."
"Android also includes a set of core runtime libraries that provide most of the functionality of the Java programming language, including some Java 8 language features, that the Java API framework uses."
You keep referring to the Android developer site as if they're some type of smoking gun when they have absolutely nothing to do with the point you seem incapable of proving other than to illustrate the obvious in that the Java language is used to make Android apps. Once the Java byte code is translated to DEX byte code, so that it can be AOT compiled on an Android device, that is the end of Java's involvement.
>Given how hard you support Google's fragmentation actions against the Java eco-system, your OS also uses C without libc.
Since Android doesn't run Java apps or use the JVM there is no fragmentation.
Most of it is generic enough to be applicable to anything that calls itself a JVM since it's required by spec. For instance, everything bytecodes, what a class file looks like, how dynamic linking works, etc.
Why would you have a different opinion? This post is almost entirely not about stuff like that. If anything, the other linked thing in this thread 'JVM Anatomy' and this post should meet somewhere and agree to swap titles.
Because those things are left unspecified and they matter specially under heavy load.
A JEE server might scale differently depending under which JVM it is running.
The GC algorithm chosen by the implementation might lead to higher pauses in another JVM.
The beautiful auto-vectorized code in one JVM might run like molasses in another JVM.
One JVM might lack tiered compilation, thus increasing the saw shape pauses when it comes to JIT a specific method.
Finally, the spec doesn't state how threads are executed, so they can be implemented as green or red threads, and certainly the code won't run the same way.
I'm well aware that my knowledge of the JVM is almost exclusively about the Hotspot lineage, and a bit about Zing, which shares a lot of DNA, and I'd like to know more about the alternatives, but either I'm looking in the wrong places, or there's simply much less accessible information out there.
My thought is that it would be better to spread information about the alternate implementations rather than exclusively complain about the misidentification.
Certain ARM-based SoCs used to be able to do this using a feature called Jazelle[1], but it had an array of problems that caused an early obsolescence.
There's nothing really wrong with this popular write-up and its many ripoffs and copycats over the years, other than the (in hindsight) poorly chosen title. Most of this stuff is an overview of what's in the JVM spec. If you are searching around for some thing or another about the actual internal implementation details of the Oracle JVM, this article and its many clones make the search term 'JVM internals' nigh-useless.
It implements a naive, simplified Python VM in Python. Of course, that is only a very high-level overview. By necessity it handwaves a ton by just relying on the underlying Python (like GC). For a more in-depth look, you can check out PyPy's dev docs (http://doc.pypy.org/en/latest/). PyPy is an alternative to CPython, so it does many things very differently (some in a way that have never been done in prog lang implementation before), but the docs do make comparisons to CPython.
I think pgbovine has done some things, but I don’t have a link. I also read a lot of shorter Python internals posts when I was learning Python. Maybe look at Raymond Hettinger?
This reminded of the "layers of crap" John Carmack was talking about once.
Java is an impressive tech, but I still fail to understand why it is so popular. It comes from a proprietary tech, it requires additional software to run, you cannot disable its garbage collector, browsers don't like it, I don't think it's very popular in the manufacture embedded controllers, and if enforces object oriented structure inside its JVM. Oh and Torvalds hates it too.
Not to mention the gargantuan bloat that are JEE and system like maven or ant. It feels really different and foreign compared to the simplicity of unix many devs are used to.
Even microsoft decided to rewrite minecraft to C++. I saw a private server had such big freezes, just to handle 3 or 4 players.
1) It’s fast. Like almost C/C++ fast. Yes like any language you can write crappy slow code in Java but it is fast by default.
2) While certainly not an easy language it is a simple language. The number of footguns in Java is pretty small.
There’s only a little of magic that languages like Ruby and Python have. Which of course means the programmer has to be more specific and add lots of boilerplate. And if you get it wrong the compiler yells loudly. And there’s none of the memory management ceremony from C/C++ that everyone gets wrong constantly.
GC can lead to hard to explain madness but your basic enterprise CRUD app is never going to see that.
3) The standard library is awesome. Things like Java collections and concurrency just work: no fuss. And when you need to reach into the back of the tool cabinet the defacto STL provided by Apache is incredible. Need something super specialized like an ordered bidi map in a tree? Apache’s got one and I have faith it’s well tested, decently performant and has good documentation
A decade ago Java could be terrible. There were a lot of people pushing giant XML confine. But even then you could always use code and smart folks did. Today the XML stuff is kept for comparability but the world has moved on. Modern frameworks end up looking and acting a lot like Rails.
>There’s only a little of magic that languages like Ruby and Python have.
>And there’s none of the memory management ceremony from C/C++ that everyone gets wrong constantly.
These statements are the spitting image of the Blub essay[0]. No matter what language you like, the world splits into languages where you have to do lots of things manually with high risk of mistakes, languages that have tons of sneaky implicit behavior, and your language.
The "blub paradox" is an opinion piece; it is not gospel. I did a bit more than two thirds of my career in non-"blub" languages. I like those languages, I know them well, I am good at them. For the last couple years I've been writing Java. I find it to be a much better tool for the job. A little bit more typing really isn't a very big deal.
I think Java is simple because it’s small. There are only 50 keywords and ~40 operators (many of which are variations). As a comparison C# has 102 [1] keywords. Java code is generally easy to understand assuming some familiarity with other languages. There aren’t many weird symbols or constructs. There are very few exceptions to the basic rules of Java. It just does what you’d expect most of the time. Java feels like a lowest common denominator language— a kind of average of everything else.
This “simpleness” is part of what makes Java not easy. It is not very expressive. Java (outside of memory management) does not give the programmer a lot of help. You have to explain things to it in excruciating detail, being very specific and never leaving anything out or the compiler will complain.
The lack of expressiveness makes some things really hard. Just look at the number of dependency injection frameworks that exist for Java. Or logging frameworks.
At a certain point of project complexity everyone ends up fighting their language. It feels that with Java that point comes early then most others. But cleverly I think it comes after a level of complexity that most people end up hitting in enterprisy CRUD apps and that’s a big part of why Java is so popular.
I can only speak for myself, but around 1997 MS totally dominated the desktop marketplace, and made also significant inroads into server territory (Linux wasn't a thing as enterprise server O/S until around 2003), so Java and Sun was seen by many as a way to evade MS ActiveX/COM/VB programming, and to save Unix. And that was accomplished indeed.
Java thrived on the dot-com bubble when large amounts of e-commerce backends were developed, many of which being maintained until today due to Java's very strong backward compatibility. Java continued to be a strong choice for the server-side because of the massive mindshare and ecosystem.
Today I'm not sure where Java is heading. I don't blame Oracle for trying to make money from Java, but recent news - releases being quickly pulled from downloads except for money, unbundling of packages from the JRE/JDK, deprecation of JEE/transfer to the Eclipse foundation, Graal/Truffle being commercial offerings rather than part of OpenJDK, the nashorn JavaScript engine being deprecated, etc. - seem out of character for what Java has stood for most of the time. For the first time in many years it's plausible (though not certain!) that Java use is going to slowly demise once a tipping point is reached where new developers aren't going to invest into it.
As to maven: when it was new I hated it with a passion. As time went by it was growing on me because of it's predictability when you're working as freelancer on many projects. Even npm/yarn respectfully mention it as the inspiration and reference for a successfull and mostly well-designed package manager.
The JVM is incredibly impressive technology. There's literally millions of man hours poured in the runtime and it's able to run Java (and other languages) code at near C/C++ speeds across an incredibly diverse set of hardware and OSs.
The Java language is a remarkably small language that achieved a great many of its design goals (safe to write, simple, object oriented, high re-usability, good for large scale teams to work with etc.). The language has carefully grown in design to include some other paradigms without turning into the language Cthulhu that C++ is.
The standard library is almost the maximum of batteries included. It's aged reasonably well -- not perfectly, but pretty well. It was smartly designed to be virtually self-documenting and emerged early with good tools and philosophies around that goal. The common secondary libraries are also pretty incredible, with first tier support for almost everything from ML to embedded systems.
Deployment is also really great. Before the latest fashion of containers and orchestration, you could spin up an app server and dump a single entirely self-contained JAR on it and you'd be more or less deployed. Some really hard problems in terms of monitoring, packaging and other issues have a good community approach.
If there's a real problem with "Java" it's the big-Enterprise culture that has emerged around it, and the lack of technical depth in many work-a-day Java devs. But this is also by design, as many enterprise software jobs are really just data plumbing and don't need AAA rockstar algorithm designers.
For people outside of Java-land (myself included), FizzBuzz Enterprise Edition is funny because it amplifies very real observations of the Java community and culture that we don't like. But not every run-time and language has to be equally used by every developer. These are tools. If C is a great tool for artisinal kernel development, Java is a great tool for assembly-line workers and heaven help us if people tried to switch those uses of the languages. It would be like carving handsoap with a chain saw and building bridges with tweezers.
That culture did not emerge with Java, rather the Taligent, CORBA, DCOM, MTS archtects moved from VB/Delphi/C++/4GL into Java and applied the same patterns.
J2EE was based on Sun's initial attempt to use Objective-C with CORBA.
Many languages require additional software to run.
> Java is an impressive tech, but I still fail to understand why it is so popular.
I used to write C++ as my goto general purpose language. After using Java once I was hooked. It was much easier to do stuff and manage my dependencies.
I think Java has 3 things going for it.
1) The ecosystem is huge. To dethrone Java for backend do not just compare another language to Java, you have to compare its ecosystem. Java has a huge ecosystem especially with Spring Boot tieing many of the most popular parts of that ecosystem together.
2) Speed. Some languages are easy to use. Some are very fast. It seems to me that if one were to quantify ease and speed and plot a min-max graph, Java would be up at the top... best performance with ease of use.
3) Here I am going to throw a hodgepodge of things that can be argued but when taken together amounts to a big deal. Reliability (its used in so many places that by the time you go to write your code rest-assured you are not stumbling onto a new bug), write once, swap JVM's, advanced garbage collection (G1 and beyond, GC is something that is constantly being tweaked and improved), evolution (Java evolves with the times, it biggest gripes became the next thing being addressed), Maven/Gradle (advanced dependency management and build orchestration... these tools are very powerful), Junit/mockito and other testing tools (very powerful testing suites).
+1 for Spring boot and the Spring ecosystem in general. I said it here a few weeks back, Pivotal(the company behind Spring) continue to keep that ecosystem innovative, modern, stable and performant and open sourced. That’s amazing...
We had a few rails developers work port some of their apps to Spring Boot, they struggled initially but after getting over that hump their feedback was it’s light years ahead of rails in terms of ease of use and performance. Easy of use = Groovy & Kotlin both of which compile to the JVM
The real game changer is when Spring runs on GraalVM. Once that happens it would be really really hard to beat java on the backend
I agree Spring has for most intents and purposes won the framework wars (which however also speaks to the relative stagnation in that space). What do you specifically expect from Spring running on GraalVM?
I'm not sure about the availability and maturity of the new-fangled Graal/Truffle/SubstrateVM stuff. I've being eying migration strategies away from the JVM for quite some time now, and towards JavaScript specifically due to its momentum and portability. Both Oracle and RedHat (or their employees as personal projects) had been running efforts for a node.js-compatible runtime system on the JVM several years ago. Now GraalVM provides a polyglot runtime for JavaScript and Ruby, but my understanding is it'll be commercial-only once it's released. So in a way, Oracle is preparing a Java exit strategy themselves :)
> Now GraalVM provides a polyglot runtime for JavaScript and Ruby, but my understanding is it'll be commercial-only once it's released. So in a way, Oracle is preparing a Java exit strategy themselves :)
Community Edition is open-source (https://github.com/oracle/graal) and has a relatively permissive license (GPL v2 + Classpath exception, all source files have the Classpath exception). The Classpath exception was added recently and will make a world of a difference.
Enterprise Edition provides additional optimizations and commercial support. Nevertheless, CE will take you a long way. Twitter says they have achieved a 12% speedup in the real world by running their Scala services with CE's Graal JIT.
All language implementations have been open-sourced by now (except for some EE optimizations). Most of them (including Graal.js and TruffleRuby) are licensed under Universal Permissive License or Eclipse Public License.
My favorite use of GraalVM is creating native executables with Substrate VM. Works great and brings startup time of my Java/Kotlin command-line applications down to 1 ms.
> What do you specifically expect from Spring running on GraalVM?
Mostly performance gains you get from AOT. I think GraalVM ( or similar technologies) is going to be a game changer for all langs that compile to intermediary byte code.
Unfortunately, GraalVM does not compile Spring as Spring uses reflection a lot and GraalVM does not fully support reflection. https://github.com/oracle/graal/issues/348
Performance gains of GraalVM's AOT are drastically reduced startup time (1 ms for my Java/Kotlin command-line applications), elimination of JIT warmup time, and reduced memory footprint. For peak performance of a language as dynamic as Java, a JIT is hard to beat. Profile-guided optimizations will narrow the gap but are only available in GraalVM Enterprise Edition. Native executables also have a less sophisticated GC than HotSpot.
Tool support should be mentioned too. Eclipse or IntelliJ come to mind, the on-the-fly compilation and error checking, code navigation and debugging support are huge power multipliers.
Your inclusion of Gradle in point (3) is in tension with point (2) in that Gradle runs at snail's pace. I do wonder whether running Gradle atop Graal will help with that problem, though I guess to get the benefits Gradle would have to be both built with and running build scripts written in statically-typed languages only, i.e. Kotlin instead of Groovy. It might even stop the developer exodus from Gradle to Bazel.
I've been using the JVM in production systems for nearly 8 years now without having written a single line of Java code. I am extremely happy with the VM I'm getting for my Clojure code: implementing virtual machines is very difficult, especially ones with good performance. I am quite happy I don't have a single-global-lock problem, that I get modern garbage collection algorithms, and impressive JIT compiler magic. Thanks to the JVM I rarely encounter any performance problems, and when I do, they are easy to solve (don't do stupid things).
> Not to mention the gargantuan bloat that are JEE and system like maven or ant. It feels really different and foreign compared to the simplicity of unix many devs are used to.
You can crap on Java all you like, but it takes a real weirdo to prefer autotools over maven.
Hahahaha, fair point. I do prefer autotools over maven, and I admit to being a weirdo. I also love awk and sometimes spend down time writing clever awk scripts to parse data. Weekends can get pretty wild ;-)
I think it really comes down to how well you the know the tool. You can take the nastiest most esoteric language and compare it to a truly beautiful one, and still prefer the former if you know it well. I've experienced this personally with bash for example. Bash is a gross language, but I love it because I know it really well. Elixir is a beautiful language, but I'm a total newb at it still and so I prefer bash to elixir.
Clever scripts tend to be easy to understand only for the author. Heck, even the author sometimes will have difficulty understanding the cleverness of their own old code.
Since Java enterprise applications can easily live on for a decade or more, it is important that they not be "clever" and be easy to maintain. Developers can come and go. New team members should be able to dive into and grok the code right away.
If we were talking about "what I would do at work" then I would agree with you.
Fortunately however the awk scripts that I hack in my down time are not even usually saved. It would be much like criticizing people who play regex golf because the regexes can be hard to understand. That code is never meant to be used for anything other than the immediate satisfaction it brings. If anyone ever did see them, it would be because they either hacked me, or I showed it to them related to some conversation about awk scripts.
However I also disagree on the definition of the word clever wrt workplace. I often consider the simplest and most straightforward implementation to be the most clever. Anyone can write impenetrable code that confuses people. Not many people can solve the problem at hand in an elegant, simple fashion.
I've never really met or talked to anyone that had both actually used autotools, and liked them. I find it positively invigorating how enormous the span of human perception and affinities seems to be.
While autotools mostly solves a very hard problem using several strategies and tactics that has come to prove themselves over time in that space, and outside of autotools, many of the implementation choices are absolutely puzzling. M4, the general weirdness of things, and not to mention the 10k+ lines of auto generated shell scripts to probe for features.
I've never loved maven, but at least it's insanity is rather symmetric.
If I had it to do over again, I'd probably switched to Erlang or something. There just was no REALLY good solution in the early days of the web. (Not that Erlang is a good choice for e-commerce)
Both are pretty over-engineered, but Maven has a drastically reduced "I want to pull all my hair out" factor.
Also, be careful not to confused "over-engineered" with "works correctly in the face of edge cases". autotools manages to be over-engineered and somehow is still not very robust. (Try using autotools on POSIX-compliant but not-very-unixy systems like QNX if you don't believe me.)
You'll have to remember the time when it was created. The idea of "write once, run anywhere" was considered a huge net positive. It can run on your Big Iron, and it can run on your watch. The fact that it was quickly adopted into education at the time led to it being used by many post grads. It's firmly entrenched in many enterprises due to Oracle (which perhaps rightly deserves a place in the enterprise) TELLING everyone "if you're serious about enterprise, if you're serious about scale, you'll use Java". This has led to the "no one has ever gotten fired for recommending we use Java" attitude in large corporations. While it was completely painful to use in the early days, it actually has gotten much better. But I'll agree, people were calling it "enterprise" when it was just a huge bloated XML nightmare.
"... I still fail to understand why it is so popular."
It was repurposed.
As you wrote, "I don't think it's very popular in the manufacture of embedded controllers."
A theory:
There is a large population of programmers who want to write bloated programs.
They will use whatever is made available to them to do it. They will prefer whatever makes it easier. This has become a "market" that others want to serve.
The supporting anecdote I always remember is the small scripting language AWK. It was not designed with the intent to write large scripts/"programs". However, if I recall correctly, Kernighan commented that he was surprised to learn that is what users were trying to do with it before Perl existed.
There are companies and governments paying massive premiums for things like Unisys and Wang mainframes, which are mostly VMs running on a Xeon chip in a box that you can’t open.
They are doing this because it’s expensive or impossible to move the code for a variety of reasons.
I’m familiar with Java systems that have been replatformed a dozen times without incident and on the cheap.
It achieved that in a similar way to the JVM though, architecture-independent bytecode.
That said, it's still incredibly impressive that System/38 programs can run unmodified and without recompilation on modern POWER8 (soon POWER9) systems. Sadly not all software can be as well-architected as AS/400.
It works in significantly different manner, there is no JIT, but TIMI gets AOT compiled into native(-ish) code (that is in turn cached in persistent storage) transparently by OS/400 when first run. But the process is hidden and fast enough to look like some kind of JIT VM.
Unisys still sells ClearPath MCP mainframes, which descend from Burroughs B5000, developed in 1961 using a variant from Algol (ESPOL) as safe systems programming.
Zero Assembly, ESPOL exposed all required hardware features as intrisics.
Based on feedback they rebooted ESPOL as NEWP, which is still the systems programming language from ClearPath MCP.
Not only it was already a kind of safe systems programming language, 10 years older than C, it already had the notion of unsafe code via unsafe modules.
They are built and sold in the similar sense as above mentioned AS/400 is built and sold. The user-visible CPU architecture is from the start designed as VM abstraction provided by the OS, which itself runs on real hardware that does not necessarily use same instruction set. Thus the today's hardware is something essentially off-the shelf (x86 in the unisys case, power for as/400).
On the other hand S/360 ("the mainframe") compatible hardware is still being manufactured by IBM and AFAIK even Fujitsu (which in addition to being S/360-compatible mainframe supplier themselves also bough Amdahl, which was the original IBM-compatible mainframe manufacturer, with the company/founder name saying a lot ;)).
I don’t know about Wang, but you can absolutely purchase Unisys mainframes, whose product lines are all descendants of ancient Univac and Sperry devices.
The hardware itself is x86. IIRC, they had some custom ASIC to do some physical isolation of workload, but that may not be a thing anymore. Fortunately, I don’t need to deal with it anymore!
I don’t know if they’re still being built, but parent didn’t make that statement. You can be paying for something even if there aren’t more of them coming off a factory line.
Many like Java for the write once run anywhere concept combined with memory safety. These can be achieved with C++ (std and RAII respectively) but it's less likely a less experienced developer will do that correctly in C++ and enterprises like solutions where you can throw more man hours at a problem with the lowest common denominator.
It's still pretty hard today even with good C++ standards. If I give a less skilled developer a problem to solve in Java I may not get as optimised a solution, but I don't have to worry about his code segfaulting or opening up RCE unless he really went out of his way to do so making code review a lot easier for low hanging fruit.
Microsoft didn't rewrite Minecraft in C++. It was rewritten in C++ by 4J Studios that were contracted to do so by Mojang in order to bring Minecraft to the consoles. Microsoft did create the Windows 10 edition and likely reused a lot of the code developed by 4J Studios.
With Oracle remaining evil and Microsoft making waves in open source these days, I wonder how likely it is, for example, that a Big Data ecosystem like Hadoop/Spark/etc. could evolve around C# and .NET.