Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Hihi, good point, I actually never have. What phenomena are to be expected? Just like you have compiled something with say 1.4 and let it run on a 1.3 platform? Anyway, I was thinking of this with respect to class loading issues... Oliver On Wed, 22 Dec 2004 13:37:44 +1300, Sharples, Colin [EMAIL PROTECTED] wrote: I do not think you can compare JDK APIs to commons APIs as you hardly have more than one version of JDK API in your classpath ;) You mean you've never written an RMI app where the client and server were running different JVM levels? ;-) Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Daniel Florey wrote: In order to find an appropriate solution to this issue, I'd like to identify the different problems that we need to address. Version: What does a version number mean? I'll make a proposal for how to use minor/major version number to have a basis on which we can identify the issues. Major version numbers indicate that some public API methods have been changed in semantics or have been removed. So an application using component-1.x might not work with component-2.x Minor version numbers indicate that the component remains backward compatible, but new methods may have been introduced. So an application using component-1.x will work with component-1.y if y0, but an application component-1.y might fail when using component 1.x A build number might indicate that private methods have changed without affecting the public api. So an application using component 1.x.a will work with component 1.x.b and an application using 1.x.b will work with component 1.x.a Does this sound reasonable? Missed something? Have you seen the guidelines in use by the Apache APR project? It looks to me like you're basically advocating the same system they have in place. It might save us hassle to just adopt their version numbering system whole-sale (as the Spring Acegi Security subsystem does) http://apr.apache.org/versioning.html I'd prefer to keep the jar naming as introducing assembly would cause some confusion. If anyone would be interested I could put a simple proposal to the sandbox. Good point, JAR may be a better name. I see two benefits to using assembly or assembler as the name: - Clearly indicates that you aren't dealing with plain-old-JAR files anymore - Parallels name used in .NET so that the analogy is directly obvious This approach will not address the trouble that may be caused by applications not using this package. So finally I think that it is required that this feature (or something comparable) will make it into Java 1.6. Up to then I still think it's a very simple but easy way to add the version number to the package names to avoid at least the very big problems concerning incompatible jars in the same classloader. I understand your reasoning behind putting this code in Java 1.6, but I think we can do this without a new release of the Java language (see below). If our ideas are successful, this new Commons component could always migrate later to a JSR proposal, as Doug Lea's concurrent package did. With regards to problems caused by components that aren't using this new package, I'm thinking that as long as the component does not make any Class.forName calls, we should be OK. If there are Class.forName calls, the component may still be able to work, but we would strongly encourage a migration to using Assembly.getType or whatever. This entails the component introducing a dependency on Assembler, which means the Assembler API will need to maintain backwards compatability as much as possible (e.g. - imagine the nightmare that would ensue if java.util.Vector were to change its semantics!) Regards, Daniel Matt -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Matt Sgarlata Gesendet: Dienstag, 21. Dezember 2004 13:04 An: commons-dev@jakarta.apache.org Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares Chris Lambrou wrote: Matt Sgarlata wrote: Does this mean .NET doesn't have reflection? That's such a killer feature of Java; I can't believe they wouldn't have ported it to .NET. Any .NET developers out there that can tell us how .NET deals with reflection when you have multiple versions of the same class? Since the class name alone is insufficient to fully identify a specific version of a class, to my knowledge there is no equivalent to Class.forName(String classname) in .NET. Instead, .NET has the Assembly class. An Assembly is roughly akin to a java jar file, and is typically a single DLL that contains one or more classes. Assembly has a non-static getType(String typeName) method, that performs the same job as the static Class.forName(String classname) method in java, but for a specific Assembly instance. There is never any ambiguity over which version of the named Type that is returned, since an Assembly can only contain one version of any given class. Support for multiple versions of a class at runtime is achieved by storing those multiple class versions in separate Assemblies. Thanks for the info, Chris! This definitely sounds like a good approach. Now my question is, can we simulate this in a new commons component? :) Here are the steps I would imagine to be involved: 1) Define our own JAR sub-type to mirror the .NET assembly notion. Include some type of a plain-text file that describes the versions of the software required to perform certain tasks. It would be nice to do this in an existing structure like MANIFEST.MF, but I don't know... are you allowed to add arbitrary information to that file? In any
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Tue, 21 Dec 2004 09:11:55 -0500, Matt Sgarlata [EMAIL PROTECTED] wrote: Daniel Florey wrote: I'd prefer to keep the jar naming as introducing assembly would cause some confusion. If anyone would be interested I could put a simple proposal to the sandbox. Good point, JAR may be a better name. I see two benefits to using assembly or assembler as the name: - Clearly indicates that you aren't dealing with plain-old-JAR files anymore - Parallels name used in .NET so that the analogy is directly obvious I'd by +1 fir assembly as well. This approach will not address the trouble that may be caused by applications not using this package. So finally I think that it is required that this feature (or something comparable) will make it into Java 1.6. Up to then I still think it's a very simple but easy way to add the version number to the package names to avoid at least the very big problems concerning incompatible jars in the same classloader. I understand your reasoning behind putting this code in Java 1.6, but I think we can do this without a new release of the Java language (see below). If our ideas are successful, this new Commons component could always migrate later to a JSR proposal, as Doug Lea's concurrent package did. With regards to problems caused by components that aren't using this new package, I'm thinking that as long as the component does not make any Class.forName calls, we should be OK. If there are Class.forName calls, the component may still be able to work, but we would strongly encourage a migration to using Assembly.getType or whatever. This entails the component introducing a dependency on Assembler, which means the Assembler API will need to maintain backwards compatability as much as possible (e.g. - imagine the nightmare that would ensue if java.util.Vector were to change its semantics!) Right. So need to think carefully about the interface ;) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: AW: AW: [proposal] avoiding jar version nightmares
I have to jump into this as well. I hope I am not just repeating what wiser minds have already said :-). The idea of changing package names just seems like a solution that looks simple, but will rapidly become a nightmare. As far as I know, no other set of libraries follow this pattern, including the Java libraries, and I think this suggests that doing this isn't wise. And, in my experience watching work done with tools like Gump, any time people do weird trickery with package names, like Sun renaming some packages from x.y.z to com.sun.x.y.z, this inevitably seems to cause lots of problems somewhere down the line. Additionally, people will soon start writing tools similar to commons-logging that attempt to put a facade over all the versions so you don't have to know which version you are working with. I understand why it is a problem, but it seems like a better solution is to pressure app vendors to upgrade faster (by using tools like Gump that demonstrate the newer versions are solid against many packages) as well as implement classloader isolation. Eric -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, December 19, 2004 5:28 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne [EMAIL PROTECTED] wrote: I would also -1. Versioned packages is not an acceptable solution. What is an acceptable solution then? Do what I said already ... create subordinate class loaders *within* your application, and load the offending subordinate modules into their own class loaders, with their own dependencies. Oliver Craig - 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: AW: AW: AW: [proposal] avoiding jar version nightmares
Daniel Florey wrote: In order to find an appropriate solution to this issue, I'd like to identify the different problems that we need to address. Version: What does a version number mean? I'll make a proposal for how to use minor/major version number to have a basis on which we can identify the issues. Major version numbers indicate that some public API methods have been changed in semantics or have been removed. So an application using component-1.x might not work with component-2.x Minor version numbers indicate that the component remains backward compatible, but new methods may have been introduced. So an application using component-1.x will work with component-1.y if y0, but an application component-1.y might fail when using component 1.x A build number might indicate that private methods have changed without affecting the public api. So an application using component 1.x.a will work with component 1.x.b and an application using 1.x.b will work with component 1.x.a Does this sound reasonable? Missed something? There are Versioning Guidelines available for commons components: http://jakarta.apache.org/commons/releases/versioning.html -- Dennis Lundberg snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: AW: AW: [proposal] avoiding jar version nightmares
And, in my experience watching work done with tools like Gump, any time people do weird trickery with package names, like Sun renaming some packages from x.y.z to com.sun.x.y.z, this inevitably seems to cause lots of problems somewhere down the line. Exactly. Remember the howls of protest when Sun changed the Swing package names from com.sun.java.swing to javax.swing? They wanted Swing to be part of the core JDK, but there couldn't be any com.sun packages in the core JDK, so they had to find a way to bring a new package into the JDK. The javax.* namespace was created precisely *because* renaming packages is such a PITA - this provided a way for anybody to write an extension to the Java libraries in such a way that they could eventually make it into the core libraries. The fact is, when package names change, it's just way too much trouble to keep up to date. I bet there is still JDK1.1 code out there using the old Swing package names even today. Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Wed, 22 Dec 2004 08:58:13 +1300, Sharples, Colin [EMAIL PROTECTED] wrote: And, in my experience watching work done with tools like Gump, any time people do weird trickery with package names, like Sun renaming some packages from x.y.z to com.sun.x.y.z, this inevitably seems to cause lots of problems somewhere down the line. Exactly. Remember the howls of protest when Sun changed the Swing package names from com.sun.java.swing to javax.swing? They wanted Swing to be part of the core JDK, but there couldn't be any com.sun packages in the core JDK, so they had to find a way to bring a new package into the JDK. The javax.* namespace was created precisely *because* renaming packages is such a PITA - this provided a way for anybody to write an extension to the Java libraries in such a way that they could eventually make it into the core libraries. The fact is, when package names change, it's just way too much trouble to keep up to date. I bet there is still JDK1.1 code out there using the old Swing package names even today. I do not think you can compare JDK APIs to commons APIs as you hardly have more than one version of JDK API in your classpath ;) Agreed? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: AW: AW: [proposal] avoiding jar version nightmares
I do not think you can compare JDK APIs to commons APIs as you hardly have more than one version of JDK API in your classpath ;) You mean you've never written an RMI app where the client and server were running different JVM levels? ;-) Colin Sharples IBM Advisory IT Specialist Email: [EMAIL PROTECTED] Mobile: +64 21 402 085 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey [EMAIL PROTECTED] wrote: The solution you proposed will not solve the issue as you cannot replace the classloader of the application server. That's not what I proposed. If you're inside a webapp, what I proposed is that you create your own classloaders *within* your application, and load the conflicting portions into their own class loaders (i.e. instead of loading them from /WEB-INF/classes or /WEB-INF/lib). Finally I think that my proposal is not that bad. If it's not possible to address this issue in future versions of the java language, this seems to be the only solution. So my vote is +1 to add at least the major version number to the components package name. That would have unacceptable impacts on people who don't have the cross-dependency issue, but just want to use a newer version of a particular library that *does* maintain backwards compatibilty across versions. Therefore, I'd -1 such a proposal on any Commons package that I'm involved with. Cheers, Daniel Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Finally I think that my proposal is not that bad. If it's not possible to address this issue in future versions of the java language, this seems to be the only solution. So my vote is +1 to add at least the major version number to the components package name. That would have unacceptable impacts on people who don't have the cross-dependency issue, but just want to use a newer version of a particular library that *does* maintain backwards compatibilty across versions. Therefore, I'd -1 such a proposal on any Commons package that I'm involved with. I would also -1. Versioned packages is not an acceptable solution. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Sun, 19 Dec 2004 14:06:40 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey [EMAIL PROTECTED] wrote: The solution you proposed will not solve the issue as you cannot replace the classloader of the application server. That's not what I proposed. If you're inside a webapp, what I proposed is that you create your own classloaders *within* your application, and load the conflicting portions into their own class loaders (i.e. instead of loading them from /WEB-INF/classes or /WEB-INF/lib). This does not work when you rely on software you can not change. Finally I think that my proposal is not that bad. If it's not possible to address this issue in future versions of the java language, this seems to be the only solution. So my vote is +1 to add at least the major version number to the components package name. That would have unacceptable impacts on people who don't have the cross-dependency issue, but just want to use a newer version of a particular library that *does* maintain backwards compatibilty across versions. Therefore, I'd -1 such a proposal on any Commons package that I'm involved with. Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was perfectly alright. I am +1 for all components I am involved with. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne [EMAIL PROTECTED] wrote: I would also -1. Versioned packages is not an acceptable solution. What is an acceptable solution then? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne [EMAIL PROTECTED] wrote: I would also -1. Versioned packages is not an acceptable solution. What is an acceptable solution then? Do what I said already ... create subordinate class loaders *within* your application, and load the offending subordinate modules into their own class loaders, with their own dependencies. Oliver Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Sun, 19 Dec 2004 23:24:52 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was perfectly alright. Collections was indeed perfectly alright to make backwards-incompatible changes between versions 2 and 3. However, you should also note that these changes were *not* universal -- for a very large number of classes, the calling sequences *are* backwards compatible. Now, let's assume that Collections had implemented the package name includes major version rule. If I had restricted myself to the (quite large) subset where there was no real change, I would have been *incredibly* irritated at having to change package names in *my* application's imports -- just because you gratuitously changed the package name (and therefore made *all* APIs backward incompatible). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was perfectly alright. If by this you are suggesting that [collections] 2 and 3 were designed to be incompatible then you are wrong. [collections] v3 'moved' classes to new packages, but _left_the_old_ones_deprecated_. Some months later I discovered an unintended incompatability in IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the 2.1.1/3.1 combination of versions. My point is that they were desinged to be compatible from 2 to 3. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Sun, 19 Dec 2004 22:46:26 -, Stephen Colebourne [EMAIL PROTECTED] wrote: Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was perfectly alright. If by this you are suggesting that [collections] 2 and 3 were designed to be incompatible then you are wrong. [collections] v3 'moved' classes to new packages, but _left_the_old_ones_deprecated_. Thanks for clarifying. Did not know the old ones co-existed. Some months later I discovered an unintended incompatability in IteratorUtils.EMPTY_ITERATOR, which can be solved by migrating to the 2.1.1/3.1 combination of versions. My point is that they were desinged to be compatible from 2 to 3. Isn't this almost like having an internal vesioning like Daniel suggested? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
You might be irritated, but I think this is the cost to pay for working around this obvious java lack of managing versioned libraries. I think it's just a matter of getting used to this package naming convention. But it doesn't solve the problem. The incompatabilities that usually hurt the most are the unplanned ones, like with collections. Your proposal is to change package with each incompatible new release. Well, applying that 'rule' to collections, I would not have changed package from 2 to 3 because as far as I was concerned at that time it WAS fully compatible. Only later did we find one constant that wasn't. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
On Sun, 19 Dec 2004 23:17:55 -, Stephen Colebourne [EMAIL PROTECTED] wrote: The incompatabilities that usually hurt the most are the unplanned ones, like with collections. Your proposal is to change package with each incompatible new release. Well, applying that 'rule' to collections, I would not have changed package from 2 to 3 because as far as I was concerned at that time it WAS fully compatible. Only later did we find one constant that wasn't. Yes, shit happens, nothing you can do. But when you already know and plan that versions are imcompatible there should be something you can do. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: [proposal] avoiding jar version nightmares
From: Daniel Florey [EMAIL PROTECTED] So the collections way to handle this issue if to move all classes to a new subpackage and leave the old ones where they've been before. To be honest: Is this not very close to my proposal? Certainly, there is some similarity. Were I to change the semantics of a class/method (deliberately), to such a degree that it was backwards incompatible, I would have to create a new class/method with a different name. In collections 3, it so happened that I used a new package, but that was because the GOAL of the release in many ways was to break up a monolith into smaller easier to understand packages. ie. the packages didn't result from semantic changes, but they did enable them - the package restructure came first. Other projects will vary, beanutils/logging/betwixt/digester are all thinking of incompatible v2s, and I can't comment on them. Another package may be the appropriate solution for a particular commons component, however a blanket rule doesn't work for me, nor does including the version number. If you create a package it should describe its purpose. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
