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.
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.