jigsaw EA feedback for apache lucene

[Uwe Schindler]

Hi Alan,

thanks for the useful information. I was able to fix the forbidden-apis checker to work correctly using the Class#getModule() approach. This can be done with easy core reflection also from older code that has to compile against Java 6. I tested it with the nightly build of b80 and works perfectly, whole testsuite of the checker passes.

Here is the description what I do:
https://goo.gl/9oT2Ch

And this is the patch:
https://goo.gl/noOYgD

I still think that the resource encapsulation is a good thing, but on the other hand at least the special case "get bytecode of class I have access to" should be supported, maybe deprecated.

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/


> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Thursday, September 10, 2015 2:47 PM
> To: Uwe Schindler; jigsaw-dev
> Subject: Re: jigsaw EA feedback for apache lucene
> 
> Uwe Schindler wrote:
> > So you would first to find out the module of a class and then ask the
> module for the resource. Is there a way to get the module from the binary
> (string a la Class#forName()) class name without actually loading the class?
> Yes, you'd need the Class object so you can call getModule().
> 
> >
> > The second problem for such checkers is: Unfortunately this needs Java 9
> at compile time... On solution for this would be to wrap the checker's internal
> loading mechanism with a class solely compiled for Java 9 at runtime, if Java 9
> was detected - that provides the missing resources - older Java versions
> would use the approach as currently implemented.
> This will work, or would using core reflection. I assume you've seen JEP
> 238 and the proposal for multi-release JAR files.
> 
> 
> > :
> >
> >
> > Is there a reason why the (system-) classloader does not return any
> resources from foreign modules anymore? I agree that some internal
> properties files and so on are not needed to be available, but if a caller can do
> Class#forName() on a specific class that is public on top, why should it not
> also do a getResource() call on the class's bytecode - this makes no sense to
> me? Many frameworks like Google Guice, Spring,... rely on that because they
> may need to create proxy classes and therefore need to have the bytecode.
> So to me this seems like a major break!
> One of the design issues that the JSR will need to decide is whether
> resources in a module are encapsulated, see:
> http://openjdk.java.net/projects/jigsaw/spec/reqs/#resource-
> encapsulation
> 
> As things stand in the current builds then code in a module can get at
> any of the resources in its own module (Class.getResourceAsStream) but
> it can't use the legacy APIs to get at resources in other named modules.
> The legacy APIs work exactly as before for resources in unnamed modules
> (think JARs on the class path). Fameworks that scan the class path for
> resources will work as before but would need changes to get at resources
> in named modules.
> 
> -Alan