groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "mgroovy (JIRA)" <>
Subject [jira] [Commented] (GROOVY-8385) CompileStatic: Improved method call/property access Java compatibility for Minecraft Forge obfuscation support
Date Sat, 09 Dec 2017 15:44:01 GMT


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:
// 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
I cannot do
entity.super.hurtResistantTime = 0
here. In addition the question would be, if this would work if the entity hit was actually
implemented in Groovy, e.g. 
// Groovy class extending Minecraft Java class
class MyExtendedEntityCow extends net.minecraft.entity.passive.EntityCow  { ... }

> CompileStatic: Improved method call/property access Java compatibility for Minecraft
Forge obfuscation support
> --------------------------------------------------------------------------------------------------------------
>                 Key: GROOVY-8385
>                 URL:
>             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
> ## 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

View raw message