On 05/12/2015 17:08, Michael Hall wrote:
Curious,
I had code for checking to see where something was at…
public static void main(String[] args) {
try {
// java.net.URL jrt = new java.net.URL("jrt:/java.base/");
ClassLoader cl = new java.net.URLClassLoader(modules);
System.out.println(cl.getResource(args[0]));
}
catch (Exception ex) { ex.printStackTrace(); }
}
This used to work with
new java.net <http://java.net>.URLClassLoader(new java.net
<http://java.net>.URL[0]);
Now with a jigsaw ea I get…
java -cp halfpipe.jar org.cmdline.cmds.Locator java/lang/String.class
null
To get it to work jigsaw for something in the base module I found it
needed an actual URL like jrt above. It worked fine for class path
outside the runtime.
I then set up an url array with a separate jrt:/ url for each module -
‘modules' in listing above, entire current list of modules omitted for
brevity.
Then it works…
java -cp .:../../HalfPipe/halfpipe.jar Locator java/lang/String.class
jrt:/java.base/java/lang/String.class
I also tried this as a ClassLoader subclass. The way I think I used to
do this lookup. It didn’t seem to work for modular runtime classes either.
I haven’t done much else ClassLoader related with jigsaw yet, and hope
to do less since I won’t need to try and load classes from tools.jar.
Are there other things expected to work a little differently? Does
loading work the same and just loadResource is different?
The jrt URL scheme defined in JEP 220 is working and you should have no
issues connecting to resources in the run-time image with those URLs.
However there is a change to the ClassLoader.getResourceXXX methods.
Mark has summarized the current state of affairs here:
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000163.html
I'm sure the JSR will discuss that topic further in due course. For now,
the implementation in the jake forest and the EA builds is as per the
summary in that mail.
-Alan.
