Hi again,

I was on my mobile only, so here is the "lengthy" explanation:

> FYI: first oddity i noticed is coming from some groovy code that seems
> to run as part of "common.test" ?
> -check-totals:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/home/hossman/.ivy2/cache/org.codehaus.groovy/groovy-
> all/jars/groovy-all-2.4.15.jar) to method java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> 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

This is a warning that's triggered by the default behavior of Groovy to call 
"setAccessible" on all and every field/method of every class it sees. If it 
does this on a JDK one, the warning is printed. But for Groovy it's harmless, 
as a failing "setAccessible" is just ignored. The method is then just not 
available. As our Groovy code does not need to access private stuff, it does 
not matter is these are accessible or not.

Gradle is also full of those warnings, they are just hidden by the startup 
scripts that passes a special flag to the JVM. For Ant we can't do this, as 
it's not our startup script. If Java forbids in a later version that we access 
internal classes - who cares?! The whole thing is a stupidity in early Groovy 
versions when they decided that Groovy has access to everything by default. 
Stupid decision, but we have to live with it. Groovy is still arguing against 
the default in Java to print the warning, but there are no movements. As far as 
I know in Groovy 3 they may have removed that legacy behaviour, but I am not 
sure. Let's try it out.

For now, just ignore the warning, it's harmless! Asciidoctor has a similar 
problem BTW, but there it might be serious as a failure to make something 
accessible may block it from running.

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to