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

Reply via email to