Community
Participate
Working Groups
I've upgraded to 3.0M6 today. When I compile, I get very strange errors (see attached image). Only a few methods in my project (roughly 1 million lines of code) is affected. The methods can be in the same class (as in the image) or in another one. My compiler settings: Compliance level: 1.3 .class file compat: 1.1 Source compat: 1.3 Disallow assert: Warn Disallow enum: Warn My first guess would be that there is a problem with the generated method tables. I've read somewhere that the method tables are optimized for Java 1.5 but it seems that this interferes with 1.3. Building a small test case didn't show the error. But the error could be fixed by adding protected void waitForMessage2 () {}; just below the definition of the abstract waitForMessage().
Created attachment 37496 [details] Screenshot which shows the problem
Just noticed a typo: That should be 3.*2*M6, of course :-)
Steps to reproduce are needed to further investigate.
Method tables are not specifically optimized for Java5. Since M6, methods are internally sorted, and binary search is performed. Maybe a bug got introduced in then, but our testing doesn't exhibit it (we do compile way more code during our testing than 1 million lines). So unless you cannot provide steps to recreate, then there is little we can do, unless someone else reports the same issue with steps. Couldn't you provide the source in a form or another ?
Unfortunately, the code is part of an internal, commercial project which I must not disclose. Can you please tell me where in the code this sorting happens (plugin, filename, method)? Also at which place in the Eclipse source code is the squiggle in the text editor generated? I could set a breakpoint there to see what the compiler *thinks* is in the method table.
This isn't something easy to find out unfortunately. Then your best chance is to narrow the problem to something simpler if possible.
As I said, it happens at three places in a million lines of code. When I add another method, the error goes away. Clean all, force rebuild, closing and reopen the project and restarting Eclipse have no effect. I'm pretty sure it must be somewhere in the new binary sort code. Tomorrow, I'll play with compiler settings (1.4 and 1.5) plus I'll see what happens when I delete a method. Maybe I can create a test case which contains only the method names but no code. My boss might accept that I send you the single file, then.
After some experiments, I found the following: - The bug wasn't present in 3.2M5a. It must have something to do with the latest changes to the Java compiler. - Reordering the methods in the source doesn't affect the bug. - Adding fields has no effect. - Adding another method affects the bug. - When I add xxx(), the bug goes away. - When I add a(), the bug goes away. - I experimented with different flags (public, private, static). It seems that only the method name has an effect. - When I duplicate a() (so I get a "duplicate method name error"), the bug appears again. - Renaming the method to waitForMessage2() has no effect. - Renaming the method to aaa() fixes the bug - Changing the throws clause has no effect - Changing the class tree (class xxx extends yyy) has an effect - Changing the class name has no effect - Setting the generated .class files compatibility from 1.1 to 1.3 fixes it - 1.2 works as well - 1.1 doesn't work Can you create a patched version which doesn't sort the methods when 1.1-mode is selected?
Not really. Sorting is expected everywhere now. However, the target difference is an interesting hint. Will investigate, thanks for the info.
We may have a test case, see bug 134839. Once it gets fixed, Aaron, can you grab the corresponding nightly build and assess if it also addresses your problem ? Will cc'you on bug 134839
Fix got released to HEAD, a patch will be posted asap (see bug 134839). Will assume this is a dup of bug 134476. Pls consider the patch, and reopen this issue in case the patch doesn't correct your scenario. *** This bug has been marked as a duplicate of 134839 ***
The bug is fixed in 3.2RC1a I can also confirm that it was related to an abstract class, so the cause seems in fact to be the same as bug 134839.
Thanks for confirming
