• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Compilers emits a warning when using ArrayList()

 
Unnar Björnsson
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This messages has been a thorn in my side for some time but I have always ignored it since it isn�t an error and doesn�t affect my applications.
But I really want to know why i.e why does the compiler show this warning when I use ArrayList(): "xxx.java uses unchecked or unsafe operations."
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Java version 5 introduced generics, a new way to work with collections like ArrayList. If you ignore the generics features, you get these warnings. You can read the linked document, and then come back here with questions if you want!
 
Unnar Björnsson
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ahh so instead of creating ArrayLists like this: ArrayList a = new ArrayList()
I would do it like this: ArrayList<type> a = new ArrayList<type>();

This is great since I don�t have to cast the element to type each time I use the get() method.

Thanks!
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's right. Glad to help!
 
Allion Salvador
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't quite get the generics stuff.
What's the use of making an ArrayList like this?
ArrayList<Cow> al = new ArrayList<Cow>();
Isn't the point to be able to put different kinds of objects in it?
 
Chad Clites
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Keeping in mind that I have only been developing for a couple of years now, I can't see any good reason why you would load an ArrayList with more than one type of object anyway. On the backend you would then have to use reflection to figure out what type of object you were getting back.Then you would have to cast it back, which isn't that big of a deal. The biggest problem would be that you would need some sort of a mechanism for dealing with the fact that the object you pull out may not be what you expected it to be, so then what happens? To me, that would be sort of a developmental nightmare. Keeping track of what was where within the collection would be horrible.

I always thought that the point of the standard libraries was to make things as flexible as possible. By being able to declare the type of objects in the container, there is no need to cast it back on the back end. (It also more closely aligns it with C++ and C also). Isn't a collection by definition a group of similar items (or objects)?
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Allion Salvador:

Isn't the point to be able to put different kinds of objects in it?


It's actually quite rare in real programs to have a specific collection of objects that don't share a common type. If they're not all of the same class, then they'll virtually always share a common interface or superclass -- i.e., if they're not all Cows, then they're probably all Mammals.

So it's nice that ArrayLists can store any kind of object -- but a single individual ArrayList is essentially never called on to store more than one kind of object. I don't know that I've ever programmed an ArrayList that contained (for example) a Cow, a String, and an int[].

Anyway, by declaring that you've got an ArrayList<Cow>, you avoid having use ugly (and potentially incorrect) type casts -- i.e., instead of

((Cow) theList.get(0)).moo();

you can simply write

theList.get(0).moo();

and the nice thing is that if you've gotten confused and tried to make a Dog moo(), the first version will throw an exception at runtime, but the second version will fail to compile. That means you fix the problem right after you make the mistake, instead of a week later when a user reports the problem to you.

Make sense?
 
Allion Salvador
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, I guess so. Thanx!
  • Cow moo
  • Cow eat
  • Cow chew cud
  •  
    Allion Salvador
    Ranch Hand
    Posts: 49
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Oh, by the way, this is a photo of my dad:
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic