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
