FYI, all JDK builds contain class files without method bodies shipped. It is used by the compiler, especially as Java 9 now allows the new "-release" switch. The whole stuff is in the ct.sym file (which is a JAR/ZIP file). It contains many small class files of all public APIs, but they are just the signatures.
Another alternative is to just use MethodHandles. You can use them directly in bytecode by referring to constant pool. The idea is to create a MethodHandle pointing to setAccessible() by default. But if Java 9 is detected it just points to trySetAccessible() and uses some adoptions using MethodHandles call signature adoption (guardWithTest, foldArguments,...). We are using similar approach in Apache Lucene for unmapping byte buffers: We just "compile" the method call to a single MethodHandle that’s easy to invoke. It also causes no slowdowns. The Java 8 unmapping is a quite complex MH (folded, guarded,...) and the Java 9 one just delegates to Unsafe: https://goo.gl/sM1gez The MH in Groovy's case could just be directly used in byte code, or called like Lucene's from runtime. There is no slowdown if the MH is declared final (which is very important). Maybe this helps with licensing. Uwe ----- Uwe Schindler [email protected] ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Jochen Theodorou [mailto:[email protected]] > Sent: Sunday, June 4, 2017 3:45 PM > To: [email protected] > Subject: using jdk9 specific API in the Groovy build > > Hi all, > > I did spent some time to think about the problem with using JDK9 > specific API in our build. > > One very basic problem is that the jigsaw parts of JDK9 are still in the > move. API is still changing, and so do command line options. Thus let us > here concentrate on AccessiblebObject#trySetAccessible in this mail > > The basic problem is us doing setAccessible. WE need to do this though, > but without the command line option --permit-illegal-access > setAccessible would fail. So this will be a required option very often. > The next problem is that --illegal-access is printing warnings about who > tried to do setAccessible. In our test build that amounts to 44k > warnings. There will be a new option > > > --illegal-access=<value> > > > > permit or deny access to members of types in named > > modules > > by code in unnamed modules. > > <value> is one of "deny", "permit", "warn", or > > "debug" > > This option will be removed in a future release. > > now, independent of what is set here, we still do not want a warn cause > thousands of warning messages.... which is why we should use > trySetAccessible instead of setAccessible, to avoid that. But this is > JDK9 only. > > Now Remi was suggesting quite some time to go with a patched JDK for > compilation in javac. We would not run against this class, it is only to > compile against (using bootclasspath patching). > > I think is technically possible, but I fear licensing problems. We can > for example not easily just provide the class in bytecode form, since > that means a binary in the source distribution of apache. We can imho > also not just take the class from the OpenJDK and add it to our build, > because then we would distribute a class under GPL. And even if we only > compile against it, this would require a "go" from apache legal in my > opinion. The next option would be to generate a AccessiblebObject class, > which contains all the signatures, but doesn't have to have bodies for > the methods. Problem here: we have to ensure the changes to this class > are reflected in our stub. > > And the other way would be to require JDK9 to build. I think this is > possible now. > > I would like to hear some thoughts on this before I start acting. > > bye Jochen
