Rolando Chaparro Fox created GROOVY-9718:
--------------------------------------------
Summary: Illegal reflective access operation to constructor
sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS
Key: GROOVY-9718
URL: https://issues.apache.org/jira/browse/GROOVY-9718
Project: Groovy
Issue Type: Bug
Components: jdk conflict
Affects Versions: 3.0.5
Environment: OS: Linux Ununtu 20.04.1 (Xubuntu flavor)
JRE version: OpenJDK Runtime Environment 11.0.8 64-Bit
Groovy Version: 3.0.5
Reporter: Rolando Chaparro Fox
Hello,
The following piece of code triggers a Warning in Java 11:
{code:java}
import sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS as ModuleInitArgs
// This CK_C_INITIALIZE_ARGS constructor call triggers the warning
ModuleInitArgs initArgs = new ModuleInitArgs()
{code}
This is the Warning:
{noformat}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.codehaus.groovy.reflection.ReflectionUtils
(file:/home/rchfox/somewhere/groovy-3.0.5.jar) to
constructor sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS()
WARNING: Please consider reporting this to the maintainers of
org.codehaus.groovy.reflection.ReflectionUtils
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future
release{noformat}
The above constructor call works fine, nonetheless .
Not quite sure, but apparently CK_C_INITIALIZE_ARGS has no explicit
constructor. Here the source code at openjdk.java.net:
[CK_C_INITIALIZE_ARGS.java|http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_C_INITIALIZE_ARGS.java]
What I know is that this "constructor" call did not trigger any warning in Java
<= 1.8.
*Side note #1*: I kind of understand the Java designers' mindset. I guess that
the idea behind this is not exposing implemented functionality required by
callers of a function/method/constructor, so that the calling code awkwardly
re-implements the same functionality in terms of those calls.
Probably the OpenJDK crypto team guys expect nobody should ever need to invoke
the CK_C_INITIALIZE_ARGS constructor. However, in my case in particular, I
haven't found yet any sound programmatic alternative to implement the
functionality I need.
*Side note #2*: I managed to bypass this issue using the new {{--add-opens}}
JVM argument (available since Java 9), as suggested in Oracle's [Migration
Guide|https://docs.oracle.com/en/java/javase/11/migrate].
However, I still need to solve this issue by other means because my app (a
JavaFX/GroovyFX Application) is launched through JWS/JNLP, using the
OpenWebStart implementation, which in turns has a bug right now that prevents
me using the new {{--add-opens}} JVM argument, as I've just reported
[here|https://github.com/karakun/OpenWebStart/issues/322].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
