Review changes caused by JIGSAW packaging and fix class loading and class traversal issues

[GoogleCodeExporter]

See http://openjdk.java.net/jeps/220

In future, the bootclasspath of Java will no longer be rt.jar and the URLs 
returned by Class.getResource() will no longer be "jar:" URLs. We have to fix 
the code that does classpath traversal to respect this.

This also affects the code that creates the deprecated lists from rt.jar.

It is currently unknown if there will be a good way to enumerate all class 
files in a classpath...

Original issue reported on code.google.com by uwe.h.schindler on 31 Oct 2014 at 9:19

[GoogleCodeExporter]

This mainly affects code here:

Inspection of "bootclasspath" to find out if a referenced class is a runtime 
classpath. I think, this can be simplified to simply check for jrt:/ url: 
https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/th
etaphi/forbiddenapis/Checker.java?r=315#100 and 
https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/th
etaphi/forbiddenapis/Checker.java?r=315#166

We have to change DeprecatedGen and the corresponding ANT task, because it 
expects rt.jar: 
https://code.google.com/p/forbidden-apis/source/browse/trunk/src/tools/java/de/t
hetaphi/forbiddenapis/DeprecatedGen.java?r=315

Original comment by uwe.h.schindler on 31 Oct 2014 at 9:41

[GoogleCodeExporter]

"A built-in NIO FileSystem provider will be defined for the jrt URL scheme so 
that development tools can enumerate and read the class and resource files in a 
run-time image by loading the FileSystem named by the URL jrt:/, [...]"

So it seems there will be a way to scan modules. Interesting.

Original comment by dawid.weiss@gmail.com on 3 Nov 2014 at 10:38

[GoogleCodeExporter]

Hi Dawid,
yes the FS api is the way to scan modules. The problem in forbidden is: the 
code must compile against java 5 or 6, so no way to easily use that stuff.

In general, the filesystem API does not yet allow to scan the whole classpath 
for packages or classes. To do that you still need to do that manually by 
handling every classpath component on their own (depending on the URL provided 
as cp component). In my opinion, ClassLoader should add methods to list 
packages reachable by the classloader and also to list all classes in those 
packages. With these new changes in jigsaw this comes more and more to be a 
requirement to build IDEs or other code tools.

Rory O'Donnel asked me to ask this question about classpath inspection to the 
Jigsaw mailing list. I already posted it in response to his mail on another JDK 
list.

Original comment by uwe.h.schindler on 4 Nov 2014 at 11:24

[GoogleCodeExporter]

Yeah, I read the jigsaw docs and I don't think scanning for classes will be/ is 
supported by that custom filesystem provider. Would have to check.

As for supporting multiple JVM versions - this should be doable with some 
engineering tricks, but the simplest solution would be most likely to create 
separate builds for >= 1.9 and the rest of Java environment.

In any case, great tool Uwe!

Original comment by dawid.weiss@gmail.com on 4 Nov 2014 at 11:30

[uschindler]

Detecting if a class in Java 9 is coming from the runtime is damn simple:
"jrt".equalsIgnoreCase(loader.getResource("java/lang/Object.class").getProtocol())
"jrt" means Java runtime and is reserved for all resources coming from the runtime, so isRuntime is very easy to detect. No bullshit needed like getting bootclasspath through RuntimeMXBean.