The stream identifier will take into account the FQCN, and the
version-identifier - so the two classes won't have the same stream
identifier, IMHO.
regards,
Martin
On 10/19/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Please consider the consequences of two different classes w/ the same stream
Yes, wouldn't that have to be the case? Otherwise, A.jar and B.jar,
created by two independent groups, might use the same version id
without realizing it, and thus break a project depending on both of
them.
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
The stream identifier will
Exactly - that's for sure. If it wasn't like that, Eclipse wouldn't
use 1 as a default version id. If it was like Dennis suggested, every
app built with Eclipse would go kaboom.
;)
regards,
Martin
On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Yes, wouldn't that have to be the case?
I've read through my posts here and I think there might be some
miscommunication.
Dennis Byrne
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Exactly - that's for sure. If it wasn't like that, Eclipse wouldn't
use 1 as a default version id. If it was like Dennis suggested, every
app
Indeed the serialVersionUID is used to distinguish between two versions
of the same class. And simply put, it's a performance enhancement. If
serialVersionUID is not present, Java will calculate one based on the
hash (I think). The thing is that needing to calculate a hash each
time a class
Why would that make any difference? The classes are in two different
packages
On Fri, 2007-10-19 at 14:29 -0500, Dennis Byrne wrote:
(not sure if this issue has been covered yet in this thread)
Because these classes are in shared, they will be split into two
classes, one for core and one
(not sure if this issue has been covered yet in this thread)
Because these classes are in shared, they will be split into two classes,
one for core and one for tomahawk. When they are split, you will have two
completely classes in the JVM who have the same serial id. I'm not going to
say don't
Please consider the consequences of two different classes w/ the same stream
identifier.
Dennis Byrne
On 10/19/07, simon [EMAIL PROTECTED] wrote:
Why would that make any difference? The classes are in two different
packages
On Fri, 2007-10-19 at 14:29 -0500, Dennis Byrne wrote:
(not
go ahead.
-M
On 10/19/07, Simon Kitching [EMAIL PROTECTED] wrote:
Hi All,
I'd like to make a trivial commit to add serialVersionUID values to two
classes in shared that don't yet have them. This avoids compile warnings in
IDEs that have warn on missing serialVersionUID set.
Adding the
Hi All,
I'd like to make a trivial commit to add serialVersionUID values to two classes
in shared that don't yet have them. This avoids compile warnings in IDEs that
have warn on missing serialVersionUID set.
Adding the serialVersionUID is technically the right thing to do, IMO although
in
On Fri, 2007-10-19 at 17:56 +0200, Mario Ivankovits wrote:
Hi!
Just some random thoughts ...
I am still not sure that it is a good idea to add the serialVersionUID.
The reasons are:
* It is currently not there as no one cares about the serializability
of class, it is just serializable
11 matches
Mail list logo
