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:

• "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?

Comments

Re:Security is a lot of why it's dying

[phantomfive]

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.

C# has unsigned bytes

[Miamicanes]

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.

Re: What?

[astrofurter]

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.