Hi, You can still get a InputStream to bytecode of JDK-internal classes: if you get the module of the Class and then call getResourceAsStream from there. I walked that route for the forbidden-apis checker with reflection: This tool needs the bytecode of runtime classes!
Code that loads bytecode of classes of the runtime with reflection: https://github.com/policeman-tools/forbidden-apis/blob/master/src/main/java/de/thetaphi/forbiddenapis/Checker.java#L223-L252 This is the reflective initialization part (to detect pre-Java 9, Java 9 without Jigsaw and Java 9 Jigsaw) and setup the 3 different possibilities: https://github.com/policeman-tools/forbidden-apis/blob/master/src/main/java/de/thetaphi/forbiddenapis/Checker.java#L132-L198 /please note, forbiddenapis also wants to know which classes of a classloader come from runtime and which are outside). So it also looks into module name (starts with java.* Or jdk.*) or if it comes from rt.jar (pre-Java 9). So code is more complicated than needed for your usecase. Unfortunately this is fine for tools like forbiddenapis that run in your build system like Maven or Gradle, but fails horrible with certain security manager configs. Maybe it is still helpful. I would like to have an explanation by the OpenJDK developers, why Jigsaw no longer returns jrt:// URL in ClassLoader#getResource on foreign modules - what the reason for this? Those hacks needed because of this to get byte code of runtime classes is incredible stupid! Uwe ----- Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf > Of Jochen Theodorou > Sent: Saturday, April 16, 2016 5:24 PM > To: jigsaw-dev@openjdk.java.net > Subject: Re: running Groovy on JDK9 > > On 10.04.2016 20:29, Jochen Theodorou wrote: > [...] > > so another change in JDK9 makes tests failing and that is that I can no > longer use ClassLoader#getResource to get an URL to a class. I remember > reading about this change here. I can work around this by using a class, > that does not originate from a module, just wanted to mention, that our > normal unit tests showed such a problem as well > > bye Jochen
