Community
Participate
Working Groups
in i1116-0800 in the PDE target code there is a call as follows PermissiveSlicer slicer = new PermissiveSlicer(profile, new Properties(), true, false, true, false, false); In the past (a week ago) this compiled fine. Something has changed such that the use of new Properties now causes a compile error because it apparently does not match Map<String, String>. I'm assuming that this runs fine since that PDE code is in HEAD but do wonder what the path here is supposed to be and why this is suddenly showing as a compile error. Note that there is a similar problem with IProfileRegistry.addProfile(String, Map<String, String>). Seems calling with a Properties object used to compile fine but not any more.
Strange, that class hasn't changed since last March. Any ideas Curtis?
My guess is this is more weirdness due to the 1.4/1.5 gap between PDE and p2. Was this actually a compile error that affected things at runtime or was it a development time error? There are several places where we use p2 APIs that use generics and errors show up in PDE.
(In reply to comment #2) > My guess is this is more weirdness due to the 1.4/1.5 gap between PDE and p2. > Was this actually a compile error that affected things at runtime or was it a > development time error? There are several places where we use p2 APIs that use > generics and errors show up in PDE. Looks like the compile error breaks things at runtime. cc'ing Olivier as he may be able to tell us what has changed in the compiler in the past week.
(In reply to comment #0) > in i1116-0800 Could you please provide the jdt.core id? (In reply to comment #0) > In the past (a week ago) this compiled fine. Something has changed such that Could you please provide the jdt.core id? I would need the jdt.core id when it used to work and when it stopped working. Thanks.
Worked in 3.7.0.v_B21 Broken in 3.7.0.v_B24 I'll have to try some other versions to narrow it down further.
Might be related to the changes released in B23 for 1.4/1.5 mixed mode issues.
Moving to JDT/Core as these errors occur when compiling the code using a 1.6 library.
The problem comes from: new Properties() not matching the Map<String, String> argument type from the constructor. If you have: import java.util.Map; public class Y { static void foo(Map<String, String> map) { } } and this is compiled in 1.5. Then you define: import java.util.Properties; public class X { static void bar(Object[] args) { Y.foo(new Properties()); } } If you compile using javac 1.6: javac X.java -source 1.4 it works. But in source 1.5 or source 1.6, it doesn't compile: X.java:12: foo(java.util.Map<java.lang.String,java.lang.String>) in Y cannot be applied to (java.util.Properties) Y.foo(new Properties()); ^ 1 error So I think the error makes sense if the code is compiled using 1.5 compliance or 1.6 compliance. But when compile in 1.4, it should work.
Created attachment 183330 [details] First draft This seems to fix this issue. I'll run all tests to double-check previous fixes around 1.4/1.5 issues.
I believe pde.code should fix their code. The API that is called is expecting a map of string, string and not a Properties object that can potentially contains any kind of Object. All 3 errors I am getting by compiling pde.core in 1.6 mode are related to this issue. So yes, the code should compile in 1.4 mode, but it might blow up at runtime. In your code, you are only putting strings inside the properties keys and values so it should work. We should fix our code to make sure that code compiles fine if the compliance is 1.4 (source <= 1.4 in fact).
(In reply to comment #10) > I believe pde.code should fix their code. > The API that is called is expecting a map of string, string and not a > Properties object that can potentially contains any kind of Object. PDE core/ui is 1.4 compliant, so we cannot use generics to specify the contents of the map.
PDE Code was updated to use a HashMap rather than the Properties class and now will compile in both 1.4 and 1.6.
Created attachment 183337 [details] Proposed fix + regression test Same patch with a regression test.
Thanks Curtis for tracking down the build info. Olivier, should we move this to JDT? Feel free to take it if so.
(In reply to comment #14) > Thanks Curtis for tracking down the build info. Olivier, should we move this > to JDT? Feel free to take it if so. You're about 6 comments late :)
(In reply to comment #14) > Thanks Curtis for tracking down the build info. Olivier, should we move this > to JDT? Feel free to take it if so. Already done :-). The bug we have is that we don't compile in 1.4 mode. In 1.5 or 1.6 our behavior is right.
sorry about that move comment. I was reading the thread in segregated mail folders and the thread jumped to a different bucket... Doh
Created attachment 183366 [details] Revised patch under test Olivier, Thanks for the patch, I think it is the right fix. In the revised patch I just eliminated the erasure operation on the method argument, while continuing to erase the formal parameter.
Released in HEAD for 3.7 M4
(In reply to comment #18) > Created an attachment (id=183366) [details] [diff] This change is causing test failures in JDT/UI (e.g. in MarkOccurrenceTest). To reproduce that setup, put /org.eclipse.jdt.ui.tests/testresources/rtstubs15.jar on the classpath of a Java project with 1.4 compiler compliance. I don't say that our test project setup is flawless, but this worked fine up to v_B24. It's getting late for me now -- I'll have a closer look tomorrow.
(In reply to comment #20) Sorry, I messed up. The problems in the JDT/UI tests are actually due to the fix for bug 330347. I've filed bug 330631 for that.
Verified using I20101207-0250 (4.1 I-build)
