> On Jul 27, 2016, at 10:15 PM, David Holmes <david.hol...@oracle.com> wrote: > > On 28/07/2016 1:52 AM, Stephen Colebourne wrote: >> On 27 July 2016 at 16:26, Remi Forax <fo...@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
