Boxing function types

[Doug Lea]

Neal Gafter wrote:
> The value of supporting the assignment conversions in the function 
> subtype relation is that it enables one to generalize generics over 
> primitive types.  That can be optimized automatically by code 
> specialization, which eliminates the boxing and unboxing at runtime.

It would be great if people worked on turning
that "can be" into the combination of source-level
compiler support, bytecode tools, class-loading
facilities and JIT support that could perform
specialization well enough for people to rely on.
The Scala folks have done some of this for scalars
using @specialized (upcoming for Scala 2.8), and
X10 generics etc have been defined to
support it for scalars and structs (see
http://dist.codehaus.org/x10/documentation/languagespec/x10-200.pdf).
And similarly but less so in C#.

My main point is that there is a cluster
of language features and underlying support
for multicore-friendly parallel programming that
you need to consider as a group, even if they are
not all introduced as a group in a particular
Java release. Including lambda-like closures,
function types, embeddable structs/values/tuples,
improved arrays (especially 2d dense), revising
JLS exception rules to better deal with async
failures, and possibly further extensions for
non-shared-memory parallelism. All of these
correspond to likely directions for evolving
improved platform-level support, leveraging the
natural advantages of JVMs over other platforms
(dynamic compilation, high-performance GC, etc)
when it comes to supporting parallelism.

Digressing further: The situation for fine-grained
parallelism right now is not too different than
it was for coarser-grained concurrency in 1995:
There was a big gap between language features
(threads+synchronized+wait/notify) and what most
people building concurrent middleware etc wanted to
do. We reduced that gap in JDK5 java.util.concurrent,
but that was a bit easier since it didn't interact
much with language features. Some days I think the
Java language evolution story is just too hard,
and that it would be more profitable to focus
on developing other JVM-hosted languages like X10 that
have worked out a more coherent story about it.
But every now and again people surprise me by
suggesting that we give a serious shot at
incremental Java language changes that might
get us closer to these goals.  I'm all for
trying this. But...

> 
> But as I said, we may have already designed ourselves out of this option.

And as I said, let's not do this again by ignoring
the nearly-inevitable follow-ons.

-Doug