[
https://issues.apache.org/jira/browse/GROOVY-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16263618#comment-16263618
]
mgroovy commented on GROOVY-8385:
---------------------------------
* @[~blackdrag]: I agree 1 is the obvious best choice. However it does not seem
like any of the core contributors will have the time to work on this in the
foreseeable future (it just is not one of the pressing issues - also as I
explained I believe it is underappreciated - and there is a lot of ground to
cover). I myself would like to work on this, but I am not sure I would have the
expertise right now, to be sure what I do does not break @CompileStatic (which
would obviously be bad).
* I therefore think easing into this might be the better and more practical way
forward. If we introduce a @CompileStatic parameter (forceStaticCalls,
obfuscationSupport, maxJavaCompatibility, ...), everyone who has need for more
Java compatibility in this regard, can give the parameter a try. We would get
feedback which cases to improve over time, and after some time might just flip
the default value for the parameter, enabling the remaining rare cases to get
the old, more dynamically compatible call bytecode generation.
> CompileStatic: Improved method call/property access Java compatibility for
> Minecraft Forge obfuscation support
> --------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-8385
> URL: https://issues.apache.org/jira/browse/GROOVY-8385
> Project: Groovy
> Issue Type: Improvement
> Components: bytecode
> Reporter: mgroovy
> Priority: Minor
> Labels: Forge, Java, JavaCompatibility, Minecraft, Modding
>
> * Even with @CompileStatic the Groovy compiler creates bytecode for method
> calls / property access which is dynamic in nature.
> * This means that e.g. Minecraft Forge's obfuscator does not pick up the
> calls in the generated bytecode, which means they do not get obfuscated,
> which in turn makes the code fail when executed in Minecraft.
> * This effectively makes it nearly impossible to write Minecraft mods with
> Groovy, which in turn is a wasted opportunity to get people involved with
> Groovy early on.
> * Possible approaches to improve the situation:
> ## Improve on a fundamental level: According to [~paulk] only a few calls are
> required to be done dynamically for Groovy functionality to work as expected
> under @CompileStatic.
> *** The problem seems to be that it could be hard to be a 100% sure no edge
> case is overlooked, as to not break @CompileStatic in situations where e.g.
> no 100% Java-call-compatibility is needed.
> ## Improve through newly introduced @CompileStatic parameters
> *** => Static method call / property access bytecode is generated for method
> code / all class methods repectively (with possible exceptions for the know
> cases mentioned above).
> ## Improve through newly introduced @ObfuscationJavaCompatibility annotation
> that can be put on a method or class
> *** behavior same as for @CompileStatic parameters above
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
