• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Old Collections Syntax in java 1.5

 
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Graeme Byers
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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'm doing laundry! Look how clean this tiny ad is:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic