Generics: struggling against type erasure...

[z-man]

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);
}

 

[Stefan Ram]

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 ); }}

 

[z-man]

"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

"wizard who can ..."


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

 

[Stefan Ram]

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.)

 

[Patricia Shanahan]

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

 

[Stefan Ram]

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.«

 

[Karl Uppiano]

"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.

 

[Lew]

"hyped"

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

 

[Thomas Weidenfeller]

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