Feature complete?

[David M. Lloyd]

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.

For example:

"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:
>
> 	http://blog.codefx.org/java/dev/javaone-2015-under-the-hood-of-project-
> jigsaw/
>
> 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:
>> Mark,
>>
>> 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
>>> serialization.
>>>
>>> That is not, however, the world that we live in.
>>>
>>> - Mark
>>>
>>
>
> - --
>
> PGP Key:
>      http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
>
> Web:
>      http://codefx.org
>          a blog about software development
>      http://do-foss.de
>          Free and Open Source Software for the City of Dortmund
>
> Twitter:
>      https://twitter.com/nipafx
>
> Diaspora:
>      nipa at pod.geraspora.de
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWXctoAAoJEMo7rS6czNUJG/MP/2WCvpURnvD98yFW+1OBCeyG
> OFq4+65vVDjgzqpM6rZNtHdybyqMgC1i7HH7InVY4F3GQMkBx7wSTEtnWrhvtpmr
> 3AltLgG7fYUppzTyuLU8PoeXkG1o7cICq6ALyIJNLD+PF2w3cCX2TvBF70o/qC6X
> oHF+GyKk0upRiQBTEEA+30KQt6zKCaJuW3bo2wQ1QnV5d+Fg5xTSBUnteZR1g+Wv
> M3p7zx1reh4FNUG1+QV2CI6y3Zr4jTHod5k3i/SljW/ly5ApTmvNW0sinz89Aeh1
> v6UvAa+e7PL5O/uufocRVqeXUM2bewHZTI0VAxvmsz5t+vmx54CYxVB5Bim/nSXO
> R0iucow9R4GieW3xbdnmUlAfBBq3rtFMCCsNkaVd95FbQJHw0LaAtFmI7ceIgjym
> ssh4LrYWuICRb1XTHcRu1mL8Bl+XJ5bCcYlYSMkeMwqRGuJAxsBLKAFCPlFP06sD
> 3yl2aQZ32m9/+uJapTGizum1gPVRKVkE90ao4ktXmFt0iI+uXfMAGWxbqriHhhk0
> JYnw2GGeRK3awKVPhTAi2MZlLW4sHYr9cEQFME2HyDymMpci6LUUbJb7Xzfsus/w
> 1sMRXTuREdMpL/8y7zoClzcssLxQaHc2UHV+qgpEM0a6Nq81etlXZLRUMIbZP769
> zggNAn1Q1UYPZRwdqIBD
> =Yn8e
> -----END PGP SIGNATURE-----
>

-- 
- DML