[ https://issues.apache.org/jira/browse/GROOVY-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284807#comment-16284807 ]
mgroovy commented on GROOVY-8385: --------------------------------- @[~paulk]: Finally had some time to look at this again. Here is an example where the problem occurs when working with a Minecraft object passed as a parameter to my Groovy class: {code} // attackEntity_GROOVY_8385_Sample lives inside Groovy Minecraft Mod class private void attackEntity_GROOVY_8385_Sample(net.minecraft.entity.Entity entity) { entity.attackEntityFrom(DamageSource.causeThrownDamage(this, this.owner), 100) // this works // Following line throws e.g. groovy.lang.MissingPropertyException: No such property: hurtResistantTime // for class: net.minecraft.entity.passive.EntityCow // (when e.g. hitting a Minecraft cow entity) entity.hurtResistantTime = 0 } {code} I cannot do {code} entity.super.hurtResistantTime = 0 {code} here. In addition the question would be, if this would work if the entity hit was actually implemented in Groovy, e.g. {code} // Groovy class extending Minecraft Java class class MyExtendedEntityCow extends net.minecraft.entity.passive.EntityCow { ... } {code} ? > 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)