Compiling Java generic files in eclipse but not on the command line

Question

I know that in the past there were several questions regarding things that compiled in eclipse, but not on the command line, but I still could not find the answer to my problem.

In particular, I think I was able to install eclipse to use my system compiler, but this still did not solve the problem.

I am currently checking: "Preferences -> Java -> Installed JREs".

This contains only one JRE, which is my system.

Here are the specifics of the problem

I have a generic java class that takes an Enum type as an argument, for example:

public class MyClass<T extends Enum<T>> 

Somewhere inside the class, I am comparing the known enum value with the values ​​of T. So, for example, let's say I have this enumeration:

 public enum OtherEnum{ a, b } 

And then I test:

 protected void foo(T enumVal){ if(enumVal == OtherEnum.a){ // do something } else if(enumVal == OtherEnum.b){ // do something else } } 

This compiles without problems in eclipse, but on javac command line I get this error:

incomparable types: T and OtherEnum

I tried this on two systems that use the java 1.6 option (1.6.0_26 and 1.6.0_16). One is the Mac, the other is Linux. They both give the same error, while eclipse compiles without problems.

So:

• How can I make sure the compiler eclipse is using?

• What is the problem?

Thanks!

Answer 1

Separate the compilers ... Using the == function forces a more rigorous check of compilation time, so in CL it uses type comparisons and errors. In Eclipse, you can control compile-time settings and relax restrictions, so to speak.

You can try Enum.equals (), and it may not use such a string compilation of compile-time types. just a thought.

Answer 2

This is a javac bug fixed in JDK 7.

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6548436

Answer 3

Very interesting question.

The following code does not compile

  Integer x = null; String s = null; if(x==s){} // error: incomparable types 

JLS3 # 15.21.3 [1] says

A compile-time error occurs if it is not possible to convert the type of any operand to the type of another using cast conversion (§5.5)

Apparently, the previous example looks like an obvious programming error, so the specification is trying to catch it and warn the programmer. There would be no problem when Java wanted to resolve this. A workaround for the example is to drop one side to Object .

Back to your question, we need to decide whether it is possible to distinguish OtherEnum from T or vice versa. This is a surprisingly difficult question; following the JLS3 # 5.5 procedure [2], the answer is no.

It all depends on whether OtherEnum be pressed on Enum<T> ; then we can find super types X=Enum<OtherEnum> and Y=Enum<T> , which are provably different parameterized types. So casting is illegal.

Well, such a specification is too complicated, who in their right mind would care?

You can get around it by dropping it to Object , say (Object)enumVal == OtherEnum.a

Java 7 behaves differently; it compiles your code. I do not know the reason. Perhaps Java7 introduces a new error. Or he has a new specification that allows the use of code (but we do not have access to the new specification). Another possibility is that I misunderstood the term "provably distinct parameterized types"; however, without a formal definition, it is intuitively clear that Enum<OtherEnum> and Enum<T> distinct.

out

[1] http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.21.3

[2] http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#20232

Answer 4

Eclipse uses its own implementation of the java compiler (ECJ), which has nothing to do with javac.

Eclipse Compiler for Java:

Java incremental compiler. Implemented as an Eclipse builder, it is based on technology developed from VisualAge for the Java compiler. In In particular, it allows you to run and debug code that still contains unresolved errors.