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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
