You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Jochen Theodorou <bl...@gmx.org> on 2017/06/04 13:45:08 UTC
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
Re: using jdk9 specific API in the Groovy build
Posted by John Wagenleitner <jo...@gmail.com>.
I like the idea of using a MethodHandle and it seems like a nice solution
that wouldn't require building with Java 9. Though I imagine that there
will probably be other changes that may require using the new module
related classes that would require building with Java 9.
On Sun, Jun 4, 2017 at 10:21 AM, Uwe Schindler <us...@apache.org>
wrote:
> 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
> uschindler@apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
> > -----Original Message-----
> > From: Jochen Theodorou [mailto:blackdrag@gmx.org]
> > Sent: Sunday, June 4, 2017 3:45 PM
> > To: dev@groovy.apache.org
> > 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
>
>
RE: using jdk9 specific API in the Groovy build
Posted by Uwe Schindler <us...@apache.org>.
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
uschindler@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -----Original Message-----
> From: Jochen Theodorou [mailto:blackdrag@gmx.org]
> Sent: Sunday, June 4, 2017 3:45 PM
> To: dev@groovy.apache.org
> 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