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.reinh...@oracle.com> wrote:
2015/12/1 7:22 -0800, vita...@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:
n...@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-----
