Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.7.10
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:wnidows xp
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)
-
Number of attachments :
Description
Following code prints 1 or 2 from time to time I start it. Tried at http://groovyconsole.appspot.com. This code generates error there:
java.lang.NoSuchFieldError: __$stMC at I1( or I2!!!!!!!!!!!!!!!!!!!!).<clinit>(Script1.groovy) at Script1.run(Script1.groovy:9)
but error differs from time to time too.
interface I1{ int VALUE = 1 } interface I2{ int VALUE = 2 } class C implements I1, I2{ } println(new C().VALUE)
Issue Links
- is related to
-
GROOVY-4756
wrong usage of _$st in interfaces
-
I splitted out the __$stMC problem for 1.8, which is realted to the performance improvements I implemented and therefore should be treated with more priority as this non-critical bug. As ofr the bug here I guess the best route would be to actually disallow it by the compiler. Only that in Java, the compiler does allow this construct. Only when you request VALUE, it will be marked as error. The only way for gRoovy would be to check in the implementing part and then throw an error here. But still, what if the interfaces and C are defined in Java. We would have to flag the println part from the Java perspective. If we don't then we would still get these strange differing outputs. On the other hand, people could simply add an VALUE field per MOP, then it would not be an error. We could maybe, when creating the meta class for C recognize that there are two fields of name VALUE and then make the usage of the field throw an erro that shows the ambigouty. I guess that would be the route that would work reliable and produces similar results to Java