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 to make e.g. the servlet container and
> clustering happy
Well, these classes must be serializable because in some situations the
container does serialize them and then reload them.
Agreed, for these particular classes it is unlikely that there would be
two different (but compatible) versions of this class around (see
below). However in general, the warning about an implicit
serialVersionUID does need to be taken seriously I think.
> * But if no one cares it is dangerous to add as then also no one will
> update this serialVersionUID
> * which will in the end make the java serialization stuff make think it
> can deserialize the class (the UID didn't change) and it start reading
> the stream - java is safe enough to deal with, but why rely on this.
> What I mean is, if the UID changes it will not happen that a getLong
> will try to read for example a double, it will fail early and no reason
> to assume that the underlying serialization process deals correctly with
> changing data types.
>
> When not adding this UID nothing bad will happen as java recalculates it
> safely.
Yes, this is good advice in general. I agree that unless the developer
community can be relied on to correctly update a serialVersionUID then
auto-assignment is better than manual assignment for exactly the reasons
you list. And even some quite experienced programmers are not aware of
when a serialVersionUID needs to be updated (or can just forget).
Ideally something like CLIRR would detect this :-)
However in these *particular* cases, a change that will alter the
serialization format is unlikely. One class is completely empty, and the
other is a Servlet that has no members at all. I cannot see any reason
to add members to either of these classes.
And in the end adding a serialVersionUID is the *right thing to do*.
Yes, possibly not the *safest* in all cases, but still *right*.
>
> Why not simply disable the warning in your IDE?
Using @SuppressWarnings would be an excellent solution in this case -
but it is not supported in java14.
Eclipse (and probably other IDEs) have no mechanism to disable this
warning just for specific classes AFAIK. And if they did, every user
would have to repeat this (well, if they cared).
Disabling all serialization warnings is not good; these warnings really
can be useful in other cases. For example, there are a number of places
in Orchestra where proper serialVersionUIDs really would be good to
assign, and the warnings are reminders to deal with that sometime.
ConversationManager really can be passed between machines in a cluster,
and so we *should* assign a proper serialVersionUID for that (and keep
it correctly updated!). It's probably best to not do that yet though -
too much flux in that class ATM, so having the warning is a good TODO
reminder.
I do use the compiler warnings lists to check for errors, and it's
annoying for some entries in the list to be "permanent". This is not an
important enough reason to introduce bugs/traps into the code, but in
the case of these two particular classes I think adding a
serialVersionUID is not in that category (though for other classes it
might be true).
Of course the reason I asked in the first place is to see what the
consensus opinion is on this...
Regards,
Simon
> >
> > 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 serialVersionUID is technically the right thing to do, IMO
> >> although in practice I agree it isn't terribly important for these
> >> particular classes.
> >>
> >> Any objections?
> >>
> >> Cheers,
> >>
> >> Simon
> >>
> >> Index:
> >> /home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
> >> ===================================================================
> >> ---
> >> /home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
> >> (revision 586396)
> >> +++
> >> /home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
> >> (working copy)
> >> @@ -74,6 +74,7 @@
> >> public static final String SELECT_ITEM_LIST_ATTR =
> >> RendererUtils.class.getName() + ".LIST";
> >> public static final String EMPTY_STRING = "";
> >> public static final Object NOTHING = new Serializable() {
> >> + private static final long serialVersionUID =
> >> -8618356560493578754L;
> >> };
> >>
> >> public static final String ACTION_FOR_LIST =
> >> "org.apache.myfaces.ActionForList";
> >>
> >>
> >> Index:
> >> /home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
> >> ===================================================================
> >> ---
> >> /home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
> >> (revision 586396)
> >> +++
> >> /home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
> >> (working copy)
> >> @@ -25,6 +25,8 @@
> >>
> >> public class SourceCodeServlet extends HttpServlet
> >> {
> >> + private static final long serialVersionUID = -2233965185519715475L;
> >> +
> >> public void doGet(HttpServletRequest req, HttpServletResponse res)
> >> throws IOException, ServletException
> >> {
> >>
> >>
> >>
> >
> >
> >
>
