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 <[email protected]> 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 >
