groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject using jdk9 specific API in the Groovy build
Date Sun, 04 Jun 2017 13:45:08 GMT
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

Mime
View raw message