Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Java IBM

IBM Open Sources Their Own JVM/JDK As Eclipse OpenJ9 (eclipse.org) 179

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.
This discussion has been archived. No new comments can be posted.

IBM Open Sources Their Own JVM/JDK As Eclipse OpenJ9

Comments Filter:
  • OpenJDK no JIT? (Score:5, Insightful)

    by Anonymous Coward on Sunday September 17, 2017 @10:38AM (#55213919)

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

    • Re: (Score:3, Informative)

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

  • Why Java? (Score:5, Interesting)

    by Anonymous Coward on Sunday September 17, 2017 @10:45AM (#55213943)

    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? (Score:5, Insightful)

      by MightyMartian ( 840721 ) on Sunday September 17, 2017 @10:53AM (#55213975) Journal

      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

    • by Anonymous Coward

      So I do around 80% of my development in C for embedded systems. When doing user interfaces I do JavaScript AJAX-style web interfaces because I find it easy and people already have a browser. But every now and then I need to do a more "IT" type system that involves a database and server (but often talking to my embedded systems software). When I get tasked with something like this I choose Java servlets because there are some good tools in Java for doing this.

      So yeah, Java GUI apps are dead. JavaScript web a

    • Only speaking about server apps in Java... Swing/GUI/applets is a hot mess...

      Java has very good backwards compatibility. We compile our app for Java 7 and run it with 7, 8 and 9. Very few bugs exist when we do a major upgrade... Typically 1-2. For minor versions within the same major release (updates as they're called in Java), we haven't seen a single backwards compatibility issue in probably 8 years.

      Sounds like you're talking about very old versions of Java (version 4 and earlier), or GUI code, w
    • - Portable binaries across all major OSes and hardware platforms.
      - Large standard library which implements nearly everything you need to write a networked application.
      - Threading supported natively.
      - Decent performance.

      A lot of people thus use Java on server-side enterprise apps. The GUI for client apps is abysmal though and some of the APIs are a pointless waste of time. But you can just NOT use those APIs (like EJBs) even if your enterprise clients love them for whatever reason.

    • Re:Why Java? (Score:5, Informative)

      by dshk ( 838175 ) on Sunday September 17, 2017 @12:10PM (#55214229)
      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? (Score:4, Informative)

        by mark-t ( 151149 ) <markt@nerdflat.cTEAom minus caffeine> on Sunday September 17, 2017 @01:50PM (#55214577) Journal

        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

      • by Anonymous Coward

        Can you do us a favor and post this to every /. article that mentions Java in the summary? Or any article about any programming language, for that matter. They all seem to lead to a lenghty discussion on common misconceptions about Java.

      • by hackus ( 159037 )

        Portability is a sorta of a half truth, and doesn't do JAVA justice.

        It is portable INFRASTRUCTURE.

        If you have a JVM you have all sorts of infrastructure available that goes way beyond the language. So for example in the definition you describe portability is limited to the language and compiler output of the binaries for different processors.

        Java goes a couple of steps further, besides a binary its environment defines a consistent portable computer that includes not just portability, but security sandboxing

      • As a language, Java has the huge advantage of automatic garbage collection.

        Except for objects that represent a resource other than memory, which the owner must close() explicitly.

        This is an issue in C, because it must be agreed on who will destroy the returned object.

        Likewise in Java for instances of classes that implement java.io.AutoCloseable.

    • Re:Why Java? (Score:4, Insightful)

      by AlanObject ( 3603453 ) on Sunday September 17, 2017 @12:33PM (#55214301)

      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: (Score:3, Insightful)

        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.

    • by gwjgwj ( 727408 )
      One incompetent programmer who overwrites memory in random places does not ruin the entire program. I think this is the main reason.
    • by HiThere ( 15173 )

      Well, Java's a lot better than C at handling multi-processing. And it's easier to handle most use-cases of unicode strings. It's got a few other minor advantages.

      I, personally, don't like it, but I haven't yet found a language that meets all my requirements. D (dmd) comes quite close, and I'm currently investigating Go. (One of my main problems with D is program documentation...not theirs, but mine. The autogenerated documentation is too ugly.)

    • Because really good programmers are hard to find [joelonsoftware.com].
    • As a C/C++ veteran of > 20 years, one angle is Android.

      That Java mantra got carried into Google at the time and it's locked in now.

      Benefits, portably recompiling (not Java) byte code on demand for 32-bit or 64-bit architectures with improved simd optimizations.

      Backwards compatibility is kept at the in the runtime-compiler, API level instead of depending on the CPU for legacy compatibility (see Intel).

      This predates .NET and only slightly suffers from progressing through the language tweaks from Java 6 thr

    • by pkphilip ( 6861 )

      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 et

    • You can write 90% of the applications with only the standard libraries. In most other languages you would need to use various third party ones to accomplish the same.
    • Because object oriented languages FORCE a measure of readability and organization and preliminary design on the developer, which improves maintainability. It's not just Java, but also C# (the interpreted object oriented languages) as well as C++ (which executes cpu-native code).

      With C, a developer can just start hacking away. "I need a function to do this, lemme write it." Put it in some file, update the makefile, done. Object-oriented languages add the "class" data structure, which is just a (required) wa

    • by jeremyp ( 130771 )

      Well, let's be honest, the whole C language is stuck in the 1980's. There's no automatic memory management. There's no bounds checking. The type system is primitive. There's no introspection. It's GUI UX is not stuck in any decade because it does not have one, nor, in fact, a proper string type.

      Granted, C is more portable at the source level than almost any other language (as long as you have one of those horrible kludges like the GNU autoconf system and you avoid all the undefined an implementation defined

    • I like C. I used it exclusively during the first part of my career and I still use it from time to time. but now I mostly use Java. I like the environment surrounding java (eg maven, JMX, even the stack traces), and the programs are written in java itself, which seems like a strange thing to say, but much of the C code was written in a macro language rather than C per se.

      The verbosity of java is not the problem I thought it would be (maybe I just got used to it) and in general I like the amount of error che

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

      I have been programming in Java since 1997, C since 1985, and C++ since 1999. I have never run into the Java versioning issue you described -- ever -- as long as I have had the highest required Java major version installed.

      As for portability, Java reigns supreme. I have Java binaries I compiled in 1997 that still run, unmodified on all supported operating systems. I write major applications in Java that run in Linux, Windows, and (probably) anything else with a conformant JVM. This includes GUI, busines

    • Java is a crummy language (which did not stop meusi g it for 10 years) but the real key here is the JVM. There are many other good languages running on a very stable and tested server platform.

      As for GUIs in Java, just no. Bad.however, 15 years ago it was a viable choice.

    • Java remains popular in programming classes because of that portability. It means that the TAs will be able to run student code, whether it was developed on Windows, Mac, or Linux. (Universities generally don't mandate ownership of a specific type of computer.) Most programming classes (except for ones that are specifically about developing GUI applications) don't use a GUI so that's not a factor.
  • It's not a JDK (Score:5, Informative)

    by klingens ( 147173 ) on Sunday September 17, 2017 @10:47AM (#55213947)

    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

    • I think IBM used to be a contributor to Apache Harmony? So they basically should have given away all the class libraries they used to have. AFAIK IBM switched to the OpenJDK class libraries after that was open sourced.

    • The original posting is so wrong in so many ways that I am now forced to question whether IBM the company actually exists, since the posting seems to indicate that it does.
    • Entirely correct, though it's worth noting that J9 does look pretty interesting as a JIT. I've reviewed quite a few paper from IBM recently about it that mostly ended up being rejected on the grounds that J9 was an internal IBM thing and there wasn't much reproduceable science in them. IBM seems to be doing quite a lot of research on top of J9. Hopefully, open sourcing it will encourage other researchers to look at it.
  • Eclipse (Score:3, Informative)

    by Anonymous Coward on Sunday September 17, 2017 @10:55AM (#55213985)

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

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

    • by ledow ( 319597 )

      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'

      • 10 seconds? WOW! QtCreator starts and is fully loaded in under a second without cache.

        • by ledow ( 319597 )

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

          However, 10 seconds with a HUGE list of active and open projects in it is barely even noticeable, especially if that's the "uncached, hasn't run once yet this session, from nothing" speed on Windows.

          On Linux (even a VM with identical projects and versions), it's half that at least, from cold.

          Neither are "oh my gosh" slow. The times for anything like SQL Server Manager, or Visual Studio are no better.

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

        • by Gr8Apes ( 679165 )
          I'll bet that QtCreator opening up in < 1s has maybe 1000 lines of code, not 5+ million across multiple cross-dependent projects.
          • LOL @ 1000 LoC. Whoever writes an IDE in 1000 LoC deserves either an award for their brilliance or a new keyboard so that they have a working "Enter" button. ;)

            • by Gr8Apes ( 679165 )
              ROFL... 1000 LoC in the project code it's loading up at startup.
              • QtCreator makes no assumptions about what you will work on, so there are no open projects when launched. Btw, having 5M LoC of interdependent projects open automatically isn't a feature I want.

                • by Gr8Apes ( 679165 )

                  QtCreator makes no assumptions about what you will work on, so there are no open projects when launched. Btw, having 5M LoC of interdependent projects open automatically isn't a feature I want.

                  It may be something you need to work efficiently. So you're really comparing apples and oranges there. How long when you open QtCreator does it take to open your project, be able to view the opened codebase for errors, and have it running a debug test session? With Eclipse, generally, once its done with its 10s opening, you're good to go with 1 click. And remember, you have a lot of code open, static analysis done, toolsets initialized, etc, it's not just a "open project now please" state.

                  • It would be trivial to implement via plugin but that seems like a terrible feature. Why would you need so many projects open all at once upon starting?

                    • by Gr8Apes ( 679165 )
                      Work on enterprise software. The details I can share involve past system projects which included up to 60 library and component projects which built out up to 10 separate servers, clients, and web applications. These were usually installed on sets of servers in HA/HR/HP configurations. When you're working across such projects and need to re-architect some base service definitions and functionality, yes, you absolutely do want that many projects open at once.
                    • No idea what exactly you are working on but it's clearly designed like shit.

                    • by Gr8Apes ( 679165 )
                      It's obvious you lack the experience and vocabulary to speak in this domain, and are only concerned with your own niche, much like a JS web developer calling themselves "fullstack" yet having no clue how to handle continuous levels of 20K transactions a second in a secure guaranteed fashion. (it's irrelevant whether you do, btw) When/if you graduate to large distributed heterogeneous enterprise systems, we may talk again. You won't be running QtCreator then.
    • If it really takes that long, go grab a cup of coffee, run to the restroom, or do any other number of small mundane tasks that are going to occupy your time at some point in the day while the IDE starts. If stating the IDE truly takes that long on your machine and you're not just being hyperbolic, compiling is going to eat up even more time in which case you probably need a new machine.
  • If you want an ISC licensed jvm, there is https://github.com/ReadyTalk/a... [github.com].
    IIRC avian has its own class library or it can use OpenJDK or the Android class library.
  • by kwerle ( 39371 ) <kurt@CircleW.org> on Sunday September 17, 2017 @02:12PM (#55214693) Homepage Journal

    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.

  • 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?

PURGE COMPLETE.

Working...