Reputation: 3
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
Reputation: 718836
There are serious problems with the quality of the "evidence" you have provided us:
The stacktrace seems to say that the exception is thrown at line 1 of HuffmanEntry.java
, and that is impossible.
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.
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
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