running Groovy on JDK9

[Jochen Theodorou]

On 16.04.2016 19:16, Uwe Schindler wrote:
> 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!

it is a bigger rewrite, but possible to do, yes.... well... anything but 
the module part. Right now I am only trying to get my tests working, not 
to make a module. And all the jars I am using are no modules either... 
so everything comes in from the classpath atm. The only modules involved 
are the ones from java itself. And for this part I don´t need the 
bytecode of those... right now that is only for the unit tests of a part 
that gets a proper configuration  when normally used.

> 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

thanks, I will keep that in mind.

> 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.

yeah, I am aware of that. I don´t intend to support runtime compilation 
with reading from jars in those environments. We can produce a ClassNode 
(which I need to compile Groovy classes) in two ways. One is by using 
ASM to get the signatures, the other to load using reflective 
information. The later one is the oldest version and cannot do as well 
as other versions because you cannot get annotation constants without 
initializing the class in all cases. Also the ASM version is actually 
faster and can deal with classes, consisting of only the signatures 
(which can be inspected by javac, but not loaded by reflection).

bye Jochen