Preview APIs in the Java Platform

[Remi Forax]

Hi Maurizio,

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Alex Buckley" <alex.buckley at oracle.com>, "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Jeudi 5 Mars 2020 19:47:41
> Objet: Re: Preview APIs in the Java Platform

> On 03/03/2020 21:15, Alex Buckley wrote:
>> I intend to update JEP 12 to incorporate preview APIs in the near
>> future, hopefully in time for 15 so that projects such as Panama can
>> benefit from them.
> 
> Thanks for looking at this Alex.
> 
> During the development of JEP 370 (memory access API [1]) we ran into
> some issues when trying to make the API fit in the (rather strict)
> incubating module rules. While using the memory access API is relatively
> easy (an --add-modules "jdk.incubator.foreign" will do the trick) the
> number of hacks we had to put in place in order to make the whole thing
> work was, I think, rather unfortunate. The main issue we faced is that,
> at its core, the memory access API adds a new kind of VarHandle - and
> all the logic for dealing with VarHandles is in java.base - but since
> incubating APIs had to live in their own separate module, we had to find
> ways to "split" the API and to create proxy interfaces [2] which
> java.base could then use in order to workaround the fact that the memory
> access API is defined in a module which is not available (for obvious
> reasons) from java.base.
> 
> Now, sometimes these hacks just result in a less-than-ideal
> implementation  - e.g. where the code is more cluttered than we'd like;
> but in the case of Panama we ran into actual performance bottlenecks [3]
> whose root cause was, precisely, the fact that we had to split the API
> into two pieces.
> 
> So I welcome any change which (a) brings Java SE API at the same level
> as the language and VM features (by allowing such APIs to also be
> 'preview') and (b) allows development of future APIs not go through the
> twist and turns we had to go through when developing the memory access API.

You only see your side of the coin, let me talk about the other side.

I've a code that run on Java 13 using Unsafe to clean a ByteBuffer, the jdk 14 introduces the incubator module jdk.incubator.foreign, so i've written a code that uses a segment instead of unsafe if I detect that jdk.incubator.foreign is available, this code is compiled with the jdk 14 and works with the jdk 14 and jdk 15 (at least for now).
Now, let suppose that the memory access API is implemented using the proposed preview API, if i want to be able to use it for jdk 14 and 15, i need to first detect if --enable-preview is set (there is no API for that), and i need the same class to be compiled once per jdk, so one for jdk14 with preview enabled and one for jdk15 with preview enabled. But there is no version of javac able to compile those two classes at the same time.

If i'm me, i will use bytecode patching but i'm pretty sure nobody sane will do that, so in practice very few people will test your API in real life.

> 
> Cheers
> Maurizio

regards,
Rémi

> 
> [1] - https://openjdk.java.net/jeps/370
> [2] -
> http://hg.openjdk.java.net/jdk/jdk/file/fbbcf9125cef/src/java.base/share/classes/jdk/internal/access/foreign
> [3] - https://bugs.openjdk.java.net/browse/JDK-8237349