Exporting - the wrong default?

Jason Greene jason.greene at redhat.com
Thu Jul 28 20:09:07 UTC 2016


> On Jul 27, 2016, at 10:15 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 28/07/2016 1:52 AM, Stephen Colebourne wrote:
>> On 27 July 2016 at 16:26, Remi Forax <forax at univ-mlv.fr> wrote:
>>> to get back to our issue,
>>> there are 4 possibilities when exporting a package, for a public type,
>>> (1) don't see it at compile time, don't see it at runtime (can't reflect on it)
>>> (2) don't see it at compile time, see it at runtime (this is the OSGI/JBoss model for not exported)
>>> (3) see it at compile time, may not exist at runtime (so be prepared to get an exception then)
>>> (4) see it at compile time and see it at runtime
>> 
>> Agreed
>> 
>>> The default can not be (3) because it's a corner case,
>> 
>> Agreed
>> 
>>> it can not be (4) because in that case we lost the 'strong encapsulation' that a module should provide by default,
>> 
>> That is what this thread discusses. It seems to me that the "strong
>> encapsulation" goal is met providing that a package can be hidden if
>> desired, and that the set of packages a module exports is still known
>> and limited (just automated by the compiler). Option (4) also
>> mitigates the issue that David Holmes has repeatedly indicated, where
>> jigsaw is currently planning on changing the meaning of "public".
> 
> I think you meant David Lloyd.
> 
> I have no issue with modules defining a new accessibility boundary. Seems perfectly natural to me, and something that has been postulated since the original superpackages proposal - JSR-294. I find it incomprehensible to be "this close" to the end and find people arguing for a reversal of the basic premises.

I don’t think its all that surprising given that there is a number of open design impacting issues at the moment (some of them brought up long ago). I have been heartened by recent dialogue with proposals on some of the issues. I hope it continues, and there is a priority to get things right, as opposed to being eternally stuck with something that doesn’t meet existing use cases.

-Jason




More information about the jigsaw-dev mailing list