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
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
: 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
: 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
--- Matt Sgarlata [EMAIL PROTECTED] wrote:
David Graham wrote:
--- Daniel Florey [EMAIL PROTECTED] wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to
find
out, which version of jdom
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
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
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
Don't you get to this same result by creating your own URLClassLoader
for each assembly, with its own set of JARs and/or directories
making up its class path?
Craig
On Tue, 21 Dec 2004 07:03:50 -0500, Matt Sgarlata
[EMAIL PROTECTED] wrote:
Chris Lambrou wrote:
Matt Sgarlata wrote:
Does
: [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
Craig McClanahan wrote:
Don't you get to this same result by creating your own URLClassLoader
for each assembly, with its own set of JARs and/or directories
making up its class path?
Haha, yes you probably do get the same result! I for one just didn't
understand what this type of a solution
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
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
] 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
]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Craig McClanahan
Gesendet: Dienstag, 21. Dezember 2004 21:28
An: Jakarta Commons Developers List
Betreff: Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
Don't forget to do a little light reading first :-)
Mechanism to declare
On Tue, 21 Dec 2004 21:51:56 +0100, Daniel Florey [EMAIL PROTECTED] wrote:
Thanks for the links. Do you know if there is a maven task to automatically
generate this manifest entries based on the project.xml?
If not this might be a first step in order to allow easy adoption for the
upcoming
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
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
I think handling different versions of classes/jars at VM level would be a nice
feature, but it would be very hard to implement nd to understand when it comes
to reflection.
Another proposal would be to do it the j2se-way:
When introducing new features to a package (e.g. java.io) don't include
David Graham wrote:
--- Daniel Florey [EMAIL PROTECTED] wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to find
out, which version of jdom was in use by some libraries as this was not
indicated by
Daniel Florey wrote:
I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection.
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe
.Net does have reflection. Some even say it's somewhat more elegant
than Java... I ain't goin' there :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Matt Sgarlata wrote:
Daniel Florey wrote:
I think handling different versions of
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
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey [EMAIL PROTECTED] wrote:
This would be really a funny thing, but how could we replace the classloader
of a given application with a custom one?
But what about a tool that decompiles all the product jars, changes the
package structure and the
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
[EMAIL PROTECTED] wrote:
This may work, but does BCEL require the use of its own custom
classloader also?
This seems to me that this isn't just a problem with commons; it is a
problem with Java itself that .NET already has a very nice
Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
[EMAIL PROTECTED] wrote:
This may work, but does BCEL require the use of its own custom
classloader also?
This seems to me that this isn't just a problem with commons
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
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 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
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
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 ...
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.
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
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Craig McClanahan
Gesendet: Sonntag, 19. Dezember 2004 23:28
An: Jakarta Commons Developers List; [EMAIL PROTECTED]
Betreff: 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.
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Craig McClanahan
Gesendet: Sonntag, 19. Dezember 2004 23:34
An: [EMAIL PROTECTED]
Cc: Jakarta Commons Developers List
Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
2004 23:46
An: Jakarta Commons Developers List; [EMAIL PROTECTED]
Betreff: 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
, 19. Dezember 2004 23:51
An: Stephen Colebourne
Cc: Jakarta Commons Developers List
Betreff: 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
On Sun, 19 Dec 2004 23:51:06 +0100, Daniel Florey [EMAIL PROTECTED] wrote:
Simple example:
If you have two libraries:
Library A using component-1.x
Library B using component-2.x
Both libraries provide some servlets that need to live in the same webapp
and get initialized at startup.
How
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
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
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
Craig McClanahan wrote:
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
[EMAIL PROTECTED] wrote:
How do we go about petitioning Sun for something like this?
A while back now (while the details for Tiger were being planned), I
happened to be in a meeting with Graham Hamilton (who basically owns
The ability to declare your own versioning information, and that of
your dependencies, in a MANIFEST.MF file already exists:
http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html
Two existing use cases for this information are applets and servlet
containers, where the container
--- Daniel Florey [EMAIL PROTECTED] wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to find
out, which version of jdom was in use by some libraries as this was not
indicated by the name of
Don't know. But I think the classloader will still not know which class to
pick as the names are still identical. So it might depend on the load order
of the jars which product will fail.
Or did I got it wrong?
Daniel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL
This would be really a funny thing, but how could we replace the classloader
of a given application with a custom one?
But what about a tool that decompiles all the product jars, changes the
package structure and the import statements and repacks this into a new jar?
;-)
Might be a megaseller...
I think Daniel is right. This would not change anything.
I am not quite sure the problem is yet obvious to anyone: The *same*
classloader must return two *different* versions of the *same* class
for different parts of your software which seems impossible for an
ordinary class loader unless the
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey [EMAIL PROTECTED] wrote:
This would be really a funny thing, but how could we replace the classloader
of a given application with a custom one?
Right. Impossible :(
But what about a tool that decompiles all the product jars, changes the
This may work, but does BCEL require the use of its own custom
classloader also?
This seems to me that this isn't just a problem with commons; it is a
problem with Java itself that .NET already has a very nice solution for.
I'm wondering if this isn't something that should be taken care of at
On Sat, 18 Dec 2004 00:15:28 +0100, Oliver Zeigermann
[EMAIL PROTECTED] wrote:
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey [EMAIL PROTECTED] wrote:
This would be really a funny thing, but how could we replace the classloader
of a given application with a custom one?
Right. Impossible
51 matches
Mail list logo
