Preview APIs in the Java Platform

Thu Mar 5 21:19:00 UTC 2020

On 05/03/2020 20:31, Remi Forax wrote:
> 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.

I see where you are coming from. Our intention is that a preview API 
such as the memory access API will be used to make 'experiments' (e.g. 
try to rewrite parts of framework XYZ to use it instead of Unsafe), then 
report feedback, then throw away the results (in a way - they might even 
persist in some obscure GitHub repo, but you see what I mean, I hope).

Here you seem to describe some use cases where you have some code that 
is production-like (maybe not in the sense of quality of the code, but 
in the sense that you expect it to just work and to be able to 
distribute it), and yet you are introducing a coupling with a part of 
the Java SE API which is not yet fully baked (whether you call that 
incubating or preview, the essence is the same).

So, let's consider this mental experiment: what if the name of the 
incubating module kept changing on each release? Wouldn't you end up 
with a similar problem? What if the set of classes available in a given 
incubating module changes when going from Java N to N + 1? What if we 
rename MemorySegment to MemoryRegion? Wouldn't you still need to recompile?

I hope you see my point: you seem to assume that incubating has stronger 
stability guarantees than it actually has. The preview feature 
mechanism, in this case, prevents (by design) from relying on the 
(wrong) assumption that the your code might work unchanged from version 
to version.

Will this prevent people from creating programs where they play with 
memory segments and layouts and report back feedback? I don't think so. 
Will this prevent a bigger project from giving JEP 370 a try and 
temporarily enable preview features/APIs in a fork to do few 
experiments? Again, I don't think so.

Cheers
Maurizio

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