groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Johnson <john...@cs.uiuc.edu>
Subject Re: Advice on compiler bug workaround
Date Tue, 23 Feb 2016 16:25:49 GMT
I understand now what "Unexpected MOP methods" means.  However, I had not
changed the class hierarchy for a few days.  Moreover, I would "clean" the
system, which means that all the classes were recompiled.   So, the problem
is not because I changed the class hierarchy.  Moreover, when I recompile
everything, a different pair of classes would report the errors, so you are
almost certainly right that the problem is caused by the Eclipse build
system and I should use another build tool.   I am trying to use Gradle but
I have never used it before and this is a fairly complex project so it
might take awhile to get it all working.

The change I made on the last day was to copy down a method from a
superclass.   The superclass was in Java.  It was from Vaadin.   The
subclass overrides a lot of methods from the superclass, and in fact should
probably be rewritten to not be a subclass.  I realized that I needed to
change one of the superclass methods, but didn't want to do that.  So, I
copied it down to the subclass.

The method is setItemDataSource, and there was already a setItemDataSource
in the subclass that had "super.setItemDataSource".  So, when I copied the
method down, I gave it a new name "privateSetItemDataSource".  Then I
realized that it was accessing the private variable, "itemDataSource",
which was no longer accessible, and so tried to access it by calling the
version of setItemDataSource in the superclass.  I had the line
  super.itemDataSource = newItemDataSource
and did not get a compile error, but it seemed to cause the error with
unexpected MOP methods.  When I replaced it with
  super.setItemDataSource(newItemDataSource)
then the compile errors went away.

It is compiling better now, but I am still going to get the Gradle build
working

Thanks!

-Ralph Johnson

On Sat, Feb 20, 2016 at 9:35 AM, Jochen Theodorou <blackdrag@gmx.org> wrote:

> On 20.02.2016 13:19, Ralph Johnson wrote:
> [...]
>
>> One file has dozens of errors, all of the form "Unexpected
>> MOP methods in the class node for
>> com.metaficient.xxx.YYY(super$2$toString)" where the xxx.YYY is always a
>> different class in the web app (not in the much bigger library), the
>> number 2 is usually a different small integer, and "toString" is often
>> "toString" but often a different method name, like "getStaticMetaClass",
>> "setReadOnly", or "addItem".  The other file has just one error,
>> "internal compiler error".
>>
>
> first an explanation what super$2$toString means and what it was/is used
> for. Groovy needs to invoke methods, but prior to invokedynamic there is no
> means of invoking a method from outside, you have overridden and where you
> want to invoke the overriden version.
>
> Example, you make a class extending Object, in which you overwrite
> toString() and in there you call super.toString() to get the object
> variant. Would we use reflection to simulate the toSring call we would end
> up in a stack overflow error, since we would not be able to call
> Object#toString, and would always end up calling our new toString. This is
> why we have those super$X$M methods, where X should be the "distance" to
> Object, and M stands for the method. These methods do a special invocation
> just like the JVM would do using the invokespecial bytecode (such an
> invocation is normally only legal in the same class hierarchy). In our
> example you would get something like super$1$toString() then.
>
> This logic has one important drawback, if you add or remove an ancestor,
> you get into trouble.So in Java if you have A extends B, you can easily
> make a change in which B will then extend C, without having to recompile A
> in many cases. In Groovy this will not work, since it now can happen, that
> the call to such a super method will call the wrong method in the hierarchy.
>
> Now imagine A extends B extends C extends D, and you remove C. removing B
> would require recompilation in Java as well, but in Groovy removing C will
> require you recompiling A as well.
>
> Now.. how do we get to "Unexpected MOP methods"? Most likely it means the
> hierarchy changed by the removal or addition of a class and you did not yet
> recompile all needed classes. Remember, in a case of A extends B extends C
> extends D, removing D will require the compilation of C in Java and Groovy,
> but in Groovy also of A and B. And if you don't recompile them together,
> you need first to recompile C, then B and then A. Since you do not compile
> using a build tool it seems, it is possible, that Eclipse tries to compile
> in the wrong order here... especially if the Java rules are applied only.
>
>  The other file has just one error, "internal compiler error".
>>
>
> that sounds like a bug in the compiler
>
> Another state is where it tells me it can't build the library and so
>> can't build the apps.  But then it doesn't tell me anything about why it
>> can't build the library.
>>
>
> Without error message I cannot do much... but I do advice using a build
> tool outside of the IDE. You would get an error message there.
>
> The system was working in the morning, and then it broke.  I know which
>> class I was editing, so I can go back to an earlier version if
>> necessary. However, the code was boring.
>>
>
> Well, what kind of change did you do?
>
> bye Jochen
>

Mime
View raw message