4

GenericsInJavaPartII.pdf, GenericsInJavaPartI.pdf.

You lose type safety when you mix nongenerics with generics. For example,
List notGeneric = genericList; type safety would not flow into notGeneric,
even though it's bound to the same list as genericList in memory.
 You can't use primitive types as parametric type or static fields of generic
type.
 Instances of different parameterized types (like ArrayList<String> and
ArrayList<Book>) belong to the same type ArrayList.
 Since the JVM has no notion of generics, other classes won't be able to take
advantage of generics via reflection.
So, if you're protected at only a superficial level, and if new languages can't
participate in the solution, the syntax only serves to further burden users with
details and inconsistencies, prompting the question, are generics a sol
ution begging
for a problem? When I ask my students how many class cast exceptions they get
from collections, very few say this is a significant problem.
Ted Neward: Generics
Author of Effective Enterprise Java

Ted Neward is an independent consultant specializing in high-scale
enterprise systems. He is an author, teacher, and consultant, focusing on
Java .NET interoperability. He has written several widely recognized
books in both the Java and .NET space, including the recently released
Effective Enterprise Java (Addison Wesley). He lives in the Seattle area
with his wife, two sons, two cats, and eight PCs.
What's wrong with
Java, in general?
TN: Hordes of developers are writing code

should be deprecated in 1.5 and
removed in 1.6). 4.3.8. Overloading
In some ways, Java's typing problems are exacerbated by another limitation
described as a feature: method overloading . Taken alone, overloading is not a
huge problem, but Java developers use overloading to enable an API that supports
multiple types. You've got a surefire recipe for API bloat.
Need an example? Take the
java.util.Array interface. Please. For convenience, you
get more than 70 methods. Peel back the onion, and you see they cover only 10 or
so pieces of actual, dis
tinct functionality. With a smarter method declaration, you'd
be able to specify parameters with keywords, and default unused parameters to an
intelligent value, like 0 or null.
4.3.9. Other Costs
When you decide to type everything, it's a slippery slope. When you need to pull
back from Java's typing system, you can't always do so. You're starting to see
many examples of Java libraries working around the typing in unusual ways. Study
the JMX interface for an excellent example. Does it use strong typing? It appears
that way, at first. Then you dig in a little and find what only can be conceptually
described as an embedded type systema mini-language, embedded in a String
parameter called ObjectID, with a complete language description in the JavaDoc
and syntax completely opaque to compilers and interface generators and
processors. Java's type system failed here. JMX architects bypassed the type
system, building metadata into strings and other objects. If you look around, you'll
find other examples of this as well. Most often, Java hides weaker types, or
dynamic types, as strings.
4.3.10. The Benefits of Static Typing

automated unit testing make it much easier to catch type problems in dynamic
languages long before they ever reach production. My experience tells me that
Java's type safety is not as important and comprehensive as most programmers
think it is, and the typing in more dynamic languages, with unit testing, is not as
limiting.
The IDE code completion problems presented by dynamic typing will probably get
solved by a combination of better browsers and smarter context. Unit testing will
make type safety less useful from a program correctness standpoint. In the end, for
application programming, more dynamic typing will prevail. The productivity
gains due to dynamic typing are too compelling to ignore.

4.4. Primitives
From the very beginning, Java designers consciously made decisions to attract the
C++ community, and favor performance over other considerations. The biggest
compromise was the inclusion of primitive types. This addition means Java is not
fully object-oriented, and presents several significant challenges. Those who came
from the C++ community don't always see a problem, but developers from other
programming languages often see primitives as an ugly kludge. Primitive types do
not descend from Object, so Java is more of a hybrid language than a true object-
oriented language. But that's all academic. There's a real cost associated with the
theory.
4.4.1. Primitives Are Limited
Java primitives limit you because they don't descend from a common Java object.
One of the nice things about most object-oriented languages is polymorphism: you
can deal with specific objects in a general way. In Java, that's not quite true,
because primitives do not descend from Object. You can't, for example, say
6.clone( ), or 6.getClass( ).

aggressively attract C++ developers, because the idea and syntax were similar. In
retrospect, though, it's created some significant problems, in terms of language
clarity, productivity, and readability.
In retrospect, we're paying for the early compromises that it took to draw away the
C++ community. That's a fair trade, in my book. Don't underestimate the cost,
though. Primitives complicate the code base, lead to inconsistencies, and bloat the
language. The next popular programming language will probably not be a hybrid
language, with both objects and primitives. C++ started the transition to object-
oriented programming and Java finished it. We don't need a crutch anymore.