Preview APIs in the Java Platform

[Bill Shannon]

forax at univ-mlv.fr wrote on 3/7/20 2:21 AM:
> ----- 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.

It would be more useful if I could specify *what* they need to be compatible
with, but just requiring them to opt in to the feature is a good start.

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

If the current feature is not sufficient for this use case, what can we do to
make it sufficient for this use case?

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

So let's work together and find a better solution to both our problems!