YAJQ: Why is this code given me trouble

[statik213]

OK so w/o generics this is what I would have done (and it works)

File[] files = ...;
Comparator fileDtComparator = new Comparator() {
public int compare(Object o1, Object o2) {
if (!(o1 instanceof File))
return 0;

if (!(o2 instanceof File))
return 0;

File f1 = (File) o1;
File f2 = (File) o2;

long t = f1.lastModified() - f2.lastModified();
if (t > 0)
return 1;
if (t == 0)
return 0;
return -1;
}
};
Arrays.sort(files, fileDtComparator);

But this code using generics blows up on me.
Note: Had to change the generic parameters to something like [file> instead of angle brackets on both sides 'cos fusetalk throws a hissy fit

Comparator[File> fileDtComparator = new Comparator[File>() {
public int compare(File f1, File f2) {
long t = f1.lastModified() - f2.lastModified();
if (t > 0)
return 1;
if (t == 0)
return 0;
return -1;
}
};
Arrays.sort(files, fileDtComparator);

The error I get is:

Exception in thread "AWT-EventQueue-0" java.lang.AbstractMethodError: harris.sal.displays.FileLoggingDisplay$2.compare(Ljava/lang/Object;Ljava/lang/O
jectI
at java.util.Arrays.mergeSort(Arrays.java:1284)
at java.util.Arrays.mergeSort(Arrays.java:1295)
at java.util.Arrays.mergeSort(Arrays.java:1295)
at java.util.Arrays.mergeSort(Arrays.java:1295)
at java.util.Arrays.mergeSort(Arrays.java:1295)
at java.util.Arrays.mergeSort(Arrays.java:1295)
at java.util.Arrays.sort(Arrays.java:1223)
at harris.sal.displays.FileLoggingDisplay.cleanUpLogFolder(FileLoggingDisplay.java:602)
//more stuff below... prbly unrelated.

Any ideas?

 

[EagleKeeper]

FYI - The attach code button allows you to provide code that does not have to be re-formatted bacause of FuseTalk

 

[statik213]

Originally posted by: EagleKeeper
FYI - The attach code button allows you to provide code that does not have to be re-formatted bacause of FuseTalk

it still does not like html like ange bracketed tags.

 

[torpid]

Seems like the stack trace indicates it is working some of the time. Did you try debugging this? my first thought is that one of the two items in the array is null on one of the iterations of the sort.

 

[statik213]

Originally posted by: torpid
Seems like the stack trace indicates it is working some of the time. Did you try debugging this? my first thought is that one of the two items in the array is null on one of the iterations of the sort.

in that case shouldn't I get a NullPointerException?

 

[kamper]

The problem is that sort algorithm doesn't seem to know that it's sorting Files so it is looking for a method called compare that takes to Objects as parameters. I've noticed before that generics start to get a little wonky when you deal with Comparable and Comparator (although these are just specific instances of a general problem). The case where you can compile your code but then actually get a form of LinkageError at runtime is quite disturbing!

It should be fixable without losing the generics though... First of all, is your array an array of Objects or of Files?

Next, you will probably have to declare your Comparator's type like this: Comparator<? super File>
Now I have at best a foggy understanding of this syntax (I basically took it from the javadoc for Arrays.sort()) so I'm not going to try to explain it, but it dives into the differences between generics at compile time and generics at runtime, I think. Very confusing stuff

 

[kamper]

On a side note, if this get's too difficult to fix using generics, there's really nothing wrong with your first snippet of code. The lack of type safety is nicely contained so you're effectively guaranteed not to have typing errors. I wouldn't even check if the Objects were instances of File, I'd just cast them and do the comparison. If you ever got a ClassCastException, it would let you know that something was wrong, rather than silently mis-sorting the elements.

 

[statik213]

Originally posted by: kamper
The problem is that sort algorithm doesn't seem to know that it's sorting Files so it is looking for a method called compare that takes to Objects as parameters. I've noticed before that generics start to get a little wonky when you deal with Comparable and Comparator (although these are just specific instances of a general problem). The case where you can compile your code but then actually get a form of LinkageError at runtime is quite disturbing!

It should be fixable without losing the generics though... First of all, is your array an array of Objects or of Files?

Next, you will probably have to declare your Comparator's type like this: Comparator<? super File>
Now I have at best a foggy understanding of this syntax (I basically took it from the javadoc for Arrays.sort()) so I'm not going to try to explain it, but it dives into the differences between generics at compile time and generics at runtime, I think. Very confusing stuff

I'm sorting on an array of files, i.e. Files[] someThing not Object[].
I looked at the Arrays.sort functions, the one I'm calling is a wrapper to another sort function which works on Objects; the underlying sort function doesn't seem to work directly with generics and may be causing the problems (i.e. it's expecting to see a comparable that takes two objects)...
Will try the alternative syntax for specifying the generic type parameter.... but don't you use that syntax when you define a class or method that take typed arguments?
weird....
Will also look at the javadoc to see what it says abt this syntax.
Thanks!

 

[statik213]

Originally posted by: kamper
On a side note, if this get's too difficult to fix using generics, there's really nothing wrong with your first snippet of code. The lack of type safety is nicely contained so you're effectively guaranteed not to have typing errors. I wouldn't even check if the Objects were instances of File, I'd just cast them and do the comparison. If you ever got a ClassCastException, it would let you know that something was wrong, rather than silently mis-sorting the elements.

Well, i know it would work perfectly well but I'm trying to promote the use of generics on this project I'm working on. Right now i'm hte only person working on it but it will be maintained by others, so I want to keep things as consistent possible...
But yeah, I'm not going to wrestle with this for much longer, if it doesn't work, it won't!!!

 

[kamper]

I'll try to give a bit of an explanation for the syntax. When you say Comparable<File> you're associating a single type with your instance. When you say Comparable<? super File> you're not associating a single type, you're saying that this could be Comparable<?> for any ? that is a subclass of File.

So from the perspective of Arrays.sort, the type of the array doesn't have to match the generic type of the Comparable instance. I must not understand this correctly though, because I can only see that reducing type safety without any additional flexibility...