Basically, Java types don't always propagate nicely. If at any point, you cast to
Object, you loose information about your types (this might not be always true in a block your compiler can analyze). And you can't always avoid
Object, due to generics.
If we look at OpenJDK's implementation, the comment says:
- Objects must implement
- Objects must be mutually comparable: you can't compare
Both checks can be done at runtime (throwing exceptions if needed).
What you suggest enables to do the first check during compilation.
However, we must consider the method with respect to its usage, and unfortunately, you can't always know the type of some objects.
I originally wrote an example with
toArray, which returns an
Object. The conversion to
Object does not allow calling
sort and I saw no easy way to convert
String. Thanks to SJuan76's comments, here is how to do it:
String strings = names.toArray(new String);
strings, thanks to array covariance, is suitable for comparison. However, this approach is not developper-friendly. Furthermore, it cannot be abstracted away by language constructs: generics use type erasing techniques that introduce
By the way, let's forget about generics for a moment: after all, early versions of Java, for which
sort was implemented, did not provide generics.
As already said, the kind of code written above is certainly not convenient for use. But more importantly, even though it is checked at compile-time, I am pretty sure it is not optimized away: there is still an array copy operation at runtime: you don't want to write an API which imposes this kind of cost to the user (also consider the performance of original virtual machines).
Then, it is better to simply accept more parameters and perform checks dynamically. Since anyway, point (2) above already requires runtime checks and possibly throws exceptions, we might as well accept
Object and test types at runtime.
Now, you might think that the fact that some functions loose type informations like
toArray (without argument) is itself unfortunate but this is more an issue of the language's type system at this point.