commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math] abstact nonsense was Re: [math][functor] More Design Concerns
Date Thu, 03 Jul 2003 17:20:52 GMT
Craig R. McClanahan wrote:

>>According to the JSR:
>>== begin quote ==
>>It is explicitly not required that the system
>>b) Support the use of primitive types as type arguments: While
>>allowing the use of primitive types (e.g., int, boolean) as type
>>arguments would be nice, it should not be a goal of the design. The
>>separation of primitive and reference types is a fundamental property
>>of the Java programming language.
>>== end quote ==
>>So, it appears generics are no panacea.  At least not in the Java
>There is a separate proposal related to auto-boxing and unboxing of
>classes like java.lang.Integer that will deal with some of the leftover
>pain.  If I read the examples correctly, it will mean that things like
>"int" and "java.lang.Integer" will be essentially interchangeable at the
>source code level.  This was discussed in the technical keynote at
>JavaOne, and seems quite likely to be part of Tiger (J2SE 1.5) also.
>To unsubscribe, e-mail:
>For additional commands, e-mail:
It does seem that the spec defines a fully backward compatible 
implementation such that pre 1.5 packages will still function in the 1.5 
environment. Ideally we should develop [math] to provide implementations 
efficient on both pre 1.5 and 1.5. Its probably easier to battle over 
design now for pre-1.5 than wait around for the final implementation of 
Generics to go fully in that direction.


There is a prototype compiler available on the Sun EA site for 
1.5/generics. It would make for some interesting sandbox projects to 
begin exploring alternate implementations of various commons projects 
for this compiler as a stepping stone for taking advantage of the 
capabilities that will be available in 1.5. Possibly someone could draw 
together demos/examples of such usage so that Jakarta projects can take 
advantage of such information to build "roadmaps" to 1.5 capabilities in 
the near future. Doing this now before the 1.5 release would place 
Jakarta at a significant advantage to leverage these capabilities and 
provide new implementations in a "timely" manner that corresponds to 
the  release of 1.5 to the public.


Mark Diggory
Software Developer
Harvard MIT Data Center

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message