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?
Not as dead as this laaaaarge portion of popcorn I'm making.
[sits back]
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
So that Oracle can get butt fucked by their decision to be so consumer unfriendly when it comes to their policies on Java.
Has Netcraft confirmed it?
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.
That seems to be the only "dead" part of Java, the idea that you can actually use it without Oracle screwing you over.
We've moved to OpenJDK for all production systems, and that sidesteps Oracle entirely.
- Vincit qui patitur.
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."
It's still populated by 141 million people and it's been a while since the last gigantic eruption, so it ain't dead at all.
The thing I've recently heard about Java is that you are subject to Oracle's random whims. Right now, you can get and use the runtime environment and development environment for free, but you don't know if they will randomly decide to charge you a ton of money to use it and send an army of lawyers after you.
Use OpenJDK. Problem solved.
"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]
I have to second this option. Java isn't "dying"...it's 2020's Cobol.
It'll be around for at least the next 10-20 years. (There's that much code based of Java out there)
But Java has been dying for years. Applets died a long time ago. JSP and Servlets are pretty much dead in favor of using a JavaScript front-end and a proper application back-end. JDBC will continue to hold java for a number of years...but watch as other languages start taking it's place. Hell, Docker killed Java's last remaining strength - write once, run anywhere. With Docker, everywhere became X86-64bit.
I don't expect C# to do well either.
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.
Java has an image problem, not due to the fact its desktop frameworks look ugly but also that it looks ancient as object-oriented programming, licensing and performance trends go. It has a public relations problem, but for those that are in the industry, its pretty obvious its life-support system is alive and well.
If you look outside the desktop, Java is fine. As previously stated, Java is core to business players - it serves a central purpose in many middleware, server and database-related solutions. Then there's the fact that Oracle is its owner and major sponsor, and RedHat closely behind it both maintain its momentum, while its essential role in the world's largest mobile platform accelerates it. Some will say even in Android Java is faltering, but Kotlin avid programmers know full well that, like Kobol and other tech in critical applications, Java will take decades to be detached from Android. The same can be side about the businesses solutions where it is central.
So while Java's core language development might stall in favor of supporting cooler, "du jour" paradigms that act as stepping stones for new players to have something fresh to stand upon, the JVM and its many clone runtimes are here to stay. And while languages that code for them keep basing themselves off of Java for bytecode endgame, so is Java.
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.
I'm sorry, are you unaware of .Net Core?
Available on Windows, Linux and Mac.
Available on x86 and ARM.
Free to use.
Free to change.
Get and fork it top to bottom on GitHub with a open source standard permissive license.
Or are you still stuck in the days of "hate MS at any cost"?
I work for a company that uses .Net Core for all its software development. We dev on Macs, deploy on Linux in Docker containers, and pay Microsoft *nothing*. We are the largest travel company in the Southern Hemisphere, and we have partnerships with the largest RV manufacturers in the world.
But don't mind us, we are just proof that your beliefs are out of date.
Somehow, Java became screaming fast and/or Lucene manages to avoid all the parts of Java that are screaming slow. Therefore Elasticsearch. Therefore that's one very good reason that Java won't go anywhere right away.
Also, despite the existence of obviously saner alternatives like REST, many enterprises use Java as a standard for service bindings. Long ago lost to the sands of time is the original intent that XML was intended to be human-readable (in the sense of not needing binary decoding) but not human-written.
I wrote a lot of semi-interesting Java in the past, and I suppose there was a time when I liked it, but I can't see that time coming again. Java is annoying. It's that grumpy, square, didactic, great uncle whose clothes haven't been updated since the 70s and whose house smells musty and who tells you about how he took no shortcuts in his life and you can't either.
Python is annoyingly gimpy (what sort of interpreted language deliberately doesn't have closures and first class functions?) but at least you can write a command-line tool in it, and maybe some day it'll be fast too. I guess dumbed down is better than a smelly old uncle.
Maybe I'll get to write some Rust soon.
If you poke something, it must be BASIC.
Why is Snark Required?
Every platform is eventually a dead end platform.
The .NET Framework is kept constantly up to date by Windows Update. It might be nice if Java was a Windows "Feature"
Perhaps you have forgotten history. Microsoft had a JVM. Then they did weird stuff to it which was not quite compatible with other JVMs, and they still wanted to call it "Java". They got sued and lost, and they could no longer play their Embrace-Extend-Extinguish game with Java, so they invented .NET to compete with Java instead. Sun went down the toilet bowl, and Oracle hasn't really even tried to keep Java current, so now .NET beats Java like a piece of meat.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Literally everything that you said in that post is wrong. In terms of being very similar to Java, here are a few differences:
As to the var thing, this is simple type inference. It is roughly analogous to C++11's auto. It's nothing to do with Visual Basic, it's more important for things like LINQ, where you end up with complex types that depend on the value of an expression and you don't want to force the programmer to write them explicitly. In these cases, var lets you bind variables to values of anonymous types. The code is still strongly statically typed.
I am TheRaven on Soylent News