You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Rolando Chaparro Fox (Jira)" <ji...@apache.org> on 2020/09/04 01:42:00 UTC
[jira] [Updated] (GROOVY-9718) Illegal reflective access operation
to constructor sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS
[ https://issues.apache.org/jira/browse/GROOVY-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rolando Chaparro Fox updated GROOVY-9718:
-----------------------------------------
Description:
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].
was:
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].
> 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
> Priority: Critical
>
> 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)