is ClassLoader.loadClass() supposed to work on module-info classes?
Stephane Epardaud
stef at epardaud.fr
Mon Dec 7 17:27:15 UTC 2015
FTR I have nothing against it being module-info.class. As far as Ceylon
is concerned, that or MANIFEST.MF are both fine.
What concerns me far more is that it's not self-sufficient since I have
to recombine it with another source (OSGi or Maven metadata) to get
version numbers and optional imports. Now if we could fix that, that'd
be great ;)
Now, from the POV of a Java and Ceylon user (and I'm a big Java user),
I'm much more familiar with module descriptors being in the language,
like package or class descriptors are (in Ceylon), so it feels much more
natural to me to have it in module-info.java than it would anywhere else.
As for it being editable easily after compilation, it's just a matter of
providing tooling, IMO. If you can replace it easily with CLI/GUI tools
then that's enough for me to make it "as easy" to edit as text
representation.
Just voicing my opinion so the JDK guys see that not everyone is opposed
to what they currently have ;)
OTOH, I just had a failure from the bndwrap Ant task that complained
that /module-info.class was not in /com/foo/module-info.class so I
suppose the backwards-compatible story is not trivial…
More information about the jigsaw-dev
mailing list