ClassLoader::getResource

[Michael Hall]

> 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 <Alan.Bateman at oracle.com> 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.
> 
>