It's not the feature that excites me, it's the pace of Java language improvements. The 6-month cycle of versions, the whole process of letting experimental features in for a couple versions to test, refine, and likely accept, it's all really working, you know? We're getting stuff that's been so long desired, and it's happening quickly enough to be exciting but not so fast that we're overwhelmed and things are breaking.
People often say that Java 8 was the big important update to the language (streams, lambdas, java.time, and more), but I think Java 9, which began this process was the true rebirth of the language.
Interested in your enthusiasm on this front. If (x instanceof String s) was demonstrated at the JavaOne announcing Java 9. The process is proceeding and visible, but finally getting things so long desired and so long available in other languages isn’t supporting much notion of improved pace. Visibility, yes.
Given that most Java using companies tend to go LTS version to LTS version, it's not like Java 13.141.59 is going to see massive uptake.
And the movement from Java 8 to Java 11 was slowed by bytecode changes and the advent of modules, which declared which of their internals you could dick with. Sure, you could add --add-opens to your commands, but it felt (as intended), hacky as all hell.
For an example, I've submitted PRs to Apache Kafka as part of the effort to replace Powermock with Mockito. Why? Because a) Powermock doesn't play nice with with JUnit 5 and b) Because it breaks totally on Java 16+, due to Java modules being enforced by default as of that version.
But for companies that are happy to keep up with the faster release schedule, there's been access to new and useful features at every new Java version, and it means that early adopters can provide feedback on new features like record classes etc. before they're crystallised in an LTS version.
And given the history of Java improvements between Java 6 and Java 8, the current release cycle is positively blistering in comparison.
> And the movement from Java 8 to Java 11 was slowed by bytecode changes and the advent of modules, which declared which of their internals you could dick with. Sure, you could add --add-opens to your commands, but it felt (as intended), hacky as all hell.
While modules were added in 9, as you mention, strong encapsulation was only turned on in JDK 16; until then, visibility was identical to 8, and no flags were neededl. Modules were not the reason for the difficulties in migration from 8 to 9+. By far, the main reason was libraries that depended on JDK, not subject to backward compatibility, that were changed. Such libraries were non-portable by design.
Strong encapsulation (in effect only since JDK 16) is intended to prevent that. You only need to --add-opens when you bypass the specification, and when you do, you know that your code is not portable. add-opens is hacky because it is needed to enable hackiness; a codebase that isn't hacky doesn't need it.
So now that strong encapsulation is in effect, modules will actually prevent those kinds of difficulties.
You're very much right, I conflated the two initially, and then separated the two later, should've edited that.
From my experience, a lot of the upgrade issues were around things fiddling with a bunch bytecode like Spring.
I'm really glad strong encapsulation is enabled by default now, it highlights dubious stuff- reusing my Powermock example, the lib is trying to mock methods on Object itself...
When you say, "so long desired," the question is, by whom? Java (the language) isn't aimed at PL enthusiasts, but the majority of programmers, and believe it or not, most programmers are quite averse to new language features, so great care is needed in adopting them if a lanugage wants to be very popular, as Java aims to be.
I can tell you that even when there's a feature we strongly believe is "right", we are wary of adding it to Java until it has been "so long available in other languages." An example I personally worked on — and it's not even a language feature, but a simple API in a single class — is structured concurrency. We love the concept, but because it hasn't yet been "so long available in other languages", we've only proposed it as an "incubator module" to let it mature, and even then we're only adding it because we believe it is too essential to be left out.
It appears that you can be extremely popular or you can be an adventurous innovator/early adopter on the language-feature front, but you can't be both. The Java platform offers multiple language for those who like more adventurous and/or feature-rich languages — and we're happy to accommodate such languages — but they are definitely in the minority (my rough estimate is that only about 10% of programmers prefer such languages).
A lot of the progression on the Java language features occurred after Jigsaw (modules) shipped. From memory it was almost a decade of delays to pretty much every JEP because they couldn’t get Jigsaw and it’s underlying architecture right. I struggle to think of one modern use case for modules.
Kotlin shouldn’t have happened but they let Java lang fester for too long.
People often say that Java 8 was the big important update to the language (streams, lambdas, java.time, and more), but I think Java 9, which began this process was the true rebirth of the language.