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?
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."
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.
Python isn't dead, but it was gravely wounded by the Python 2/3 debacle. (Python 3 is backward incompatible with Python 2, without actually fixing any of the big problems with Python 2.).
A lot of people still use Python because of the huge library ecosystem. However not many new projects are being started in Python today. The quality of the community has also dropped precipitously as good developers jumped ship and the code monkeys piled in.
Golang, otoh, is alive and doing very well. Docker, Kubernetes, Terraform, Etcd, and Prometheus are a few of the high profile FOSS projects written in Go. Many talented folks who jumped ship from Python are now Gophers.
If I look at job openings in my market, Tulsa, there are as many Java jobs as C# and Python put together. Only a handful of C/C++ jobs--I say this as a 25+ year C++ developer. I would say that if demand means anything, Java is far from dead.
Try doing anything that involves robotics. Or OpenGL ES. Or pretty much anything that involves I2C, reading sensors, or parsing binary data files (like NEXRAD radar sweeps).
After a few hours of having every. goddamn. math. operation. turn into shit like someValue = (byte)((someValue * 2)&0xff);, your brain just turns to jello & you start to forget things... do I have to do the 'and' THEN cast? Cast then 'and'? Do multiple 'ands' throughout the operation THEN cast? Eventually, it starts blurring, and you end up with stupid errors that the compiler won't catch, because the whole reason those stupid errors happened is because the compiler made you play stupid fucking games to try and outsmart it so it would ALLOW you to deal with 8-bit unsigned values.
Clarifying my lambda comment... When you're reading an anonymous class declaration, you know:
1. The name of the Interface the class is implementing
2. The name of the method being implemented.
3. The names of the arguments, in addition to their types.
With Java lambdas, #1 and #2 both end up getting stripped away.
Here's an example taken straight out of Ken Kousen's book, "Modern Java Recipes: Simple Solutions to Difficult Problems in Java 8 and 9"... chapter 1, pages 4-5:
The traditional, human-readable approach:
File directory = new File("./foo");
String[] names = directory.list(new FilenameFilter() {
@override
public boolean accept(File dir, String name) {
return name.endsWith(".java");
}
});
Reading it, we can immediately see that we're calling directory.list with something called a FilenameFilter(), which has a single method named "accept" and takes a File object called 'dir' and a String called 'name', then returns a boolean. It doesn't take a genius to figure out what it does, EVEN IF you've never used a FilenameFilter in your life and have no idea what it does. Between the interface name, the method name, the argument names, and the code inside itself, it's BLATANTLY obvious what it does.
Now, consider its Lambda equivalent:
File directory = new File("./foo");
String[] names = directory.list((dir,name) -> name.endsWith(".java"));
OK, we're calling directory.list and... er... um... WTF?!?
Yeah, this is a somewhat trivial example that most people could figure out, but now imagine that you're using Lambdas with a more obscure interface that the person reading the source ISN'T already intimately familiar with. Or, god forbid, calling a lambda with lambdas as arguments, then chaining it to another lambda (yes, I've seen those). God fucking HELP you if you have to try and untangle a mess like that by hand with nothing but printed sourcecode and Google to help you. It entails something like this:
1. Figure out what kind of object 'directory' is. Remember, in a real program, it won't necessarily be declared one line away. If you're lucky, it's either declared within a screen or two of where it's used... or near the first few screens of source near the top. Unless, of course, it's a static class that's defined within another class definition, in which case it might be somewhere around line 2400.
2. Figure out what kind of objects 'dir' and 'name' are. Once again, remember... real life won't always be as trivial as this example. Happy hunting!
3. Humor me, and pretend that File is a class in some thirdparty library you've never heard of, and you now have to find its javadocs & figure out what kind of arguments File.list expects. Remember, parametric polymorphism. And inheritance, since there might be additional variants declared in the superclass.
4. OK, so, eventually, you figure out that File.list has a variant that takes a FilenameFilter object. Go look up FilenameFilter, and pray to every deity you can think of that you'll find an interface that has a single method that takes a F
Javascript, Python, vbscript and a number of other scripting languages are to programming like a tricycle for kids is to a long haul truck. You can get to the goal, but you will hit a number of snags and it takes time to find coding errors that a full-blown fully type-safe compiler would have found.
With many scripting languages you find the typing faults at runtime and not when compiling.
But if you want some small isolated functionality maintained by a single programmer and it's only something around 100 lines of code then a scripting language is sufficient.
Scripting languages suffers from the same limitations as Basic did in the 80's - a great instep, but prone to 'bit rot'.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
At a job interview a few weeks back (embedded), they showed me another team's product--cross platform app development for ios/android/pc/mac and it was all C# with Xamarin. If it's sufficiently cross-platform for companies to use for their products, it's probably not that limited.
I know lots of companies for which Java is a major part of their infrastructure. I have never heard of anyone ever paying for Java. "OpenJDK is the official reference implementation of Java SE since version 7." See https://en.wikipedia.org/wiki/...
It is the PL/1 of the web era.
I disagree, it's the COBOL of the web era. It's hugely popular, very verbose, not particularly fast (it can be, but easiest ways to write code in Java don't tend to perform well) and the go-to choice for business logic. And, no matter how much you may dislike Java, be thankful for every organisation it got to move off COBOL...
I am TheRaven on Soylent News