Community
Participate
Working Groups
Created attachment 182531 [details] test project This setup may be considered bogus. Basically we have a project compiling with the jsr14 flag but compiling against the J2SE 1.4 class library. To reproduce you must have a 1.4 VM configured into your workspace and import the attached project. It complains about code like this: Class type == null; if (type == byte.class) <== fails here return;
I wonder if we should not check if java.lang.Class is generic before creating a parameterized type binding for "byte.class".
(In reply to comment #0) > Created an attachment (id=182531) [details] > test project > > This setup may be considered bogus. Basically we have a project compiling with > the jsr14 flag but compiling against the J2SE 1.4 class library. To reproduce > you must have a 1.4 VM configured into your workspace and import the attached > project. > > It complains about code like this: > > Class type == null; > if (type == byte.class) <== fails here > return; [Srikanth slapping himself on his forehead] I should have anticipated this problem. This is really the other side of the coin so to speak as is obvious from https://bugs.eclipse.org/bugs/show_bug.cgi?id=328827#c3 That bug was fixed the method isEquivalentTo in the TypeBinding hierarchy. We should also fix the method isProvablyDistinct in the TypeBinding hierarchy. Patch will follow shortly.
(In reply to comment #2) > I should have anticipated this problem. This is really the > other side of the coin so to speak as is obvious from > https://bugs.eclipse.org/bugs/show_bug.cgi?id=328827#c3 https://bugs.eclipse.org/bugs/show_bug.cgi?id=323633#c14 does anticipate these issues. FWIW.
(In reply to comment #0) > Created an attachment (id=182531) [details] > test project > > This setup may be considered bogus. Basically we have a project compiling with > the jsr14 flag but compiling against the J2SE 1.4 class library. The oddity with the set up is just a red herring. The problem is the same as in bug 329588. In establishing type equivalence, we need to be prepared to see a type in one of three forms : as a parameterized form, a raw form or a "plain" (1.4) form. I'll add a regression test and close this as a duplicate of bug 329588. (In reply to comment #1) > I wonder if we should not check if java.lang.Class is generic before creating a > parameterized type binding for "byte.class". This does fix the current problem, but the more general fix is already committed via the fix to bug 329588
Created attachment 182557 [details] Regression test junit for test case corresponding to comment# 0
TypeBinding Class is now not provably distinct from Class<java.lang.Byte> *** This bug has been marked as a duplicate of bug 329588 ***
Released regression test in HEAD for 3.7 M4
*** Bug 329589 has been marked as a duplicate of this bug. ***
Verified using I20101207-0250 (4.1 I-build)
