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

[Jochen Theodorou]

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
>