Exporting - the wrong default?

[Paul Benedict]

I think what Jigsaw has done (to modularize the JDK) is well-achieved and a
round of kudos should go out to Mark, Alan, Alex, and the rest of the
Oracle crowd for spending years on this herculean effort. With that said,
there are many more wrinkles to iron out for everyone else. I believe the
active collaboration, agreements, and disagreements show that being "this
close to the end" is much brighter for the JDK itself than for the rest of
the world. Does anyone else see this divide? What's good for the JDK itself
is sometimes not good for the rest and vice-versa. The contention over
reflection I believe is a pinnacle example, but there are so many more too.
Issues will continue being brought up as such bleeding-edge experts and
hobbyists toy with with these new features.

You can take Stephen's opinion on what reflection has meant to Java
seriously or not, but I think he's right. Reflection has always been a huge
cornerstone of Java's success. Developers can escape the social constructs
laid down in the Java language and go directly into messing with objects,
fields, and methods. Everyone enjoys that freedom. The other huge
cornerstone of Java's success is the near-infinite backward compatibility
that has been provided. Things deprecated for 20 years continue to exist.
Putting both of those concerns together, I cannot escape coming to the same
conclusions as Stephen. I understand "me too" opinions are not in
themselves convincing, but hopefully something I have mentioned is. Please
do not change how reflection operates with regard to package exports.

Cheers,
Paul

On Thu, Jul 28, 2016 at 3:09 PM, Jason Greene <jason.greene at redhat.com>
wrote:

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