TechBookReport skrev:

"Intrusive and ugly," seems rather strong. I'm just glad that they used
the angle brackets that C++ already uses for templating; no point in
re-inventing a symbol when there's already heritage.

And as for generics being part of the language, well, yes you have to
know them in case you're using code that uses them, but they are still
optional for your own, original work. Generics should be used when the
following two conditions hold:
A) There are a significant number of casting errors caused by mxing
types in collections.
B) Identifying the errors introduced in (A) is significantly
time-consuming.

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

TechBookReport skrev:

The benefit is big. Genericity is a fundamental building block of a
type safe programming language (which, I hope, Java is meant to be), so
generic types and methods should have been included in Java from day
one. The implementation, as you mention, is lacking. Not changing the
JVM to support generic types was a mistake and the cost of this mistake
will only increase with time until it's rectified. The .NET
implementation of generics has VM support, which is a big plus, but the
implementation of type contraints is better in the Java version.

The awkwardness of using generic types could be mitigated by
introducing type inference of field and local variable types, for
example:

let v = new Vector<Point<Integer>>();

which would be equivalent to:

Vector<Point<Integer>> v = new Vector<Point<Integer>>();

Replace "let" with your favourite keyword. Maybe this could be filed as
an RFE, if it hasn't been already. It probably won't be approved,
because the Sun engineers are probably busy implementing the XML
language syntax. *shiver*

/Jesper Nordenberg

That's my opinion.

The benefits gained are two-fold.  We significantly reduce (but not eliminate)
the risk of casting errors.  We gain better self-documentation of the code.

The first of these is (IMO) completely negligible.  It just wasn't worth the
effort.  It doesn't even justify the small effort of typing in the <>s.  Let
alone the massive complications to the javac implementation; to the java
specification (which is now essentially unreadable, while it /used/ to be a
valuable resource); and to all Java-aware tools such as Eclipse.  (Just think
what valuable improvements to Eclipse we are missing because the programmers'
time was spent on the changes needed to support generics -- and God knows,
Eclipse could do with a bit of improvement...)

The second is (IMO) a lot more valuable.  Certainly I'd rather know that some
method answers a List<Point> than just a List.  However, when you factor in the
"wildcard" notation, the generic type definitions quickly become unreadable.
And, in my limited experience, so far, that happens more often than not.  So
you end up ignoring the spec, and assuming that it's "correct" and does in fact
mean what logic and experience suggest it /should/ mean.  So the documentary
value is compromised.

I think they blew it.

   -- chris

It appears that most of those spouting off about the evilness of
generics are dynamic typing fans. If you don't like static typing, then
you aren't going to want more of it. If you do like static typing, it
might as well be done properly.

No it's not a big deal. Although it is ugly, tends to lead to
unnecessary code and the source is complicated precisely where you want
it as simple as possible.

ClassCastException is a red herring. Searching through the Bug Parade
brings up seven times more bugs with NullPointerException than
ClassCastException.

Given that we have such good static type checking, runtime type checking
is an obscure feature. Having said that, as 1.4- isn't targeted, I would
have preferred a JVM level implementation, particularly for covariant
return types (which still have outstanding bugs).

It's not a valid criticism coming at it from a dynamic typing point of
view, anyway. You can't, as I understand it, take a Smalltalk collection
and ask what shapes will all its contents, past and future, will conform to.

The real issue, assuming you welcome static typing into your life, is
documentation. It's much easier to understand what is in Set<EmployeeID>
than Set with the element type hidden amongst the JavaDocs if at all and
if kept in sync.

For instance, modifying a JRoller Velocity template, many of the methods
return Lists. But the documentation (often) doesn't (didn't) say what
they contain. I've inherited code that accidentally used the same map
for two different mappings. That only became apparent because, coming
from C++, I used to put type information within /*<  >*/.

I find JavaDoc Use pages useful in understanding how a piece of code
fits together. In olden days, if you didn't use arrays, you didn't get
to see a lot of important relationships. In one case, I was witting the
public API documentation to a product and wrote in on the type
description the missing uses. Shortly after that the PSE changed the
Collections to arrays. But really, we would like to encourage the use of
interfaces over nasty arrays.

While some people coming to generics might find them confusing, if they
push their minds back far enough, they probably found polymorphism
confusing too. They are essentially the same thing, just with a layer of
indirection. Perhaps it will take a while for texts to become stable.

Tom Hawtin

They allow even more errors to be caught at compile time.

Nor is catching Exception instead of specific exceptions. But it's
still bad practice compared to the alternative.

No, it doesn't, otherwise you would be using a good-looking language
like Eiffel or Smalltalk instead of *any* member of the fugly C
family.

You want to make IDE-dependent languages? I thought that idea died
with Smalltalk?

And that is good enough reason to have it.