Generics

Thread view:

deelBlue - 13 Mar 2008 21:13 GMT

Hi ,

I am trying to program a stack with an array, the interesting part of the
implementation looks like :

public class Stack<T> {

    T[ ] field;

    Stack(){
        field=new T[10];
    }

}

but I am getting a compiler error by creating the field (new T[10] ).

can some one help me please.

Reply to this Message

Eric Sosman - 13 Mar 2008 22:13 GMT

> Hi ,
>
[quoted text clipped - 12 lines]
>
> but I am getting a compiler error by creating the field (new T[10] ).

It's a FAQ:

http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html

... and look for "Can I create an array whose component type
is a concrete parameterized type?"

Signature

Eric.Sosman@sun.com

Reply to this Message

Mark Space - 13 Mar 2008 23:30 GMT

> It's a FAQ:
>
> http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html
>
> ... and look for "Can I create an array whose component type
> is a concrete parameterized type?"

So many problems would be solved if Sun just got rid of erasure. I hope
they do in Java 7.

Reply to this Message

Jan Thomä - 20 Mar 2008 14:00 GMT

> So many problems would be solved if Sun just got rid of erasure. I hope
> they do in Java 7.

They prolly won't as it would break backwards compatibility which was the
whole idea about erasure IIRC...

Signature

_________________________________________________________________________
insOMnia - We never sleep...
http://www.insOMnia-hq.de

Reply to this Message

Mark Space - 20 Mar 2008 19:32 GMT

>> So many problems would be solved if Sun just got rid of erasure. I hope
>> they do in Java 7.
>
> They prolly won't as it would break backwards compatibility which was the
> whole idea about erasure IIRC...

I understand. However, I think there's a time to maintain
compatibility, and a time to break it. There has to be some way to
introduce reifiability (sp?) with the minimum of disruption.

I think some new types in the collection interface (RefiableHashMap,
RefiableTreeSet, etc.) and a modification to the generic syntax for
reifiable types would allow backwards compatibility with the old types
while giving folks the option to move to reifiable types.

Reply to this Message

Jan Thomä - 28 Mar 2008 11:25 GMT

> I think some new types in the collection interface (RefiableHashMap,
> RefiableTreeSet, etc.) and a modification to the generic syntax for
> reifiable types would allow backwards compatibility with the old types
> while giving folks the option to move to reifiable types.

Well they did that in Dot.Net which introduced a lot of headaches because
you could no longer use libraries that used untyped collections together
with typed collections. So if you wanted to use a library that was still
using the old collections together with a project of yours that used the
new collections you were basically stuck. That's why i think the erasure
concept is a bit more clever in that regard. Actually i didn't have any big
issues with erasure apart from the fact that you cannot do a new T() thingy
but i find Sun's solution a lot more elegant than Microsoft's which
basically breaks backwards compatibility. But am not trying to incinerate
holy war here. In case you really need to do something like new T() you can
still do something like that

T create(Class<T> clazz) {
T result = clazz.newInstance();
}

Granted, not as nice as a new T() but i'd trade this for backwards
compatibility every time.

My $0.02 ;)

Signature

_________________________________________________________________________
insOMnia - We never sleep...
http://www.insOMnia-hq.de

Reply to this Message

Lew - 28 Mar 2008 13:10 GMT

> T create(Class<T> clazz) {
> T result = clazz.newInstance();
> }
>
> Granted, not as nice as a new T() but i'd trade this for backwards
> compatibility every time.

If you already have a Class<T> instance, you don't need a cover function for
your one-line call to newInstance(). Now, if you were to encapsulate the
error-handling in that one-liner, it very likely is worth the cover function.

Signature

Lew

Reply to this Message

Jan Thomä - 28 Mar 2008 13:41 GMT

>> T create(Class<T> clazz) {
>> T result = clazz.newInstance();
[quoted text clipped - 5 lines]
> error-handling in that one-liner, it very likely is worth the cover
> function.

Indeed. My intent was to show that one way of doing it is to force the users
of your class to supply you with a Class<T> if you really need to
instanciate a T in your class. Of course you don't need the wrapper. I'll
try to be more clear next time.Thanks for the hint ;)

Jan

Signature

_________________________________________________________________________
insOMnia - We never sleep...
http://www.insOMnia-hq.de

Reply to this Message

Roedy Green - 28 Mar 2008 13:30 GMT

>Well they did that in Dot.Net which introduced a lot of headaches because
>you could no longer use libraries that used untyped collections together
[quoted text clipped - 7 lines]
>holy war here. In case you really need to do something like new T() you can
>still do something like that

I had a talk with Bill Joy a few years back when he came to the
Colorado Software conference. I felt quite elated afterwards mainly
because I learned many of the things Sun had done that I ascribed to
incompetence were done because of some other factor I had not
considered. They were quite aware of the drawback and were just as
disturbed about it as I was. He described the politics within Sun of
competing needs. One of them is being careful not to freak out the JVM
licensees with too many changes. They did not want to scare them off.

That would have loomed big in the decision to do generics with type
erasure.

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Mark Space - 28 Mar 2008 22:14 GMT

>> I think some new types in the collection interface (RefiableHashMap,
>> RefiableTreeSet, etc.) and a modification to the generic syntax for
[quoted text clipped - 4 lines]
> you could no longer use libraries that used untyped collections together
> with typed collections. So if you wanted to use a library that was still

This is a good point. Lately I've been advocating some sort of
annotation that would give the compiler a hint for it to generate
boilerplate.

Try to do that on one's own runs into two problems:

1. Not everyone is going to implement their own API in the same way. So
non-standard and diverse implementations make it harder on the programmer.

2. The Class class is final, and can't be extended for a new class type
or new methods. If Sun would add a new type, or a some new methods to
Class, to support a type with reifiable types, again folks would not
have to come up with their own non-standard solutions.

I think just adding boilerplate to the existing classes would keep
backwards compatibility. The Class issue might be harder, but if the
new class type is only available through new interfaces, then I think
computability issues will be kept to a minimum.

Reply to this Message

Roedy Green - 14 Mar 2008 07:27 GMT

>but I am getting a compiler error by creating the field (new T[10] ).

you have to cheat. For why see
http://mindprod.com/jgloss/generics.html

To figure out how to kludge, see the links in that essay or study how
Sun cheats in classes like ArrayList.

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Generics

Free Magazines