Caciocavallo (was Re: <AWT Dev> Removing all methods that use the AWT peer types in JDK 9)

[Alex Buckley]

On 2/19/2015 2:19 PM, Phil Race wrote:
> On 2/19/2015 8:49 AM, Alan Bateman wrote:
>> On 19/02/2015 16:30, Roman Kennke wrote:
>>> Hmm. I am not totally familiar, but from what I heard at FOSDEM from
>>> Mark Reinhold, it is possible to export certain APIs *only to other
>>> known modules*. This is similar in concept to C++ friends, except it
>>> happens on a module basis instead of class basis. Which is fine. Could
>>> somebody from jigsaw please comment on this, confirm or deny if I'm
>>> wrong with my understanding?
>>>
>>> So suppose we'd have a Cacio module that is part of OpenJDK (doesn't
>>> have to be part of any provided profile). Then the desktop module could
>>> export the required APIs to Cacio, without exporting it to anyone else.
>>> If I understand the modules stuff correctly.
>>
>> The JSR 376 group is currently discussing the draft requirements
>> document, which has an item on this topic called "Qualified Exports":
>> http://openjdk.java.net/projects/jigsaw/spec/reqs/01#qualified-exports
>
> However, http://openjdk.java.net/jeps/200 states under Design Principle
> #4 :
> If it is a Java SE module, /i.e./, to be proposed for inclusion in
> the Java SE Platform Specification, then it must not export any non-SE
> API packages.
>
> You probably should head over to the jigsaw emailing list to ask
> whether that means Caciocavella's non-standard interfaces might be
> allowed to be exported from the Java SE java.desktop module at all,
> or whether it would be allowed in the 'restricted' fashion discussed
> above

A Java SE module, such as java.desktop, will not export any non-SE 
packages to anyone at all.

I have no opinion about Cacio code being physically located in the 
java.desktop module. Assuming it isn't, then Cacio code can only access 
proprietary types like SunGraphics2D and java.awt.peer.* if the end user 
launches the runtime with a flag to make those types accessible.

Alex