RE: [collections] Generifying Collections
Torsten Curdt wrote on Thursday, October 26, 2006 11:20 PM: I still think that's a better world than package name changing every time we want to make a non-backwards compatible change. Frankly speaking - I don't really say a way around this if you want to save people from dependency hell. +1 ... and we're already there in our projects. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Generifying Collections
Hi Niall, Niall Pemberton wrote on Thursday, October 26, 2006 3:18 AM: [spip] Beyond this, there are some classes (like TypedList that we don't even want to port as they'd be pointless), plus my desire to create a smaller jar file (time depending), there is ample reason to not worry excessively about backwards compatability. We shoud target about 90% backwards compatible, with the rest being fixing API flaws and issues we have now. Don't you mean 0% backwards compatability - which is what changing the package name results in? A simple port may appeal conceptually, but its not really viable at all. I would disagree - if it really is the case that 90% could be ported with backwards compatibility, then it would seem viable IMO. This is true for an application, but not for a library that is used wide-spread. I know a lot of commercial packages depending on some commons jars. See if my app is using a package of vendor a that depends on collections-2.0 and vendor B that depedns on collections-4.0. Now I cannot build/run my app anymore, since either package of vendor A fails or the one of vendor B. And don't call this hypothetic, we already have such a situation in real life altzough the lib versions are 95% binary compatible - it was unfortunately not enough. Therefore the whole discussion is not really about introducing generics, but of handling incompatibilities between major version changes. And if we cannot get the compatibility right anyway, we can also make the next step and refactor/clean-up API between major versions much better along with increasing the version dependecy on the JDK. This way a user might have to search and replace the package name in *his* library, but then he might be able to compile in 90% of the time and has a 100% certainty, that he does not break another app/library his artifact must coexist with. Having said that, its not me thats going to be doing the work, but it does seem valuable to discuss port vs. refactor rather than refactor being a defacto decission and just having an argument on package names. It is somewhat a general decision for commons. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
I believe that our users will find 5 == JDK5 to be an easier concept to grasp. +1 cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/25/06, James Carman [EMAIL PROTECTED] wrote: For someone who uses Commons Collections a lot in their applications, this is going to be quite a pain if I want to upgrade. Yes, I realize that there's such a thing as find and replace, but the fact that I have to do that if I want to upgrade is just a bother. That's my $0.02. Well, easy ...then you don't upgrade ;) Sorry, but the fact that an upgrade is not always is as easy as replacing a jar is not an argument (IMO) As long as there is an upgrade path it's up to the user to walk that path or not. The important thing though is to have such a path. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
One reason that I proposed (c) is simply that when you say collections5 or collections2 aloud it sounds like you're talking about a version of Collections, whereas if you say commons5-collections it's more suggestive of a fork, which is what we're really trying to get at. ...is it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/26/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 10/25/06, Niall Pemberton [EMAIL PROTECTED] wrote: snip/ Having said that, its not me thats going to be doing the work, but it does seem valuable to discuss port vs. refactor rather than refactor being a defacto decission and just having an argument on package names. snap/ :-) Its not going to be me either, which is why I have (more or less) retired from the conversation. You're right that this isn't about package names, but really whether the intent is to produce a backwards compatible generified collections: * If so, be encumbered with whatever that entails * If not, acknowledge with new collections package It appears to me that the latter might bring more joy to the development of the new collections and result in elegance and entirety of the transformation, but for the reason I mentioned a couple of paragraphs ago, my opinion is not as important as some others. +1 - the final decision is down to whoever is going to work on it and if they want to take the opportunity to refactor, then better to do that and see progress rather than try and impose something which would probably mean nothing happens. Still, I think its worth debating/considering since IMO even if the decision stays the same, its a better decision for having been fully discussed. -Rahul P.S.- Regarding your Collections#max question, using casts like you suggest compromises the upper bound of T in the signature, and doesn't convey the correct information to the reader (and arguably more importantly, to the compiler, which consequently cannot guarantee the author-intended type safety, at which point the value proposition of using generics diminishes greatly) Thx. I guess I've only seen the benefits of generics as saving a cast and making the code more readable - since type safety hasn't ever really caused me problems. Probably I need to make this mindset shift for java5. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/26/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Niall, Niall Pemberton wrote on Thursday, October 26, 2006 3:18 AM: [spip] Beyond this, there are some classes (like TypedList that we don't even want to port as they'd be pointless), plus my desire to create a smaller jar file (time depending), there is ample reason to not worry excessively about backwards compatability. We shoud target about 90% backwards compatible, with the rest being fixing API flaws and issues we have now. Don't you mean 0% backwards compatability - which is what changing the package name results in? A simple port may appeal conceptually, but its not really viable at all. I would disagree - if it really is the case that 90% could be ported with backwards compatibility, then it would seem viable IMO. This is true for an application, but not for a library that is used wide-spread. I know a lot of commercial packages depending on some commons jars. See if my app is using a package of vendor a that depends on collections-2.0 and vendor B that depedns on collections-4.0. Now I cannot build/run my app anymore, since either package of vendor A fails or the one of vendor B. And don't call this hypothetic, we already have such a situation in real life altzough the lib versions are 95% binary compatible - it was unfortunately not enough. I think you mis-understand me - I get the issues with backwards compatibility in libraries (I was around last time Collections caused problems!). I was suggesting porting the 90% and doing something else with the rest that couldn't be ported with backwards compatibility (e.g. deprecate MutliMap and create generified MultiMap2) - with the result being 100% backwards compatibility. Niall Therefore the whole discussion is not really about introducing generics, but of handling incompatibilities between major version changes. And if we cannot get the compatibility right anyway, we can also make the next step and refactor/clean-up API between major versions much better along with increasing the version dependecy on the JDK. This way a user might have to search and replace the package name in *his* library, but then he might be able to compile in 90% of the time and has a 100% certainty, that he does not break another app/library his artifact must coexist with. Having said that, its not me thats going to be doing the work, but it does seem valuable to discuss port vs. refactor rather than refactor being a defacto decission and just having an argument on package names. It is somewhat a general decision for commons. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/25/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 10/25/06, Niall Pemberton [EMAIL PROTECTED] wrote: snip/ Having said that, its not me thats going to be doing the work, but it does seem valuable to discuss port vs. refactor rather than refactor being a defacto decission and just having an argument on package names. snap/ :-) Its not going to be me either, which is why I have (more or less) retired from the conversation. You're right that this isn't about package names, but really whether the intent is to produce a backwards compatible generified collections: There are two conversations overlapping each other :) One is collections specific. What to actually do for the next major version of collections/separate version of collections-generics. The other is commons specific. When we make non-backwards compatible API changes outside of the 0.x-1.0 dev cycle, do we let the user deal with the random pain of transitive dependencies mismatching at runtime after recompiling, or do we force them to deal with the non-random pain of having to change their package names before recompiling. This only really applies to recompiling - anyone who drops a major version change in at runtime doesn't deserve any kind of support. If you're pulling in a major version change, then it's also definitely your responsibility to check your transitive dependencies. I don't think we should be renaming packages to make that easier for people. The only bit that makes the package rename tempting is that in many cases the transitive is going to be more than just your development group and commons, there will be other open source (well any external) projects in between. So people will be held up from using those other projects until they move. I've mulled it for a bit, and I don't think that it's worth it for us to try and change package names to make it easier for people not to be held up by other entities. If we do that then there will be less pressure for those projects to upgrade, and we'll just be causing lots of pain for the many to save pain for a much smaller group. Admittedly the many get their pain at compile time while the smaller group wouldn't have found their pain until runtime if they don't have good build practices. Tomcat's not a good example btw - people rarely depend on Tomcat jars, they don't put the major version in the package name (or any kind of number) and there was lots of confusion when Tomcat 5 and 5.5 were out. So I'm -1 to the package stuff - just not convinced by the argument so far. I do hope that we can get the generics stuff moving without the package name bit being an issue until we release. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Henri Yandell wrote: I've mulled it for a bit, and I don't think that it's worth it for us to try and change package names to make it easier for people not to be held up by other entities. If we do that then there will be less pressure for those projects to upgrade, and we'll just be causing lots of pain for the many to save pain for a much smaller group. Admittedly the many get their pain at compile time while the smaller group wouldn't have found their pain until runtime if they don't have good build practices. That's quite a hard line to take. A great many projects depend upon older versions of the commons jars, and getting the development group for a third-party jar that you depend upon to upgrade their dependencies can be a process that takes way too long for many development environments. Hell, this is a problem even within commons - I have an application that depends on Digester 1.7, which in turn depends upon Collections 2.1 while my code needs features from Collections 3.2, and the only reason it works is because 3.2 is backwards compatible for the features that Digester is using. Realistically, users only have so much leverage on projects to get them to upgrade, and development teams only have so much time to cut new releases. Are we going to start doing point releases for our own projects for dependency version upgrades whenever someone requests it? So I'm -1 to the package stuff - just not convinced by the argument so far. I do hope that we can get the generics stuff moving without the package name bit being an issue until we release. I'm definitely +1 to getting moving, so would folks agree to at least create a branch from the head of collections where the development can get started? We can always move stuff around in SVN as needed at a later date. Kris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Torsten Curdt wrote: On 10/25/06, James Carman [EMAIL PROTECTED] wrote: For someone who uses Commons Collections a lot in their applications, this is going to be quite a pain if I want to upgrade. Yes, I realize that there's such a thing as find and replace, but the fact that I have to do that if I want to upgrade is just a bother. That's my $0.02. Well, easy ...then you don't upgrade ;) Sorry, but the fact that an upgrade is not always is as easy as replacing a jar is not an argument (IMO) As long as there is an upgrade path it's up to the user to walk that path or not. The important thing though is to have such a path. This seems like a strange argument, since the Don't Upgrade path is valid for people who are running into conflicts from API changes as well (and there are probably a lot more people that won't run into these problems if the removals are mostly focused on deprecated components.) I understand that sometimes conflicts can be a bit round about, they upgrade to (or add) a new component of Y and it causes their commons-collections to get upgraded. They still have the choice of not making this upgrade, or using that other component. Or they have the choice of using JarJar or some other tool force package changes. Or helping to fix the dependency if they are using some open source project. I think we want to make the common case as easy as possible, and changing the package names makes the common case a pain in the butt. I would suggest this means staying as close to backwards compatible as possible, with the removal of only things that have been deprecated. cheers -- Torsten - 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]
Re: [collections] Generifying Collections
Kris Nuttycombe wrote: Henri Yandell wrote: I've mulled it for a bit, and I don't think that it's worth it for us to try and change package names to make it easier for people not to be held up by other entities. If we do that then there will be less pressure for those projects to upgrade, and we'll just be causing lots of pain for the many to save pain for a much smaller group. Admittedly the many get their pain at compile time while the smaller group wouldn't have found their pain until runtime if they don't have good build practices. That's quite a hard line to take. A great many projects depend upon older versions of the commons jars, and getting the development group for a third-party jar that you depend upon to upgrade their dependencies can be a process that takes way too long for many development environments. Hell, this is a problem even within commons - I have an application that depends on Digester 1.7, which in turn depends upon Collections 2.1 while my code needs features from Collections 3.2, and the only reason it works is because 3.2 is backwards compatible for the features that Digester is using. I was just about to take the same example. Digester 1.7 also depends on older beanutils 1.6.1 or ancient JCL 1.0(.0) Realistically, users only have so much leverage on projects to get them to upgrade, and development teams only have so much time to cut new releases. Are we going to start doing point releases for our own projects for dependency version upgrades whenever someone requests it? Exaclty. And big commercial venders are even worse. If you do not use exactly their delivered dependency, you can lose the maintenance because you have an undefined environment. So I'm -1 to the package stuff - just not convinced by the argument so far. I do hope that we can get the generics stuff moving without the package name bit being an issue until we release. I'm definitely +1 to getting moving, so would folks agree to at least create a branch from the head of collections where the development can get started? We can always move stuff around in SVN as needed at a later date. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/26/06, Henri Yandell [EMAIL PROTECTED] wrote: I've mulled it for a bit, and I don't think that it's worth it for us to try and change package names to make it easier for people not to be held up by other entities. If we do that then there will be less pressure for those projects to upgrade, and we'll just be causing lots of pain for the many to save pain for a much smaller group. Admittedly the many get their pain at compile time while the smaller group wouldn't have found their pain until runtime if they don't have good build practices. I can support either way but if I'm going to support breaking backwards compatibility I think we should release minor releases of all components that are broken by this change, even if they aren't the latest major release. My personal preference is to let a few people who care about refactoring collections perform some major surgery into a new package name and produce something leaner, meaner and hopefully easier and more robust to use. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/26/06, Jörg Schaible [EMAIL PROTECTED] wrote: Kris Nuttycombe wrote: Henri Yandell wrote: I've mulled it for a bit, and I don't think that it's worth it for us to try and change package names to make it easier for people not to be held up by other entities. If we do that then there will be less pressure for those projects to upgrade, and we'll just be causing lots of pain for the many to save pain for a much smaller group. Admittedly the many get their pain at compile time while the smaller group wouldn't have found their pain until runtime if they don't have good build practices. That's quite a hard line to take. A great many projects depend upon older versions of the commons jars, and getting the development group for a third-party jar that you depend upon to upgrade their dependencies can be a process that takes way too long for many development environments. Hell, this is a problem even within commons - I have an application that depends on Digester 1.7, which in turn depends upon Collections 2.1 while my code needs features from Collections 3.2, and the only reason it works is because 3.2 is backwards compatible for the features that Digester is using. I was just about to take the same example. Digester 1.7 also depends on older beanutils 1.6.1 or ancient JCL 1.0(.0) Then the options are: 1) don't upgrade 2) yell at middle project to do a new release (ie: Digester in this case) 3) yell at us to do a backport release (ie: you need specific bugfixes on the collections 2.x branch and not the 3.x one). 4) do it yourself and depend on an internal fork (of either 2 or 3). 5) risk that the library is backwards compatible for the necessary features (by testing lots and hoping). I still think that's a better world than package name changing every time we want to make a non-backwards compatible change. Realistically, users only have so much leverage on projects to get them to upgrade, and development teams only have so much time to cut new releases. Are we going to start doing point releases for our own projects for dependency version upgrades whenever someone requests it? Exaclty. And big commercial venders are even worse. If you do not use exactly their delivered dependency, you can lose the maintenance because you have an undefined environment. Doesn't that mean you'd be kept off of Collections 4.x too? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Kris Nuttycombe wrote: I'm definitely +1 to getting moving, so would folks agree to at least create a branch from the head of collections where the development can get started? We can always move stuff around in SVN as needed at a later date. I'm happy for you to start work now. I don't see that we need to hold you up :-) You need to 'tag' the current collections trunk, then branch it. For the moment, the JDK5 branch can go in commons-proper rather than the sandbox. [collections] trunk needs to stay as the 3.3 / JDK1.2 line for now. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Okay, fine with me. Do I need to request any special write access for SVN, or should I be okay? Thus far all I've done is work in the sandbox. Kris Stephen Colebourne wrote: Kris Nuttycombe wrote: I'm definitely +1 to getting moving, so would folks agree to at least create a branch from the head of collections where the development can get started? We can always move stuff around in SVN as needed at a later date. I'm happy for you to start work now. I don't see that we need to hold you up :-) You need to 'tag' the current collections trunk, then branch it. For the moment, the JDK5 branch can go in commons-proper rather than the sandbox. [collections] trunk needs to stay as the 3.3 / JDK1.2 line for now. 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]
Re: [collections] Generifying Collections
Kris Nuttycombe wrote: Okay, fine with me. Do I need to request any special write access for SVN, or should I be okay? Thus far all I've done is work in the sandbox. Depends on what the vote was when you joined. If there was no vote, and you just got sandbox access because you were already in ASF then we need to vote on you ;-) If you got voted on, then you should have commit rights. You could try making a small commit (add or remove a space to a file) and see if it works. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Yep, I was voted on and tested out adding a blank line to a file and it appears I'm set to go. Thanks! Kris Stephen Colebourne wrote: Kris Nuttycombe wrote: Okay, fine with me. Do I need to request any special write access for SVN, or should I be okay? Thus far all I've done is work in the sandbox. Depends on what the vote was when you joined. If there was no vote, and you just got sandbox access because you were already in ASF then we need to vote on you ;-) If you got voted on, then you should have commit rights. You could try making a small commit (add or remove a space to a file) and see if it works. 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]
Re: [collections] Generifying Collections
Well, easy ...then you don't upgrade ;) Sorry, but the fact that an upgrade is not always is as easy as replacing a jar is not an argument (IMO) As long as there is an upgrade path it's up to the user to walk that path or not. The important thing though is to have such a path. This seems like a strange argument, since the Don't Upgrade path is valid for people who are running into conflicts from API changes as well (and there are probably a lot more people that won't run into these problems if the removals are mostly focused on deprecated components.) Sorry, not sure I get what you are saying If it's just your decision to upgrade a library you should not be moaning about work. We are talking about a major API change! Don't expect that to be done with a jar replacement. If you have to upgrade because another library is depending on another version that's another story ...and then comes the question whether that's easy or not. I understand that sometimes conflicts can be a bit round about, they upgrade to (or add) a new component of Y and it causes their commons-collections to get upgraded. They still have the choice of not making this upgrade, or using that other component. Or they have the choice of using JarJar or some other tool force package changes. Or helping to fix the dependency if they are using some open source project. I think we want to make the common case as easy as possible, and changing the package names makes the common case a pain in the butt. Your project depends on A and B. A depends on the old-style collections while B already made the move and uses the new collections. Now what? As it is an incompatible change the only thing is trying to push A to upgrade its dependency. (or jarjar magic) THAT is what I call a PITA. While otherwise they would be happily living next to each other and everyone is happy. For sure we could provide some scripts or even eclipse refactoring scripts if necessary/possible. Most likely you will only need to remove all imports and ask eclipse to organize imports on your code base anyway. To me that sounds easier than trying to squeeze (let's face it) a new API into the same package. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
I still think that's a better world than package name changing every time we want to make a non-backwards compatible change. Frankly speaking - I don't really say a way around this if you want to save people from dependency hell. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Generifying Collections
Hi Kris, Kris Nuttycombe wrote on Tuesday, October 24, 2006 5:10 PM: (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c (http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg One possibility that occurs to me is that we could take the problem to a higher level. Since a number of projects are going to be facing this problem, what about a package rename at the commons level - say, org.apache.commons2 or org.apache.commons5? This way, the Maven problem and the package rename problems can be solved, and yet we can still keep the individual brand names untainted. This can also scale with new JDK releases - you would end up with a commons for each release where you have a binary incompatible break, but this seems less obnoxious to me than having each project have to keep up with a component-level naming scheme. well, I don't think this is necessary for complete commons, but we may consider doing so for major releases of the individual componnets. Collections might have org.apache.commons.collections4 for the next major version ... and so it would not interfere with older versions, have individual groiupIds (concerning Maven) and the artifacts can coexist, the version scheme is not dependent on the JDK and the minimal JDK requirement can be changed easily. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
For someone who uses Commons Collections a lot in their applications, this is going to be quite a pain if I want to upgrade. Yes, I realize that there's such a thing as find and replace, but the fact that I have to do that if I want to upgrade is just a bother. That's my $0.02. On 10/25/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Kris, Kris Nuttycombe wrote on Tuesday, October 24, 2006 5:10 PM: (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c (http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg One possibility that occurs to me is that we could take the problem to a higher level. Since a number of projects are going to be facing this problem, what about a package rename at the commons level - say, org.apache.commons2 or org.apache.commons5? This way, the Maven problem and the package rename problems can be solved, and yet we can still keep the individual brand names untainted. This can also scale with new JDK releases - you would end up with a commons for each release where you have a binary incompatible break, but this seems less obnoxious to me than having each project have to keep up with a component-level naming scheme. well, I don't think this is necessary for complete commons, but we may consider doing so for major releases of the individual componnets. Collections might have org.apache.commons.collections4 for the next major version ... and so it would not interfere with older versions, have individual groiupIds (concerning Maven) and the artifacts can coexist, the version scheme is not dependent on the JDK and the minimal JDK requirement can be changed easily. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Generifying Collections
James Carman wrote on Wednesday, October 25, 2006 11:50 AM: For someone who uses Commons Collections a lot in their applications, this is going to be quite a pain if I want to upgrade. Yes, I realize that there's such a thing as find and replace, but the fact that I have to do that if I want to upgrade is just a bother. That's my $0.02. I know, but you really start to hate the situation, if you rely on 3.x and some old component you're also dependend on needs 2.x (and cannot use 3.x becasue of compatibility). - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
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]
Re: [collections] Generifying Collections
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 d) using '2' would just indicate a major major next generation release. The package would be commons-collections2-1.0. I'd prefer (d) as then we can have a commons-collections3 in the future if needed without having it to couple to a JDK version, in case the fork is not coupled to a new technology brought by the JVM. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Generifying Collections
Mario Ivankovits wrote on Wednesday, October 25, 2006 3:03 PM: 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 d) using '2' would just indicate a major major next generation release. The package would be commons-collections2-1.0. I'd prefer (d) as then we can have a commons-collections3 in the future if needed without having it to couple to a JDK version, in case the fork is not coupled to a new technology brought by the JVM. (d) +1 IMHO the best solution for the complete unsatisfying topic. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
From: Mario Ivankovits [EMAIL PROTECTED] 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 d) using '2' would just indicate a major major next generation release. The package would be commons-collections2-1.0. I'd prefer (d) as then we can have a commons-collections3 in the future if needed without having it to couple to a JDK version, in case the fork is not coupled to a new technology brought by the JVM. I believe that our users will find 5 == JDK5 to be an easier concept to grasp. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Stephen Colebourne wrote: From: Mario Ivankovits [EMAIL PROTECTED] 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 d) using '2' would just indicate a major major next generation release. The package would be commons-collections2-1.0. I believe that our users will find 5 == JDK5 to be an easier concept to grasp One reason that I proposed (c) is simply that when you say collections5 or collections2 aloud it sounds like you're talking about a version of Collections, whereas if you say commons5-collections it's more suggestive of a fork, which is what we're really trying to get at. Again, I think that this convention would be useful for other commons projects trying to make the same switch. (a) -0 (b) +0 (c) +1 (d) -0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/21/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. 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]. Thus, it has to be a new package, and this is best thought of as a new component. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) From a simplistic user perspective seems to me that the compatibility achieved by the JDK is successful. I don't understand the intricacies required to generify a library, but if we could do the same wouldn't this be the best solution from a user perspective? Perhaps you could expand on what the issues are with the JDK approach and why they're not desirable in Commons Collections - when I look at the differences for example between the generified and non-generified versions of java.util.List, I don't see the mess you describe. Also I don't understand the compatibilty issue - does the following, for example, constitute a break in compatibility? Going from: boolean add(object o) to: boolean add(E e) Apologies if these are stupid questions, but seems to me that if we could retain backwards compatibility it would be the optimum solution from a user perspective. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
I don't like forking all of commons together. To say commons5-collections-1.0 doesn't work for me. Then, we have to get all of the commons projects to decide on fork points. Am I understanding (c) correctly? On 10/25/06, Kris Nuttycombe [EMAIL PROTECTED] wrote: Stephen Colebourne wrote: From: Mario Ivankovits [EMAIL PROTECTED] 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 d) using '2' would just indicate a major major next generation release. The package would be commons-collections2-1.0. I believe that our users will find 5 == JDK5 to be an easier concept to grasp One reason that I proposed (c) is simply that when you say collections5 or collections2 aloud it sounds like you're talking about a version of Collections, whereas if you say commons5-collections it's more suggestive of a fork, which is what we're really trying to get at. Again, I think that this convention would be useful for other commons projects trying to make the same switch. (a) -0 (b) +0 (c) +1 (d) -0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/25/06, Stephen Colebourne [EMAIL PROTECTED] wrote: 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. The reason I don't think it's a fork is that I don't think we'll be saying Use Old Collections in JDK 5.0 for any reason beyond backwards compat. This is the new version of Collections and the current one would be supported in the same way that the 2.x tree has been. Basically for something to be a fork we have to have a indefinite long term goal to keep both going - one does not replace the other. In this case it seems odd for us to maintain a non-generified version for reasons other than legacy. I can see it being intangible for a while and being a research branch rather than the mainline. The later d) of having collections2 is a bad idea - just look at the weirdness of Axis2 1.0. With a), you suggested that we wouldn't have to change package names when a new major version only removed deprecations. Even in this case it seems that users are going to have pain; apart from a compiler warning a deprecation removal is the same as any other removal. So I think it's either a) or we let the user's deal with the pain as they have been up to now (said pain does create impetus for re-users to upgrade - though possibly they'll just inline the bits they use as with Spring). c) is going to be more painful to search and replace, and implies a common commons jar that we've never been in favour of before. b) implies a fork - though we did do net5 for net's new version didn't we? --- As a separate idea that someone suggested to me at work; how about a facade on top of collections that provides generified inputs/outputs. Could we extend the classes and wrap the static methods to get such a thing? Long term I'd prefer for the core collections to be generified with an old-style wrapper, but then we get into class compatibility issues (49 vs 48) and missing APIs when trying to target older jvms. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
James Carman wrote: I don't like forking all of commons together. To say commons5-collections-1.0 doesn't work for me. Then, we have to get all of the commons projects to decide on fork points. Am I understanding (c) correctly? I don't think there has to be commons-wide fork at all. I just see the name change at the commons level rather than the package level being an approach that can be useful to other packages, so that the other projects that will inevitably make the switch can do so in a uniform manner. In the end, I'm most interested that whatever method is adopted be a solution that can work for all of the commons projects that may want to generify. BeanUtils could certainly be improved with generics, as could Lang and others. In my shop, at least, we've been using JDK5 for over a year now and the lack of progress towards creating generic versions of the Commons components bespeaks a bit of stagnation. I've got the itch for generics across the board; I'd like to be able to scratch it. Kris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Perhaps you could expand on what the issues are with the JDK approach and why they're not desirable in Commons Collections - when I look at the differences for example between the generified and non-generified versions of java.util.List, I don't see the mess you describe. Yes, this is something I had in mind too, just didn't bring it up as I thought the team has good reasons to fork (or whatever), but maybe there is no need at all to fork or package rename as long as we do not use a new jdk5 api. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
From: Niall Pemberton [EMAIL PROTECTED]
From a simplistic user perspective seems to me that the compatibility
achieved by the JDK is successful. I don't understand the intricacies
required to generify a library, but if we could do the same wouldn't
this be the best solution from a user perspective?
Perhaps you could expand on what the issues are with the JDK approach
and why they're not desirable in Commons Collections - when I look at
the differences for example between the generified and non-generified
versions of java.util.List, I don't see the mess you describe.
The problem is erasure. The JDK wipes all knowledge of the type that you
connect to the collection. Thus
ListString list = new ArrayList();
if (list instanceof ListInteger) {
}
fails to compile as the String type is erased.
In order to preserve backwards compatability, Sun had to go to extreme lengths
to ensure that the erased type of each generics element corresponds to the
previous type of the method. Consider the max method on Collections:
public static T extends Object Comparable? super T T max(Collection?
extends T coll)
Where because Object comes before Comparable in the list of bound types, its
Object that the method signature gets erased to. Now thats pretty nasty.
For [collections], there are cases worse than this, such as MultiMap, where the
sf projects have demonstrated that it is not possible to generify the class
without breaking backwards compatability, typically because our interface isn't
a true implementation of the original interface.
Beyond this, there are some classes (like TypedList that we don't even want to
port as they'd be pointless), plus my desire to create a smaller jar file (time
depending), there is ample reason to not worry excessively about backwards
compatability. We shoud target about 90% backwards compatible, with the rest
being fixing API flaws and issues we have now.
A simple port may appeal conceptually, but its not really viable at all.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
From: Kris Nuttycombe [EMAIL PROTECTED] James Carman wrote: I don't like forking all of commons together. To say commons5-collections-1.0 doesn't work for me. Then, we have to get all of the commons projects to decide on fork points. Am I understanding (c) correctly? I don't think there has to be commons-wide fork at all. I just see the name change at the commons level rather than the package level being an approach that can be useful to other packages, so that the other projects that will inevitably make the switch can do so in a uniform manner. In the end, I'm most interested that whatever method is adopted be a solution that can work for all of the commons projects that may want to generify. BeanUtils could certainly be improved with generics, as could Lang and others. In my shop, at least, we've been using JDK5 for over a year now and the lack of progress towards creating generic versions of the Commons components bespeaks a bit of stagnation. I've got the itch for generics across the board; I'd like to be able to scratch it. Yes. I regret using the word 'fork' now, as it has negative connotations. And I agree that quite a few projects need generifications (or rather Java5-ification). Now I'm on JDK5 at work (and its been a massive pain upgrading) I'd like commons to support JDK5. Consider [lang] - a good proportion of [lang] is providing ways to support JDK5 features on earlier JDKs. We might not choose to support them once we have a JDK5 version. The same applies to [collections]. The commons5 name is quite a nice way to express all this. Is it really much different to how Tomcat manages J2EE versions? And I definitely do not think it involves forking the whole of commons!!! Not sure where that idea comes from, but 'commons5' is just a naming conventinon (and package name) for those projects which want a JDK5+ specific version. We need to remember why JDK5 is so important - its because its almost a whole new language. Its not a small incremental step like prior upgrades. We should treat it as such. (Especially as lots of big enterprises are perfectly happy on JDK1.4 and aren't planning to upgrade) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
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 TestClassT {
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.
TestClassTester test1 = new TestClassTester();
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]
Re: [collections] Generifying Collections
Stephen Colebourne wrote:
The problem is erasure. The JDK wipes all knowledge of the type that you
connect to the collection. Thus
ListString list = new ArrayList();
if (list instanceof ListInteger) {
}
fails to compile as the String type is erased.
In order to preserve backwards compatability, Sun had to go to extreme lengths
to ensure that the erased type of each generics element corresponds to the
previous type of the method. Consider the max method on Collections:
public static T extends Object Comparable? super T T max(Collection?
extends T coll)
Where because Object comes before Comparable in the list of bound types, its
Object that the method signature gets erased to. Now thats pretty nasty.
Are fixes like this really grosser than a full package rename? Seems
like the amount of code changed by fixing this in collections is much
less than the amount of code changed if all the new users of collections
need to change package names. Thus, the average upgrade experience
would be better.
For [collections], there are cases worse than this, such as MultiMap, where the
sf projects have demonstrated that it is not possible to generify the class
without breaking backwards compatability, typically because our interface isn't
a true implementation of the original interface.
If there are specific classes where you cannot fix them, it might make
more sense to make parrallel classes rather than a whole package
change. It seems like there will be more collections where creating
generics is straightforward, than ones where it is impossible.
Beyond this, there are some classes (like TypedList that we don't even want to
port as they'd be pointless), plus my desire to create a smaller jar file (time
depending), there is ample reason to not worry excessively about backwards
compatability. We shoud target about 90% backwards compatible, with the rest
being fixing API flaws and issues we have now.
A simple port may appeal conceptually, but its not really viable at all.
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]
Re: [collections] Generifying Collections
I agree on the latter point - that JSE5 is in some ways a complete shift in Java paradigm. Whatever solution is chosen going forward, +1 for a cross-Commons approach... otherwise figuring out compatibility between Commons JARs will become even tougher. I dislike the idea of putting version numbers into package names, but I don't see a realistic alternative giving the fact that Java's handling of JAR manifest versioning isn't as rigorous as we might like for this sort of problem. org.apache.commons.collection5.CollectionUtils is all well and good, but what happens when we migrate to Mustang? Do we go with org.apache.commons.lang6? -- Stephen Smith, MEng (Wales). http://www.stephen-smith.co.uk/ Stephen Colebourne wrote: From: Kris Nuttycombe [EMAIL PROTECTED] James Carman wrote: I don't like forking all of commons together. To say commons5-collections-1.0 doesn't work for me. Then, we have to get all of the commons projects to decide on fork points. Am I understanding (c) correctly? I don't think there has to be commons-wide fork at all. I just see the name change at the commons level rather than the package level being an approach that can be useful to other packages, so that the other projects that will inevitably make the switch can do so in a uniform manner. In the end, I'm most interested that whatever method is adopted be a solution that can work for all of the commons projects that may want to generify. BeanUtils could certainly be improved with generics, as could Lang and others. In my shop, at least, we've been using JDK5 for over a year now and the lack of progress towards creating generic versions of the Commons components bespeaks a bit of stagnation. I've got the itch for generics across the board; I'd like to be able to scratch it. Yes. I regret using the word 'fork' now, as it has negative connotations. And I agree that quite a few projects need generifications (or rather Java5-ification). Now I'm on JDK5 at work (and its been a massive pain upgrading) I'd like commons to support JDK5. Consider [lang] - a good proportion of [lang] is providing ways to support JDK5 features on earlier JDKs. We might not choose to support them once we have a JDK5 version. The same applies to [collections]. The commons5 name is quite a nice way to express all this. Is it really much different to how Tomcat manages J2EE versions? And I definitely do not think it involves forking the whole of commons!!! Not sure where that idea comes from, but 'commons5' is just a naming conventinon (and package name) for those projects which want a JDK5+ specific version. We need to remember why JDK5 is so important - its because its almost a whole new language. Its not a small incremental step like prior upgrades. We should treat it as such. (Especially as lots of big enterprises are perfectly happy on JDK1.4 and aren't planning to upgrade) 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]
Re: [collections] Generifying Collections
(Ok - how bizarre - I sent this mail yesterday (2 days?), but it went nowhere...) Definitely. It's built to be as api compatible as possible with collections, while upgrading to generics. It's also going through the process of making it easier to use from a generics side of things (doesn't give as many compiler warnings). There are a few things that I have noticed that have been deprecated prematurely, but it's way ahead of just converting the code to generics. Let's get going on this... I have a whole heap of architecture tickets I want to open (can't against the sourceforge project, as it's api compatible :) AND they've been wanting to get into the sandbox for a while, but there hasn't been the community to support it (from what I can see)... Cheers Stephen Niall Pemberton wrote: What about the guys that have already done this in sourceforge? http://sourceforge.net/projects/collections If what they've done is any good, it would make sense to start with that they have and get them invloved here. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
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]
Re: [collections] Generifying Collections
On 10/25/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
From: Niall Pemberton [EMAIL PROTECTED]
From a simplistic user perspective seems to me that the compatibility
achieved by the JDK is successful. I don't understand the intricacies
required to generify a library, but if we could do the same wouldn't
this be the best solution from a user perspective?
Perhaps you could expand on what the issues are with the JDK approach
and why they're not desirable in Commons Collections - when I look at
the differences for example between the generified and non-generified
versions of java.util.List, I don't see the mess you describe.
The problem is erasure. The JDK wipes all knowledge of the type that you
connect to the collection. Thus
ListString list = new ArrayList();
if (list instanceof ListInteger) {
}
fails to compile as the String type is erased.
In order to preserve backwards compatability, Sun had to go to extreme lengths
to ensure that the erased type of each generics element corresponds to the
previous type of the method. Consider the max method on Collections:
public static T extends Object Comparable? super T T max(Collection?
extends T coll)
I agree that this is a mess from a library Developer POV - but from a
user perspective isn't it pretty neat that it works for both old
ungenerified code and new generified code?
Where because Object comes before Comparable in the list of bound types, its
Object that the method signature gets erased to. Now thats pretty nasty.
Just to clarify are you calling the method declaration nasty or the
fact that it gets erased to an Object nasty? To be honest I still
don't fully get why Sun did it that way even after reading the
tutorial [1] which has it as a specific example. I guess I'm probably
showing my generic naivety, but the following would seem simpler with
a check/cast to Comparable within the method:
public static T T max(CollectionT coll)
Anyway, apologies for digressing - I realize this isn't generics 101.
For [collections], there are cases worse than this, such as MultiMap, where the
sf projects have demonstrated that it is not possible to generify the class
without breaking backwards compatability, typically because our interface isn't
a true implementation of the original interface.
So perhaps MultiMap should remain unchanged (deprecated?) and a new
MultiMap2 provide a proper generified implementation. Surely this is
much less painful for the few cases than changing the name of
everything.
Beyond this, there are some classes (like TypedList that we don't even want to
port as they'd be pointless), plus my desire to create a smaller jar file (time
depending), there is ample reason to not worry excessively about backwards
compatability. We shoud target about 90% backwards compatible, with the rest
being fixing API flaws and issues we have now.
Don't you mean 0% backwards compatability - which is what changing the
package name results in?
A simple port may appeal conceptually, but its not really viable at all.
I would disagree - if it really is the case that 90% could be ported
with backwards compatibility, then it would seem viable IMO.
Having said that, its not me thats going to be doing the work, but it
does seem valuable to discuss port vs. refactor rather than refactor
being a defacto decission and just having an argument on package
names.
Niall
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
I for one would like to see the getInstance() methods renamed to getClassName(). With java 5 static importing, it enables concise construction/getting without specifying the class name. It's short, highly readable, and most of the time the generic types can be inferred. It's things like this that require a rewrite/break with previous compatibility. Let alone the methods that can't have sensible returns because they're void at the moment. Cheers Stephen Stephen Smith wrote: I agree on the latter point - that JSE5 is in some ways a complete shift in Java paradigm. Whatever solution is chosen going forward, +1 for a cross-Commons approach... otherwise figuring out compatibility between Commons JARs will become even tougher. Stephen Colebourne wrote: We need to remember why JDK5 is so important - its because its almost a whole new language. Its not a small incremental step like prior upgrades. We should treat it as such. (Especially as lots of big enterprises are perfectly happy on JDK1.4 and aren't planning to upgrade) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/25/06, Niall Pemberton [EMAIL PROTECTED] wrote: snip/ Having said that, its not me thats going to be doing the work, but it does seem valuable to discuss port vs. refactor rather than refactor being a defacto decission and just having an argument on package names. snap/ :-) Its not going to be me either, which is why I have (more or less) retired from the conversation. You're right that this isn't about package names, but really whether the intent is to produce a backwards compatible generified collections: * If so, be encumbered with whatever that entails * If not, acknowledge with new collections package It appears to me that the latter might bring more joy to the development of the new collections and result in elegance and entirety of the transformation, but for the reason I mentioned a couple of paragraphs ago, my opinion is not as important as some others. -Rahul P.S.- Regarding your Collections#max question, using casts like you suggest compromises the upper bound of T in the signature, and doesn't convey the correct information to the reader (and arguably more importantly, to the compiler, which consequently cannot guarantee the author-intended type safety, at which point the value proposition of using generics diminishes greatly) Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
(Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c (http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg One possibility that occurs to me is that we could take the problem to a higher level. Since a number of projects are going to be facing this problem, what about a package rename at the commons level - say, org.apache.commons2 or org.apache.commons5? This way, the Maven problem and the package rename problems can be solved, and yet we can still keep the individual brand names untainted. This can also scale with new JDK releases - you would end up with a commons for each release where you have a binary incompatible break, but this seems less obnoxious to me than having each project have to keep up with a component-level naming scheme. Kris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/23/06, Tyler Ward [EMAIL PROTECTED] wrote: I think a very significant part of this problem is just the profusion of jars anyway. The real incompatibility you're worried about is when two projects are using different versions of subcomponents, or at least the multitude of subcomponents makes it that much more likely. Commons isn't that large, it doesn't have lots of outside dependencies, why not just pare it down to one (1) jar, and then the vast majority of this version trouble goes away. Mix and match is a recipe for instability anyway. Our worry is over the projects using us, rather than the stuff we use. So if a company has a project A, that uses Commons X and OpenSourceProject O, and O also uses X, then project A is going to be stuck on upgrading to X.2 until O also upgrade to X.2. If we rename packages then A can run X.2 and O, with X.1 sitting there for O to use behind the scenes. The package contains the specification version. It's a lame solution though - but smarter stuff would involve much more JVM involvement (OSGi does some of this though I think, but as far as I understand it means users have to have embraced OSGi). Something like this. Any project can do whatever it wants. Periodically, all projects are collected together, and a single commons jar is produced. When this found to be stable, it becomes the current version. Rinse, repeat. Programs would then be strongly advised to depend on exactly 1 version of commons, etc Maybe break into 2 or 3 jars, but this whole 30 jars idea is really where the problem lies, it seems to me. Anything running in the same JVM should use the same version anyway. I think users would balk at depending on a huge Commons jar - tempting as it would be to merge a few of the central non-dependency ones into Commons JDK. I think it'd also slow down development. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/24/06, Henri Yandell [EMAIL PROTECTED] wrote: On 10/23/06, Tyler Ward [EMAIL PROTECTED] wrote: I think a very significant part of this problem is just the profusion of jars anyway. The real incompatibility you're worried about is when two projects are using different versions of subcomponents, or at least the multitude of subcomponents makes it that much more likely. Commons isn't that large, it doesn't have lots of outside dependencies, why not just pare it down to one (1) jar, and then the vast majority of this version trouble goes away. Mix and match is a recipe for instability anyway. Our worry is over the projects using us, rather than the stuff we use. So if a company has a project A, that uses Commons X and OpenSourceProject O, and O also uses X, then project A is going to be stuck on upgrading to X.2 until O also upgrade to X.2. If we rename packages then A can run X.2 and O, with X.1 sitting there for O to use behind the scenes. The package contains the specification version. It's a lame solution though - but smarter stuff would involve much more JVM involvement (OSGi does some of this though I think, but as far as I understand it means users have to have embraced OSGi). snip/ OSGi does more in that you can specify import and export package version ranges for your bundles (rather than fixating on one version), which at times lessens the headache. But when push comes to shove, the resolver which forms the basis of the class loading architecture has a constraint solving algorithm designed to pick the higher version (all else being equal). Its possible for a bundle to fail loading if fragments require mutually exclusive version ranges of the same dependency. Generifying [collections] is a pervasive change for the component, lets not be shy about package renaming in such cases, especially the broad shallow heavily depended on category. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] Generifying Collections
Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. 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]. Thus, it has to be a new package, and this is best thought of as a new component. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.x needs JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c (http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/21/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. 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]. Thus, it has to be a new package, and this is best thought of as a new component. 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 :) Basically - we need to start putting the major version in our package names. I hate that, but I can see the need. So this would be a branch of collections, with a package name change to org.apache.commons.collections4.*. 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. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Tomcat has been able to do this without any real problems. Why can't we just keep the Commons Collections name (and packages, etc.), but just use the version numbers to keep it straight? Tomcat 5.5.x requires JDK5. Couldn't we just say that Commons Collections 4.x (and beyond) requires JDK5? That way, for those folks who want to upgrade, it's not very tough. For the most part, the classes/methods will have the same names. On 10/23/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. 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]. Thus, it has to be a new package, and this is best thought of as a new component. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.xneeds JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c ( http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/23/06, James Carman [EMAIL PROTECTED] wrote: Tomcat has been able to do this without any real problems. snip/ Because now (TC6, some in 5.5, maybe other branches too) they've package renamed dependency artifacts (digester, logging, dbcp -- and even hinted at JDT ;-). -Rahul Why can't we just keep the Commons Collections name (and packages, etc.), but just use the version numbers to keep it straight? Tomcat 5.5.x requires JDK5. Couldn't we just say that Commons Collections 4.x (and beyond) requires JDK5? That way, for those folks who want to upgrade, it's not very tough. For the most part, the classes/methods will have the same names. On 10/23/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. 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]. Thus, it has to be a new package, and this is best thought of as a new component. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.xneeds JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c ( http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
I think a very significant part of this problem is just the profusion of jars anyway. The real incompatibility you're worried about is when two projects are using different versions of subcomponents, or at least the multitude of subcomponents makes it that much more likely. Commons isn't that large, it doesn't have lots of outside dependencies, why not just pare it down to one (1) jar, and then the vast majority of this version trouble goes away. Mix and match is a recipe for instability anyway. Something like this. Any project can do whatever it wants. Periodically, all projects are collected together, and a single commons jar is produced. When this found to be stable, it becomes the current version. Rinse, repeat. Programs would then be strongly advised to depend on exactly 1 version of commons, etc Maybe break into 2 or 3 jars, but this whole 30 jars idea is really where the problem lies, it seems to me. Anything running in the same JVM should use the same version anyway. My $0.02. On Oct 23, 2006, at 8:06 PM, Rahul Akolkar wrote: On 10/23/06, James Carman [EMAIL PROTECTED] wrote: Tomcat has been able to do this without any real problems. snip/ Because now (TC6, some in 5.5, maybe other branches too) they've package renamed dependency artifacts (digester, logging, dbcp -- and even hinted at JDT ;-). -Rahul Why can't we just keep the Commons Collections name (and packages, etc.), but just use the version numbers to keep it straight? Tomcat 5.5.x requires JDK5. Couldn't we just say that Commons Collections 4.x (and beyond) requires JDK5? That way, for those folks who want to upgrade, it's not very tough. For the most part, the classes/methods will have the same names. On 10/23/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM: Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. 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]. Thus, it has to be a new package, and this is best thought of as a new component. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.xneeds JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c ( http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg - 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]
Re: [collections] Generifying Collections
What about the guys that have already done this in sourceforge? http://sourceforge.net/projects/collections If what they've done is any good, it would make sense to start with that they have and get them invloved here. Niall On 10/20/06, Stephen Colebourne [EMAIL PROTECTED] wrote: We are just moving to JDK1.5 at work, and I too judge that the time is about right for this. I don't know how much time I'll be able to spend on it though. We'll have to see. There is a clear difference of approach, however, with some factors being: a) keep everything as close as possible to the current source (not always achievable) b) split into 3-5 smaller components c) same package name or different package name d) same project [collections] or new project Thus, I propose that this task is: - started in the commons-sandbox - uses a different package name [collgenerics] - follows the current single jar/package structure - no deprecated classes are ported This allows coding to start quickly, but out of everyones way. It also then allows those of us (like me) who want to re-group the code to do so in a sandbox environment rather than commons-proper. Getting the promotion vote later should be no problem. Kris, are you a committer @ apache? Stephen Kris Nuttycombe wrote: Speaking of porting to collections to generics, I have a bit of time available to contribute to this effort. Could we at least create a generics branch in SVN to get the ball rolling? This topic has been bounced around for a long time, but the process needs to start at some point. I realize that collections needs to be refactored into some smaller projects, but I'm not convinced that the two tasks need to necessarily be undertaken simultaneously. It may in fact be simpler to generify the code in its current architecture since this will involve less disruption to the unit tests. Kris Stephen Colebourne wrote: Hi, It would be useful to attach anything to a JIRA call, as that is an easier worklog than email. The biggest issue that I can see with this is that [collections] as a project is currently at the 'full' point, and needs refactoring into smaller units. This should probably be done as part of moving collections to JDK1.5. Unfortunately, [collections] has little development time available, so just porting to generics is a big enough concept, even before considering a new collection like Trie. There may be another committer willing to volunteer time to this of course... Stephen - Original Message From: Sam Berlin [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Cc: Roger Kapsi [EMAIL PROTECTED] Sent: Wednesday, 20 September, 2006 12:42:12 AM Subject: Contributing to Collections Hi Folks, I sent an email last week about contributing a Patricia tree to the Commons Collections project, but haven't heard back. The project is fully voluntary, so I understand that responses may take a long time. I'd like to make sure that I sent the offer to the correct place, though. Is there some other venue I should be looking at for contributing code? Should I be doing this through JIRA? To recap last week's email, Roger Kapsi I have developed a Patricia tree that fits the Map SortedMap interfaces (and can easily fit the upcoming Java 1.6 NavigableMap), and we'd like to offer it for inclusion in commons-collection. It's currently written for Java 1.5's generics and licensed under the GPL, but we can easily remove the generics if required and should likely be able to change the license if necessary. Thanks very much, Sam - 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] - 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]
Re: [collections] Generifying Collections
On 10/20/06, Stephen Colebourne [EMAIL PROTECTED] wrote: We are just moving to JDK1.5 at work, and I too judge that the time is about right for this. I don't know how much time I'll be able to spend on it though. We'll have to see. There is a clear difference of approach, however, with some factors being: a) keep everything as close as possible to the current source (not always achievable) b) split into 3-5 smaller components c) same package name or different package name d) same project [collections] or new project Thus, I propose that this task is: - started in the commons-sandbox - uses a different package name [collgenerics] - follows the current single jar/package structure - no deprecated classes are ported Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Henri Yandell wrote: Why not just start a branch within Collections? I don't see why this is a new component, are we going to be advising people to use Collections 3.x on JDK 1.5+ for any reasons other than legacy or instability of our generified version? My view is to make a collections-generics branch in collections with a view to it being Collections 4.0. 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]. Thus, it has to be a new package, and this is best thought of as a new component. (Compare this with the JDK where they had to jump through ridiculous hoops to make generics fully backwards-compatible, and created a half-arsed mess in the process...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Whatever you want to do is good, but I'd like to see the first bit be an analysis of the various forks that have happened in terms of 1.5 versions of collections. There's stuff out there that wanted to get involved, now that we're thinking of moving they might be interested and have valuable code and/or ideas. I'm not convinced on splitting up collections yet; simply having a big jar isn't enough of a reason for me. Hen On 10/20/06, Kris Nuttycombe [EMAIL PROTECTED] wrote: Speaking of porting to collections to generics, I have a bit of time available to contribute to this effort. Could we at least create a generics branch in SVN to get the ball rolling? This topic has been bounced around for a long time, but the process needs to start at some point. I realize that collections needs to be refactored into some smaller projects, but I'm not convinced that the two tasks need to necessarily be undertaken simultaneously. It may in fact be simpler to generify the code in its current architecture since this will involve less disruption to the unit tests. Kris Stephen Colebourne wrote: Hi, It would be useful to attach anything to a JIRA call, as that is an easier worklog than email. The biggest issue that I can see with this is that [collections] as a project is currently at the 'full' point, and needs refactoring into smaller units. This should probably be done as part of moving collections to JDK1.5. Unfortunately, [collections] has little development time available, so just porting to generics is a big enough concept, even before considering a new collection like Trie. There may be another committer willing to volunteer time to this of course... Stephen - Original Message From: Sam Berlin [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Cc: Roger Kapsi [EMAIL PROTECTED] Sent: Wednesday, 20 September, 2006 12:42:12 AM Subject: Contributing to Collections Hi Folks, I sent an email last week about contributing a Patricia tree to the Commons Collections project, but haven't heard back. The project is fully voluntary, so I understand that responses may take a long time. I'd like to make sure that I sent the offer to the correct place, though. Is there some other venue I should be looking at for contributing code? Should I be doing this through JIRA? To recap last week's email, Roger Kapsi I have developed a Patricia tree that fits the Map SortedMap interfaces (and can easily fit the upcoming Java 1.6 NavigableMap), and we'd like to offer it for inclusion in commons-collection. It's currently written for Java 1.5's generics and licensed under the GPL, but we can easily remove the generics if required and should likely be able to change the license if necessary. Thanks very much, Sam - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
We are just moving to JDK1.5 at work, and I too judge that the time is about right for this. I don't know how much time I'll be able to spend on it though. We'll have to see. There is a clear difference of approach, however, with some factors being: a) keep everything as close as possible to the current source (not always achievable) b) split into 3-5 smaller components c) same package name or different package name d) same project [collections] or new project Thus, I propose that this task is: - started in the commons-sandbox - uses a different package name [collgenerics] - follows the current single jar/package structure - no deprecated classes are ported This allows coding to start quickly, but out of everyones way. It also then allows those of us (like me) who want to re-group the code to do so in a sandbox environment rather than commons-proper. Getting the promotion vote later should be no problem. Kris, are you a committer @ apache? Stephen Kris Nuttycombe wrote: Speaking of porting to collections to generics, I have a bit of time available to contribute to this effort. Could we at least create a generics branch in SVN to get the ball rolling? This topic has been bounced around for a long time, but the process needs to start at some point. I realize that collections needs to be refactored into some smaller projects, but I'm not convinced that the two tasks need to necessarily be undertaken simultaneously. It may in fact be simpler to generify the code in its current architecture since this will involve less disruption to the unit tests. Kris Stephen Colebourne wrote: Hi, It would be useful to attach anything to a JIRA call, as that is an easier worklog than email. The biggest issue that I can see with this is that [collections] as a project is currently at the 'full' point, and needs refactoring into smaller units. This should probably be done as part of moving collections to JDK1.5. Unfortunately, [collections] has little development time available, so just porting to generics is a big enough concept, even before considering a new collection like Trie. There may be another committer willing to volunteer time to this of course... Stephen - Original Message From: Sam Berlin [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Cc: Roger Kapsi [EMAIL PROTECTED] Sent: Wednesday, 20 September, 2006 12:42:12 AM Subject: Contributing to Collections Hi Folks, I sent an email last week about contributing a Patricia tree to the Commons Collections project, but haven't heard back. The project is fully voluntary, so I understand that responses may take a long time. I'd like to make sure that I sent the offer to the correct place, though. Is there some other venue I should be looking at for contributing code? Should I be doing this through JIRA? To recap last week's email, Roger Kapsi I have developed a Patricia tree that fits the Map SortedMap interfaces (and can easily fit the upcoming Java 1.6 NavigableMap), and we'd like to offer it for inclusion in commons-collection. It's currently written for Java 1.5's generics and licensed under the GPL, but we can easily remove the generics if required and should likely be able to change the license if necessary. Thanks very much, Sam - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/20/06, Stephen Colebourne [EMAIL PROTECTED] wrote: We are just moving to JDK1.5 at work, and I too judge that the time is about right for this. I don't know how much time I'll be able to spend on it though. We'll have to see. There is a clear difference of approach, however, with some factors being: a) keep everything as close as possible to the current source (not always achievable) b) split into 3-5 smaller components c) same package name or different package name d) same project [collections] or new project Thus, I propose that this task is: - started in the commons-sandbox - uses a different package name [collgenerics] - follows the current single jar/package structure - no deprecated classes are ported snip/ This sounds like a decent approach to me. collections5 ? (don't like collgenerics) This allows coding to start quickly, but out of everyones way. It also then allows those of us (like me) who want to re-group the code to do so in a sandbox environment rather than commons-proper. Getting the promotion vote later should be no problem. Kris, are you a committer @ apache? snap/ Better ;-) Jakarta. http://marc.theaimsgroup.com/?l=jakarta-commons-devm=115515520306438w=2 -Rahul Stephen Kris Nuttycombe wrote: Speaking of porting to collections to generics, I have a bit of time available to contribute to this effort. Could we at least create a generics branch in SVN to get the ball rolling? This topic has been bounced around for a long time, but the process needs to start at some point. I realize that collections needs to be refactored into some smaller projects, but I'm not convinced that the two tasks need to necessarily be undertaken simultaneously. It may in fact be simpler to generify the code in its current architecture since this will involve less disruption to the unit tests. Kris Stephen Colebourne wrote: Hi, It would be useful to attach anything to a JIRA call, as that is an easier worklog than email. The biggest issue that I can see with this is that [collections] as a project is currently at the 'full' point, and needs refactoring into smaller units. This should probably be done as part of moving collections to JDK1.5. Unfortunately, [collections] has little development time available, so just porting to generics is a big enough concept, even before considering a new collection like Trie. There may be another committer willing to volunteer time to this of course... Stephen - Original Message From: Sam Berlin [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Cc: Roger Kapsi [EMAIL PROTECTED] Sent: Wednesday, 20 September, 2006 12:42:12 AM Subject: Contributing to Collections Hi Folks, I sent an email last week about contributing a Patricia tree to the Commons Collections project, but haven't heard back. The project is fully voluntary, so I understand that responses may take a long time. I'd like to make sure that I sent the offer to the correct place, though. Is there some other venue I should be looking at for contributing code? Should I be doing this through JIRA? To recap last week's email, Roger Kapsi I have developed a Patricia tree that fits the Map SortedMap interfaces (and can easily fit the upcoming Java 1.6 NavigableMap), and we'd like to offer it for inclusion in commons-collection. It's currently written for Java 1.5's generics and licensed under the GPL, but we can easily remove the generics if required and should likely be able to change the license if necessary. Thanks very much, Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Hi! collections5 ? (don't like collgenerics) I think we should try not to put the technology into the name, nor the target jvm version number. Think about something like collections5 4.0 somehow strange, no? - like java2 1.3.0 ;-) Personally I'd simply create a new branch, maybe call it 5.0 and continue developing there, but I know that this is not possible due to the version conflicts where one library requires the non generified and and another the new one. Hopefully java will solve this some day. What if we simply take the singluar of collections: collection ? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Stephen Colebourne wrote: snip/ Thus, I propose that this task is: - started in the commons-sandbox - uses a different package name [collgenerics] - follows the current single jar/package structure - no deprecated classes are ported This sounds like the best approach to me, for the same reasons as you outline. Kris, are you a committer @ apache? Yes. If others like, I can (I think) create the sandbox project once a name is agreed upon. Should we make 3.2 the start of the branch, or is there a reason to branch from the current state of the trunk? Kris Kris Nuttycombe wrote: Speaking of porting to collections to generics, I have a bit of time available to contribute to this effort. Could we at least create a generics branch in SVN to get the ball rolling? This topic has been bounced around for a long time, but the process needs to start at some point. I realize that collections needs to be refactored into some smaller projects, but I'm not convinced that the two tasks need to necessarily be undertaken simultaneously. It may in fact be simpler to generify the code in its current architecture since this will involve less disruption to the unit tests. Kris Stephen Colebourne wrote: Hi, It would be useful to attach anything to a JIRA call, as that is an easier worklog than email. The biggest issue that I can see with this is that [collections] as a project is currently at the 'full' point, and needs refactoring into smaller units. This should probably be done as part of moving collections to JDK1.5. Unfortunately, [collections] has little development time available, so just porting to generics is a big enough concept, even before considering a new collection like Trie. There may be another committer willing to volunteer time to this of course... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/20/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! collections5 ? (don't like collgenerics) I think we should try not to put the technology into the name, nor the target jvm version number. Think about something like collections5 4.0 somehow strange, no? - like java2 1.3.0 ;-) snip/ I'm sure there can be a better package name. I just didn't like the first name proposed, and I'd rather see the name issue resolved now (before there is anything in SVN), rather than later. -Rahul Personally I'd simply create a new branch, maybe call it 5.0 and continue developing there, but I know that this is not possible due to the version conflicts where one library requires the non generified and and another the new one. Hopefully java will solve this some day. What if we simply take the singluar of collections: collection ? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Kris Nuttycombe wrote: Should we make 3.2 the start of the branch, or is there a reason to branch from the current state of the trunk? I think that we should tag HEAD of [collections], and then copy from there. Rahul Akolkar wrote: collections5 ? (don't like collgenerics) I would have suggested collections5 or collections15, but as has already been pointed out, this is a little strange when JDK6 is about to come out. Naming after the feature seems to make more sense. That said, the advantage with using the name collections5 is that we could use the same naming style for other projects - lang5, io5 etc. By the way, I hope to split the jar before release, so the name may not be *that* important right this second. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Hi! That said, the advantage with using the name collections5 is that we could use the same naming style for other projects - lang5, io5 etc. Yea, thats true. Hmmm ... But then we can do it like java does in the past - we go the collections2 way, though, wouldn't be against collections5 any longer ;-) Do you plan to start over with release 1.0 or can we move on with the next major version number? In this case it would be 4.0. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
What we call it sort of depends upon what we expect the future of the project to be, doesn't it? Splitting the jar will just move some stuff out; there'll likely still be a central collections component, and *eventually* it'd be nice to still be able call this commons-collections. Name recognition and all. So, perhaps create the sandbox project as collections5 but use the org.apache.commons.collections package name, and when it's time to promote, do it as a major version release (maybe 5.0) of collections? Kris Stephen Colebourne wrote: Kris Nuttycombe wrote: Should we make 3.2 the start of the branch, or is there a reason to branch from the current state of the trunk? I think that we should tag HEAD of [collections], and then copy from there. Rahul Akolkar wrote: collections5 ? (don't like collgenerics) I would have suggested collections5 or collections15, but as has already been pointed out, this is a little strange when JDK6 is about to come out. Naming after the feature seems to make more sense. That said, the advantage with using the name collections5 is that we could use the same naming style for other projects - lang5, io5 etc. By the way, I hope to split the jar before release, so the name may not be *that* important right this second. 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]
Re: [collections] Generifying Collections
On 10/20/06, Stephen Colebourne [EMAIL PROTECTED] wrote: snip/ Rahul Akolkar wrote: collections5 ? (don't like collgenerics) I would have suggested collections5 or collections15, but as has already been pointed out, this is a little strange when JDK6 is about to come out. Naming after the feature seems to make more sense. snap/ There is a similar play with naming after a feature, clearly on due (long term) evolution, the benefits of the new [collections] have potential to exceed beyond just generics. The 5 suffix in my mind has little to do with tiger, its just an excuse that makes sense (and still has semblance of having the new having come from the old). Though I'm hardly going to insist on any name here. -Rahul That said, the advantage with using the name collections5 is that we could use the same naming style for other projects - lang5, io5 etc. By the way, I hope to split the jar before release, so the name may not be *that* important right this second. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
On 10/20/06, Kris Nuttycombe [EMAIL PROTECTED] wrote: What we call it sort of depends upon what we expect the future of the project to be, doesn't it? Splitting the jar will just move some stuff out; there'll likely still be a central collections component, and *eventually* it'd be nice to still be able call this commons-collections. Name recognition and all. So, perhaps create the sandbox project as collections5 but use the org.apache.commons.collections package name, and when it's time to promote, do it as a major version release (maybe 5.0) of collections? snip/ IMO, its better to package rename [collections] at this point (lesser jar hell to deal with). -Rahul Kris Stephen Colebourne wrote: Kris Nuttycombe wrote: Should we make 3.2 the start of the branch, or is there a reason to branch from the current state of the trunk? I think that we should tag HEAD of [collections], and then copy from there. Rahul Akolkar wrote: collections5 ? (don't like collgenerics) I would have suggested collections5 or collections15, but as has already been pointed out, this is a little strange when JDK6 is about to come out. Naming after the feature seems to make more sense. That said, the advantage with using the name collections5 is that we could use the same naming style for other projects - lang5, io5 etc. By the way, I hope to split the jar before release, so the name may not be *that* important right this second. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
We could also mash together collections and generics to get commons-collagen I'm sure there are some great puns we could pull out of that. . . --Will Mario Ivankovits wrote: Hi! collections5 ? (don't like collgenerics) I think we should try not to put the technology into the name, nor the target jvm version number. Think about something like collections5 4.0 somehow strange, no? - like java2 1.3.0 ;-) Personally I'd simply create a new branch, maybe call it 5.0 and continue developing there, but I know that this is not possible due to the version conflicts where one library requires the non generified and and another the new one. Hopefully java will solve this some day. What if we simply take the singluar of collections: collection ? Ciao, Mario - 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]
