groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniil Ovchinnikov <daniil.ovchinni...@jetbrains.com>
Subject Re: Synthetic GroovyObject methods
Date Sat, 10 Mar 2018 09:36:11 GMT
Thank you for looking into this.

> In an IDE, if you have x.<auto complete keys here> you would then be presented
with getProperty, setProperty and get/setMetaClass. Do we actually want that?

These methods are public and non-synthetic in GroovyObject interface so they will be suggested
independently of their implementations.

—

Daniil Ovchinnikov
Software Developer
JetBrains
jetbrains.com
“Drive to develop”


> On 10 Mar 2018, at 03:48, Paul King <paulk@asert.com.au> wrote:
> 
> 
> We have recently also started adding @Generated to such methods. Originally this was
to assist with better results when doing coverage. One option would be to remove the synthetic
now with the expectation that tools could look for the annotation.
> 
> But I understand Jochen's point that this has been there a while so it might be hard
to understand all the implications for all language users.
> 
> Cheers, Paul.
> 
> On Sat, Mar 10, 2018 at 9:10 AM, Jochen Theodorou <blackdrag@gmx.org <mailto:blackdrag@gmx.org>>
wrote:
> On 09.03.2018 17:19, Daniel.Sun wrote:
> Hi Daniil,
> 
>        Maybe Jochen can tell us the reason.
> 
>        Ping Jochen ;-)
> 
> 
> Checking Verifier I see:
> 
>         if (!node.hasMethod("getProperty", GET_PROPERTY_PARAMS)) {
>             MethodNode methodNode = addMethod(node, !isAbstract(node.getModifiers()),
>                     "getProperty",
>                     ACC_PUBLIC,
>                     ClassHelper.OBJECT_TYPE,
>                     GET_PROPERTY_PARAMS,
>                     ClassNode.EMPTY_ARRAY,
>                     new BytecodeSequence(new BytecodeInstruction() {
>                         public void visit(MethodVisitor mv) {
> ...
>                         }
>                     })
>             );
>             if (shouldAnnotate) methodNode.addAnnotation(generatedAnnotation);
>         }
> 
> This is having only ACC_PUBLIC as modifier, no ACC_SYNTHETIC.
> 
> Using Groovy 2.4.14 to compile class X{} shows this:
> 
>   // access flags 0x1001
>   public synthetic getProperty(Ljava/lang/String;)Ljava/lang/Object;
> 
> Investigating further shows, addMethod is there as well.... investigating more into the
history points me to
> 
> fix for GROOVY-3877. To ensure abstract classes can always be extended in Java, even
if precompiled, all Groovyobject methods must not have the synthetic flag being set. In normal
classes this is no problem.
> 
> but that is only to lift the restriction for abstract classes.... and then it goes to
way before... 891ad59d074990a38d7ba0dca65890e80061158a from Jan 29 2004, a change made by
James explicitly to add synthetic
> 
> I think the idea was that everything the compiler adds as a helper method is supposed
to be synthetic. Most likely back then getProperty and friends have been seen as internal
methods, not to be called directly. And from Java code you rarely do. In most cases you go
through GroovyObject instead. Now given that this is there for like 14 years I think it is
worth spending a minute on the implications.
> 
> In an IDE, if you have x.<auto complete keys here> you would then be presented
with getProperty, setProperty and get/setMetaClass. Do we actually want that?
> 
> bye Jochen
> 


Mime
View raw message