Will Pugh wrote:
I'm not sure we're optimizing for the right thing by changing the
package names and creating parralel forks for Generic Collections.
Generics have done a pretty good job of dealing with backwards
compatibility. It feels like we will make the upgrade path for the vast
majority of people more difficult for the advantage of a pretty small
few. What specific BackCompat issues are you expecting? When I hear
"Generifying Collections", I keep thinking you will keep the APIs the
same, but you will simply add generic support to them. Am I off?
I've obviously not been clear enough.
It is, in *theory*, possible for us to covert the existing [collections]
component to generics without changing any APIs or breaking backwards
compatability. Call this option 'porting' the API to JDK5.
However, I already know of at least one case (MultiMap) where this isn't
possible due to generics clashes in the implentation. Thus producing a
binary compatible JDK5 port will simply not be possible in some cases.
And doing so in other cases will compromise the quality of the generic
API. Plus, there are other cases, such as the Typed* classes or the
Fast* classes where porting them to JDK5 seems pretty pointless.
What I am proposing is that we use this opportunity to not just do a
straight 'port' to JDK5, but to re-evaluate the library. To go through
each collection and consider if it should be ported and how best that
should occur. Call this option 'refactoring' the API to JDK5 and all the
new idioms. The aim would be to keep the general shape of the library
and be about 90% compatible, but to agree that breaking some API methods
without deprecation is acceptable.
This is a less simple task for us, and a less simple task for upgraders
(its not just a package rename), but the end result is an heck of a lot
better quality component.
Your opinion of 'port' vs 'refactor' will depend in some measure on how
important you view JDK5. Having just got into using it, I view it as a
really serious change in the language, and one that IMHO should cause
all API writers to refactor their code and not just port.
And, because the JDK was forced to port and not refactor, that is IMHO
one reason why generics can prove to be a horrible mess in places in the
JDK.
(Note that the whole package name/number business is really a
manifestation of this underlying decision)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
