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.
Are you saying that OpenJDK doesn't have a JIT compiler? That seems untrue.
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.
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.
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