File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Old Collections Syntax in java 1.5 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Old Collections Syntax in java 1.5" Watch "Old Collections Syntax in java 1.5" New topic
Author

Old Collections Syntax in java 1.5

Graeme Byers
Ranch Hand

Joined: Apr 16, 2004
Posts: 127
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"

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
Bartender

Joined: Jan 28, 2003
Posts: 3934
    
  17

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"

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?


Steve
Graeme Byers
Ranch Hand

Joined: Apr 16, 2004
Posts: 127
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) :

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
Rancher

Joined: Aug 05, 2005
Posts: 3165
    
  10
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.


Joanne
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 3934
    
  17

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:


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


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


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


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:


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>:


So when I later changed to LinkedList:


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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Old Collections Syntax in java 1.5
 
Similar Threads
question about ArrayList
Generics warnings... I don't understand?!
Generics Teaser
ArrayList Problem(s)
Mixing genric and non-genric code in assignment