[ 
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)

Reply via email to