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 uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Alan Bateman [mailto:alan.bate...@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
