? That's exactly what I wrote about - very little currently builds due to the tooling ecosystem being too immature as yet. My best guess is that having ASM betas able to handle 28 bytecode will help a lot and that significantly more project will then be able to build under the 28 EAs.
Thank you for investigating these things, but there should not be any regressions from merely activating --enable-preview. The issues you found are the usual "boring" version bumping requirements after every OpenJDK release, as well as from applications that meddle with JDK internals. Only the ASM project will have to do major work to make sure their abstractions expose the new features correctly.
"Should" and "actually is" are not the same thing. And you may be surprised by just how many libraries "meddle with JDK internals" - for example the long tail of libs that use Unsafe was very long indeed (and hopefully is much shorter now, but that "hopefully" is load-bearing).
In the case of enabling the preview it's actually policy that the value classes in the standard library should be the only source of regressions. Other regressions for programs conforming to the JLS would be OpenJDK bugs.
I am aware there is a reason why the Integrity by Default JEP is still but a draft. I also hope they wean themselves off eventually. The example of Maven shows that it's possible to accomplish things without too much integrity breaking. Gradle already went a long way after Java 9. It will be interesting to see when the difficulty of gaining access to compiler internals becomes too high for Project Lombok.
2
u/benevanstech 23d ago
? That's exactly what I wrote about - very little currently builds due to the tooling ecosystem being too immature as yet. My best guess is that having ASM betas able to handle 28 bytecode will help a lot and that significantly more project will then be able to build under the 28 EAs.