commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pugh <willp...@sourcelabs.com>
Subject Re: [collections] Generifying Collections
Date Wed, 25 Oct 2006 17:22:35 GMT
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?

Example:
If you generi-size

--------
 public class TestClass {
    public Object Get(Object t) {
        return t;
    }
}
--------
to be
--------
public class TestClass<T> {
   
    public T Get(T t) {
        return t;
    }

}
--------

It is still valid to either use the generics or not, e.g.  both of these 
still work.

--------
TestClass<Tester>   test1 = new TestClass<Tester>();
TestClass           test2 = new TestClass();

tester = test1.Get(tester);
tester = (Tester) test2.Get(tester);
--------

Therefore, simply upgrading the library should not cause you backwards 
compat problems, unless there is something I'm missing.  However, you 
will make it much harder for people to simply upgrade to the new release.

    Thanks,
    --Will


Stephen Colebourne wrote:
> Stephen Colebourne wrote:
>   
>>> Because commons isn't like other OSS projects. We can't go around
>>> changing our APIs freely, even between major versions. Its a simple case
>>> of us being at the bottom of the stack of jars. If we do change an API,
>>> any API then jar hell ensues because higher OSS projects will clash on
>>> their required versions of [collections].
>>>       
> Henri wrote:
>   
>> I'm not convinced by that. What you're saying is that if we want to
>> have a major API change in a component, that we need to change the
>> package name so two pieces of code can sit side by side. If that's
>> true, then we should do it for all major versions (as major API change
>> is the defining factor of major version changing) and stay within the
>> same component.
>> Having a bit of deja vu - think we had this discussion 6 months ago
>>     
>
> Actually it was over [net], and recently. And yes, its not nice, but a different package
name is all that we get given by Java at present. However, there are cases where a major version
change can be done without breaking backwards compatability - typically, where the only change
is to remove deprecations ([lang] 3?).
>
> We could just say that its the responsibility of everyone using commons to repackage
our code into their package structure, but IMHO thats just not practical, and quite wasteful.
>
>   
>> Basically - we need to start putting the major version in our package
>> names. I hate that, but I can see the need.
>>     
> Yep, it sucks. Yep, its essential.
>
>   
>> So this would be a branch of collections, with a package name
>> change to org.apache.commons.collections4.*.
>>     
> Well, the number is dependent on the strategy we are trying to achieve:
>
> a) using '4' would indicate that every major version will have a new package name, but
then you can't use a major version to just remove deprections (a compatible major version
change)
>
> b) using '5' would indicate the technology reason for the version. The package would
be commons-collections5-1.0.
>
> c) using '5' as the commons name - commons5-collections-1.0
>
> I favour (b) as I view this as a fork of [collections] for a new technology. I believe
the language changes in JDK5 are significant enough to warrant a fork.
>
>   
>> Would be sweet to have a build system that could deal with moving
>> source from org/apache/commons/collections/ to the correct directory
>> and package name prior to compiing/source-packaging. Might be worth
>> playing with some Ant scripts for that.
>>     
> Not sure how that helps. The new JDK5 code will probably be a proper fork, with some
significant method name/class changes.
>
> Stephen
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message