Slashdot Mirror
Ask Slashdot: How Dead Is Java? (jaxenter.com)
This week HackerRank reported Java is now only the second most popular programming language, finally dropping behind JavaScript in the year 2018.
Now long-time Slashdot reader shanen asks about the rumors that Java is dead -- or is it?
Can you convince me that Java isn't as dead as it seems? It's just playing dead and will spring to life?
This week one Java news site argued that Java-based Minecraft has in fact "spawned a new generation of Java developers," citing an interview with Red Hat's JBoss Middleware CTO. (And he adds that "It's still the dominant programming language in the enterprise, so whether you're building enterprise clients, services or something in between, Java likely features in there somewhere.") Yet the original submission drew some interesting comments:
Now long-time Slashdot reader shanen asks about the rumors that Java is dead -- or is it?
Can you convince me that Java isn't as dead as it seems? It's just playing dead and will spring to life?
This week one Java news site argued that Java-based Minecraft has in fact "spawned a new generation of Java developers," citing an interview with Red Hat's JBoss Middleware CTO. (And he adds that "It's still the dominant programming language in the enterprise, so whether you're building enterprise clients, services or something in between, Java likely features in there somewhere.") Yet the original submission drew some interesting comments:
- "The licensing scheme for Java kills it..."
- "Java programs still are 'the alien on your desktop'. They suck in many ways. Users have learned to avoid them and install 'real programs' instead..."
But what do Slashdot's readers think? Leave your own answers in the comments.
How dead is Java?
It's alive and well server-side. It's dead on the desktop because it's dreadful, slow, memory-hungry and extremely annoying each time Oracle forcibly imposes things that break legacy applications.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
No. Oracle killed Java.
It's dead .. in that it's now the NUMBER TWO MOST POPULAR LANGUAGE IN THE WORLD?
Wow. Perhaps my understanding of the meaning of "dead" is misinformed.
The commentary here seems to center around Java as a language for desktop applications or similar.
It's not. It hasn't been for decades.
Java is used mostly to make enterprise-class server-side software. It's used extensively in the financial services sector.
Most of the code for any FI's web applications you interact with is Java. And so is all of the backend code.
And it's not going anywhere in that space.
That's a little bit like asking "is Linux dead?", simply because it's not a popular desktop OS. Just because the majority of users don't realize they're interacting with something, doesn't mean it's not widely used. In the case of Java, the Android platform is a major client-facing deployment. However, the majority of enterprise and webservices are still Java/Java EE and that application is growing, driven by the move to the cloud and the popularity of microservice architecture in new enterprise installations.
JavaScript obviously is a bit deal too, given the increasing importance of heavy client-side web-apps. But most of those webapps have Java on the back end.
Between it's different versions, the security problems this brings, etc., it's dying fast in the professional environment
What security problems come with Java?
I don't see a lot of JSP servers, either
JSP is legacy now, but a lot of companies are using Java on the backend in a web services model. The frontend can be in Angular, or React, or whatever. It's a good choice when you want stable, cheap developers.
As my own professional opinion, I would say that Java is better for writing backend APIs than Node/Express.
"First they came for the slanderers and i said nothing."
[quote]“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Bjarne Stroustrup[/quote]
Not sure why there's comments of licensing issues... it's a free download from Oracle's website
Well the issue is complex if you stick to Oracle provided binaries, the TL;DR simple answer is to move on to OpenJDK and be done with it.
Java SE 8 which was the last version you could "freely" use in a commercial product, if you go to Oracle's website at the moment, you'll get this message.
Oracle will not post further updates of Java SE 8 to its public download sites for commercial use after January 2019. Customers who need continued access to critical bug fixes and security fixes as well as general maintenance for Java SE 8 or previous versions can get long term support through Oracle Java SE Subscription or Oracle Java SE Desktop Subscription. For more information, and details on how to receive longer term support for Oracle JDK 8, please see the Oracle Java SE Support Roadmap.
Going forward you now have two options. Oracle OpenJDK which is an open source JDK that you may use as you see fit, the end. Oracle JDK, which starting at version 11 is Oracle OpenJDK plus some Oracle enhancements. You may freely download Oracle JDK and use it for development and testing, however, Oracle JDK cannot be used for production or commercial use without being anally raped by Oracle, so yeah you cannot download Oracle JDK and just use it without being in some degree of violation of Larry Ellison's 37th yacht fund somewhere in the fine print of that download. Additionally, Oracle has gotten a little blood thirsty lately so use Oracle JDK without a license at your own damn risk.
So you might ask, so if we have OpenJDK, who would want Oracle JDK? The important thing to remember that OpenJDK provided by Oracle is Oracle's build of OpenJDK, which may or may not have all the most recent patches. Basically, Oracle's OpenJDK is on par patch wise the day a new version hits with Oracle JDK. So when Java 11 hit, that day Oracle JDK and Oracle OpenJDK were functionally the same. However any patches that Oracle JDK has received since that day, Oracle OpenJDK hasn't or might have, it's basically "meh we patch it when we patch it." However, Oracle isn't the only game in the OpenJDK build world.
Here's a post about all the different folks building OpenJDK. I suggest OpenJDK from AdpotOpenJDK or if you are using Linux, BSD, Unix, etc Just use the OpenJDK that your vendor provides, they usually keep it reasonably up to date. What the change does do, is make everyone change their old habit of just going to Oracle's site, download their JDK, and go from there. Instead, just go grab a non-Oracle build, beside we shouldn't be frequenting Oracle anyway.
Outside of that, Java is still Java and unsurprisingly Oracle is still shooting themselves in the foot. The most recent move with Java 9, 10, and 11 only further cements folks' decisions to leave Oracle as their provider of a Java implementation.
Emotionally, Java died for me the day I discovered that C# has real, honest to god unsigned bytes. You have to be masochistic beyond words and the world's ULTIMATE glutton for punishment to attempt programming OpenGL ES using Java, because GLES does EVERYTHING by juggling around byte arrays, and dealing with raw unsigned bytes in Java is pure misery.
It's no secret that 'unsigned bytes' are one of (if not THE) most-requested features in the history of Java. And the one that evokes the angriest ideological debates, often getting it called 'syntactic sugar' (as if providing a language construct to avoid having to do things known to create STAGGERING numbers of insidious code errors due to typos is a morally-decadent thing).
Personally, I love how some people get all righteous about calling unsigned bytes 'syntactic sugar', then proceed to defend dumping six pounds of 'syntactic salt' into Java in the form of the way Java now handles lambda expressions.
Lambda expressions per se aren't necessarily a bad thing. Pretty much every major language now has them. But the specific WAY they were implemented in Java is an abomination. Put bluntly, they're basically "human-compiled" object code PRETENDING TO BE actual source code.
For anyone who doesn't understand what I just said, here's an alternate explanation. Basically, when the Java compiler sees a Lambda expression, it recursively searches through the list of interfaces known to it until it finds an interface that defines a single method whose arguments match the types of those used by the lambda. It takes the compiler (or IDE) a fraction of a second to do a brute-force search through the API to find a match. Humans, unfortunately, aren't quite so agile at things like that, which is why we invented source code in the first place 50 years ago.
Behind the scenes, the compiler is just automatically assembling an anonymous class that implements the interface. And if you had the sourcecode TO that anonymous class in front of you, making sense of it would be easy. The problem is, Java's lambda syntax strips away most of the contextual information that the anonymous class would provide you with, so you're left trying to make sense of a cryptic glob of punctuation characters that makes obfuscated Perl look like Ada or Visual Basic by comparison.
The end result is that if I write a nontrivial program using Java lambda expressions, print out a method, and hand it to you, there's a VERY high likelihood that you'll scratch your head and be completely unable to make sense out of it without at least looking back at the includes near the top, and probably a few minutes with Google. In contrast, if those lambdas had been printed in the source AS anonymous classes implementing the same interface, you'd probably be able to effortlessly make sense of them without a second thought. And that's what's fundamentally wrong with Java Lambda Expressions, in a nutshell. They optimize the wrong problem, and result in sourcecode that's human-unreadable.