[ACCEPTED]-Type aliases for Java generics-casting

If you want full type safety, I don't think 22 you can do better without some kind of wrapper 21 classes. But, why not make those classes 20 inherit/implement the original generic versions, like 19 this:

public class FooBBQ extends Foo<Bar<Baz,Qux>> {
...
}

This eliminates the need for toGeneric() method, and 18 it is more clear, in my opinion, that it 17 is just a type alias. Also, generic type 16 can be cast into FooBBQ without a compiler warning. It 15 would be my personal preference to make 14 Foo, Bar, Baz... interfaces, if possible, even if some code 13 duplication would occur in implementation.

Now, without 12 knowing concrete problem domain, it is hard 11 to say whether you need, say FooBBQ, like in your 10 example, or perhaps a:

public class FooBar<X, Y> extends Foo<Bar<X, Y>> {
...
}

On the other hand, have 9 you thought about simply configuring Java 8 compiler not to show some of the generic 7 warnings, and simply omit the parts of generic 6 definition? Or, use strategically placed 5 @SuppressWarnings("unchecked")? In other words, can you make DoableImpl only "partly 4 genericized":

class DoableImpl implements Doable<Foo<Bar>>,Foo<Bar>> {
    Foo<Bar> doIt(Foo<Bar> foobar) { ... } 
}

and ignore the warnings for 3 the sake of less code clutter? Again, hard 2 to decide without a concrete example, but 1 it is yet another thing you can try.

Scala has nice support for type aliases. For 5 example:

type FooBBQ = Foo[Bar[Baz,Qux]]

I realize that this answer won't 4 be helpful if you don't have the option 3 of switching to Scala. But if you do have 2 the option of switching you might have an 1 easier time.

Maybe having this many generic parameters 7 flying around is just a bad idea and I need 6 to re-think the problem?

Very probably. Do 5 need to specialise 'Doit' in 8 dimensions?

In 4 a lot of cases, these types don't exist 3 in a vacuum and you should be thinking what 2 domain objects your 'wrapper' represents 1 rather than using them as a coding convenience.

Well, Java has no type aliases so you're 11 out of luck. However, type aliases sometimes 10 can be replaced with type variables! So 9 we solve the problem of too many generics 8 with even more generics!

As you've stripped 7 all content from your example I can't guess 6 where or whether it makes sense to introduce 5 additional type variables, but here is one 4 possible decomposition:

class DoableImplFoo<A,B> implements Doable<Foo<A>,Foo<B>> {
  public DoableImplFoo(SomePropertyOf<A,B> aAndBAreGoodEnough) { ... }
  Foo<A> doIt(Foo<B> fooB) { ... }
}

When you instantiate 3 A to Bar<Baz,Qux> and B to Bar<Zot,Qux> later you may find that there 2 is some boilerplate again, but it could 1 be less than what you originally had.

I would say that, yes, you need to rethink 2 the problem. The declaration

 class DoableImpl implements Doable<Foo<Bar<Baz,Qux>>,Foo<Bar<Zot,Qux>>> {
    Foo<Bar<Baz,Qux>> doIt(Foo<Bar<Zot,Qux>> fooBZQ) { ... } 
 }

is a pretty 1 clear case of overusing generics.