Preview APIs in the Java Platform

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Bill Shannon" <bill.shannon at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Alex Buckley" <alex.buckley at oracle.com>, "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Jeudi 5 Mars 2020 22:27:28
> Objet: Re: Preview APIs in the Java Platform

> Remi Forax wrote on 3/5/20 12:18 AM:
>> Hi Bill,
>> I think you don't understand how preview APIs work,
>> as a user, using a preview API requires --enable-preview at compile time so the
>> generated bytecodes will be tagged with the minor version of the classfile
>> being equals to 65 535 (in violation of semver BTW),
>> so the only way to use a jar containing such classfiles is to use
>> --enable-preview at runtime.
>> 
>> So as a user it means once you use a preview API, you can not re-distribute your
>> work, you can not by example upload such jar on Maven Central.
> 
> Why not?  Doesn't it just mean that anyone who wants to use my preview
> jar has to use --enable-preview at runtime?

and have all their dependencies compatible with a very specific version of the JVM.

The issue is that in term of dependencies, it's like Python2/Python3, you have to wait for all dependencies that are using --enable-preview to use the same JDK.
In fact, it's worst that Python2/Python3 because it's not a once in a lifetime change but an every 6 months change due to the Java release cadence.
Practically, you are waiting for a blue moon so your application can compile/run.

> 
>> Why JakartaEE will want such restriction on their own APIs ?
> 
> For exactly the same reason the JDK wants such restriction.
> Is that so hard to imagine?

Given the drawbacks of the preview APIs, yes !
Unlike the JDK that has no external dependency, any applications JakartaEE will end up in the 10th circle of hell, the dependency hell.

[...]

Rémi