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

[Peter Levart]

On 12/02/2015 09:16 PM, Alex Buckley 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

Hi Alex,

Loosely related to this debate, I would like to ask what's the story 
with modular jars that can run on JDK8 classpath and as modules on JDK9. 
How is one supposed to create such jar file as it must have:

- classes compiled with JDK8 javac (or JDK9 javac with -source 8 -target 
8 or -release 8)
- module-info.class which can only be produced with JDK9 javac, but not 
with -source 8 -target 8 or -release 8

Is one expected to invoke javac twice, 1st for sources (excluding 
module-info.java), 2nd just for module-info.java ? Wouldn't it be nice 
for jar tool to be able to fabricate the module-info.class from scratch 
using just command-line options? It currently can edit module-info.class 
to add main class. If it could also print module-info.class and create 
it, it would be almost like having a text file an vi, wouldn't it?


Regards, Peter