Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Generics: struggling against type erasure...

Reply
Thread Tools

Generics: struggling against type erasure...

 
 
z-man
Guest
Posts: n/a
 
      10-05-2006
Let me say: generics type erasure is just a misfeature that's
embarrassingly hiped as a "feature".

Is there any wizard that can solve this annoying problem (dynamic
instantiation from a type variable using its default constructor -- see
example below)?

Dropping all the type information at compile time is definitely a shame.

protected <T,TSuper extends MySuperType<T>> void setEntry(
String key,
T value
)
{
TSuper entry = myMap.get(key));
if(entry == null)
{
// Owing to that crappy type erasure, neither this works...
myMap.put(key,entry = new TSuper());
// ...nor this one (no 'class' member available).
myMap.put(key,entry = TSuper.class.newInstance());
}

entry.setValue(value);
}
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      10-05-2006
z-man <(E-Mail Removed)> writes:
>Let me say: generics type erasure is just a misfeature that's
>embarrassingly hiped as a "feature".


"hyped"

Please be aware that some people in this newsgroup love Java,
so when you use such wording you might hurt their feelings.

You could have just asked your question without the
introducing rant.

>Is there any wizard that can solve this annoying problem (dynamic


"wizard who can ..."

>protected <T,TSuper extends MySuperType<T>> void setEntry(
> String key,
> T value
> )
>{
> TSuper entry = myMap.get(key));
> if(entry == null)
> {
> // Owing to that crappy type erasure, neither this works...
> myMap.put(key,entry = new TSuper());
> // ...nor this one (no 'class' member available).
> myMap.put(key,entry = TSuper.class.newInstance());
> }
>
> entry.setValue(value);
>}


This sounds like an FAQ. My own, untested approach in this
case would be:

public class EntrySetter <T, TSuper extends MySuperType< T >>
{ final Factory<TSuper> factory;

public EntrySetter( final Factory<TSuper> factory )
{ this.factor = factory; }

public void setEntry
( final java.lang.String key,
final T value )
{ final TSuper old_entry = myMap.get( key );
final TSuper entry;
if( old_entry == null )
{ entry = factory.newInstance();
myMap.put( key, entry ); }
else entry = old_entry;
entry.setValue( value ); }}

 
Reply With Quote
 
 
 
 
z-man
Guest
Posts: n/a
 
      10-06-2006
On 10/06/2006 12:27 AM, Stefan Ram wrote:
> z-man <(E-Mail Removed)> writes:
>> Let me say: generics type erasure is just a misfeature that's
>> embarrassingly hiped as a "feature".

>
> "hyped"


sorry for my typo.

> Please be aware that some people in this newsgroup love Java,
> so when you use such wording you might hurt their feelings.


I sincerely didn't want to hurt anybody. Anyway, I think not to be the
only one to complain about such a crippling implementation choice.

> You could have just asked your question without the
> introducing rant.


That was due to my frustration

>> Is there any wizard that can solve this annoying problem (dynamic

>
> "wizard who can ..."
>
>> protected <T,TSuper extends MySuperType<T>> void setEntry(
>> String key,
>> T value
>> )
>> {
>> TSuper entry = myMap.get(key));
>> if(entry == null)
>> {
>> // Owing to that crappy type erasure, neither this works...
>> myMap.put(key,entry = new TSuper());
>> // ...nor this one (no 'class' member available).
>> myMap.put(key,entry = TSuper.class.newInstance());
>> }
>>
>> entry.setValue(value);
>> }

>
> This sounds like an FAQ. My own, untested approach in this
> case would be:
>
> public class EntrySetter <T, TSuper extends MySuperType< T >>
> { final Factory<TSuper> factory;
>
> public EntrySetter( final Factory<TSuper> factory )
> { this.factor = factory; }
>
> public void setEntry
> ( final java.lang.String key,
> final T value )
> { final TSuper old_entry = myMap.get( key );
> final TSuper entry;
> if( old_entry == null )
> { entry = factory.newInstance();
> myMap.put( key, entry ); }
> else entry = old_entry;
> entry.setValue( value ); }}


I thank you Stefan.
Don't you think, anyway, that being forced by the language to use the
awkward factory pattern is much more a workaround than an elegant solution?

Best Regards
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      10-06-2006
z-man <(E-Mail Removed)> writes:
>Don't you think, anyway, that being forced by the language to
>use the awkward factory pattern is much more a workaround than
>an elegant solution?


If classes were more like objects, they could double as
factories themselves. (As Java is now, one needs to use
reflection to do this.)

Type parameters belong to a compile-time type system,
so they can not be known at run-time.

Java also has a run-time type system, insofar as every
object knows its class, but this information is not
available at compile-time.

(However, one could imagine a special pre-processor
for Java, that implements something like C++-templates.
It should know the static type of all arguments and
then create a special instance of a class declaration
for each call with the type parameter values hardwired.
In this case, an instance creation would be possible.
Given the huge amount of such tools, there is a chance
that such a program already exists somewhere.)

 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      10-06-2006
Stefan Ram wrote:
> z-man <(E-Mail Removed)> writes:
>> Don't you think, anyway, that being forced by the language to
>> use the awkward factory pattern is much more a workaround than
>> an elegant solution?

>
> If classes were more like objects, they could double as
> factories themselves. (As Java is now, one needs to use
> reflection to do this.)
>
> Type parameters belong to a compile-time type system,
> so they can not be known at run-time.


java.lang.Class implements java.lang.reflect.GenericDeclaration, which
has method getTypeParameters.

At least some of the type parameter information is known at run-time, at
least for JVM version 3 class files.

Patricia
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      10-06-2006
Patricia Shanahan <(E-Mail Removed)> writes:
>Stefan Ram wrote:
>>Type parameters belong to a compile-time type system,
>>so they can not be known at run-time.

>java.lang.Class implements java.lang.reflect.GenericDeclaration, which
>has method getTypeParameters.


Thank you! Actually I used the wrong term and meant to say:
»Type /arguments/ can not be known at run-time.«

 
Reply With Quote
 
Karl Uppiano
Guest
Posts: n/a
 
      10-08-2006
> "hyped"
>
> Please be aware that some people in this newsgroup love Java,
> so when you use such wording you might hurt their feelings.
>
> You could have just asked your question without the
> introducing rant.


I too am a Javaphile, but I am aware of several non-optimal things in the
language and in the library API. I would say for someone to become offended
when someone points out a shortcoming, even with blunt precision, is being
overly sensitive. This preoccupation about not offending people is one of
the biggest problems of our time, IMHO.


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-08-2006
>> "hyped"
>>
>> Please be aware that some people in this newsgroup love Java,
>> so when you use such wording you might hurt their feelings.
>>
>> You could have just asked your question without the
>> introducing rant.

>

Karl Uppiano wrote:
> I too am a Javaphile, but I am aware of several non-optimal things in the
> language and in the library API. I would say for someone to become offended
> when someone points out a shortcoming, even with blunt precision, is being
> overly sensitive. This preoccupation about not offending people is one of
> the biggest problems of our time, IMHO.


Besides, offensive posts, sarcasm, haughty condescension and the like are part
of what makes newsgroups so very entertaining.

Some folks actually are helping querents with seeming derisive posts, such as
"Do your own homework" and "Google is your friend (GIYF)", even "Please do not
top-post". If one sets ego aside and follows these putatively rude dicta,
they actually end up learning much more than if coddled, or spoon-fed canned
answers.

Trolls excepted, natch.

- Lew
 
Reply With Quote
 
Thomas Weidenfeller
Guest
Posts: n/a
 
      10-09-2006
Karl Uppiano wrote:
> I too am a Javaphile, but I am aware of several non-optimal things in the
> language and in the library API. I would say for someone to become offended
> when someone points out a shortcoming, even with blunt precision, is being
> overly sensitive. This preoccupation about not offending people is one of
> the biggest problems of our time, IMHO.


It is not about becoming offended about discussing shortcomings. It is
about being sick and tired of yet another troll trying to stir up yet
another language war. Or yet another kook on a mission "to save us" and
"convert us" to some other "best of all" programming language.


/Thomas
--
The comp.lang.java.gui FAQ:
http://gd.tuwien.ac.at/faqs/faqs-hie...lang.java.gui/
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/...g/java/gui/faq
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
M$ against Blu-ray, M$ for Blu-ray, M$ against Blu-ray, M$ forBlu-ray, ...... Blig Merk DVD Video 66 04-27-2008 04:46 AM
Struggling with Wireless network. =?Utf-8?B?T0MxMQ==?= Wireless Networking 3 06-09-2005 07:15 PM
struggling at starting blocks getting workgroup recognised =?Utf-8?B?Q2Fyb2wgQg==?= Wireless Networking 2 02-13-2005 10:33 PM
Struggling With Concept One Handed Man \( OHM#\) ASP .Net 1 06-12-2004 02:07 PM
enableSessionState - still struggling Martin ASP .Net 6 12-29-2003 03:30 PM



Advertisments