aspose file tools*
The moose likes Beginning Java and the fly likes Sorting things.... **a generic meltdown** Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Sorting things.... **a generic meltdown**" Watch "Sorting things.... **a generic meltdown**" New topic
Author

Sorting things.... **a generic meltdown**

Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

Preface: I have the book Big Java by Horstmann. I also am using HF Java ed2. This is part of a project for school.....

The Big Java text has a section about "sorting real data." It said to sort data I can implement the Comparable interface. Their example is as follows:



My issue is I need to sort Student objects by lastName:

And somewhere else I call:

(I can give you more code if we need it here)

The Collections.sort(studentList) is giving me a warning during compile.... something about it being unchecked.
The declaration for the Student class is also warning me that Student is not abstract (not sure what this means).
The number one problem here is it's giving me a compiler error based on the fact that the "operator < cannot be applied to String". I read that Strings ARE comparable....

What the heck am I doing wrong?
Janeice


When you do things right, people won't be sure you've done anything at all.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3011
    
  10
Janeice DelVecchio wrote:The number one problem here is it's giving me a compiler error based on the fact that the "operator < cannot be applied to String". I read that Strings ARE comparable....

They are Comparable, in the sense that they implement the Comparable interface, which has a compareTo() method. That does not, unfortunately, mean that you can use operators like < or > on them. And even using == is highly suspect; you probably would want to use equals() instead.

Your other issues are all related to generics. Some of them are ignorable, at least in the short term. But the message about Student not being abstract, look closely - exactly what method does it say hasn't been implemented? And how is that different from the method you have implemented?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18748
    
  40

Janeice DelVecchio wrote:
The Collections.sort(studentList) is giving me a warning during compile.... something about it being unchecked.


Lists support generics. If you don't use generics -- it is fine. But you get a warning error.

Janeice DelVecchio wrote:
The declaration for the Student class is also warning me that Student is not abstract (not sure what this means).


It means that you didn't correctly implement comparable. Comparable also takes generics. You implemented the method as if you are using generics, but you didn't declare it as such. You can't have it both ways, you can either implement generics, or you can *not* implement generics -- you can't do both.

Janeice DelVecchio wrote:
The number one problem here is it's giving me a compiler error based on the fact that the "operator < cannot be applied to String". I read that Strings ARE comparable....


Strings ARE comparable, but not with those operators. You have to use the strings compareTo() method.

[EDIT: Beaten by 40 seconds... ]

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

Thanks!! We'll call it a tie.....

now:
Mike Simmons wrote:
Your other issues are all related to generics. Some of them are ignorable, at least in the short term. But the message about Student not being abstract, look closely - exactly what method does it say hasn't been implemented? And how is that different from the method you have implemented?


I'm getting really frustrated with this Big Java text. It seems they always leave me out in the cold when it comes to DOING anything. I checked out the HF and the generics section was included in the sorting section. Big Java? They're separated by over 100 pages. Perfect.

The actual error (and I thought it was a warning... hah!) is as follows:
Student.java - Student is not abstract and does not override abstract method CompareTo in java.lang.Comparable.
...... uhmmm...... I thought by putting in my own compareTo() it WAS overriding it...... just sayin'.

Big Java says to make my own generic class. HF recommends against it.

My head says that this should only be a list of Students, not a generic list of objects. Do I know what that means? No.

I'm going to go read the chapter in HF about sorting and generics.... maybe you folks can offer some more knowledge/help/advice.

I fixed the String comparison error :-) thanks!
Janeice
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Janeice wrote:I thought by putting in my own compareTo() it WAS overriding it...... just sayin'.

Look closely at the method signature.

Comparing the Comparable docs of Java 1.4 (pre-generics) with 1.5 (generics) will probably point you in the right direction:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Comparable.html
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

I don't understand all this <E> and <T> business...... much less do I see how this applies.

I don't think I WANT to use a generic class because I want an ArrayList of STUDENTS not WHATEVERS.

This has got to be the most syntactually confusing subject I have seen yet.

Is there anyone who can explain this generic thing (and also why I should use it or care about it) in a watered down way so I can apply it to what they're saying in the books? Even the HF might have been written in Sanskrit for all I know.

I am incredibly frustrated.
--Janeice
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

..... as an added fact, I added the <Student> to the end of the Comparable.....

it works(compiles), but I have no idea what is going on.

less frustrated, but still confused,
Janeice
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3011
    
  10
Henry Wong wrote:[EDIT: Beaten by 40 seconds... ]

Neener, neener!

Janeice DelVecchio wrote:We'll call it a tie.....

No way! I beat him fair and square!

Janeice DelVecchio wrote: I checked out the HF and the generics section was included in the sorting section. Big Java? They're separated by over 100 pages. Perfect.

Well, I don't have a copy of either book on hand at the moment, but I can see arguments for doing it both ways. Generics are a meaty subject that will eventually require a lot more space than being sandwiched into the sorting section. I bet HFJ also has more later... and I bet Big Java (no I'm not abbreviating that one) ;) has at least some mention of generics before that later chapter.

Janeice DelVecchio wrote:The actual error (and I thought it was a warning... hah!) is as follows:
Student.java - Student is not abstract and does not override abstract method CompareTo in java.lang.Comparable.

Hm, when I write a similar test it says "...is not abstract and does not override abstract method compareTo(java.lang.Object) in java.lang.Comparable". The extra info I see in my message is key. Are you sure it's not there in your message as well?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18748
    
  40

Janeice DelVecchio wrote: I don't understand all this <E> and <T> business...... much less do I see how this applies.

I don't think I WANT to use a generic class because I want an ArrayList of STUDENTS not WHATEVERS.


I think you are confusing what generics does. With generics, you can have a type specific ArrayList -- meaning an arraylist of STUDENTS. Without generics, everything is treated as an object -- meaning your array list is treated as an array list of Objects (even though they are students), and you have to cast them to STUDENTS.

Henry
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

..... ok......

Now that my app works and I can calm down a little.

I'm still confused.

When I say:



Doesn't that take care of making sure it's a list of STUDENTS? I mean if I forget in an accepting method to put that <Student> in the bracket it comes up with that asinine warning.... like I'm gonna put a Dog in a list of Students.....

I STILL don't get why the <Student> now has to go in the declaration of the implementation of Comparable. Isn't that why I made the compareTo() method? So it knows I'm comparing lastNames of Students and not collarColors of Dogs? And why is this only since the advent of this mysterious "generic" business (i.e. Java 5)?

Thanks for your time,
Janeice

[EDIT] Just found this on the web: This is going in my Favorites.......

David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Doesn't that take care of making sure it's a list of STUDENTS? I mean if I forget in an accepting method to put that <Student> in the bracket it comes up with that asinine warning.... like I'm gonna put a Dog in a list of Students.....

You're doing two things: defining a variable, and creating a list. Both need to be complete. Java is very "high ceremony": it doesn't do any type inference. You must tell it precisely what to do.

I STILL don't get why the <Student> now has to go in the declaration of the implementation of Comparable. Isn't that why I made the compareTo() method? So it knows I'm comparing lastNames of Students and not collarColors of Dogs?

No, you made the compareTo() method to satisfy the interface's contractual obligations. The <Student> goes in to the implements statement because that's what you're implementing: Comparable<Student>. That's different than Comparable, which you discovered earlier.

(And Comparable doesn't know you're comparing the last names of students--it knows you're comparing Students, because you told it you were.)
John de Michele
Rancher

Joined: Mar 09, 2009
Posts: 600
Janeice:

Generics provide type safety that the pre-Java 1.5 collections don't have. So, in Java 1.4, you would do something like this:

You'll note the casts to Object. Because of that, this line is also possible:

The JVM won't find this error until you try and run the program. This makes it much harder to diagnose the issue. Generics basically hide the cast behind the scenes, so that these errors can be caught at compile time:

Hopefully, that made sense .

John.
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

Here's the $1,000,000 question....

Why do they call it "generics" when it's all about being more "specific"? Am I missing something?


Thanks so much everyone!
--Janeice
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3011
    
  10
Well, it's about taking a single class or method which was written to be really generic, and allowing it to be more specific. It's also about taking a method that was written in a very specific manner, and rewriting it in a way that allows it to be used in a more generic manner. Which also allows it to be used more specifically, in very different contexts from the original. Without generics, if you wanted a type-safe list of Strings, a type-safe list of Integers, and a type-safe list of Persons, someone would have to write three different classes. With many more on the way. With generics, you just need one class - but when you use it, you need to specify which specific type you want your generic class to deal with.

They could just as well have called it "specifics", I suppose. It's like yin and yang - each concept implies the existence of its opposite. But "specifics" was already in use for something completely different. If I said "let's talk about specifics in Java" - well, you'd wonder which specifics. If I say "let's talk about generics in Java" - you may not completely understand the concept, but at least you know I'm talking about a particular feature of the Java language.
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

So I just figured out that I was freaking out over this name "generics" and made it pretty complicated.

I mean, it probably IS more complicated, but for my needs right now it's pretty simple. Not to mention I've been unknowingly doing this generic thing the whole time I've been using these ArrayLists.

I just need to remember to let the asinine compiler know there won't be Dogs in my Students. I mean, it's only looking out for me, right?

**end meltdown**

I'm good now.

Thanks,
Janeice

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3011
    
  10
Janeice DelVecchio wrote:I just need to remember to let the asinine compiler know there won't be Dogs in my Students. I mean, it's only looking out for me, right?

Ummm... yes. Of course.

[whistles innocently]
Ruben Guillen
Greenhorn

Joined: Sep 02, 2009
Posts: 28
Dear Janeice

Another important issue related to generics is that they only applies during compilation time, at runtime they do not exist. Read the following here.

Related to you sorting problem:
1) In Java appart from primitivies everything else are objects, please read the mistake 7 here for information in comparing object.
2) As a second option for your sorting check the API for Interface Comparator. This could be of help when you would like to use several different sorting options on the same object. It works with overloaded method sort of util class Collections.

Regards.


SCJP, OCMJD
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38412
    
  23
Ruben Guillen is right about Comparators. Does a "Student" have a "natural ordering"? Do you order by name, age, marks, etc? Have a look at some old posts which might (or might not) be helpful about Comparator and Comparable. Note some of those links use non-generic code. 1 2
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

I built the compareTo() based on the specs of the project. Alphabetically by last name. I was to assume there would be no duplicate last names (although if there were I could sort by fullName, another instance variable I created).

Checking out the comparator API last night was a nightmare. It has a lot of functions that I just don't need and I got overwhelmed. The only example in the crummy text is of sorting coins by int value, not sorting Strings. Even the HF book was a little too many <E>s for me and I got confused.

That Angelika Langer site is pretty good for this. Once I understood the basic concept, the syntax for what I needed seemed natural.

For example, during the class declaration meltdown I knew there had to be something in those pointy brackets. I thought, "well, I'm defining the class and saying that it's comparable... doesn't it want to know that it's based on lastName?" ..... well I don't need to tell you <lastName> didn't work. When I realized it wanted to know what it's comparable TO for type-safeing..... <Student> was the easy pick. But I still dunno why anyone would want to compare a Student to anything else.

--Janeice
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38412
    
  23
Comparator only has two methods, and one is equals(), so you can ignore it.
Why have you got lastName and fullName fields in your Student class? You should have name, or firstName lastName. If you have lastName fullName, you can get problems if (for example) one of your women Students marries.
campbell@queeg:~/java$ java Person Campbell 96 Janiece 21 Carlos 21 Maria 23 Maria 42 Esteban 17 Rob 57
Now run that and see what outputs you get. Note particularly what happens to the two Marias with different ages.
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

I have a full name because I needed to output :

lastName firstName (in caps) and grade

to the 2D arraylist, and eventually to the unbuffered file writer.

so instead of concatenating them together for each arrayList entry, I chose to create a getName() method:



the wholeName is a function of lastName and firstName.....
uhmmm...... was that not right?

Campbell.... I'm trying your code now.
Janeice


John de Michele
Rancher

Joined: Mar 09, 2009
Posts: 600
Janeice:

You'll probably want to rename your method to 'getWholeName()' then. That's a little more standard.

John.
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

I just submitted it for grading.

I don't think they'll mark me down for that though... they more want functionality and a "robust user experience"

... well I hope anyway.....
--Janeice
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38412
    
  23
Janeice DelVecchio wrote: . . . the wholeName is a function of lastName and firstName.....
There is a risk of incorrect data if you store the same information in two places; if one changes you must change the other. I would have suggested
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Well, getName() does use existing data to set and return a different instance variable.

If that instance variable is independently available and the other setters don't set it there's a problem. If it's not available then it's not really a problem, although it would pollute the instance variables with unnecessary cruft.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38412
    
  23
But I'm a suspicious so-and-so who sees potential errors everywhere.

Mwaahaahaahaa!
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1660
    
  11

My score report came out.... and I quote:

The evaluator was impressed with the student's apparent skill in Java coding fundamentals, use of Scanner class for input, array construction and manipulation, file output, command line menu design, and error-trapping. The quality of commenting is also commendable and documents all major functional blocks. This program shows a great effort in Java and the student is encouraged to keep up the great work!




Thanks for all the help!!
Janeice
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38412
    
  23
Well done
John de Michele
Rancher

Joined: Mar 09, 2009
Posts: 600
Congrats!

John.
 
 
subject: Sorting things.... **a generic meltdown**