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.
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.
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.
(Note though that I have zero idea how GraalVM impacts any of this. It might completely negate all the things I flagged above.)
It's retired now. I used it once, it worked pretty well.
Python's most widely used CPython implementation uses a VM: https://leanpub.com/insidethepythonvirtualmachine/read
Ruby "compiles the abstract syntax tree into lower-level byte code. This byte code is then run by the Ruby virtual machine.": http://blog.honeybadger.io/how-ruby-interprets-and-runs-your...
Perl 6 runs on the Parrot VM: https://perl6.org/archive/architecture.html (and I believe Perl 5 had a different stack-based VM)
Most people run Rakudo Perl 6 on MoarVM, but it also runs on the JVM (with some caveats) and there is a JS based runtime that is being worked on.
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.
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'.
That's just PR. But real projects need sound technical motivations for making such a move.
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.
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.
I'd also throw in the Shenandoah GC from Red Hat. I don't remember the details anymore, but I remember thinking it was an amazing bit of code:
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?
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.
But you should try the new J8 GC algos before you try a whole new VM
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.
Rest assured, I am quite good parroting.
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.
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.
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.
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.
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.
"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."
Given how hard you support Google's fragmentation actions against the Java eco-system, your OS also uses C without libc.
>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.
I surely have been there a few times.
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.
My thought is that it would be better to spread information about the alternate implementations rather than exclusively complain about the misidentification.
Both are actually quite common misconceptions.
Also embedded java, (kind of the JVM without floats, or GC) is common on base band processors for cellphones and satellites.
The full modern JVM10 spec has way to much magic to do in hardware. Some of the opcodes do things hardware can’t easily emulate.
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.
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.
>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. 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.
I was curious about this comment, could you elaborate? How can it simultaneously be both "not an easy language" and "a simple language"?
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.
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.
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 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.
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).
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
Your understanding is wrong.
GraalVM comes in two editions: Community Edition (CE) and Enterprise Edition (EE) (https://www.graalvm.org/downloads/).
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.
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
You can crap on Java all you like, but it takes a real weirdo to prefer autotools over maven.
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.
Anyway, thanks for the lols :-)
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.
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.
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.
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.)
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).
It was repurposed.
As you wrote, "I don't think it's very popular in the manufacture of embedded controllers."
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.
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.
AS/400 went from 48-bit CPUs to 64-bit without even a recompile
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.
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.
Here is a PR leaflet about NEWP and safety on modern versions of ClearPath
NEWP programming manual
The computing world would have turned out much different if AT&T had been allowed to sell UNIX right from the beginning.
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 ;)).
Can’t go into a lot of detail, but I’d suggest starting here: https://en.m.wikipedia.org/wiki/OS_2200
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!
There is always that guy using a C++ compiler as if writting C.
Most important, it let you concentrate on your domain problem rather than fighting the language. It gets the job done!
Great find and wish we got more things like this.