Community
Participate
Working Groups
3.3 M5 see also bug 174327 - Example taken from bug 174265: ------- Try.java ----------- package org.example; import java.util.Collections; import java.util.Map; public class Try { void caller() { method(Collections.emptyMap()); } void method(Map<String, String> map) { } } ------------------------------ - there is a compile error in the caller method > a quick fix to parameterize the emptyMap call could be provided, resulting in the following code: method(Collections.<String,String>emptyMap());
*** Bug 176734 has been marked as a duplicate of this bug. ***
Wake up, Becker! :)
Hey Becker, instead of working on fancy not-opensourced screenshot tools, what about this one :)?
Ok, I'm working on it ;) Infact I had several longer discussions with Martin about this one. And the problem we do have with this one is, that the return type of the Collections.emptyMap() Statement does not contain the parametrized information. This is due to fact of the way the compiler is implemented. The parameter case differs from the local variable assignment case. In the following case: Map<String,String> map=Collections.emptyMap(); The compiler would provide resolved parameter Types. In the parameter case these information is discarded as it is not needed, because of the Type Erasure. The first solution to get these informations would be to create a workingcopy, create an assignment to a variable, parse it, throw the working copy away, and insert it using the newly gained resolved information. Obviously this is not what a quickfix is meant to be, because it is not quick. The other option would be to as JDT Core for a resolved type for this, which would mean changes to the compiler and changes to the IType+ hierarchy. As I got assigned to this bug after API freeze the second option was not applicable, and the first too slow. But I heard that you have some good contacts to JDT Core, so feel free to ask them for the new API ;)
Agreed. Solution #1 may be a fix, but it's not quick by any means.
Evaluating the type that is needed to case to is quite tricky unless we get extra information from the compiler. At the moment there are no plans for this.
