is ClassLoader.loadClass() supposed to work on module-info classes?

[Cédric Champeau]

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 <blackdrag at 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" <pbenedict at apache.org>
> > An: "Alex Buckley" <alex.buckley at oracle.com>
> > Cc: jigsaw-dev at 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.buckley at 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. at Exported per tool so that a project can
> be
> > preprocessed for module-info generation.
> >
> > Cheers,
> > Paul
> >
>