Generics - good, bad or indifferent?

[Ian Pilcher]

The problem there is arrays. It's arrays that should be avoided. In the
same way you prefer String/StringBuilder over char[], you should prefer
List<T> over T[]. ArrayList has already been implemented. We don't need
to worry about it.

I'm not sure if you're being intentionally sarcastic or not. You don't
really think that arrays should never be used, do you?

Regardless, array creation is only one example. How about an object
created by Class.newInstance?

Perhaps Mustnag will fix a few bugs, but don't expect language changes.

At least the Mustang compiler supports @SuppressWarnings. You know, the
annotation that Sun introduced in 1.5, but didn't bother to actually
support in fripping compiler.

 

[Thomas Hawtin]

I'm not sure if you're being intentionally sarcastic or not. You don't
really think that arrays should never be used, do you?

I think arrays of objects should be avoided. Not always, but your code
is probably better off with a List.

Regardless, array creation is only one example. How about an object
created by Class.newInstance?

The Class.newInstance method itself is fine (apart from the

At least the Mustang compiler supports @SuppressWarnings. You know, the
annotation that Sun introduced in 1.5, but didn't bother to actually
support in fripping compiler.

1.5 update 6 will support it.

Tom Hawtin

 

[Ian Pilcher]

The Class.newInstance method itself is fine (apart from the
exception-safety aspect of it). Called on a object of the Class<T> it
returns a reference of type T. What are you expecting here?

Called on an object of Class<HashSet> it returns a HashSet. There is
no want to convert that reference to a parameterized HashSet without a
compiler warning. I'm simply flumoxed that Sun thought this was
acceptable.

1.5 update 6 will support it.

Well, that's good news. Do you have a source for this?

 

[Stefan Ram]

My term for an instance of a parameterized type.

The type of an instance is what

instance.getClass()

returns, or - possibly - every type T with

instance instanceof T

This type is never parameterized because of type erasure.

Types of objects (instances) (entities of the run-time model)
are not parameterized - only types of expressions or other
entities of the source-code model can be parameterized.

 

[Mark Thornton]

Called on an object of Class<HashSet> it returns a HashSet. There is
no want to convert that reference to a parameterized HashSet without a
compiler warning. I'm simply flumoxed that Sun thought this was
acceptable.

Your complaints all seem to be about the unavoidable consequences of
erasure. Unfortunately the compatibility problems of not using erasure
are such that I don't think Sun could have reasonably taken such a step.

Mark Thornton

 

[Thomas Hawtin]

Called on an object of Class<HashSet> it returns a HashSet. There is
no want to convert that reference to a parameterized HashSet without a
compiler warning. I'm simply flumoxed that Sun thought this was
acceptable.

Seems completely reasonable to me. If you were to pass
Class<HashSet<String>> to Class.newInstance, then you would get a
HashSet<String>. I'm simply flummoxed that you thought this was
unacceptable.

In any case, you should expect casting and unsafe code if you play about
with reflection.

Perhaps you refer the hack to the handling of Object.getClass that
returns the erasure of the class (you can handle that in one place, if
you wish). Also HashSet<String>.class will not work. There are also
cases were the library hasn't used generics as well as it might.

The exception-safety aspect of Class.newInstance, is in my opinion
unacceptable. Constructor.newInstance should be used instead.

Well, that's good news. Do you have a source for this?

http://www.google.com/search?q=SuppressWarnings+5.0u6

Tom Hawtin

 

[Ian Pilcher]

Seems completely reasonable to me. If you were to pass
Class<HashSet<String>> to Class.newInstance, then you would get a
HashSet<String>. I'm simply flummoxed that you thought this was
unacceptable.

I think it's unacceptable that the *compiler* doesn't provide a way to

In any case, you should expect casting and unsafe code if you play about
with reflection.

I don't have a problem with the requirement for casting. I have a
problem with a compiler that provides no way to do *required* casting
(without generating a warning which is not allowed in a lot of
environments).

http://www.google.com/search?q=SuppressWarnings+5.0u6

Thanks. I've been tracking 4986256; too bad they didn't put 2125378 in
as a related bug.

 

[Ian Pilcher]

Your complaints all seem to be about the unavoidable consequences of
erasure. Unfortunately the compatibility problems of not using erasure
are such that I don't think Sun could have reasonably taken such a step.

My complaints revolve around the *compiler*, and the fact that the
current released compiler provides no way to do several necessary things
without generating warnings.

 

[TechBookReport]

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

But at what cost? It seems to me that the additional complexity in the
language is a high price to pay.

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

There's a difference between those. In the first place before generics
there was no alternative to casting objects into and out of collections.
It wasn't a bad practice, it was how things worked. This is not the same
as catching Exception instead of a specific exception - in this case it
really is a practice.

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.

Not true. I think that Java has a relatively stripped down and sparse
syntax that makes it easy to read clean, maintainable and readable code.

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

No, I wasn't suggesting that at all. I was suggesting that if the
classcast problem was so significant than added intelligence in some of
the IDEs might have helped crack the problem. Leaving it with tools and
not in the language means that those people who want a solution can seek
out an appropriate tool, for everybody else the language is not
encumbered with additional syntax.

 

[TechBookReport]

TechBookReport wrote:




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

I was thinking along those lines. One consequence is that learning Java
is now a lot more complicated than it needs to be. This is bound to have
a knock-on effect in the longer term.

 

[TechBookReport]

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.

If I was a dynamic typing fan I wouldn't be using Java at all. There are
times when a quick and dirty hack is what you need and dynamic typing
makes that easier. But to be honest even my one-off bits of code end up
being Java, as it is for most Java developers I imagine. So, my comments
are nothing to do with being against strong typing or static typing.

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.

But now you've moved the complication elsewhere.

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.

See previous - this is not about dynamic vs static typing.

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.

But this can be solved using documentation and/or smarter tools.

 

[TechBookReport]

I think the reasons are more the complexity of the code required for a
fairly trivial end, and the way type erasure causes so much code that
makes perfect sense to humans, not legal.

It is a implementation driven syntax.

Yep.

 

[Oliver Wong]

Those are 4 identical token sequences.

Yes, sorry, I didn't realize until Thomas Hawtin's reply that you were
talking about difficulties involving parsing Java code. I thought when you
said "adds a lot of mess to the language", you were talking about some sort
of sense of aesthetics from a human perspective.

- Oliver

 

[Roedy Green]

I was thinking along those lines. One consequence is that learning Java
is now a lot more complicated than it needs to be. This is bound to have
a knock-on effect in the longer term.

what does knock-on effect mean, "cumulative", "multiplier"?

 

[Chris Uppal]

One consequence is that learning Java
is now a lot more complicated than it needs to be. This is bound to have
a knock-on effect in the longer term.

I'm not a teacher, but to me it seems as if the biggest problem will be that
"generics" are not an implementation of parameterised classes (itself a perfect
transparent notion, I would say), but only of parameterised types -- and an
incomplete implementation af that. It's the irregularity and baffling[*]
incompletness that will cause more problems. Parameterisation is a powerful
notion, and a student either gets it or they don't; but when that notion is
arbitrarily[*] restricted, then it becomes much more work to internalise.
Someone (up-thread) compared generics with polymorphism; not a bad comparison
IMO -- but the actual analogy would be more like polymorphism with some added
"feature" such as that it didn't work if any method parameter was of a
primitive type or array type...

([*] "baffling" and "arbitrary" from the POV of a newcomer, of course -- or of
anyone who cares about simplicity and consistancy of design.)

-- chris

 

[TechBookReport]

what does knock-on effect mean, "cumulative", "multiplier"?

Cumulative probably. It's another complication to gaining proficiency in
Java.