On Tue, Jul 12, 2016 at 5:00 PM, John Rose <john.r.r...@oracle.com> wrote: > On Jul 12, 2016, at 8:01 AM, Paul Benedict <pbened...@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