I've solved my problem, as elegantly as it appears to be possible.

Manager handles Data.

Manager1 handles Data1.
Manager2 handles Data2.

The add() method in Manager is overloaded in each of the subManagers.
Not very elegant, forces one to keep track of all the manager subclasses
but it's better than writing the same code over and over again.

snipped...

Thats because Interfaces are classes, and so can't be created - they are
a means of specifying what a given class looks like - nothing else.

They don't have any implementation, so there's no way for Java to know
what to do even if it let you instantiate them.

What languages do you know - we may be able to show how they are similar
to something from those languages....

Failing that, read the Java tutorial, google for Interfaces, as it
appears you have large gaps in your understanding.

I think what you want is this:

Class Manager
{
   private Vector<DataInterface> dataVector;

    add(){
       dataVector.add( new Data1(blabla) );
   }

}

class Data1 implements DataInterface{
}

notice: the dataVector accepts objects of type DataInterface. When you
actually add data, you will create a Data1 object (with "new") but it will
be of type DataInterface as well.

You seem to have overlooked that you can use Interface types like this:

DataInterface myData = new Data1();

HTH,
andreas

You can use a general Manager class for this, but you'll need to play
some tricks to instantiate the Data classes.

public class Manager<T extends Data>
{
   private Class<T> dataClass;
   private Vector<T> dataVector;

   public Manager(Class<T> c)
   {
       dataClass = c;
       dataVector = new Vector<T>();
   }

   public void add()
   {
       try
       {
           T data = dataClass.newInstance();
           dataVector.add(data);
       }
       catch (...) { ... } // error handling omitted
   }
}

NOTE A: The Class<T> parameter is admittedly a bit ugly.  It is required
in order to accomodate type erasure.  On the other hand, at least it's
impossible to pass the wrong class as a parameter because of compile-
time checking of the generic type.

NOTE B: This assumes a zero-argument constructor.  Theoretically, it's
possible to do the same thing with arguments to the constructor.  In
practice, that's a bad idea because you have to clearly document a
complex constructor signature that isn't checked until runtime.  If you
think you need that, then instead consider (a) adding a method to Data  
-- Data.setInitialState or something like that, or (b) using an abstract
factory class instead, so you can create the factory class with no
parameters, and then pass parameters to a nice documented and type-
checked method.