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 >
