is ClassLoader.loadClass() supposed to work on module-info classes?
peter.levart at gmail.com
Thu Dec 3 18:04:07 UTC 2015
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
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?
More information about the jigsaw-dev