user3444455
user3444455

Reputation: 3

java.lang.ClassCastException: cannot be cast to java.lang.Integer

I wanted to create a compareTo method but it gives me an error. Can anyone help me with this ?

     package defaultpackage;
     public class HuffmanEntry implements Entry<Integer, String> {
     private String c;  
     private Integer freq;

     public HuffmanEntry(String c, Integer freq){    
     this.c = c;
     this.freq = freq;
     }

     @Override
     public int compareTo(Integer arg0) {
    if(getKey()<arg0){
        return -1;
    }else if(getKey()>arg0){
        return 1;
    }else{
        return 0;   
    }
}

      @Override
      public Integer getKey() {
      return freq;
      }

Here's my error:

Exception in thread "main" java.lang.ClassCastException: defaultpackage.HuffmanEntry cannot be
cast to java.lang.Integer
at defaultpackage.HuffmanEntry.compareTo(HuffmanEntry.java:1)

Upvotes: 0

Views: 15100

Answers (2)

Stephen C
Stephen C

Reputation: 718836

There are serious problems with the quality of the "evidence" you have provided us:

  1. The stacktrace seems to say that the exception is thrown at line 1 of HuffmanEntry.java, and that is impossible.

  2. The stacktrace seems to say that your code is attempting to cast a HuffmanEntry object to an Integer in compareTo, but (according to the source code) that cannot happen in that method. All objects used in that method have a declared type of Integer, and there are no explicity typecasts.

  3. The stacktrace shows that compareTo is the one and only method call, and that is impossible.

(3 impossible things before lunch? Nah! Don't buy it!)

In short, the evidence you have shown us is not real. It has been tweaked / mangled, and in ways that make it impossible to interpret.

Please provide a real (complete and unedited) stacktrace, and source code that precisely matches the compiled code you ran to produce the stacktrace. Also any compilation errors.

Alternatively, provide us with an SSCCE that we can run ourselves to reproduce this facially impossible behaviour / evidence.


Looking at the code you linked to, I think I understand the general problem ... if not the specific one.

Basically, you are mixing generic and non-generic code and (you must be) ignoring the resulting compiler warnings about unchecked conversions, use of raw types and so on. The result is that errors that should be picked up by the Java compile-time type checker are not being reported.

For example, in MyHeap.java, you write:

private ArrayList<Entry> entryList; 

But Entry is actually a generic interface, meaning that ArrayList is actually being interpreted as ArrayList<Entry<Object, Object>> where Object is the raw type corresponding to the unbounded type parameters K and T. Now there is an int compareTo(K) method in the Entry interface ... and the raw type signature is int compareTo(Object).

Now look at

if (entryList.get(i*2).compareTo(entryList.get(i*2+1))==-1){ 

Note that you are effectively calling Entry.compareTO(Object) passing another Entry as the argument. The compiler has said OK .... because it thinks you are using raw types at that point. But if you had been using generics properly, the compiler would have realized that you are calling Entry<K, V>.compareTo(Entry<K, V>) where the generic method signature is really Entry<K, V>.compareTo(V) . That would have been flagged as a compilation error.

I suspect that this explains the strange exception too. The Java compiler has added some hidden runtime typecasts to make sure that the JVM's core runtime type safety is not compromised. You are seeing the exception when one of those runtime checks fails. And that happens because you effectively ignored or suppressed the compile time checks that should have you told you of your programming error.

Anyway, the bottom line is that you should NOT ignore compiler warnings about misuse of generics, unchecked conversions, etc. You do so at your peril ... and in this case, you got bitten.

Upvotes: 3

ErstwhileIII
ErstwhileIII

Reputation: 4843

You implement Comparable to allow your class objects to be compared, not to compare different objects.

Perhaps you want to provide use something like if (Integer x > huffmanObject.getFreq()) instead? Sounds much simpler.

Upvotes: 0

Related Questions