Since Java introduced generics the type declarations got at lot longer. This is especially annoying when an API forces you to cast objects, like the reflection-API, the JDO-API , etc. There are plenty of APIs which requires such casts. Those casts force you to write the (obvious) type twice, for the type-declaration and the cast.
We know that for methods the generic arguments can be inferred. I already demonstrated that this can be used to rethrow checked exceptions without wrapping it, which has become one of my favorite Java utility methods. So maybe we can create something similar for casts? Well yes, it’s possible. In order to do so we just define a static cast-method. The return type and the argument type are generic. Since both are inferred by the compiler, we just introduced a ‘cast’ which automatically casts to the expected type.
A few examples of the usage
Note that this also allows impossible casts, which are usually detected by the Java compiler. Let’s take a look at an example:
Furthermore this only works for type declarations. If you immediately pass it to another method it doesn’t work =(
Additionally we can restrict our cast method usage. We can use the co- and contra-variance declaration for generics. Even cooler we can define relations between the generic arguments. For example we can define that the cast-target has to be a sub-type in order to be casted.
Here’s a example where the restrictions apply
With such generic trickery you might hit edge cases where the compilers disagree with each other. With this cast-method there’s a edge case when you combine the inference with auto boxing. The Java-6 javac-compiler will give a compiler error when cast something to a primitive-type. The Eclipse compiler is fine with that and works as expected. With the boxed type Integer it works just fine with both compiler.
I’ve demonstrated that you can define a cast-method which infers the cast target type from its usage. However this only works in some cases, loses some compiler checks and also brings some compiler edge cases differences to the surface. So it’s not really a good idea for production code.
- C# 5.0 Async-Feature: Unit Testing Part III, Avoid Void.
- Nicer Collection Instantiation In Java