Primitives in Generics

[Reinier Zwitserloot]

Doesn't the OP of this thread show a way forward to get to (B) given SotL is
implemented for java7? Nothing in SotL so far seems to clash with my
proposal.

However, omitting primitives-in-generics for java7 would mean the flurry of
development that'll ensue to take advantage of lambdas may result in a
number of specialization SAMs (IntComparator would for example be a
specialization of Comparator<Integer>), which will then have to be supported
in perpetuity when java8 deprecates all of them by offering direct support
of either primitives in generics or specialization. Case in point: Given
that PA was the driving use case for Project Lambda, one would imagine that
if SotL goes ahead, PA will be added to the core runtime libraries of java7.
Presumably with the full 132 SAMs of PA.Ops. Those would then have to remain
there forever.

I can imagine worse things; they are small interfaces that can easily be
corralled into a module. Nevertheless, a point worth thinking about, because
I doubt PA.Ops will be the only library that ends up shipping with
specialization SAMs. If in the end we're stuck with some 1000-odd
specialization SAM types amongst commonly used java libraries, that's a
sizable price to pay now for omitting the feature.

NB: Other than arrays-of-parameterized-types I've yet to hear of a
fundamental problem with my proposal. Arrays remain popular in large part
_because_ primitives in generics doesn't work, so while
arrays-of-paramerized-types is never going to work particularly well in my
proposal when the parameterized type is a primitive, on the plus side it'll
reduce the number of times folks are messing with T[] in the first place.

 --Reinier Zwitserloot



On Sat, Jul 10, 2010 at 8:34 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 07/09/10 15:38, Brian Goetz wrote:
>
> >> My take is that you have three choices:
> >> A) Support function types covering primitives
> >> B) Support primitives in generics
> >> C) Do something that doesn't restrict your options to reconsider
> >> (A) or (B) in Java8 in response to all the complaints about
> >> sucky parallel performance.
> >
> > Indeed so. We believe we have chosen (C). If we have not, please say
> something!
> >
>
> On only a little thought, I don't know the answer. If someone could
> provide a rough sketch for how either of these (presumably only (B)?)
> could be done in Java8 given the Java7 plans, it would be a big comfort.
>
> For one example of a generics system that accommodates both A and B
> see the X10 specs:
> http://dist.codehaus.org/x10/documentation/languagespec/x10-latest.pdf
> Scala also comes close with upcoming "specialize" directives. See
>
> http://www.scala-lang.org/sites/default/files/sids/dragos/Mon,%202009-11-16,%2017:34/sid-spec.pdf
> or maybe some more recent docs?
> (Also, to some extent, C#.)
>
> I worry a bit because (1) the base generic type systems for
> both are fairly different than Javas and (2) both implementations
> are still in pre-release mode running on JVMs.
>
> -Doug
>
>
>
>