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.

Comments

OpenJDK no JIT?

[Anonymous Coward]

Are you saying that OpenJDK doesn't have a JIT compiler? That seems untrue.

Re:OpenJDK no JIT?

[Anonymous Coward]

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.

Re: OpenJDK no JIT?

[red_dragon]

No way an OBDS has a four-digit ID. I'll have you know that I have a two-story residence, thankyouverymuch.

Why Java?

[Anonymous Coward]

Not intended as a troll, but a sincere question of a C-veteran of soon 20 years: why do people use Java?

To block the only apology I've heard so far - "portability": way back when (10 years or so?) Java-applications were a major PITA to install, as they needed Java version X.Y.Z; every last digit significant. It seems that these days applications have fixed this by shipping the entire Java run-time in the installation package. So the applications are not portable even between the language implementations.

Why not to use Java? The GUI UX seems to be stuck in the 1990's, and language has (at least to me) something offputting in its syntax.

So why do you choose java for your next project?

Re:Why Java?

[MightyMartian]

Most of the Java code out there isn't GUI code, and yes, high portability is one of the major reasons. And honestly, I have compiled code written 15 years ago that still runs on newer JVMs

Re: Why Java?

[Lothsahn]

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.

Re: Why Java?

[MightyMartian]

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.

Re:Why Java?

[dshk]

I have used C and mostly C++ for 10 years. Java for 15+ years, full time.

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.

Re: Why Java?

[MightyMartian]

And what "complexity" is that? You're not going to write device drivers in Java, that's for sure, but modern Java is pretty capable whether it's desktop apps or, where it's used more often, in enterprise solutions, which is why the big guys like IBM use it.

And what's wrong with abstracting the architecture. One of C's original intentions was portability, and a lot of that was done by porting over libc to as many platforms as possible so all the system calls of the operating system in question were, well, abstracted. Java's just further down that road.

And OOP has been with us for over thirty years, and while not suitable for every problem, is still a pretty rock solid way to solve a lot of problems. That's why people went out and developed c++ and Objective C, and why most of the other modern iterations of earlier pre-OOP languages have had OOP extensions for a couple of decades now.

Re:Why Java?

[AlanObject]

The question of "why this or that language" comes up often and my stock answer is as follows:

To me the specific language is irrelevant. The reason you use a given language is because a given framework, class library, or function library is written in it and that body of proven work is the best for whatever application you are pursuing.

The criteria of what is "best" can vary. However as a project manager I place a high weight on what my team (which may be only myself) is familiar with. So if your boys and girls are crackerjack with Django idea-to-deployment-in-3 days then Python it is. Staid old JavaEE types invariably end up with -- well Java. If you are doing a reactive or SPA web-app you will end up with Javascript. Instrument control? Learn TCL.

Another highly-weighted criteria is what the available frameworks are that are most suitable for the application. I remember back decades where if you wanted to control telescopes for astronomy the choice was FOCAL for some reason. I wonder if that is still the case but I doubt it. And for some bizarre reason MUMPS was the base for many hospital/healthcare based apps.

Too many people dwell over the merits of C vs. C++ vs. C# vs. Java vs. Python vs. Ruby vs. Javascript vs. Swift vs. what-ever-the-cool-thing-is-today. The arguments go on forever repeating the same points over and over and they are meaningless.

Any halfway competent software engineer can pick up a language they have never used before in a few days max. It is the libraries and frameworks that have the real learning curve. So keep on using C if that is what you are used to -- but not if you get a project where you find yourself writing a new framework that has already been done, tested, and deployed in another language. Then just suck it up and learn that language. You might surprise yourself with how enjoyable it is.

Re: Why Java?

[MightyMartian]

Because coding in Perl is like having a root canal. Perl may run on more platforms than Java, but I hate programming in Perl. And Python brings nothing to the table that Java doesn't already have, so why should I bother?

Re: Why Java?

[K. S. Kyosuke]

Java beats C hands down in portability.

I think that well-written C code, such as, e.g., Lua, is really portable. It compiles everywhere, even into freestanding environments.

Re:Why Java?

[mark-t]

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.

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

Re:Why Java?

[spiritgreywolf]

The bottom line is that it's picking the right tool for the right job.

MUMPS though still alive in Open Source fashion has been pretty much taken over by Intersystems and re-branded/extended called "Cache" and the language "Cache Objectscript". At it's core it's still an awesome language for manipulating persistent sparse arrays and includes easy methods of exposing pretty much any data hierarchically as well as SQL projections, and has the ability to talk to Java, .NET, C, C# and just about everything else.

At the time of its inception, it was built to "fiscal edge" needs, not "bleeding edge" needs - as MUMPS ran on pretty inexpensive hardware and could do things with massive amounts of clinical data faster than most other languages at the time. It's what Epic (a giant Hospital Information System implementation at most hospitals anymore) runs on, including Indian Health Services RPMS and VA's VistA (not saying much as both of those behemoths could use serious re-engineering - but they work)

You're right though - I couldn't give a rats ass what the framework is - does it fit the job? Is it maintainable? Does it make sense? And if my developers all walked out or committed mass suicide to reach some comet in the sky, could I bring in people that could pick it up and support it?

"Wicked Cool" are not words I ever want to hear with respect to code that is running in production. I want safe, supportable, accurate, responsive. If I get paged at 2AM in the morning to fix something that broke, and that's after I had a couple margaritas celebrating a friends birthday the night before? If I cannot read that code, debug it, figure out what is going on and get it working rapidly, then someone did NOT do their job right and deploy code that is easy to maintain. I do not want to have to jump into stack traces going "What the F**K was this guy trying to do?!" because he thought it was cool and witty at the time. Save that Perl-esqe obfuscating bullshit for your Github-based personal projects. That kind of shit would never pass peer-review.

I used to come across "JavaEE is the answer to EVERYTHING in Healthcare" like bloated engines sitting on top of Glassfish and Tomcat. it was goddamned ridiculous (still is). And when a real-time message went "boom" someplace in the architecture, it took a team of onshore and offshore ass-hats just to find the problem? Your solution sucks ass. Period. I know of a very large healthcare entity that still uses IBM Websphere and ESQL that requires many DOZENS of people to support and has the responsiveness to change like glacier made of tungsten. And of course dropping millions into keeping it going because nobody wants to admit they totally fucked up and didn't keep up with the times? It seems the choice of architecture is sadly more of a political one than one of technical correctness.

Re:Why Java?

[pkphilip]

Java is excellent for some scenarios such as the development of server-side applications, webservices and so on. For stuff such as desktop GUI development, C/C++/.NET etc may be better options.

Apart from that, Jave has the following advantages:
Excellent portability
Automatic garbage collection
Huge collection of excellent libraries accessible via well-organized central repositories via build tools such as maven, gradle and so on
Dependency management is lot easier if you use build tools such as maven/gradle etc
Huge numbers of competent developers

Re:Why Java?

[MightyMartian]

There have been plenty of insecure frameworks built in all the major languages, and thus far has anyone proven that Struts was the source of the hack?

Re: Why Java?

[Anonymous Coward]

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.

Re: Why Java?

[Gr8Apes]

Why do you ignore languages like Perl, Python, and even Tcl

Because Perl doesn't even consistently compile itself in different versions on the same platform, and writing anything interesting in it beyond a mere utility script would be like performing your own root canal. Python I've never actually seen used in the enterprise, hence 0 reason to use it. Maybe smaller projects use it, I don't know, nothing I'm paid for utilizes it. TCL, people still use it? Haven't seen any development in that in more than 15 years. Might as well ask about fortran or SQL. Oh, right, neither of those are portable either unless you meet a bunch of criteria both in your coding and in your platform/compiler selections.

Re: Why Java?

[Zero__Kelvin]

You just contradicted yourself. Java can't beat C for portability, and be unavailable on a vast number of systems. C is FAR more portable than Java. The Linux kernel supports more than 30 hardware architectures, for example. What you mean is that Java ships with Middleware (i.e. the JVM) that makes it run unmodified on a few different Operating Systems. It isn't more portable by any stretch of the imagination.

Re: Why Java?

[Espectr0]

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.,

Having C available on every platform is portability for some people. Regarding that metric, C beats Java easily.

Re: Why Java?

[TheRaven64]

Java beats C hands down in portability.

That's not really a fair comparison. The C specification defines a language and a very small standard library. The Java specification defines a language and a huge standard library. For anything where Java is an appropriate choice, you're not going to be writing C and relying on just the C standard library, you're going to be using some third-party toolkit that, like the Java standard library, abstracts away a lot of platform independence.

Even then, I'd disagree. Java is good for portability if you're using one of the common platforms, but the further you get from that, the more patchy it becomes. Try running Java on OpenBSD / MIPS (actually, try running Java on any OS on 64-bit MIPS - the only implementation that mostly works is JamVM, and it's a simple interpreter that doesn't support the latest version of Java) and you'll find that the portability isn't quite as good as you might think.

Java is portable to any platform that the JVM and standard library have been ported, but the same is true of most languages: they'll run on any platform where the compiler and the libraries that you're using have been ported. The difference with Java is that it tends to be an all-or-nothing proposition. You aren't allowed to ship partial implementations of Java (the patent grant on the various bits of Java only extends to fully conforming implementations) and so you're unlikely to find a subset of Java that does everything (or almost everything) your program needs working on a platform, whereas you often will with other languages.

Re: Why Java?

[TheRaven64]

C++17 is pretty much my go-to language these days, but this is just plain wrong:

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).

Re:Why Java?

[TheRaven64]

No dirty macro preprocessor

Unfortunately, no macro preprocessor or templating system at all which means that everyone invents their own. I've seen Java code that had sed, awk, Perl, Python, and Ruby as preprocessing steps (and a few projects that used more than one).

Re: Why Java?

[pkphilip]

You are arguing that java should not be used because one of the dozens of mvc libraries had a security issue? That is similar to saying operating systems should not be written in C because operating systems written in C have had security vulnerabilities in the past

Re: Why Java?

[K. S. Kyosuke]

Designing a new language to solve a particular problem domain is the ultimate technique in programming and isn't generally shunned.

Re: Why Java?

[Beezlebub33]

As a java developer, I have found that python libraries for machine learning, scientific computing, and numerical processing are much better. Numpy / scipy, scikit-learn, and the like are truly amazing, blazingly fast, and the ability to do terse matrix slicing and dicing is so much more efficient. And Jupyter makes it into a live web-based analysis and visualization tool. Almost like magic.

I still do most of my development in java, I understand the ecosystem better, can control the dependencies better (gradle FTW), can make a much larger application, better unit and integration testing, code coverage, can throw it into Tomcat and manage it, can do auth/auth in standard ways, etc. But if you are doing math, python beats its pants off.

It's not a JDK

[klingens]

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

Eclipse

[Anonymous Coward]

The IDE where the startup time is measured in geological time.

I've seen glaciers move several feet while Eclipse started up.

Re:Eclipse

[ledow]

Start... Run... Programming... Eclipse... Eclipse
(Yes, I use classic shell and old-fashioned start menus categorised and in alphabetical order).

1...
2...
3...
4...
5... (Splashscreen)
6...
7... (loading huge default-open project)
8...
9...

Loaded.

That's from a REALLY cold filesystem cache for it, I doubt it was in there at all.

Libreoffice comes up in 4, admittedly.

But Steam takes longer, as does a game called Factorio (to get to the MENU!) as does anything complex.

I wouldn't call it "long". And if it worried me, I'd just leave it in the background - I already never log off because... what's the point?

And that's on Windows. On Linux, it's so much faster.

Re:Eclipse

[Gravis Zero]

My virtual-speed-penis is obviously not as big as yours.

Whoa there buddy. I was just pointing out that 10 seconds is a really long time for software to start in 2017.

The times for anything like SQL Server Manager, or Visual Studio are no better.

Yeah, Microsoft has always been slow at everything. Desktop computers are lightning fast, so 10 seconds is far too long an amount of time to launch any program.

F U /. for such a crap summary

[kwerle]

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.

Lost the fox, you have..

[LesserWeevil]

When IBM out-maneuvers you on one of your core technologies, you've lost the fox. Hey Larry, what part of Sun have you not pissed away?