[groovy-user] Groovy Decompiler

[Steve Amerige]

Is there a Groovy decompiler out there that works (especially if there is a plugin for Eclipse)?  I tried JAD, but it completely failed.

Thanks,
Steve Amerige, Senior Software Developer

[Will Piasecki]

Hey! Last time i used jd (java.decompiler.free.fr/) to decompile a groovy class and it worked great.

---

De: Steve Amerige <Steve....@sas.com>
Para: us...@groovy.codehaus.org
Enviadas: Domingo, 23 de Setembro de 2012 9:34
Assunto: [groovy-user] Groovy Decompiler

[Jochen Theodorou]

Am 23.09.2012 14:34, schrieb Steve Amerige:
> Is there a Groovy decompiler out there that works (especially if there
> is a plugin for Eclipse)? I tried JAD, but it completely failed.

you have to see though, that decompiling groovy bytecode to Java cannot
always work and is often not very readable. The decompiled source may
not compile, but I guess that is ok. The reason for not being very
readable is the custom call site caching we are doing. The method names
simply do not stay with the call site places in that one. And if you
decompile groovy code that used indy, then I doubt the decompiler can
make anything out of that in Java, since Java does not support
invokedynamic in source.

So what you see is an "idea" of how it could maybe look in Java, but by
no means it is a correct representation in every case.

Unless the decompiler knows Groovy... then it should decompile to Groovy
though

bye blackdrag


--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Steve Amerige]

Hi Jochen (or do you prefer Blackdrag :-),

Thanks for your reply.  My motivation for decompiling Groovy .class files is part of an internal training course that I'm preparing in which I can more clearly expose access details as they relate to the "private" and other modifiers as they are used on and within classes.  Exposing access details for Groovy constructs such as "public", "private", "protected", the ".@" operator, the "@PackageScope" transformation, etc., can be helpful and I am thinking that looking at decompiled Groovy code might be useful in this regard.

Many thanks again!

Steve Amerige, Senior Software Developer

SAS Institute

[Bob Brown]

The thought occurs that if training and understanding of the 'innards' of
Groovy is your goal, perhaps you could look at the AST browser:

http://groovy.codehaus.org/Groovy+Console
http://groovy.dzone.com/articles/groovy-ast-browser-web-now

HTH,

BOB

> Thanks for your reply. My motivation for decompiling Groovy .class files
is
> part of an internal training course that I'm preparing in which I can more

[Cédric CHAMPEAU]

wow, I didn't know about the web version of the AST Browser. Cool :)

Le 26/09/2012 14:08, Bob Brown a �crit :

[Jochen Theodorou]

Am 26.09.2012 13:37, schrieb Steve Amerige:
> Hi Jochen (or do you prefer Blackdrag :-),

Jochen, blackdrag, theo... I am used to all of them ;)

> Thanks for your reply. My motivation for decompiling Groovy .class
> files is part of an internal training course that I'm preparing in which
> I can more clearly expose access details as they relate to the "private"
> and other modifiers as they are used on and within classes. Exposing
> access details for Groovy constructs such as "public", "private",
> "protected", the ".@" operator, the "@PackageScope" transformation,
> etc., can be helpful and I am thinking that looking at decompiled Groovy
> code might be useful in this regard.

but frankly I am not sure it is good to show the bytecode or the
decompiled code for this. Take for example a private method... Since
many of our calls go either through Reflection or through runtime
generated classes we don't call the private method directly. Instead our
custom call site caching will select a helper method this$... which is
marked as public and synthetic to make the call. In there you find a
direct method call. But the call to the private method may not be
direct. If it really goes through our custom callsite caching you see
only something like getCallSiteArray[x].invoke(), where x is the index
of the method in the call site array, representing our cache. With a
Groovy >=1.8.0 you will also see the primopts path, which may contain a
direct method call to that method and does not use the helper method at all.

What I am trying to say is that the decompiled code, even if the
decompiler is halfway good, will produce a lot of code for a small
snippet of Groovy code and 90% of that code is not interesting.

I am just wondering if you will really reach your goal that way. on the
other hand, if the goal of that internal training is to show each and
every dirty little detail Groovy does, then this is surely ok... though
you could maybe go with disassembled bytecode then ;)