It seems like it should be possible to leave generics mostly "as is"
except for having an ability to do things like:
<T> ....
{
...
T array = new T[10];
}
where the type T would be fetched from an internal runtime type holder
associated with the instance. A "raw" type would presumably either
return Object.class here or a null, producing a specific exception that
one could catch (to allow interop with older code that might pass you a
raw type).
This again wouldn't produce the ivory tower some are looking for, but it
would seem to cover a large percentage of the headaches caused by type
erasure.
On 8/31/2010 2:04 PM, Kevin Wright wrote:
If there ever was a realistic move to reify Generics then, given what
we've since learnt, wouldn't it make much more sense to first shift
Java to declaration-site variance?
I think it's fair to believe that any future polymorphic,
statically-typed language on the JVM would use this paradigm. And
reifying the alternative could well harm the JVM's potential to
compete with .NET as a flexible multi-language platform. This is a
very unlikely move, as I suspect it would impact SCOracle's bottom line.
Changing Java like this is a *big* proposition though, as it would
effectively require a breaking change in the language spec,
sacrificing backwards compatibility. Allowing both declaration-site
and call-site variance would be hideously complicated!
On 31 August 2010 19:38, Jess Holle <[email protected]
<mailto:[email protected]>> wrote:
On 8/31/2010 1:15 PM, Russel Winder wrote:
I guess the questions are not so much can you survive with
type erasure
on the JVM but are:
1. Did the CLR gain by supporting run time type parameters for
generics?
They gained 2 disparate collections libraries for starters. Given
the plethora of Java libraries using collections, splitting the
Java universe that using old collections and that using new
collections seems like a much bigger issue than doing this to the
younger, smaller .Net library space.
2. Why were the annotations people allowed to amend the JVM
when the
generics people were not?
Annotations didn't break anything. The straightforward
reification approach used by .Net of 2 having different,
non-interoperable versions of APIs would have split the Java
technology space -- a "break" in my book at least. A reification
approach that would allow seamless interoperation between old and
new libraries (i.e. with 1 collection library where any collection
can be passed to both old and new libraries) but provide runtime
knowledge of generic type parameters is a much taller order -- and
it's easy to see how this was beyond the scope of Java 5. Anyone
who comes up with such an approach could ostensibly still add it
to Java N, though.
--
Jess Holle
--
You received this message because you are subscribed to the Google
Groups "The Java Posse" group.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:javaposse%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
--
Kevin Wright
mail/google talk: [email protected]
<mailto:[email protected]>
wave: [email protected] <mailto:[email protected]>
skype: kev.lee.wright
twitter: @thecoda
--
You received this message because you are subscribed to the Google
Groups "The Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
