groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From grv87 <gr...@yandex.ru>
Subject Re: Help: At wit's end with failing transformation
Date Fri, 07 Dec 2018 20:37:35 GMT
Hit this recently by myself. In modern Groovy (2.5) there are @CompileStatic
and @TypeChecked annotations. But, if you create new class or method node in
local AST transformation and try to annotate it with those, this won't work.
The reason is that code that they are implemented with local AST
transformations too, and the code that detects which transformation should
be applied is run before your AST transformation. More exactly, it is run in
SEMANTIC_ANALYSIS phase. And you can't create local AST transformation
before this phase.

Workaround that I found is to call appropriate transformation by yourself:
new StaticCompileTransformation().visit([new
AnnotationNode(ClassHelper.makeCached(CompileStatic), node] as ASTNode[],
sourceUnit)
In this case it works. Hope it'll help somebody.
In more complicated cases (with different annotations) this may not work
since that transformation may require specific phase and don't work in
yours.

Best regards,
Basil Peace


Alex Tkachman wrote
> This is because default getter setter are generated directly in byte
> code and your code works via standard Groovy compiler, which assume
> all possibilities of dynamic dispatch and meta programming magic.
> 
> The option you have is to grab Groovy++ and  add @Typed annotation to
> some of the methods you generate. It will produce as fast bytecode as
> Java does.
> 
> On Thu, Jan 20, 2011 at 11:31 PM, Matthew Adams &lt;

> matthew@

> &gt; wrote:
>> Hi Hamlet,
>>
>> Based on your message, I experimented with some different ways of
>> implementing the statement generation for the getter, which left me
>> with some confusion (surprise) on what I saw.  If you get the latest
>> from http://repo.matthewadams.me/groovypropertyastx, you can gradle
>> compileTestGroovy, then decompile the class
>> GroovyClassWithPropertyAnnonatedField to see what the implementations
>> of the property methods look like.  You can decompile class "Vanilla"
>> to see what groovyc is doing.
>>
>> What I can't explain is why groovyc produces the simplest of property
>> method implementations, specifically "return foo" and "this.foo =
>> paramValue", whereas the implementations generated after my transform
>> have all sorts of Groovy MOP/reflection gobbledy-gook (see below).
>> Note the ScriptBytecodeAdapter stuff in both methods and the two
>> return statements in the decompiled setter.  WTF?
>>
>> // Decompiled with Emmanuel Dupy's Java Decompiler (JD) v0.3.3 GUI
>> over v0.6.0 Core
>>
>> public class GroovyClassWithPropertyAnnotatedField
>>  implements GroovyObject
>> {
>>  private String prop;
>>
>>  public GroovyClassWithPropertyAnnotatedField()
>>  {
>>    GroovyClassWithPropertyAnnotatedField this;
>>    CallSite[] arrayOfCallSite = $getCallSiteArray();
>>    MetaClass tmp12_9 = $getStaticMetaClass();
>>    this.metaClass =
>> ((MetaClass)ScriptBytecodeAdapter.castToType(tmp12_9,
>> $get$$class$groovy$lang$MetaClass()));
>>    tmp12_9;
>>  }
>>
>>  protected void setProp(String value)
>>  {
>>    CallSite[] arrayOfCallSite = $getCallSiteArray();
>>    String tmp5_4 = value; this.prop =
>> ((String)ScriptBytecodeAdapter.castToType(tmp5_4,
>> $get$$class$java$lang$String())); tmp5_4; return; return; }
>>  protected String getProp() { CallSite[] arrayOfCallSite =
>> $getCallSiteArray(); return
>> (String)ScriptBytecodeAdapter.castToType(this.prop,
>> $get$$class$java$lang$String());
>>  }
>>
>>  static
>>  {
>>    Long tmp6_3 = Long.valueOf(0L);
>>    __timeStamp__239_neverHappen1295562007912 = (Long)tmp6_3;
>>    tmp6_3;
>>    Long tmp20_17 = Long.valueOf(1295562007912L);
>>    __timeStamp = (Long)tmp20_17;
>>    tmp20_17;
>>    return;
>>  }
>> }
>>
>> What gives?  Why are groovyc's methods so special and my methods are
>> so special ed?
>>
>> I've really beefed up the unit tests to cover almost all of the basic
>> functionality and all of the tests are passing, which include not only
>> behavioral tests, but Java reflection-based tests for the correct
>> artifacts on the generated classes.
>>
>> Thanks,
>> Matthew





--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Mime
View raw message