Slashdot Mirror
IBM Open Sources Their Own JVM/JDK As Eclipse OpenJ9 (eclipse.org)
IBM has open sourced a "high performance, scalable virtual machine" with "a great pedigree... [it's] at the core of many IBM enterprise software products." Slashdot reader dxb1230 writes: IBM has open sourced their JDK/JVM implementation named J9 as OpenJ9. The community now has an alternative implementation of Java which has been well tested on enterprise workloads and hardware. This unlike, OpenJDK, has all the bells and whistles like jit.
You beat me to asking this very question. OpenJDK most certainly does have JIT (both c1 and c2). I'm all for having an alternative JRE -- but OpenJDK has been great for running my production workloads for a while now.
The summary is wrong in several counts.
It's not a JDK but simply a JVM. A JDK would comprise at least a JVM, a java compiler and the needed class libraries. As the linked FAQ in the first entry says:
"Is Eclipse OpenJ9 a replacement for OpenJDK?
No. Eclipse OpenJ9 is a Java virtual machine (JVM), the engine that runs Java applications, whereas OpenJDK is a complete development kit that contains other components, like the Java class libraries, as well as a JVM. By default, OpenJDK builds with a JVM called Hotspot."
The "unlike OpenJDK also has all the bells and whistles like jit" is also wrong.
Hotspot almost 20 years ago replaced the JVM of that age which was a JIT compiling virtual machine, as was standard quite some time before. Hotspot however has JIT too but also does adaptive optimization on the fly which was the new cool thing back then. As wikipedia says:
" It features improved performance via methods such as just-in-time compilation and adaptive optimization." What it does and why it is called Hotspot is, it constantly checks what parts of the code are used the most often and it then optimizes those parts over time further if possible.
However it always uses JIT compilation like almost every other VM software does. Maybe IBM has some secret sauce JIT that Hotspot lacks, but the summary doesn't tell which or gives any other indication why IBM JIT is better than old Sun JIT
The IDE where the startup time is measured in geological time.
I've seen glaciers move several feet while Eclipse started up.
Java developer here...
Easier? Probably, since you know c. For me, Java is definitely easier.
More portable? Doubtful. I work on an Enterprise app with millions of lines of code and the same Jar works fine with essentially no extra work on both the IBM JDK and Sun JDK on Windows, Linux, and HP-UX.
We encounter typically 1-2 issues a year that are OS or JDK dependent issues. This is
If you want to argue c is better than Java, argue on it's strengths... Performance, bare metal control, and platform support (a lot of very small embedded platforms don't have a Java runtime... or it's terrible). Java beats C hands down in portability.
-=Lothsahn=-
Largely my experience now. There are certainly a few incompatibility issues that creep up, after all Java is over 20 years old now, so that's quite a few iterations of both the language and the JVM. But when I consider the complexity of porting C code from, say, Linux to Windows, or in many cases from Linux to BSD or some other *nix flavor, the odd quirk I run up against when popping a JAR file on to a new platform, I'd say Java is as close as anything gets to true cross-platform portability. No one has put more effort into making obscuring the underlying architecture than the JVM teams, and I still get a thrill when I fire up a Java app I've written on Windows on my Linux test machine and it, well, just works. No recompiles, no wild makefiles and compiler redirectives.
C is an awesome language, and truly one of the great inventions of the computer age, but it is fundamentally a different tool than Java, with very different intentions. For me, Java means I'm not locked into any architecture, and not having to fight my way out of the box that the architecture represents. It's not for every task, but for the bulk of problems thrown at me, it does the job very well. Not perfectly, but very well.
The world's burning. Moped Jesus spotted on I50. Details at 11.
My experience with Java portability is extremely good, during 15 years I guess i have less than 5 cases when I have to modify our own code for portability reasons. I mean binary compatibility, no recompilation is necessary. Upgrades were seamless too. However I know that others has worse experiences. Regarding C, I almost never have been able to compile C programs without issues in a new environment.
As a language, Java has the huge advantage of automatic garbage collection. That not only means that I do not have to destroy object at the end of functions, that is not really important. The big thing is that returning newly allocated objects to the caller is the natural way of doing things. This is an issue in C, because it must be agreed on who will destroy the returned object. Java also has a huge standard library, and - except web applications - there is an obvious candidate for everything.
Java has comprehensive runtime information about anything, so tools and frameworks can do almost anything runtime, including generating new code. And they do this nicely, they do not mess with the code unnecessary. There is a precise stack trace in each and every case. There is no pointer arithmetic, so there are no mysterious memory corruptions, ever.
Also, in contrast to the somewhat popular, moronic thinking, Java is very fast and very secure, it is compiled and recompiled several times dynamically runtime and there are no memory leaks. It usually requires more memory than a well-written C program, and its startup is slower, but that is rarely an issue on modern (i.e. not older than 10 years old) machine.
Overall I am much more productive with Java.
It's also an issue in c because such newly allocated objects are typically allocated on the heap, which is much slower than automatic storage allocation. Java uses the notion of short term storage, analogous to automatic storage in c and c++, when allocating objects (which are migrated to longer term storage as necessary) so performing such allocations in Java is not typically as expensive as heap allocations are in C
File under 'M' for 'Manic ranting'
Is Eclipse OpenJ9 a replacement for OpenJDK?
No. Eclipse OpenJ9 is a Java virtual machine (JVM), the engine that runs Java applications, whereas OpenJDK is a complete development kit that contains other components, like the Java class libraries, as well as a JVM. By default, OpenJDK builds with a JVM called Hotspot. Put simply, OpenJ9 is an alternative JVM that you can include as part of an OpenJDK binary.
Is Eclipse OpenJ9 the same as Hotspot?
Hotspot and Eclipse OpenJ9 are both Java virtual machines that can be included in an OpenJDK build, but each has different capabilities. Depending on the build process you follow, you can build an OpenJDK binary that includes either Eclipse OpenJ9 or Hotspot.
Why use Eclipse OpenJ9 instead of the default JVM?
If you are looking for an enterprise class runtime environment for your application, build OpenJDK with Eclipse OpenJ9. This high performance, scalable virtual machine is at the core of many IBM enterprise software products, so it has a great pedigree.
You can also tune OpenJ9 to further improve the performance of Java applications for specific scenarios. For example, you can switch garbage collection policies to manage memory for different types of workload.
Why did IBM contribute their J9 virtual machine to the Eclipse Foundation?
IBM is publicly committed to bringing innovation into the open source development community. Contributing the J9 virtual machine, which has been at the core of IBM SDK, Java Technology Edition for many years, demonstrates that commitment. The OpenJ9 virtual machine is itself based upon core technology components of the Eclipse OMR project, which was contributed by IBM to the Eclipse Foundation in 2016. IBM continues to invest resources in both Eclipse OpenJ9 and Eclipse OMR to ensure that their enterprise products can take advantage of the latest hardware technologies.
You clearly don't know C++. These days we use smart pointers, which have almost no overhead, and easily avoid memory leaks and memory management. We also use the STL data structures and algorithms, which have excellent performance. C++14 and C++17 are better than Java in pretty much every way.
These days we use smart pointers, which have almost no overhead, and easily avoid memory leaks and memory management
The C++ standard library provides two kinds of smart pointers (ignoring weak ones for now): std::unique_ptr and std::shared_ptr. The former doesn't have 'almost no overhead', it has exactly no overhead, because the entire implementation is optimised away. The latter; however, can have significant overhead. C++ relies on deterministic destruction and so none of the techniques that are normally used to optimise reference counting can be used: as soon as the last std::shared_ptr to an object is destroyed, the object must be destroyed. This means that every copy of a shared_ptr is an atomic increment and every destruction is an atomic decrement. If the object is not shared between threads, then this is very cheap, but if it is (even if the object itself is immutable) then each pointer copy and each pointer destruction can have around a 300-cycle cost (plus the cost of the branch in the destroy case). This can add up quite quickly. In contrast, a language with a tracking collector can make most pointer manipulations as cheap as bare pointers. In terms of throughput, tracing GCs scale a lot better to multiple cores than this kind of atomic reference counting, though they trade some worst-case latency for this (which can be a problem in distributed systems).
I am TheRaven on Soylent News