To add a bit of perspective from the build tool side (disclaimer, I'm on the Gradle team), what we do today is that we rely on our model of exports, which basically follows the Jigsaw one, to generate different artifacts depending on the target JDK. This has several consequences:
- our model can (but is not) be richer than the JDK model. Especially, we *could* decide to enhance our model with OSGI like configuration too - we can produce modularized artifacts for pre-jigsaw era. This is already working, and if you declare an API within Gradle, compiling with say JDK 8, then if a dependent module tries to access a non-exported class of a dependency, it will fail at compile time. - we can generate a module-info.java file - it's super fast, which is very important for industrial scale projects Honestly I don't see why the module-info class is compiled to bytecode. I see more disadvantages than advantages. It seems to be a practical reason for not relying on a parser or something because properties file are too weak to model modules. However, I would even prefer keeping a *source form* module descriptor in the JAR, rather than a compiled version. Or any other human readable file format. I think it would effectively be more convenient. And it would also prevent us from having a 2 phase compilation in case someone wants to provide a modularized jar for pre-jigsaw (that is to say, include a module-info.class JDK 9 format file into a JDK 8 format class, even if I consider this as well as multi-release jars as a Frankenjars). Obviously compiling a single JDK 9 module-info file seems pretty cheap, but if you think about the fact that you will want to have a JDK 8 installed to compile your classes, plus a JDK 9 Jigsaw installed to compile the descriptor, and then add that you have to fork the compilers, the cost of this operation is visible both in terms of infrastructure and build time. Whereas with a plain text descriptor, one would be able to compile just with JDK8 at hand. Second, the problem with `@Exported`, while being particularly convenient for fine grained exports, is that it would force the build tools to process to the compilation step in order to determine if the API of a component has effectively changed (in terms of exported classes). This would have a huge impact on performance of compilation of large projects, because we cannot rely on a single source of truth anymore. Today, with an external API descriptor, everything is self contained, that is to say that we know we need to rebuild a module if the descriptor changed. In case of `@Exported`, as soon as *any* source file changes, we have to recompile the classes to determine if the API changed. This introduces coupling that is bad for scalability of large projects. So I think that the current solution, with a module-info descriptor, is pretty good in terms of trade-offs between convenience and performance. 2015-12-04 9:06 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>: > since the world does not only consist of java and javac and since there > are many more bytecode files producing languages out there, I expect > multiple such tools working on the bytecode plus language based tools, for > those that want to support strong encapsulation at runtime. > > > Gesendet: Donnerstag, 03. Dezember 2015 um 21:42 Uhr > > Von: "Paul Benedict" <pbened...@apache.org> > > An: "Alex Buckley" <alex.buck...@oracle.com> > > Cc: jigsaw-dev@openjdk.java.net > > Betreff: Re: is ClassLoader.loadClass() supposed to work on module-info > classes? > > > > On Thu, Dec 3, 2015 at 1:46 PM, Alex Buckley <alex.buck...@oracle.com> > > wrote: > > > > > I expect you will say, "Encode exports somewhere other than the module > > > declaration, such as with @Exported annotations on types or packages." > To > > > which I repeat: "if we're going to introduce the concept of a > > > module to millions of Java developers, we see value in consolidating > both > > > kinds of configuration [dependencies and exports] in one place". > > > > > > > Regardless of the class file vs config file debate, I find it interesting > > there is no room for annotations in the current solution. All of this is > > still configuration anyway. An @Exported/@Retention(RUNTIME) would easily > > eliminate all "export" directives from a developer's Java project. It > would > > also address Jonathan Gibbon's concern about having to syntax check > package > > names (empty or not). Anyway, if that is really off the table, have you > > thought about how many tools are going to try to fill the gap by offering > > the Module Descriptor to be auto-generated? I can easily see a > > proliferation of custom x.y.z.@Exported per tool so that a project can > be > > preprocessed for module-info generation. > > > > Cheers, > > Paul > > >
