commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <>
Subject Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Date Tue, 21 Dec 2004 17:03:32 GMT
On Tue, 21 Dec 2004 09:11:55 -0500, Matt Sgarlata
<> 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 ;)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message