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