The plan is for non backwards compatibility, as there are too many
things that don't make sense for generics, and some things that plain
don't work. The Map coercion methods become silly, and TransformedMap
can't conform to the map interface in it's current form (is that the
right one?).
Having said that, I am planning (in my zero time - probably until
christmas :( ), to have a "1.4 upgrade" generics collections that has
minimal changes (where necessary) and will provide a general drop in
replacement. The main release will be a clean generics release without
deprecation, for those wanting to get started afresh. BTW, absolutely
none of the trunk's deprecated API will make it anywhere into the
generics project (it's gone already...). [You're using it to make a
jump, so *you're going to* make the jump].
So, there will be minimal binary changes, but you will likely have to
recompile (some CollectionUtils void methods will now return something
useful).
Some classes will need revamping, and potentially entirely renamed to
ensure that there is no conflict with different prior behaviour - I
haven't really looked at the maps.
NB!!! Don't submit patches for CollectionUtils --- I have it 90%
complete, and will find time to do the other 10% if people want to see
it (are people actually using the generics branch? I am, but then I know
it's as good as my own code :)
I don't think it will be too difficult to strip out deprecated methods
at build time, but will probably take a bit of time to get right.
Yeah, maybe I will try and find some more time... but generally, I work
on it as I need it's [generic] features.
+1 Wiki page, and for someone to summarise the mailing list. I believe
this message contains the major consensus from the previous discussions
(actually, having a minimal 1.4 upgrade-deprecated jar is my idea -
simply because it'll be easier to do a double [remove
deprecation->upgrade] jump than to do it all in one)
Cheers
Stephen
Requests for clarification welcome.
James Carman wrote:
Maybe we should set up a wiki page to discuss this 1.5 problem for
collections (and maybe other projects). We should outline why we have
been reluctant as of yet to "genericize" collections (binary
compatibility, serialization issues, etc.). That way folks don't have
to try to search through the archives or try to remember (I'm having a
hard time remembering the whole conversation) all the details.
On 10/25/07, Brian A. Egge <[EMAIL PROTECTED]> wrote:
Hi,
What's the status of the JDK 1.5 branch? It seems the developers are split as
to if it's a good thing, and if so, if the API should be different or the same.
Most advice I see says to use the collections15 project on SourceForge.
What I would like, is a drop in replacement, with binary backwards
compatibility with the 1.4 version. I want everything in the same package
name, and to have the same names. If there are some additional methods, then
that would be ok. Basically, I found upgrading the JDK collections has been
rather painless. My 1.4 projects work fine in 1.5, and if I want to change my
code to use generics I can. Eclipse even will help me out with this. Because
Java decided to use type erasure, it's possible to have a library with
generics, that works identically to one without.
I ran clirr against the 1.5 branch, comparing it to the 3.3 snapshot in the
trunk. It reported 93 differences. I'm happy to spend some time creating
patches for this project, if there are other people (read committers) who have
the time to review and apply the patches, and also share my vision of a
compatible library.
Commons Collections is one of the most popular components within the Commons
project, and the main use of generics is within container classes, so I think
it would be a real benefit to get this project up to date.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
------------------------------------------------------------------------
* <http://www.orionhealth.com>*
*Stephen Kestle Software Engineer*
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
P: +64 9 638 0619
M: +64 27 453 7853
F: +64 9 638 0699
S: skestle <callto:skestle>
www.orionhealth.com <http://www.orionhealth.com>
This e-mail and any attachments are intended only for the person to whom
it is addressed and may contain privileged, proprietary, or other data
protected from disclosure under applicable law. If you are not the
addressee or the person responsible for delivering this to the addressee
you are hereby notified that reading, copying or distributing this
transmission is prohibited. If you have received this e-mail in error,
please telephone us immediately and remove all copies of it from your
system. Thank you for your co-operation.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
