I've come up w/ an example using generics for a List. Both for parameter and returning objects.

import java.util.List;

final List<PVector> myList = new ArrayList();
final List<PImage>  myImgs = new ArrayList();

void setup() {
  noLoop();
  background(0200);

  myList.add( new PVector(PI, TWO_PI, THIRD_PI) );
  final PVector vec = getItem(myList, myList.size() - 1);
  println(vec);

  myImgs.add( createImage(50, 50, ARGB) );
  final PImage  img = getItem(myImgs, myImgs.size() -1);

  img.loadPixels();
  for (int i = 0; i != img.pixels.length; i++)
    img.pixels[i] = color(50, 100, 30, i % img.width << 3);
  img.updatePixels();

  image(img, 17, 17);
  image(img, 34, 34);
}

static <Type> Type getItem(List<Type> al, int idx) {
  return al.get(idx);
}

I'd have to see your code (or at least a portion of it) to fully understand the problem, but by the way you describe it, it sounds as if the way you have setup your program is fundamentally flawed. As a general rule, I try to stay clear of instanceof statements as they generally run into problems such as this, and only allow you to get further along before running into the wall. Also, it's typically a bad idea to have any kind of "tree", be it of if statements or instanceof statements.

With that in mind, I would try to come up with an alternative solution that involves inheritance. You can create one base class for all of the possible return types for your function, and then have all of the different types extend that base class. I would typically try to use abstract classes if possible, but for your situation, you may not need them. With abstract classes (or interfaces, even) you can declare a set of methods that is universal across all subclasses of the base class, extend each of them in your subclasses, and thus completely bypass the need to cast anything.

If you haven't tried out using abstract classes before, then you may not know how to do any of this. There are plenty of tutorials out there, but you can get more help from myself and other members of the forum if you provide code that isolates the problem and that we can work with.

I have an abstrat superclass that all of my object classes extend from already. I did not know that if you made an abstract class and made subclasses of it you do not even need to cast when you pull it from an array list ( that is if you cast the array list on initialization to the abstract superclass)  Thank you so much, that helps a lot if it works! 

@harry, I made several times similar remarks to GoToLoop, now I renounced...

On one hand, he likes to skip re-declarations of types in collections initializations, to avoid typing; on the other hand, he likes to sprinkle his code of useless modifiers (useless in Processing, at least) like static, byte instead of int, and so on.
final is, IMO, a more useful modifier... (but less so in such short code)
Fancy code like width >> 2 instead of width / 2 is also funny, but confusing to the main audience of this forum, beginners.

@GoToLoop this is unsafe: List< PVector> myList = new ArrayList();
(you're running flawed code!).

Well, let's try to defend myself!  

I guess every1 knows the effects of a generics declaration for a reference variable:

1. It makes sure that methods like add(), addAll(), put(), putAll(), append(), set(), etc. accepts only the same data-type as the declared generics for that ref. variable.
2. And my favorite 1, no need to use cast operators every time we use get() and such! 

Now, what's the only effect of generics usage on Collection instantiation part?:

It merely makes sure that in the rarest case we decide to pre-initialize it w/
another Collection of sorts, it is indeed the same type as the declared generics.

Now tell me how -> List<PVector> myList = new ArrayList<PVector>();
can be any safer than -> List<PVector> myList = new ArrayList(); ???

That List is being instantiated empty!
Placing a < PVector> to the right won't make any difference at all, but more verbosity!!!

Actually, initializing a Collection w/ anything makes it incompatible w/ JS Mode!

Even such example as -> List<Integer> integers = new ArrayList<Integer>(strings);
isn't that brilliant, b/c any1 can easily spot that variable strings is a List< String>.

Although it's an extra safe-guard, it's very rare for some1 to make such "crass" bug! 

Nevertheless, it's important for when the pre-filling Collection comes from a source
we can't be much sure of its generics content.

Also be aware that any generics is stripped off once program is compiled!
Generics are only relevant for the Java compiler. There's none present in byte-code!

Note, in Java 7 you can simply use <> aka "diamond inference":

Although I'm using OpenJDK 7 in my Processing, I can't use any of its new features like:

1. <> inference;
2. binary literals -> 0b11001110;
3. String as switch() parameter;
4. Separate digits w/ _ -> 130_491;
5. enum types;
6. etc.
   

And enum type is Java 5! Seems like Processing's pre-compiler still lives in medieval Java 4!!!

Fancy code like width >> 2 instead of width / 2...

Actually, width >> 2 is width / 4. width / 2 is the same as width >> 1. 

I agree with PhiLho.

- "The key to performance is elegance, not battalions of special cases".

Well, less verbosity is more elegance! 

Anyways, I've already proven that using generics only to the declared variable is as safe as using it
for both declared variable & instantiated Collection parts when it isn't pre-populated w/ another Collection.

And taking reasonable care, it's safe even when the Collection is pre-populated after all. 

And generics don't remain in the compiled byte-code!

@GoToLoop let's say List<T> list = new ArrayList() is not unsafe per se, it's just "not recommended practice" and emits compiler warnings (not visible from the Processing editor but annoying in other IDEs). Also the List<Integer> list = new ArrayList(strings) mistake is obvious only because the argument is named "strings", but what if one named it "foo" or "values" or whatever, and declared it somewhere beyond your scope so that you can't immediatly see its type? That's not a rare case, that's typical.

2) "Verbosity" is somewhat ironic, given eg. the pointless modifiers you often use. Don't mistake "pretty/flashy" code for "elegant" code, elegance is in the approach, reliability and maintainability, not the number of characters or lines of code, nor the flashy tricks/features you put.

I've tested a sample using BlueJ IDE and indeed it generates a warning about unsafe operation and such.

But I don't think I should consider that for Processing IDE.
Otherwise I'd put public access keyword everywhere too!

And warnings aren't errors. Even non-standard procedures can trigger it.
Even though completely harmless & correct!

Remember that generics was a Java 5 new feature. Was Java 4 code unsafer then?
Or the fact that generics aren't present in compiled byte-code makes them irrelevant?
The question is you've claimed my code was unsafe due to it!

List<T> list = new ArrayList(); isn't any unsafer than List<T> list = new ArrayList<T>();
b/c that Collection is being instantiated empty!

An extra <T> to the right side only safe-guards a pre-populated instantiation like:
List<T> list = new ArrayList<T>( new Collection<TT>() );

In case TT would be different to T, the extra <T> would catch it! But it's redundant for empty instantiations!

And more than 95% of ArrayList instantiation cases I see in Processing are empty!
And any argument would make it incompatible w/ JavaScript mode anyways!

static final String[] commonWords(String x, String y) {
  final String[] xWords = x.toLowerCase().split("[^a-z]+");
  final String[] yWords = y.toLowerCase().split("[^a-z]+");

  final HashSet<String> xSet = new HashSet(Arrays.asList(xWords));
  xSet.retainAll( new HashSet(Arrays.asList(yWords)) );

  return xSet.toArray( new String[xSet.size()] );
}

Another thing is determinism. There's no way both xWords & yWords be anything other than String[].
So I'm pretty confident I don't need an extra < String> to the right-side HashSet!

I'd need to create another deliberate Array w/ a different type other than a String
and use that in place of xWords or yWords.
But it's a lotta effort to force it to become buggy! 

Anyways, there weren't generics in Java 4 era.
Although I program in Processing/Java very recently. 

And wonder how JavaScript or Python programmers can even code w/o type declarations? 

I'm a Python programmer too but that's not the point.
Yes, older Java code were less typesafe and this is why they introduced generics, with more ore less success.

Redundant type parameter (which is actually obsolete since diamond inference) is required at least to avoid warnings, so it's more "correct" at least from the compiler's point of view. Again, it's optional and sometimes boring but a good practice IMO, plus it looks more coherent.

Sorry for annoying the other forum users.

(which is actually obsolete since diamond inference)

As stated before, diamond inference is incompatible w/ Processing's pre-compiler.
If it was permitted, I'd probably use it. 

But that would make it incompatible w/ Java 6.
And unfortunately, Processing comes bundled w/ that. And even w/ an old version of it!

The main point of this discussion, IMHO, is that this forum is mostly frequented by newbies.
That's why I believe more advanced users like you should show good practices, like avoiding warnings, and should avoid tricks that leave them perplexed, like this >> 1 and body of loop in the update section of the for loop...
That's just my opinion, I don't think I will convince you, and I won't insist anymore.