Safe Casting Collections using utility methods

Question

Hi,
I am wondering, are there any utility methods that help extract the elements form one collection<?> to Collection<Box>??
for example, I may have a method signiture that takes List<Box> as a parameter called doYourJob.
and I have a List of List< ? extends Object> someList.
ofcourse I cant use this object for that method:
List<? extends Object> someList;
doYourJob(someList);//wrong
public void doYourJob(List<Box>list){
}what I need to do is to make a utility method that extracts a spisific type from the collection and puts them in another collection:
public List<Box> extract (List<?>list){
ArrayList<Object>newList=new ArrayList<Object>();
for(Object o:list){
if(o instanceof Box)newList.add((Box)o);
return newList;
}my question is: are there in the jave API utility methods to change the generic type of a collection by changing the collection as whole.
Maybe I can send the type that I want as Box.class and it returns that list.
Sorry if the question is repetitive!

Answer 1

I wish his was something that was easier to do in
Java because I think more people would use that
approach if it weren't so verbose.
Maybe I'm confused here, but I don't think of coding
up an interface as being an especially verbose or
arduous exercise...? But then I'm not too sure what
you're comparing it with.It's not writing the interface that's the problem. It's writing the code to wrap the existing classes in your wrappers or whatever implementation you come up with. Doing it once is no big deal but if you are using it as a fairly common approach in your code (as I do) it can become pretty messy. What really bothers me is that it takes a lot of fluff code. I've been looking at other languages esp. Scala on this and they have very concise composition syntax. I'm not ready to go with Scala but I think if the language steered people more towards composition and 'recasting' objects through interfaces, people would do more of it.
I'm working with one now that's all about return
codes and simulating in-out parameters (I said it
once and I'll say it again: Joel Spolsky is an
idiot.)
Hmm. I read Joel On Software, and from a business
perspective he seems pretty clued in. I've never
encountered any of his code, nor read anything much
of a purely technical-diatribe nature from him. But
I'm still alittle surprised.Not sure if you've read this:
http://www.joelonsoftware.com/items/2003/10/13.html
I'm exaggerating, of course. I don't really think he's an idiot but I think the above is super-extra-double-plus stupid. I really can't fathom why he thinks return codes are superior. I can only think he doesn't really get how exceptions work.
There's also this ironically named URL:
http://www.joelonsoftware.com/articles/Wrong.html