Old Collections Syntax in java 1.5

[Graeme Byers]

Two questions.
1. Senario :
GBTest was written in 1.4 now I have 1.5 and I can javac -source 1.4 OK.
But now I'm enhancing it and using new 1.5 features and the old Collections syntax does not compile : "uses unchecked or unsafe operations"

import java.util.* ;
public class GBTest {
 
       public static void main (String[] args) { 
          //  List myList = new Vector() ;                        
              List<String> myList = new Vector <String> () ;      
              myList.add("A") ;
              System.out.println (myList) ;
        }
}

So, what else is not upwardly supported ? In a real environment I would not only have to code and test my changes but re-code and re-test now unsupported syntax. Not good !
"You can mix generic code with older non-generic code , and everyone is happy" (S&B page 576)

2. Unrelated question but using code sample above.
I seem to understand all that I read but I'm not "getting it".
I think I'm asking a question about the design of Collections and
what I have read is the usual same old stuff (as in the SCJP).
Why polymorphically ?
"In practice, you'll typically want
to instantiate an ArrayList polymorphically like this ...
List<String> myList = new ArrayList<String>() ; " S&B page 547

Now usually one instantiates as :
ArrayList<String> myList = new ArrayList<String>() ;

Now an ArrayList is a List so I can code OK :
List<String> myList = new ArrayList<String>() ;
Vector has a toString() , ArrayList does not , but AbstractCollection does.

Thank you.

[Steve Luke]

Originally posted by Graeme Byers:
Two questions.
1. Senario :
GBTest was written in 1.4 now I have 1.5 and I can javac -source 1.4 OK.
But now I'm enhancing it and using new 1.5 features and the old Collections syntax does not compile : "uses unchecked or unsafe operations"

import java.util.* ;
public class GBTest {
 
       public static void main (String[] args) { 
          //  List myList = new Vector() ;                        
              List<String> myList = new Vector <String> () ;      
              myList.add("A") ;
              System.out.println (myList) ;
        }
}

So, what else is not upwardly supported ? In a real environment I would not only have to code and test my changes but re-code and re-test now unsupported syntax. Not good !
"You can mix generic code with older non-generic code , and everyone is happy" (S&B page 576)

You can still use the old syntax with 1.5, the unchecked or unsafe operation warning is just that, a warning saying you are using a class that should be a Checked type, but aren't. If you wanted to get rid of these warning (without adding Generic definitions) you could use the @SupressWarning("unchecked"). This will hide the warning until you are ready to go back and put in the checked types later on.

Originally posted by Graeme Byers:
Vector has a toString() , ArrayList does not , but AbstractCollection does.

All objects have a toString() method... if they don't implement one themselves they inherit from their parent (up through to Object which has one).

I am not sure I understand this part of your question. Can you try re-wording it?

[Graeme Byers]

Thanks Steve,
I'm happy about your answer to the first question.

I know my second question is confused but I am asking why everyone codes :
List<String> myList = new Vector<String>() ;
instead of the more usual :
Vector<String> myList = new Vector<String>() ;
Why the up-cast ?
Is it because one can easily switch (without other code changes , still using toString) from using Vector to any other Collection(say ArrayList) :

 
List<String> myList = new Vector<String>() ;
List<String> myList = new ArrayList<String>() ;

where both are subclasses of an abstract class that does implement that method ?
I do understand that the abstract classes are there to allow you to code your own collection classes , inheriting or overriding their implemented methods etc.

[Joanne Neal]

Originally posted by Graeme Byers:
Is it because one can easily switch (without other code changes , still using toString) from using Vector to any other Collection(say ArrayList)

It allows you to switch from using a Vector to using any other type of List. Not all classes that implement the Collection interface will implement the List interface. Some do but not all.

[Steve Luke]

Yes, referencing a Vector<String> as a List<String> allows you to easily change which List<String> implementation you want to use later on, without affecting other code.

It is mainly important for method signatures or any object reference to be used by an external source. Some examples:

Let's say I have an ArrayList full of people that I make in a getPeople() method. I may use this:

public ArrayList<Person> getPeople() {
    ArrayList<Person> people = new ArrayList<Person>();
    //... fill the list ...
    return people;
}

I use that ArrayList in other places, perhaps to iterate and display the people. So Somewhere else I would call:

   ArrayList<Person> people = getPeople();
    for(Person person : people) {
        displayPerson(person);
    }

Now, after some testing I find out that a LinkedList<Person> would perform better in my use-case. So I switch to:

public LinkedList<Person> getPeople() {
    LinkedList<Person> people = new LinkedList<Person>();
    //... fill the list ...
    return people;
}

But now my display code is broken, so I have to re-write that as well:

   LinkedList<Person> people = getPeople();
    for(Person person : people) {
        displayPerson(person);
    }

And I would have to find every location I called the getPeople() method (or worse, every location I, or any of my co-workers or clients called the method) and fix it.

But if I publish all my objects in the least-specific interface as possible, then my original code would have looked like this:

//Method signature is what is important... it is what the rest of the world knows
public List<Person> getPeople() {
    //I can still keep the ArrayList reference inside the method - it may be usefull to have the specific implementation here
    ArrayList<Person> people = new ArrayList<Person>();
    //... fill the list ...
    return people; //Will up-cast to List<People> because of return type
}

If I had done that originally, my calling method would have been forced to reference the list of people as List<Person> not ArrayList<Person>:

    List<Person> people = getPeople();
    for(Person person : people) {
        displayPerson(person);
    }

So when I later changed to LinkedList:

public List<Person> getPeople() {
    LinkedList<Person> people = new LinkedList<Person>();
    //... fill the list ...
    return people;
}

The outside world doesn't know. They only see List<Person> which doesn't change. I have the freedom of modifying the implementation of the specific type of List<Person> used without affecting any callers. To them it is just a detail better left to the method.

The same thing goes when passing objects into a method. Make the type of the parameter as broad as possible while still being able to do the work that is needed, and you will make more robust and versatile code as you later change implementation details or broaden the spectrum of data types you need to call the method on.

There are a few key points
1) The method signature's return type and parameter lists are it's interface to the outside world. Keep the that interface as generic as possible.
2) Specific types of objects should be considered an implementation detail. Keep it a secret as long as you can
3) Always return a type that allows the caller to do what it needs to do, but also make sure it is specific enough to document its behavior. What I mean is: You can return an ArrayList as a List, or a Collection. Both allow you to add items or iterate over the data. But it may be important that your collection allows duplicates or is ordered. In that case it would be better to return a List, so callers know it isn't a Set, which may be un-ordered and doesn't allow duplicates.