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

Alex Buckley alex.buckley at oracle.com
Wed Dec 2 22:49:29 UTC 2015


On 12/2/2015 1:34 PM, Paul Benedict wrote:
> Alex, the primary benefit of annotations (vs. XML) is delivering code
> and configuration in one bundle. It's unnecessary to deliver
> configuration separately (i.e., XML) if you have a component that
> primarily has one way of being configured. That's exactly why
> annotations are very valuable in EE development and can displace
> configuration files. Because of the bundling, no, I have no any
> expectation of going into a text editor for modification.

Totally agree so far.

> On the contrary, the discussion on these boards make me believe the
> module information is going to be more fluid. Right now it's expressing
> dependencies, but it seems frameworks and other tools may want to add
> their own bits of information along the way. This, like the Manifest, I
> do have expectations for editing at will. Perhaps I want to add data
> only I care about, and I may want to see what others have added. That's
> all a possibility.

Now we reach the disagreement. We don't think the module declaration 
will be as fluid as you do. Yes, frameworks and other tools will want to 
modify module declarations (usually by addition of dependencies or 
exports) but that's a handful of actors, all of whom are perfectly 
capable of using ASM. 99.99% of humans have no business modifying 
someone else's module declaration by hand, so there is no reason for it 
to be easy.

> But, with that said, I am unsure the point you're trying to make. The
> Module Descriptor is neither annotation nor XML and doesn't configure
> code. Rather, it configures the build-time and/or run-time environment.
> It's practically a weak "make" file or IDE project configuration in its
> current form. It's very odd to take this information and shoe-horn it
> into a class file.

A module declaration configures code -- "exports" determines the 
accessibility of types.

A module declaration ALSO configures the build-time and run-time 
environment -- I agree that "requires" is the same kind of dependence 
widget as found in an IDE project configuration. (Though "requires 
public" is quite a bit more powerful.)

Sure, you could configure accessibility with @Exported on public type 
declarations, and configure the build-time and run-time environment with 
a module.xml file. But 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 in one place -- a place that's fluid during 
development and not very fluid thereafter.

Alex

> Cheers,
> Paul
>
> On Wed, Dec 2, 2015 at 2:16 PM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     On 12/2/2015 8:31 AM, Paul Benedict wrote:
>
>         All that information is locked in binary format but it
>         should be human readable. I should be able to go in myself and
>         do this with
>         a text editor. I shouldn't have to compile a file anymore than I
>         have to
>         compile my MANIFEST.MF or web.xml or application.xml. This is
>         all about
>         configuration; not executable code.
>
>
>     Annotations are human readable in source code but end up "locked in
>     binary format". Entity mappings and REST endpoints (since we're
>     speaking of EE constructs like application.xml) are configuration
>     ... do you expect to be able to use a text editor to modify them?
>
>     Is there any more to say on the issue of "source-flowing-to-binary
>     versus structured-text" than is already rehearsed at
>     http://stackoverflow.com/questions/182393/xml-configuration-versus-annotation-based-configuration
>     ?
>
>     Alex
>
>


More information about the jigsaw-dev mailing list