On Tue, 2010-08-31 at 09:35 -0700, Cédric Beust ♔ wrote: > Hi Russel, > > On Tue, Aug 31, 2010 at 7:51 AM, Russel Winder <[email protected]> > wrote: > Perhaps the JVM could then support type parameters and the > abomination > that is type erasure could be dispensed with. > > I'm surprised by the intensity of your statement, it's quite unusual > coming from you :-)
:-)
Given half an hour and a whiteboard, I think I could explain, let's see
if I can explain quickly in a short email . . .
Point 1 is exemplified by having API entries such as toArray in
ArrayList:
public <T> T[] toArray(T[] a)
This means I have to supply a parameter that is redundant to my code and
algorithm because the compiler is incapable of deducing or inferring the
correct types -- because of type erasure.
This is indicative of a bigger problem. Java has two type systems, the
compile time type system and the run time type system. This is not
necessarily a problem per se, but when the compiler insists on imposing
compile time type structuring in a run time type context then it all
gets vexatious.
If there is to be a separation of compile time and run time type systems
then the compiler should actively support only using raw types in a run
time context. Enforcing compile time types in a run time context is at
best a lie and at worst completely misleading.
> In a regular Java code base, I would say that the amount of reflection
> is very low, probably 5% or less (already a generous number in my
> opinion, since most of it is probably because of annotations).
OK, in a pure Java, "all I am doing is wiring one framework to another"
context, type erasure may not even be noticed. I guess I end up working
95% of the time in the 5% are.
Also, of course, most of my JVM-based activity is associated with GPars
which is a mixed Java/Groovy code base, and this is really where this
get not just vexatious, but positively painful
> Out of these 5%, how much really needs access to erased type
> information? That number is probably vanishingly small.
I am still trying to get my ADS library in a fit state to use again, as
this is all about containers, I am squarely in that n%.
> And the thing is: if you really need this information, you can have it
> to some extent with
> * getGenericType
> * Or even better, the very clever TypeLiteral.
I guess I need to investigate these again.
> Overall, I think erasure has worked very well in practice, so I'm
> curious to hear why you think it's such a disaster?
Point N is that Eclipse really annoys in trying to be helpful, it
generates warning messages and then when you select one of its actions,
the warnings turn into obscure errors, compilation ceases to work and so
you revert. It seems impossible to have codebases that are warning
free. I guess I am just an Emacs addict.
Point N + 1 is really a Groovy problem (and I apologies to Andrew and
the GrEclipse crew but . . ). In order to get consistent Java and
Groovy incremental compilation, they have amended the JDT Java compiler
to handle Groovy. This means Eclipse is imposing the requirement of
type parameters on a dynamic language. Groovy works with type checking
at run time i.e. erased types so it makes sense to only use raw types
and to avoid all type parameters. Eclipse fails to allow me to do this.
This is just a glimpse into the issues, but hopefully it answers your
question.
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?
2. Why were the annotations people allowed to amend the JVM when the
generics people were not?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected]
41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected]
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
