It's not too late for access control

[Sanne Grinovero]

On Tue, Jul 12, 2016 at 5:00 PM, John Rose <john.r.rose at oracle.com> wrote:
> On Jul 12, 2016, at 8:01 AM, Paul Benedict <pbenedict at apache.org> wrote:
>>
>> All things being equal with Jigsaw features today, I'd rather have "public"
>> retain it's global visibility and extend "package private" to the module.
>
> Again, $0.02, with apologies in advance for opining on a subject I'm not
> an expert in.
>
> From a pure language POV I find this appealing, but in our world there
> are myriads of existing public classes already coded in libraries which need
> large-scale encapsulation.  Surely we need to be able to tell some libraries,
> "Hey, not so public, there; we're restricting your visibility."  If we can't do that
> we don't have modules at all.  If Java had modules from the start, maybe
> we'd say "public is globally public, so any class can punch through all layers of
> encapsulation by using the super-strong keyword 'public', and the default
> is 'module'."  (Advance apology if this is a straw-man.)

As a maintainer and contributor to several popular Java open source
libraries my experience is that in practice very few existing
libraries will "just work" in Java 9 out of the box: people will have
to update their code. This is based on my experience, as some of these
projects have dozens of dependencies and it's taking a long time to
identify each problematic point, discuss patches, getting other
communities to release timely, an often there is need for "recursive
releases" and various iterations for each problem as they get
identified, for each dependency.

The priority for most OSS communities and developers at this stage is
to be able to compile and run basic tests; some started early and are
in a good shape today (e.g. Apache Lucene, Hibernate), but several
others have not been sensible to this matter: so improving modularity
and adjusting visibility is "only" a secondary need for many (not
defending this position, just my impression), but I'm confident that
we'll eventually get all library maintainers to actively update their
API as well.

No doubt there will be a next phase in which existing APIs will be
reviewed to take advantage of Jigsaw, for example I look forward to
publish our Hibernate libraries as Jigsaw modules, but this is work
that needs to be done by explicitly by updating the libraries and
review the APIs with a focus on visibility.

I'm generally grateful that the OpenJDK developers are working hard to
not break existing libraries, but in this case I don't think it's
worth it as we'd merely have outdated libraries half-working at best.

I'd rather see the modules system be truly great, so that it will be
worth our time to fix all the libraries in the coming years; in the
mean time, I suspect that exposing too much as "public" shouldn't be a
problem as it worked well enough so far.

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

Great points. In fact in my team we also have experience "packaging"
lots of these OSS Java libraries into JBoss Modules, and have always
appreciated that - as an assembler - with JBoss Modules I can define
the dependencies via external metadata, without having to recompile or
have to reassemble the jar.
As you suggest, it is indeed useful to be able to override the intent
of the library authors, especially as different libraries are
developed by independent teams / communities / companies.

This was also raised by David in the past; I'm a bit concerned that
Jigsaw's more strict ways have not been tested enough "on the field"
on the aspect of strict metadata being packaged in the module itself.
In particular, I appreciated the flexibility of JBoss Modules most
after having used it for a long time: some libraries started to evolve
over time and you need to start thinking about backwards/forward
compatibility among many libraries which are released at different
points in time. Often even this "timeline" of releases isn't a
linearizable sequence, as different libraries will release
independently on their own timeline and not necessarily upgrading all
of their dependencies consistently with other projects in the world.

Please don't underestimate the importance of this flexibility for the
"assembler": its importance might not be very clear now when drawing
dependency graphs in a "clean room" scenario, but it becomes essential
when you consider that the rich ecosystem of libraries is actually in
constant evolution.

Regards,
Sanne

>
> 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.
>
> (HTH.  I'm probably missing a couple of Third Way options; please point them
> out.  I'll go back to lurk mode now.)
>
> — John