You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <lg...@mobilebox.pl> on 2004/11/19 23:18:57 UTC
Eclipse warning concerning serializable classes
The serializable class PageLocalImpl does not declare a static final
serialVersionUID field of type long
There is a lot of these in cocoon's sources. Can I fix that by adding:
private static final long serialVersionUID = 1L;
This is one of eclipse's QuickFix so I can have this done in few minutes.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Eclipse warning concerning serializable classes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Antonio Gallardo wrote:
> Hi Lezsek wich version of eclipse are you using?
>
> Best Regards,
>
> Antonio Gallardo
>
> Leszek Gawron dijo:
>
>>The serializable class PageLocalImpl does not declare a static final
>>serialVersionUID field of type long
>>
>>There is a lot of these in cocoon's sources. Can I fix that by adding:
>>private static final long serialVersionUID = 1L;
>>
>>This is one of eclipse's QuickFix so I can have this done in few minutes.
>>
>>--
>>Leszek Gawron lgawron@mobilebox.pl
>>Project Manager MobileBox sp. z o.o.
>>+48 (61) 855 06 67 http://www.mobilebox.pl
>>mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
>>
>
>
3.1.0 build 200408122000 (win32)
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Eclipse warning concerning serializable classes
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Lezsek wich version of eclipse are you using?
Best Regards,
Antonio Gallardo
Leszek Gawron dijo:
> The serializable class PageLocalImpl does not declare a static final
> serialVersionUID field of type long
>
> There is a lot of these in cocoon's sources. Can I fix that by adding:
> private static final long serialVersionUID = 1L;
>
> This is one of eclipse's QuickFix so I can have this done in few minutes.
>
> --
> Leszek Gawron lgawron@mobilebox.pl
> Project Manager MobileBox sp. z o.o.
> +48 (61) 855 06 67 http://www.mobilebox.pl
> mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
>
Re: Eclipse warning concerning serializable classes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
> Leszek Gawron wrote:
>
>> The serializable class PageLocalImpl does not declare a static final
>> serialVersionUID field of type long
>>
>> There is a lot of these in cocoon's sources. Can I fix that by adding:
>> private static final long serialVersionUID = 1L;
>
>
> No! "1" is not "The stream-unique identifier".
>
> http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/class.html
This was just an example :). Eclipse has an option to insert a generated
serialVersionUID. Thing is after your post I checked it and it .. does
not do anything :)
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Eclipse warning concerning serializable classes
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 21 November 2004 01:38, Vadim Gritsenko wrote:
> Only from the Sun doc - I've not taken my time reading their serialization
> source code. Doc gives impression that it is gotta be universally unique
> number.
:o) Your "excuse" is accepted...
To brief you why I "happen to know"; I used to be heavily involved in
RMI/Serialization back in the late 90's. I had my own kind-of RMI
implementation under JDK1.0, so when RMI was released n JDK1.1, I was quick
to throw away my own garbage and use RMI extremely early, and got to know a
fair bit of the inner workings early on, and strong participation in the RMI
community. That resulted in being invited by Sun to participate in JSR-78 RMI
Custom Remote Reference (http://www.jcp.org/en/jsr/detail?id=78).
Anecdote; The spec was forced through the process too quickly to be ready for
the JDK1.4, and had parts that didn't belong (thread pooling and
configuration), and that was a shame. Otherwise a really cool thing, which
would allow for JSR-76 RMI Security. Most of JSR78 ended up in the Jini
community, but I haven't followed that...
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: Eclipse warning concerning serializable classes
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Niclas Hedhman wrote:
> On Saturday 20 November 2004 08:16, Vadim Gritsenko wrote:
>
>>No! "1" is not "The stream-unique identifier".
>
> Vadim, I don't know where you get that 1L wouldn't work... But it does (and I
> kind of know what I am talking about).
Only from the Sun doc - I've not taken my time reading their serialization
source code. Doc gives impression that it is gotta be universally unique number.
> The serialVersionUID is used to determine the compatibility between a loaded
> class and the serialized object of such class. There is not much more to it.
>
> The serialver executable is provided so that you can figure out the
> serialVerUID after the fact of releasing your code first time.
Yup.
> So, i.e. you can use any number you want, and your challenge is to figure out
> when the number needs to be changed, i.e. serialization compatibility is no
> longer possible.
True.
> To that effect, by not using writeObject()/readObject() it will indeed be
> slightly more tricky to maintain the serialization compatibility. With those
> methods, it shouldn't be too hard to maintain compatibitity almost forever.
Yup.
Vadim
Re: Eclipse warning concerning serializable classes
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 20 November 2004 08:16, Vadim Gritsenko wrote:
> No! "1" is not "The stream-unique identifier".
Vadim, I don't know where you get that 1L wouldn't work... But it does (and I
kind of know what I am talking about).
The serialVersionUID is used to determine the compatibility between a loaded
class and the serialized object of such class. There is not much more to it.
The serialver executable is provided so that you can figure out the
serialVerUID after the fact of releasing your code first time.
So, i.e. you can use any number you want, and your challenge is to figure out
when the number needs to be changed, i.e. serialization compatibility is no
longer possible.
To that effect, by not using writeObject()/readObject() it will indeed be
slightly more tricky to maintain the serialization compatibility. With those
methods, it shouldn't be too hard to maintain compatibitity almost forever.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: Eclipse warning concerning serializable classes
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> The serializable class PageLocalImpl does not declare a static final
> serialVersionUID field of type long
>
> There is a lot of these in cocoon's sources. Can I fix that by adding:
> private static final long serialVersionUID = 1L;
No! "1" is not "The stream-unique identifier".
http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/class.html
Vadim
Re: Eclipse warning concerning serializable classes
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 20/nov/04, alle 18:45, Vadim Gritsenko ha scritto:
> Ugo Cei wrote:
>> Then go for it! I hate those warnings and was planning to remove some
>> of them myself, like unread local variables or declared exceptions
>> that are never thrown.
>
> There is a caveat: if you remove declared but not thrown exception,
> you'll break all classes which use this method.
Yes, that is a possibly incompatible change, if the method is called
from "outside" Cocoon. One more reason to have a formal distinction
between public and internal classes.
A bigger problem is derived classes overriding methods from which
"throws" clauses were removed. One more reason to avoid checked
exceptions ;-)
I'd like to go over these cases one by one and start by fixing some of
them in trunk, if it looks safe to do so. Then, if someone complains,
we can always revert the change.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: Eclipse warning concerning serializable classes
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ugo Cei wrote:
>
> Then go for it! I hate those warnings and was planning to remove some of
> them myself, like unread local variables or declared exceptions that are
> never thrown.
There is a caveat: if you remove declared but not thrown exception, you'll break
all classes which use this method.
Vadim
Re: Eclipse warning concerning serializable classes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Ugo Cei wrote:
>
>> Il giorno 20/nov/04, alle 10:34, Leszek Gawron ha scritto:
>>
>>> I've found some neat ant task:
>>> http://serialver.sourceforge.net/serialver.html
>>
>>
>>
>> Then go for it! I hate those warnings and was planning to remove some
>> of them myself, like unread local variables or declared exceptions
>> that are never thrown.
>
>
>
> Mmmh... before putting serialVersionUID all over the place just because
> Eclipse barfs, shouldn't we think a bit more about what fixing this
> number actually means?
>
> AFAIK, we need to specify this when a serializable class is subject to
> evolutions and we want to ensure that serialized instances of an old
> version of a class can be reloaded by a newer version of that same
> class. If that constant isn't present, then the JVM will compute one
> automatically from the class' structure.
>
> So, if we fix these UIDs, that means that from there on we have to take
> great care that future versions of these classes are
> structure-compatible with older versions, i.e. no field renaming or
> deletion, and no new field whose value is set up in the constructor.
>
> So my feeling is that this could cause more harm than good (having a
> serialization exception is better than some other obscure failure)
> furthermore considering that Cocoon is not a system where serialized
> objects are supposed to be long-lived. And in the hypothetical case
> where that would be the case, then the relevant classes, and only these
> ones, could have a serialVersionUID, with the appropriate warning in the
> javadoc about the needed compatibility of future versions.
>
> So my advice: disable the warning in Eclipse, and that's all!
So I did. I just was not aware of the consequences. Now that I know how
it works in more details I also think that this is a bad idea.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Eclipse warning concerning serializable classes
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
> Il giorno 20/nov/04, alle 10:34, Leszek Gawron ha scritto:
>
>> I've found some neat ant task:
>> http://serialver.sourceforge.net/serialver.html
>
>
> Then go for it! I hate those warnings and was planning to remove some
> of them myself, like unread local variables or declared exceptions
> that are never thrown.
Mmmh... before putting serialVersionUID all over the place just because
Eclipse barfs, shouldn't we think a bit more about what fixing this
number actually means?
AFAIK, we need to specify this when a serializable class is subject to
evolutions and we want to ensure that serialized instances of an old
version of a class can be reloaded by a newer version of that same
class. If that constant isn't present, then the JVM will compute one
automatically from the class' structure.
So, if we fix these UIDs, that means that from there on we have to take
great care that future versions of these classes are
structure-compatible with older versions, i.e. no field renaming or
deletion, and no new field whose value is set up in the constructor.
So my feeling is that this could cause more harm than good (having a
serialization exception is better than some other obscure failure)
furthermore considering that Cocoon is not a system where serialized
objects are supposed to be long-lived. And in the hypothetical case
where that would be the case, then the relevant classes, and only these
ones, could have a serialVersionUID, with the appropriate warning in the
javadoc about the needed compatibility of future versions.
So my advice: disable the warning in Eclipse, and that's all!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Eclipse warning concerning serializable classes
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 20/nov/04, alle 10:34, Leszek Gawron ha scritto:
> I've found some neat ant task:
> http://serialver.sourceforge.net/serialver.html
Then go for it! I hate those warnings and was planning to remove some
of them myself, like unread local variables or declared exceptions that
are never thrown.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: Eclipse warning concerning serializable classes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Ugo Cei wrote:
> Il giorno 19/nov/04, alle 23:18, Leszek Gawron ha scritto:
>
>> The serializable class PageLocalImpl does not declare a static final
>> serialVersionUID field of type long
>>
>> There is a lot of these in cocoon's sources. Can I fix that by adding:
>> private static final long serialVersionUID = 1L;
>
>
> Wouldn't it be better to use the serialver command to generate a
> serialVersionUID?
I've found some neat ant task:
http://serialver.sourceforge.net/serialver.html
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Eclipse warning concerning serializable classes
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 19/nov/04, alle 23:18, Leszek Gawron ha scritto:
> The serializable class PageLocalImpl does not declare a static final
> serialVersionUID field of type long
>
> There is a lot of these in cocoon's sources. Can I fix that by adding:
> private static final long serialVersionUID = 1L;
Wouldn't it be better to use the serialver command to generate a
serialVersionUID?
Ugo
--
Ugo Cei - http://beblogging.com/