Community
Participate
Working Groups
Build Identifier: M20110210-1200 If you debug a class with generics in the display view, you get the following error: Evaluations must contain either an expression or block of well-formed statements You need a class with two methods with a generic <T> that extends from two different classes. If the generic extends from the same class or you name the first one <T> and the second one <U> it works fine. Maybe this bug is related to #161364. Testcase: public class Test { public static void main(String[] args) { Bug bug = new Bug(); bug.method1(Test.class); } public static class Bug { public <T> void method1(Class<T> clazz) { // Breakpoint here System.out.println("method1: " + clazz.getName()); } // You can use any other class (instead of Object) here. public <T extends Object> void method2(Class<T> clazz) { System.out.println("method2: " + clazz.getName()); } } } Reproducible: Always Steps to Reproduce: 1. Add a breakpoint in the method1() 2. Debug the main method 3. Open the display view 4. Try to use any java code... System.out.println("hello world"); Evaluation failed. Reason(s): Evaluations must contain either an expression or a block of well-formed statements
This is far from the only case under which this error occurs. Unfortunately, we have not been able to extract additional examples from within the depths of our code, but will add them when we are able. Additionally, the problem can be seen using the test case from the description if you attempt to inspect (Ctrl+Shift+I) any expression from the source context or evaluate any expression in the Expressions view--even literals--while suspended on the breakpoint.
We successfully reduced one of our classes that exhibits this issue to the following test case: public class Test { public static void main(String[] args) { // Add breakpoint on following line; when breakpoint is // hit, evaluate "hello" using Inspect or any expression // (including literals) using the Expressions or Display // views System.out.println("hello"); } private <T> void method1() { } private <T extends Object> void method2() { } } This is quite similar to that provided in the original description, but has some differences: 1. The methods take no arguments. 2. It's not necessary to call the generic methods, nor even instantiate the class. 3. The class with generic methods doesn't have to be a static inner member. 4. The generic methods don't have to contain any code. 5. The generic methods are private. For this test case, we've confirmed the following claims from the original description: 1. Renaming the type parameter of either method (e.g., <T> to <E>, or <T extends Object> to <E extends Object>) fixes the issue. 2. Changing the generic declaration on method2 to remove the extends clause (e.g., <T extends Object> to <T>) fixes the issue. While we're not in any way familiar with the Eclipse code, it seems probable that method type parameters with the same name are being confused; if they are defined differently, they collide, causing the issue. If there is more information we can provide, please let us know. Thank you.
The underlying problem is the same for this bug and 349524 - our AST engine is not compiling the snippet properly and we end up with the following error during the evaluation: 1. Pb(520) Duplicate type parameter T bug 349476 aims to clean up the evaluation failure messages.
*** Bug 349524 has been marked as a duplicate of this bug. ***
Disappointing that the underlying cause is known and yet this isn't going to be fixed for 3.8. I'm tempted to bump up the severity/importance of this - IMHO, no way should expression evaluation be broken under known circumstances in such a mature part of Eclipse. Is there a bug for the incorrect snippet compilation, or just the error messages (Bug 349476)?
Is there any plan to address this issue? It has been in the air for some time already, and (to be frank) its causing some legacy code not debug-able (which is really a pain) On the side: does anyone know any workaround for this, other then removing the generics?
(In reply to comment #6) > Is there any plan to address this issue? > It has been in the air for some time already, and (to be frank) its causing > some legacy code not debug-able (which is really a pain) > > On the side: does anyone know any workaround for this, other then removing the > generics? The last part of Comment 2 has the work-arounds. Changing the type parameter name worked for me.
That this core functionality is not working properly should be considered a blocker. This is much more important than any nifty feature elsewhere. Its hard to understand why this has not been fixed yet and still is not planned to be fixed. What is missing to address this issue?
(In reply to comment #7) > (In reply to comment #6) ... > > > > On the side: does anyone know any workaround for this, other then removing the > > generics? > > The last part of Comment 2 has the work-arounds. Changing the type parameter > name worked for me. This workaround is only helpful if you can change the underlying source, which isn't always an option. Right?
A workaround should not be neccessary for debugging Java Code - which is among the most important features of the Eclipse IDE.
The patch on bug 341232 also fixes this issue, marking as a dupe *** This bug has been marked as a duplicate of bug 341232 ***
I faced the same issue and finds the workaround to inspect. Its very simple. put break point on the line where you need to inspect and select the particular variable or object in the line and select show view "Variable"(go to 'Windows' menu -> select 'Show View' -> select 'Variables' OR Alt+Shift+Q,V) In 'Variables' window you will get all the expecting values can be inspect.
