Open Collective
Open Collective
Progressing towards Groovy 3.0.0 with greatly reduced illegal access errors
Published on May 12, 2019 by Paul King

Once again, a big thank you to our contributors. You are enabling us to more rapidly progress the Groovy language and other important projects in the Groovy ecosystem. We are happy to report on another activity that we have helped support and that is initial Groovy 3 improved support for JDK 9-13 changes to greatly reduce illegal access warnings. Special thanks for working on this task go to Daniel Sun.

As many of you would know, JDK9 and above support the Java Platform Module System. This system is designed to improve performance, security, and maintainability within the JDK. While not strictly enforced yet, the JVM flags previously allowed forms of access. The access still currently works fine without any reduced functionality but gives an intrusive warning message and on some yet unknown future JVM version may simply no longer work. The JPMS restrictions aren't too bad to work with for most traditional Java projects but pose a problem for some kinds of usage patterns that exist in the Java ecosystem. Some modes of using Groovy fall into the problematic territory. Groovy's flow typing and flexible access modes for testing weren't accounted for by the JDK team when providing alternatives to some of the access patterns they were trying to reduce or eliminate. This has meant fixing these problems has taken some time. The good news is that the work Daniel has done has allowed us to make great strides in this area. We still have plenty to do but many users will no longer see these intrusive warnings!

Here are some examples. On Windows, we checked versions, ran the groovy commandline, groovysh REPL and groovyConsole. Note no warning messages are appearing.

While the console was open, we ran the script and inspected the AST.

On Linux, we checked versions, ran the Groovy command line and compiled a Groovy script. Note no warning messages are appearing.

Expect to see further improvements as we:

  • work on moving more of the generated bytecode to use invoke dynamic capabilities
  • make the generated bytecode smarter to handle some more complex cases
  • provide further module support down the track