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
