Redesign miscStuff so as not to be filled with different things.

Failing that, use the first option, and accept the warning.

Aaron,

A TreeMap<Object,Object> is intrinsically not a usefully typed
collection; you have just added it to make the compiler shut up, or
because you think you should for generics.

In your case, it appears that you are using Strings as keys, and either
a Vector<Integer> or a Vector<String> as a value.

The problem with this is that at runtime, Vector<Integer> is just a
Vector, and Vector<String> is just a Vector; there is no way for the
compiler or the runtime to ensure that you are operating on what you
think you are.  Throw an invisible ball to your friend; you cannot know
whether he caught it.

Polymorphism is a useful tool for dealing with this.  As you are using
Vector, your Java book probably predates modern code, so I'll
demonstrate this with abstract classes rather than interfaces.

This solution makes a homogenous (same-type) collection out of what was
a heterogenous (lots of different types) collection.  Another solution
might be to make more than one collection instead, one for each type.
Anyway, here goes the visitor design pattern:

abstract class VectorHolder
{
       public abstract void accept(VectorVisitor visitor);
}

abstract class VectorVisitor
{
       public abstract void visitStringVector(Vector<String> vector);
       public abstract void visitIntegerVector(Vector<Integer>
vector);
}

class StringVectorHolder extends VectorHolder
{
       private final Vector<String> vector;

       public StringVectorHolder(Vector<String> vector)
       {
               this.vector=vector;
       }

       public void accept(VectorVisitor visitor)
       {
               visitor.visitStringVector(vector);
       }
}

class IntegerVectorHolder extends VectorHolder
{
       private final Vector<Integer> vector;

       public IntegerVectorHolder(Vector<Integer> vector)
       {
               this.vector=vector;
       }

       public void accept(VectorVisitor visitor)
       {
               visitor.visitIntegerVector(vector);
       }
}

Now your map is:

TreeMap<String,VectorHolder>

If you have more types than just these two, you can add a method in
VectorVisitor, e.g., visitColor, and then make a ColorVectorHolder.  Of
course, VectorHolder and VectorVisitor might be bad names if you use
anything other than Vectors there..

Don't dismiss this immediately as being a lot of useless code; it is
giving you real runtime information about the elements in your
collection, without you having to cast.

Casting is for magicians.

aaronfude@gmail.com schreef:

new Vector<Integer>(oldVector);

Are you sure you do not want an ArrayList?

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

Clone is a broken API in the context of Java 1.5, because it actually
mentions Object.

Object was only necessary without generics, now we can use type
parameters.

Angelika Langer has something to say on the matter:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#How
%20do%20I%20best%20implement%20the%20clone%20method%20of%20a%20parameterized%20t
ype

Cloning is very often not what you want anyway, as it is shallow
copying.

Serialising and deserialising tends to be more thorough, but very
wasteful.  I'd rather avoid 'magic' behaviour, and write an explicit
copy constructor or factory method, which is the approach the Java
collections APIs take.

Cheers.