Community
Participate
Working Groups
Created attachment 181835 [details] test projects I20101025-1800 This likely is a dup of bug328775. But the scenario is slightly different so I am opening a separate bug. As in bug328775 a J2SE 1.4 project is behaving incorrect. The following block of code causes a compile error in the J2SE 1.4 project when it should not: EventProperties props = new EventProperties(null); Event event = new Event("test/topic", props); The issue is the compiler does not think EventProperties is a Map, but it implements Map<String, Object> The signature of the Event constructor that should be used is: public Event(String topic, Map<String, ? > properties) But the compiler fails to find that constructor for the test.event1 project, which is using J2SE 1.4 compiler settings. The test.event2 project finds the constructor and is using J2SE 1.5 compiler settings.
Srikanth, please investigate.
This is caused by the fix for bug 324850. Srikanth, I think we now need to "filter" some generic information where we didn't need to in the past. If we cannot "fix" this, we might want to revert bug 324850 for M3 as this is causing grief to OSGI users.
Created attachment 181907 [details] Patch under test This patch fixes the problem. The automated tests are being run now. Will update status once done. Basically, the problem is that with hybrid 1.4/1.5+ projects modes, while establishing type equivalence, the compiler needs to be prepared for a type such as Map appearing in one of three distinct forms: (a) As a ParameterizedTypeBinding e.g Map<String, String> (b) As a RawTypeBinding (Map#RAW) and finally (c) As a BinaryTypeBinding When the usage of a type lacks type parameters, whether we land up with the raw form or not depends on whether the underlying type was "seen to be" a generic type in the particular build environment or not. So usages of Map in a 1.4 project don't produce a "raw" type, as Map is not seen to be a generic type in the first place by the compiler when found in a 1.4 JRE.
Created attachment 181911 [details] Revised patch under test Patch that avoids applying erasure prematurely. Under test.
Created attachment 181920 [details] Final patch - passes all JDT/Core tests Same fix as before, with its application tightened.
Olivier, please review, TIA. We probably need a similar fix in org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.isEquivalentTo(TypeBinding) and org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.isEquivalentTo(TypeBinding) but I'll treat that as a separate case from this bug report.
I agree with the principle.
Just verified that build I20101028-1441 does not have this bug.
Will you also update the SourceTypeBinding implementation ?
Released in HEAD for 3.7 M4 (In reply to comment #9) > Will you also update the SourceTypeBinding implementation ? Yes, however, I'll follow up on this on a separate defect.
(In reply to comment #6) > Olivier, please review, TIA. We probably need a similar fix > in > org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.isEquivalentTo(TypeBinding) > > and > org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.isEquivalentTo(TypeBinding) > > but I'll treat that as a separate case from this bug report. The latter change is necessitated by and handled in the context of the fix for bug 186565
(In reply to comment #11) > The latter change is necessitated by and handled in the context of ^^^^^^^^^^^^^^^^ I meant to say "needed for".
Verified for 3.7M4 using build I20101205-2000.
