Hi There

I ran into an unexpected behaviour with the MXJClassLoader compared to the regular java class loader. This difference leads to problem where the URL cannot be used to make an URI (and resources fail to load). Lets me give some context first.

The classloader can be used to find a file within a jar file. It can return you an URL to that file. For example:

URL url = this.getClass().getClassLoader().getResource( "myfile.txt" );

The URL is used in some libraries (for example, I am using the Netbean Platform libraries) to extract the resource from the jar file. In NetBeans case, it will create a URI from the URL as part of its processing. A URI is more syntax specific than a URL. Which is where I noticed the difference.

If I were to use regular java code, without MaxMSP to acquire the URL, this is an example what the URL would be as a string.

jar:file:/F:/temp/lib/myfile.jar!/myfile.txt

Now here is where the oddity. It depends how the jar file is included for the Max System using the max.java.config.txt. If I include it using the ‘max.system.jar.dir’, I get the same output as a regular classloader would provide. However, if use the ‘max.dynamic.jar.dir’ to include the jar, I get the following output:

jar:file:F:\temp\lib/myfile.jar!/myfile.txt

There appear two things here that prevent this URL from being convert to an URI and a File for reading.

1) The slashs are the wrong way (I am using windows). URI can’t handle the windows style of path slashes.
2) There is no leading slash, which would not allow the URI to be used to create file (even if you were to converted the to /)

I have attached the jar file with a resource in it, a regular java application and a java object than extends MaxObject to reproduce this scenario. Would someone be able to comment as to whether the second behaviour for dynamic class paths is expected? More importantly whether it can be changed to be consistent with the regular classloader in both cases?