David M. Lloyd
david.lloyd at redhat.com
Tue Dec 1 17:11:13 UTC 2015
I would take that with a big grain of salt though, as a lot of the
design reasoning in Jigsaw and presented there is self-justifying.
"Strong encapsulation is about being able to prevent access even if the
accessing class and the target class are in the same class loader and
even if someone is using core reflection to manipulate class objects."
This statement alone is based on the very heavy and unjustified
assumption that a class loader is, somehow, "too big" to be a
representation of encapsulation (i.e. a module), and therefore you would
not want some classes in a class loader to see others. Yet a Module is
conceptually nearly identical to a class loader in form and function,
breaking a variety of things for no real good reason.
Likewise with the justification for the weird "lateral" accessibility
rules in Jigsaw: it is definitely NOT the only viable solution to the
problem, it's just the solution that the Jigsaw designers used.
And finally I'd like to point out that the JSR 376 EG has to date made
no agreement on Jigsaw as its modularity implementation, despite how it
has been presented thus far by its proponents, so in my view these
issues are still very much up for discussion.
On 12/01/2015 10:31 AM, Nicolai Parlog wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> Hi Vitaly,
> I summarized each of the J1 talks about Jigsaw. Here's Under The Hood:
> If you want to see the original video for a section, hit the
> Play-Button next to it.
> so long ... Nicolai
> On 01.12.2015 16:47, Vitaly Davidovich wrote:
>> I'm glad I gave you the opportunity to share your thoughts on what
>> java would look like if designed right now :), but I was strictly
>> speaking about the access modifier for modules. The question is
>> basically whether a module-private access modifier was omitted due
>> to legacy/migration concerns or something more fundamental.
>> Apparently the Under the Hood talk mentions the reason, so I'm
>> hoping someone can just quickly mention the reason here.
>> On Tue, Dec 1, 2015 at 10:41 AM, <mark.reinhold at oracle.com> wrote:
>>> 2015/12/1 7:22 -0800, vitalyd at gmail.com:
>>>> Well, people can get used to just about anything, doesn't mean
>>>> it's necessarily the right way. But fundamentally, I'd like to
>>>> look at java source/types and be able to infer as much
>>>> semantics as possible, this includes visibility. With jigsaw,
>>>> this is now blurred for public types. If modules are truly a
>>>> first class citizen, they ought to have their own
>>>> language-visible access modifier. Let's put it this way --
>>>> green field scenario, no legacy code to worry about, is this
>>>> still the right choice?
>>> In a green-field scenario, with no legacy code to worry about,
>>> we probaby wouldn't have packages, protected members, or even
>>> non-private constructors -- and we definitely wouldn't have
>>> That is not, however, the world that we live in.
>>> - Mark
> - --
> PGP Key:
> a blog about software development
> Free and Open Source Software for the City of Dortmund
> nipa at pod.geraspora.de
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> -----END PGP SIGNATURE-----
More information about the jigsaw-dev