Bug 90433 - [1.5][compiler] Comparing class objects by '=='
Summary: [1.5][compiler] Comparing class objects by '=='
Status: VERIFIED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M3   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-06 08:05 EDT by Volker Renneberg CLA
Modified: 2007-10-29 05:35 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Volker Renneberg CLA 2005-04-06 08:05:28 EDT 
The folloging code compiles with eclipse, but generates an error with JDK 1.5
public class CompareAtomicClasses<S extends Comparable<S>> {
    public void f() {
        Class<S> currentClass = null;
        boolean b = currentClass == Long.class;
    }
}

JDK1.5 (1.5 Update 2) says: 
incomparable types: java.lang.Class<S> and java.lang.Class<java.lang.Long>

ciao
Volker
Comment 1 Olivier Thomann CLA 2005-04-06 08:39:26 EDT 
Reproduce with M6.
Comment 2 Philipe Mulet CLA 2005-04-12 04:47:22 EDT 
Class<S> is not provably distinct from Class<Long>, so I would say we are right
and javac is wrong according to JLS 5.5 (casting) and JLS 4.5 (provably distinct).

So it is different from comparing: Class<String> and Class<Long> as these are
provably distinct.
Comment 3 Philipe Mulet CLA 2005-04-12 05:58:17 EDT 
Maybe you should report this to javac buglist.

Added GenericTypeTest#test588.
Comment 4 Philipe Mulet CLA 2007-09-27 06:46:52 EDT 
Based on discussion with Java spec lead, this is an area where the spec is going to become stricter. So the rules for probable distinctness are going to evolve to take bounds into accounts for wildcard/intersectionTypes/type parameters. 

Note that javac seems to do some of it already.
Reopening to investigate alignment there.
Comment 5 Philipe Mulet CLA 2007-10-09 06:09:12 EDT 
Current discussions would confirm that Class<S> and Class<Long> are not provably distinct. Hence javac would be wrong.
Comment 6 Philipe Mulet CLA 2007-10-09 06:19:40 EDT 
See also bug 95066
Comment 7 Philipe Mulet CLA 2007-10-09 16:33:46 EDT 
Closing as INVALID. Our behavior is actually correct.
Released some changes near cast conversion, as part of fix for bug 158870.
But the scenario reported here remains unchanged.
Comment 8 Maxime Daniel CLA 2007-10-29 05:35:58 EDT 
Verified for 3.4 M3 using build I20071029-0010.