[Disclosure: I haven't used Java professionally for a year but I had worked with it continuously for the 20 years before.]
This is going to appear like a collection of random thoughts, but please bear with me.
Let's start with the easy stuff, client-side Java.: just no. It's always been clunky but had the advantage of a relative ease of multi-platform distribution. Note that this was an amazing feature nothing else would match at the time. However it was also hideously insecure and instead of fixing it, they nuked it. And without that, only the clunk remains.
Verbosity is an issue but not as big as it's made out to be, at least in the long run: while it steepens the initial phase of the learning curve, once you're up and running and use a modern IDE, it makes little difference.
A thing often overlooked is the Java Language Specification. It's a tremendous asset. There is great value in being able to reach back to a formal definition of every language structure that is only appreciated when you start working in a language without one. However, if you know the JLS inside out, you will also be aware of where holes had to be cut out to accommodate new features. And the number of these holes is growing.
The fact you can take a piece of code written and compiled 10 years ago and run it now is a double-edged sword. Compared to the here-today-gone-tomorrow nature of JS libraries, it definitely feels nice to have some kind of longevity (especially in a corporate environment), but it comes with a price that gets heftier with time (see also: holes in JLS).
Another thing worth mentioning is that the Java language and the Java VM are two increasingly separate entities and as far as I'm concerned, the VM should be made the flagship product (if it hasn't been already).
So why else would you not choose Java? Well, Oracle. And not just Oracle in general.
The "new" release cadence seems to have created a "worst of two worlds" chimera: features aren't getting implemented much faster than before but licensing and support have become much more complicated and seemingly designed to discourage people from wanting to work with Java. I haven't got anything more to say on this other than if you do use Java, try to pretend non-LTS releases are simply overnight builds: fun to play with but shouldn't be anywhere near production.
So to sum it up: is Java still worth trying? Yes, I would say it is, if only in the same way Latin is still worth learning. Java still features important concepts and ideas that are worth knowing even if eventually you choose to go with another language.
I do have a few comments/questions to add and perhaps clarify.
First, I'd like to understand better your comment on client-side Java and security issues. Are you referring to the Java Plug-in for web browsers, or are you referring to Swing and JavaFX?
On verbosity, I can't stop to think whether this comment is "by looking back", or "by looking at Java as of today". In other words, haven't the latest language features (up to Java 15) helped at all reduce the verbosity while keeping readability?
What holes have been added to the Java Language Specification in your opinion? What is missing? And how backward compatibility, maturity and stability can be a good and a bad thing at the same time?
In your opinion, how licensing and support have impacted users, considering that Java continues to be free, and with multiple choices of companies to choose commercial support from. If anything, what Oracle did was to start charging for production use of their commercial binary of Java, while still offering GPL2 binaries too, and with other companies in the market that have been doing that for years.
I was referring to applets, WebStart and the browser plugin: the methods of distribution of client-side code. These were inherently insecure and while they could've probably been replaced, they weren't. As for Swing and JavaFX, they're the clunky part of client-side Java. They certainly do the job but...
They absolutely have helped massively. But there is a reason Project Lombok still exists, there's still a lot of what many would consider clutter in vanilla Java. (Then again, the fact that something like Project Lombok CAN exist shows the power of the platform and the tooling.)
"Holes" was probably a bad word, as we're not talking about undefined behaviour but about things that used to be simple, and then had a really complicated thing bolted on top of it. Take a look at type inference for example: docs.oracle.com/javase/specs/jls/s...
That is true but what I saw in practice is that it just confused everyone, both end users and companies. Now this might have cleared up over the time I spent away from Java, but back then I did have a nagging feeling that it's almost like they were trying to make this as difficult as they can. I could of course be completely wrong but I can't really explain it any better.
On the client-side, it is worth to anyone (Java developer or not) to revisit JavaFX. At the bottom of the OpenJFX website, there is a set of use cases. There's also this amazing tool to demonstrate the power of the platform these days: Binjr.
On the JLS point, I think it is well defined. Yes it is long, because it covers all aspects of where type inference may occur, and how. One doesn't have to learn Java by reading the specification though. Many great authors have been able to translate the technical specification into more easily consumable books. Again, touches the ecosystem vibe. A good thing IMO.
In many cases, especially on Linux, one simply does apt install openjdk and boom, they get a binary of OpenJDK. On Mac and Windows, from a developer perspective, it is indeed a bit more confusing given that there is no longer "go here and get Java". But there is progress in this area with packages now available over Homebrew, and JDK managers like SDKMAN.
Thank you, it's good to here that things are improving on the packaging front.
With JavaFX, while I really liked working with it, its weird half-in, half-out status it had for a long time was a big mistake in my opinion, and put many developers off. It still felt a bit clunky at times (could be that I wanted to do clunky things though), then again, if I had to write a thick desktop client now, it'd probably be my first port of call.
The JLS is of course well defined, the problem is that its complexity explodes with each new major feature bolted on. Now, I used to dig into the JVM on a fairly low level, so maybe this affected me more than most, but it was hard not to notice how the number of compiler bugs went up, signalling that leap in complexity.
The problem of course arises not from the new features, which are all fine, but from the need to maintain backward compatibility, so historic compromises (like the covariance of arrays) have to be tiptoed around. As I said, it's a double-edged sword.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
[Disclosure: I haven't used Java professionally for a year but I had worked with it continuously for the 20 years before.]
This is going to appear like a collection of random thoughts, but please bear with me.
Let's start with the easy stuff, client-side Java.: just no. It's always been clunky but had the advantage of a relative ease of multi-platform distribution. Note that this was an amazing feature nothing else would match at the time. However it was also hideously insecure and instead of fixing it, they nuked it. And without that, only the clunk remains.
Verbosity is an issue but not as big as it's made out to be, at least in the long run: while it steepens the initial phase of the learning curve, once you're up and running and use a modern IDE, it makes little difference.
A thing often overlooked is the Java Language Specification. It's a tremendous asset. There is great value in being able to reach back to a formal definition of every language structure that is only appreciated when you start working in a language without one. However, if you know the JLS inside out, you will also be aware of where holes had to be cut out to accommodate new features. And the number of these holes is growing.
The fact you can take a piece of code written and compiled 10 years ago and run it now is a double-edged sword. Compared to the here-today-gone-tomorrow nature of JS libraries, it definitely feels nice to have some kind of longevity (especially in a corporate environment), but it comes with a price that gets heftier with time (see also: holes in JLS).
Another thing worth mentioning is that the Java language and the Java VM are two increasingly separate entities and as far as I'm concerned, the VM should be made the flagship product (if it hasn't been already).
So why else would you not choose Java? Well, Oracle. And not just Oracle in general.
The "new" release cadence seems to have created a "worst of two worlds" chimera: features aren't getting implemented much faster than before but licensing and support have become much more complicated and seemingly designed to discourage people from wanting to work with Java. I haven't got anything more to say on this other than if you do use Java, try to pretend non-LTS releases are simply overnight builds: fun to play with but shouldn't be anywhere near production.
So to sum it up: is Java still worth trying? Yes, I would say it is, if only in the same way Latin is still worth learning. Java still features important concepts and ideas that are worth knowing even if eventually you choose to go with another language.
Thanks for sharing these thoughts.
I do have a few comments/questions to add and perhaps clarify.
First, I'd like to understand better your comment on client-side Java and security issues. Are you referring to the Java Plug-in for web browsers, or are you referring to Swing and JavaFX?
On verbosity, I can't stop to think whether this comment is "by looking back", or "by looking at Java as of today". In other words, haven't the latest language features (up to Java 15) helped at all reduce the verbosity while keeping readability?
What holes have been added to the Java Language Specification in your opinion? What is missing? And how backward compatibility, maturity and stability can be a good and a bad thing at the same time?
In your opinion, how licensing and support have impacted users, considering that Java continues to be free, and with multiple choices of companies to choose commercial support from. If anything, what Oracle did was to start charging for production use of their commercial binary of Java, while still offering GPL2 binaries too, and with other companies in the market that have been doing that for years.
Good questions.
I was referring to applets, WebStart and the browser plugin: the methods of distribution of client-side code. These were inherently insecure and while they could've probably been replaced, they weren't. As for Swing and JavaFX, they're the clunky part of client-side Java. They certainly do the job but...
They absolutely have helped massively. But there is a reason Project Lombok still exists, there's still a lot of what many would consider clutter in vanilla Java. (Then again, the fact that something like Project Lombok CAN exist shows the power of the platform and the tooling.)
"Holes" was probably a bad word, as we're not talking about undefined behaviour but about things that used to be simple, and then had a really complicated thing bolted on top of it. Take a look at type inference for example: docs.oracle.com/javase/specs/jls/s...
That is true but what I saw in practice is that it just confused everyone, both end users and companies. Now this might have cleared up over the time I spent away from Java, but back then I did have a nagging feeling that it's almost like they were trying to make this as difficult as they can. I could of course be completely wrong but I can't really explain it any better.
On the client-side, it is worth to anyone (Java developer or not) to revisit JavaFX. At the bottom of the OpenJFX website, there is a set of use cases. There's also this amazing tool to demonstrate the power of the platform these days: Binjr.
On the JLS point, I think it is well defined. Yes it is long, because it covers all aspects of where type inference may occur, and how. One doesn't have to learn Java by reading the specification though. Many great authors have been able to translate the technical specification into more easily consumable books. Again, touches the ecosystem vibe. A good thing IMO.
In many cases, especially on Linux, one simply does
apt install openjdkand boom, they get a binary of OpenJDK. On Mac and Windows, from a developer perspective, it is indeed a bit more confusing given that there is no longer "go here and get Java". But there is progress in this area with packages now available over Homebrew, and JDK managers like SDKMAN.Thank you, it's good to here that things are improving on the packaging front.
With JavaFX, while I really liked working with it, its weird half-in, half-out status it had for a long time was a big mistake in my opinion, and put many developers off. It still felt a bit clunky at times (could be that I wanted to do clunky things though), then again, if I had to write a thick desktop client now, it'd probably be my first port of call.
The JLS is of course well defined, the problem is that its complexity explodes with each new major feature bolted on. Now, I used to dig into the JVM on a fairly low level, so maybe this affected me more than most, but it was hard not to notice how the number of compiler bugs went up, signalling that leap in complexity.
The problem of course arises not from the new features, which are all fine, but from the need to maintain backward compatibility, so historic compromises (like the covariance of arrays) have to be tiptoed around. As I said, it's a double-edged sword.