Not commenting on the entire piece here, just one bit...
On 07/12/2016 11:00 AM, John Rose wrote:
On Jul 12, 2016, at 8:01 AM, Paul Benedict <pbened...@apache.org
<mailto:pbened...@apache.org>> wrote:
This makes great sense to me. Why? Because when I develop a library, I
really don't see any great benefit in hiding a type from another package.
Let me qualify that.... I really don't see any great benefit in hiding a
type from another package **that I own!** (double emphasis). I have
inspected all my uses of "package private" and it always comes down to one
thing: preventing static linkage to the type from packages **outside my
library**.
To me this looks like a simple power struggle between the class author
expecting a platform for full publicity, and the system assembler expecting
to be able to control inter-library visibility. Both can't have the
final word.
Shouldn't the assembler have it? And if the assembler is given absolute
control over some unit of access control, it seems likely to me that this
unit has to look a lot like a Jigsaw module.
In the current model though, the assembler doesn't have the control at
all. The module author is the one who decides who can access what.
Before Java 9, it was just by making some things public and some things
non-public; now it's a question of ensuring that certain packages (maybe
all) are accessible to all using explicit mechanisms, but the end result
is basically the same.
If the assembler wants to add nuance to accessibility, they have to
modify those lovely binary descriptors at assembly time. I don't think
Jigsaw's restriction of "public" adds anything over what I propose in
this regard (note that what I propose does not involve editing classes
for any reason though); my proposal doesn't really change this one way
or another, except that it retains the current well-understood
difference between visibility and accessibility, with the former acting
not as a security mechanism but a linking mechanism, just like today.
Note that system assemblers cannot be expected to edit individual classes.
That would be another scale error. So in the end, the author of a class and
of a package has to provide a provisional, local spec. of what's
visible, while
the assembler (who works with unmodifiable libraries) owns the global spec.
Yeah but think about it: how different is the need to edit classes from
the need to edit binary module descriptors, encoded *as* class files?
Really, the assembler should have to do neither thing, because that's an
undue burden.
--
- DML
