jigsaw EA feedback for apache lucene

[Uwe Schindler]

Hi,
 
> On 10/09/2015 06:06, Robert Muir wrote:
> > :
> >
> > 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.h
> > tml
> This one is subtle is that it was using core reflection to call a protected
> method in sun.nio.ch.FileChannelImpl. Static analysis with tools such as jdeps
> don't find cases like this. Good to see that a solution was found to this.
> 
> > * Cleaning up a bunch of bad package accesses, these were already
> > TODOs in our test security policy, mostly just test bugs and the like.
> "bad package accesses", do you mean direct use of JDK-internal classes?
> As you mention security policy then I will guess that these must be granting
> of accessClassInPackage.$PKG because the default policy when running with
> a security manager does not allow direct access to sun.* APIs.

That was the case here, we were able to remove it: http://goo.gl/nBsmK4
This only affected some tests but we were able to solve the problem. As Robert said, it was on our TODO list already.
Tests sometimes want to assert special stuff. Production code in Lucene Core never used stuff like that.

> > 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.
> Thanks for sending the mail with your experiences, this is exactly the type of
> discussion we are interested in.

Thanks for providing the builds before they are included into EA builds!

I will respond to the answer from Sundararajan Athijegannathan about the forbiddenapis static analysis tool, because this really causes headaches. For now we can no longer do the static analysis for our code quality, if you build Lucene with Java 9. The getResourceAsStream()/getResource() on JIGSAW packages always returning null is a disaster, also for many mocking frameworks or stuff that needs to "see" the bytecode in an easy way. Using the jrt-Filesystem makes the code horrible, because you have to mimic the whole classloader! And you cannot easily do that in tools that need to compile with Java 5 or Java 6 (most stuff in Maven/Ant has this requirement). :(

Uwe