> 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
>
> <http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000163.html>
From the above
Resource encapsulation
___________________________
2015/9/28 10:02 -0700, peter.kriens at aqute.biz
:
> The javadoc for getResource* says:
>
> ‘This method does not find resources in named modules’.
>
There is a plethora of resource-lookup methods. The current state of
affairs is:
- A class in a named module can read its own resources via the
Class::getResourceAsStream method, which returns an InputStream. It
can get a URL to one of its own resources via the Class::getResource
method [1]. These methods will not locate resources in other named
modules.
- The ClassLoader::getResource* methods do not locate resources in any
named modules.
_______________________
Although I was a little disappointed this wasn’t quite as easy as it used to
be, my understanding from reading this is should not be possible at all to do a
getResource against the runtime? If they are included in “named modules”?
Doesn’t URLClassLoader using the jrt:/ specification get around this?
Michael Hall
> On Dec 5, 2015, at 11:23 AM, Alan Bateman <[email protected]> wrote:
>
>
>
> 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.
>
>
>
> 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.
>
>
