Feature complete?

[Alex Buckley]

The reason is given after the first minute of the first video section 
that Nicolai links to, "Accessibility & Readability":

"As usual, migration drives a lot of our thinking. We want to make it 
easy to place an existing package into a module and immediately give 
that package the benefit of strong encapsulation. We don’t want each and 
every public type in a package to have to “opt in” to strong 
encapsulation. So, public types in a package are not accessible outside 
the module by default."

Alex

On 12/1/2015 8: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-----
>