jigsaw EA feedback for apache lucene

[Sundararajan Athijegannathan]

The forbidden-apis' Checker.java has these lines:

       final URL objectClassURL = 
loader.getResource("java/lang/Object.class");
       if (objectClassURL != null && 
"jrt".equalsIgnoreCase(objectClassURL.getProtocol())) {
         // this is Java 9 with modules!
         isSupportedJDK = true;
       } else {
         final RuntimeMXBean rb = ManagementFactory.getRuntimeMXBean();
         if (rb.isBootClassPathSupported()) {


https://github.com/policeman-tools/forbidden-apis/blob/master/src/main/java/de/thetaphi/forbiddenapis/Checker.java

ClassLoader.getResource for a .class resource is checked to detect if it 
runs on jdk9. This returns a "jrt:" URL in jdk9 EA build - but, returns 
null with jigsaw build. Also, RuntimeMXBean.isBootClassPathSupported() 
returns false.
So, isSupportedJDK will be false.

Better solution would be to check if "jrt" nio file system is available 
& use the same to check and/or read .class files of JDK classes.

-Sundar

On 9/10/2015 10:36 AM, Robert Muir wrote:
> Thanks for posting this EA release! I played around with it just to
> try to get lucene working with it, got the lucene test suite passing,
> though initially tons of tests were failing.
>
> Problems were basically all test/build related:
> * API oddities around FileChannel required a better hack (thanks
> Brian): http://mail.openjdk.java.net/pipermail/nio-dev/2015-September/003322.html
> * Cleaning up a bunch of bad package accesses, these were already
> TODOs in our test security policy, mostly just test bugs and the like.
> * A few silly one-off's like a test that was trying to open
> String.class as a resource
> * some issues with a static analysis tool we use
> (https://github.com/policeman-tools/forbidden-apis), I think it wants
> to look at class files too.
>
> I also started investigating elasticsearch, which is another big
> codebase, but an app versus a library. This will require some more
> work (nothing compiles, all tests fail, app doesnt start) but I can
> report back on that later, after I try to cleanup.
>
> Overall I like how this stuff is more locked down. I do think a lot of
> projects will need to cleanup their code. For both these projects I am
> testing, we already had a nice head start: testing 9-ea versions
> already, running tests with security manager, trying to whittle down
> the bad package accesses for a while now, submit fixes to libraries we
> depend on, etc.