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

[Janeice DelVecchio]

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:

public class Coin implements Comparable {
     public int compareTo(Object otherObject) {
          Coin other = (Coin) otherObject;
          if (value < other.value) return -1;
          if (value == other.value) return 0;
          return 1;
     }

ArrayList<Coin> coins = new ArrayList<Coin>();
// add coins
Collections.sort(coins);    

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

public class Student implements Comparable {	
     // appropriate instance variables here
     // a ton of other code / methods / etc here
	public int compareTo(Student otherStudent) {
		if (lastName < otherStudent.lastName) return -1;
		if (lastName == otherStudent.lastName) return 0;
		return 1;
	}    

And somewhere else I call:

Collections.sort(studentList);    

(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

[Mike Simmons]

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]

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

[Janeice DelVecchio]

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]

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]

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]

..... 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]

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]

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]

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

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

I'm still confused.

When I say:

ArrayList<Student> studentList = new ArrayList<>();    

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]

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]

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:

List list = new ArrayList(); // a list of Strings
String string1 = "string 1";
String string2 = "string 2";
String string3 = "STRING 3 IS IN ALL CAPS";
Long long1 = new Long(1L); // a Long
list.add((Object) string1);
list.add((Object) string2);
list.add((Object) string3);

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

list.add((Object) long1); // Ooops!, Can't catch this until run-time after trying to get it from the list!

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:

List<String> list = new ArrayList<String>(); // a list of Strings
String string4 = "string 4";
String string5 = "string 5";
String string6 = "STRING 6 IS IN ALL CAPS";
Long long2 = Long.valueOf(1L); // a Long
list.add(string1);
list.add(string2);
list.add(string3);
list.add(long2); // The compiler won't allow this

Hopefully, that made sense .

John.

[Janeice DelVecchio]

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]

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]

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]

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]

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.

[Campbell Ritchie]

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]

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]

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.

student mariaCordban = new Student("Maria", "Cordoban", new Birthdate(1, 2, 1989));
mariaCordaban.setFullName("Maria Rodrigues");
mariaCordoban.getLastName(); /* returns "Cordoban" */

public class Person
{
    private String name;
    private int age;

    public Person(String name, int age)
    {
       if (name == null)
           throw new NullPointerException("Value for name in Person constructor must not be null");
       // Other validation code
       this.name = name;
       if (age < 0 || age > 200)
           throw new IllegalArgumentException("Age of " + age + " not possible. Person constructor.");
       this.age = age;
    }//end constructor

    public int getAge()
    {
       return age;
    }//end get age

    public String getName()
    {
       return name;
    }
/*
 * Lots more methods
 */

    @Override public String toString()
    {
        return "Person " + name + " age " + age;
    }
  
    public static void main(String[] args)
    {
        java.util.List<Person> people = new java.util.ArrayList<Person>();
        for (int i = 0; i < args.length; i += 2)
        {
            people.add(new Person(args[i], Integer.parseInt(args[i + 1])));
        }//end for
        java.util.Collections.sort(people, new AgeComparator());
        System.out.println(people);
        java.util.Collections.sort(people, new NameComparator());
        System.out.println(people);
    }//end main
}

public class AgeComparator implements java.util.Comparator<Person>
{
    public AgeComparator(){}//empty constructor

    public int compare(Person a, Person b)
    {
        return a.getAge() - b.getAge();
    }
}

public class NameComparator implements java.util.Comparator<Person>
{
    public NameComparator(){}//empty constructor

    public int compare(Person a, Person b)
    {
        return a.getName().compareTo(b.getName());
    }
}

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]

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:

	public String getName (){
		wholeName = lastName.toUpperCase() + " " + firstName.toUpperCase();
		return wholeName;
	
	}    

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]

Janeice:

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

John.

[Janeice DelVecchio]

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]

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

@Override public String toString()
{
   return firstName.toUpperCase() + " " + lastName.toUpperCase() + " " + grade;
}

[David Newton]

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]

But I'm a suspicious so-and-so who sees potential errors everywhere.

Mwaahaahaahaa!

[Janeice DelVecchio]

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]

Well done

[John de Michele]

Congrats!

John.