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

[Peter Levart]

On 12/03/2015 08:46 PM, Alex Buckley wrote:
> On 12/3/2015 10:04 AM, Peter Levart wrote:
>> 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 ?
>
> Yes (or get your build tool to do it).
>
> More generally, anyone creating a multi-release JAR file (you didn't 
> ask about them, and they are not necessary to achieve what you want 
> above, but I mention them for completeness) will invoke javac multiple 
> times. It's the cost of doing business.
>
>> Wouldn't it be nice
>> for jar tool to be able to fabricate the module-info.class from scratch
>> using just command-line options?
>
> No. How does a Java compiler know what's exported from a module, in 
> order to enforce accessibility, if the module declaration isn't 
> fabricated until packaging time?

In this case (of building a modular jar file that is able to run on JDK8 
classpath), classes are compiled with javac -release 8, which can't run 
in "modular" mode and consequently can't enforce any accessibility. When 
module-info.java is then compiled separately, there are no classes to be 
compiled and so there's nothing to enforce accessibility on.... Unless 
the 2nd compilation includes all sources and then throws the .class 
files away, just to get compilation errors from modular accessibility 
checks...

>
> 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".

No, I like all things to be specified in one place.

>
> Alex

Thanks,

Peter