Jack Woehr wrote:
Jess Holle wrote:
Compile-time checking wherever it is net time savings to the
developer and does not hinder runtime performance is a very good
thing. In the case of generics, I believe they're a big time saver
overall.
Generics, while weak compared to C++ container polymorphism, are a
vast improvement
to Java. Methods can return specific types without casts. Earlier Java
code is littered
with hard-to-read and error-prone casting.
Actually I believe Java got it right as compared to C++ -- at least as
used in the ANSI C++ generic collections library. This library
generates big chunks of object code for *every* type thrown at it --
irrespective of similarities in types. Just use:
vector<long>
vector<void*>
vector<char*>
vector<const char*>
vector<Foo*>
vector<Bar*>
...
and you'll get the idea. While each one of chunks of object code is
potentially very well optimized for a given type (though I can't see it
making any difference in the case above), that's got to wreak havoc with
working set size, etc -- which Java has enough issues with already.
One could say this is just a library / STL issue in C++, but having
written C++ collections that don't have this issue I can say you have to
work a lot harder to get this. C++ generics crank out mounds of code
unless you're quite careful not to let them do so.
There are a few rough bits (which certainly have reasonable workarounds)
where I'd like to do something like:
public class Foo<T>
{
public void doIt()
{
Class targetClass = T.getClass(); // this clearly won't work...
}
}
But otherwise, I think the Java generics guys did an amazingly good job,
especially given the constraint of interoperability with legacy code
using collection classes.
--
Jess Holle
