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

[Rafael Winterhalter]

As a follow-up question. What if I need to import a library into my
namespace and therewith module? ("shaded dependencies") This is a quite
common practice to avoid version conflicts.

Would for example the reflection semantics for these classes change? Or
would the byte code level serve as a fallback? (But then the mentioned
"modularity for pre-9 libraries" would not work.)
Am 03.12.2015 7:04 nachm. schrieb "Peter Levart" <peter.levart at gmail.com>:

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