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.

7 of 179 comments (clear)

  1. OpenJDK no JIT? by Anonymous Coward · · Score: 5, Insightful

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

  2. Re:Why Java? by MightyMartian · · Score: 4, Insightful

    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

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  3. Re:Why Java? by AlanObject · · Score: 3, Insightful

    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.

  4. Re:Why Java? by spiritgreywolf · · Score: 2, 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.

    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.

    --
    Never have a philosophy which supports a lack of courage
  5. Re: Why Java? by MightyMartian · · Score: 1, Insightful

    is this an all or nothing kind of thing? Sure, if I wanted pure OOP, I'd look at Smalltalk. But what I'm looking for is a language built on OOP principals, even if not fully object oriented (ie. possesses non-object primitives), with a large set of libraries. Java and C++ are close enough to that that I can live with them not being pure object oriented languages.

    I'm picking a tool set, not a religion.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  6. Re: Why Java? by Anonymous Coward · · Score: 1, Insightful

    C is an abomination designed by an NSA contractor in order to generate lots of buggy software to be subverted by NSA malware.

  7. Re: Why Java? by Anonymous Coward · · Score: 0, Insightful

    C and C++ Code from a seasoned EXPERT (not a junior developer) *can* (if so desired) be highly portable.

    And it will be at least two times more RAM-efficient than competing Java code. It *can* (if so desired) be real-time capable, unlike Java code using the standard library or similar libraries (because of heap memory and the garbage collector which stops the entire program for seconds or more).

    With C++ you can finely control the allocation and de-allocation of RAM, file handles, buffers, sockets, window resources etc. With Java, you never know when it will be "garbage collected". See the RAII pattern, which is very powerful and elegant.

    Java is full of waste and basically a tool for junior people, who would run into "memory cancer" issues with C++ rather quickly.