2 ms·

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

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.

pron 4y ago
> 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.
- EdwardDiego 4y ago
  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...

pron 4y ago

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

EdwardDiego 4y ago
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...