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

David M. Lloyd david.lloyd at
Thu Dec 3 12:47:08 UTC 2015

On 12/02/2015 04:49 PM, Alex Buckley wrote:
> 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.

I am baffled as to the basis for this assertion.  This kind of change in 
fact happens (present tense) frequently - very frequently if you have 
any kind of system for updates.  Modules get split or merged, 
implementations from one vendor get swapped out for another, multiple 
versions of things are introduced.  I honestly can say that I do not 
understand how the Jigsaw team arrives at this kind of conclusion with 
literally zero production experience!

>> 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
>> <mailto:alex.buckley at>> 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
>>     ?
>>     Alex


More information about the jigsaw-dev mailing list