Sounds like a consensus; I will continue to use the suppression going forward.
Perhaps we can spawn the shark conversation into another thread. :) Jacques Le Roux wrote: > > Scott, > > From: "Scott Gray" <[email protected]> >> Hi Jacques, >> >> I'm not going to sit here and pretend to be some sort of expert on the >> subject, I was merely correcting a statement which I knew >> to be false. > > I was not false but badly expressed :p. I wanted to speak about the > peculiar case of versionning with serialisation (actually that > what serialVersionUID is all about). > Because it's the only case that may introduce an issue. The implicit > mechanism should work in most cases but is not guaranteed[1][2] > >> That said, it is my understanding that java serialization always uses >> versioning on objects that implement the Serializable >> interface, the only choice is whether it is implicit (done by the >> compiler) or explicit (hand coded or autogenerated by an IDE). >> >> The discussion in hand is about what that choice should be implicit or >> explicit, with both options appearing to have some >> downsides. In regards to that decision I really have nothing of value >> to add :-) > > I agree with David, let the compiler deals with it and if someone has a > real need then she/he should use serialVersionUID in her/his > code. > So I'd prefer to put @SuppressWarnings("serial") everywhere (even in the > cases I reported serialVersionUID is currently used ) and > forget about it > > I learnt one thing : Runtime computation of the serial version UID hash is > expensive in terms of performance > One question remains : should we continue to "support"(include) Shark ? > > Jacques > [1]<<As a general rule, it's always a good idea to declare explicit serial > version UID values for serializable classes. There are > two reasons for doing that: > a.. Runtime computation of the serial version UID hash is expensive in > terms of performance. If you don't declare a serial version > UID value, then serialization must do it for you at runtime. > b.. The default serial version UID computation algorithm is extremely > sensitive to class changes, including those that might > result from legal differences in compiler implementations. For instance, a > given serializable nested class might have different > default serial version UID values depending on which javac was used to > compile it. That's because javac must add synthetic class > members to implement nested classes, and differences in these synthetic > class members are picked up by the serial version UID > calculation. >> > c.. http://java.sun.com/developer/JDCTechTips/2001/tt0306.html > [2] http://en.wikipedia.org/wiki/Serialization#cite_ref-2 > > >> >> Regards >> Scott >> >> On 5/11/2009, at 7:49 PM, Jacques Le Roux wrote: >> >>> Hi Scott, >>> >>> Actually I did not well express myself yesterday night. I was speaking >>> about serialisation *and* versionning. >>> As Bob explained, we don't need to put serialVersionUIDs as long as we >>> are not concerned by versionning. >>> BTW, the only places we currently have serialVersionUIDs are >>> AuthenticatorException and a bunch in Shark (BTW I wonder if we >>> should keep Shark in OFBiz ?) >>> >>> I wonder if in RMI, session replication and session persistence will >>> ever use versionning ? I mean you use it in a context >>> where you will not change classes and compile, isn'it ? >>> Now I wonder how you envision to use serialisation versionning with >>> runtime data for persisted services. Could you elaborate >>> please ? >>> >>> Anyway all above is not really related with @SuppressWarnings("serial") >>> which is only a convenient way to hide a warning and >>> does not block any future uses of serialisation versionning. >>> >>> Jacques >>> >>> From: "Jacques Le Roux" <[email protected]> >>>> Ha yes, I forgot about RMI and session replication, thanks Scott. >>>> >>>> So this introduce san uncertainty about using >>>> @SuppressWarnings("serial") or not because you have to consider how >>>> the class >>>> will be used. >>>> Maybe we should stay as we were and not put this annotation anywhere >>>> or very carefully ? >>>> For instance in the POS I don't expect any uses of RMI nor any points >>>> Scott's outlined below, so I guess it's safe there. >>>> And anway in case we need serialisation we can always remove the >>>> annotation and seralise isn'it ? >>>> >>>> Jacques >>>> >>>> From: "Scott Gray" <[email protected]> >>>>> FYI Jacques, we do use serialization and will in the future, RMI, >>>>> session replication, session persistence, runtime data for >>>>> persisted services, etc. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> HotWax Media >>>>> http://www.hotwaxmedia.com >>>>> >>>>> On 5/11/2009, at 11:43 AM, Jacques Le Roux wrote: >>>>> >>>>>> KISS : my opinion is that we don't use serialisation and should not >>>>>> in the future, so @SuppressWarnings("serial") seems good >>>>>> to me. >>>>>> And I always remember being badly biteen by serialisation in Visual >>>>>> C ++ 10 years ago >>>>>> When changing fields (adding or removing can't remember), it worked >>>>>> for objects alone, but not when these objects were in a >>>>>> CMap and you wanted to serialise all (list+its objects) >>>>>> >>>>>> Jacques >>>>>> >>>>>> From: "Bob Morley" <[email protected]> >>>>>>> >>>>>>> I do not disagree with the overall premise. >>>>>>> >>>>>>> However, I believe that there is no "compiler handling" in this >>>>>>> case. My >>>>>>> understanding (and I stand to be corrected) is that if we were to >>>>>>> serialize >>>>>>> an object, have a new field added, and then attempt to deserialize >>>>>>> it, it >>>>>>> will always throw an exception if we have not specified the serial >>>>>>> number. >>>>>>> (I believe at runtime it will use reflection, determine the class >>>>>>> definition >>>>>>> has changed, and throw the exception). >>>>>>> >>>>>>> Contrast this to having a serial number on the class, where new >>>>>>> fields (in >>>>>>> the same scenario) would be effectively ignored but the object >>>>>>> would be >>>>>>> successfully deserialized. >>>>>>> >>>>>>> Having said this, my guess is that we do not do much of this >>>>>>> (perhaps job >>>>>>> sandbox?) so it might be much to do about nothing. I was more >>>>>>> curious if >>>>>>> there was a discussion / lots of thought put into not specifying a >>>>>>> serial >>>>>>> number and using the warning suppression. >>>>>>> >>>>>>> Personally, I have no vested interest in doing it one way or >>>>>>> another. I am >>>>>>> really looking for the best practice as I go through and clean- up >>>>>>> other >>>>>>> warnings in the source code. Since our internal process has been >>>>>>> to >>>>>>> generate the serial number, I thought it would be good to have a >>>>>>> quick >>>>>>> dialog and see if we are doing the right thing or if we should make >>>>>>> a >>>>>>> change. >>>>>>> >>>>>>> >>>>>>> David E Jones-4 wrote: >>>>>>>> >>>>>>>> >>>>>>>> In this and in general I prefer not to manually or personally >>>>>>>> control >>>>>>>> things that I know I am likely to mess up. In other words, I think >>>>>>>> this is one case where it is likely that we will often forget to >>>>>>>> update manual serial UIDs, even if some IDEs help with it. >>>>>>>> >>>>>>>> I may be missing something, but isn't this better to let the >>>>>>>> compiler >>>>>>>> handle? >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>>> On Nov 3, 2009, at 8:24 AM, Bob Morley wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Wondering if it makes sense for the best practice for serialized >>>>>>>>> classes to a >>>>>>>>> generated serial number instead of just suppressing the warning? >>>>>>>>> Currently >>>>>>>>> in Ofbiz there are lots of examples of the suppression in place >>>>>>>>> but >>>>>>>>> only one >>>>>>>>> generated serial number >>>>>>>>> (org.ofbiz.common.authentication.api.AuthenticatorException). >>>>>>>>> >>>>>>>>> My brief understanding is that Java will make use of the >>>>>>>>> generated >>>>>>>>> serialVersionUID when it is determining if the definition of a >>>>>>>>> class >>>>>>>>> has >>>>>>>>> changed for deserialization rather than using reflection. >>>>>>>>> >>>>>>>>> We have been working on cleaning up warnings in the source code >>>>>>>>> and >>>>>>>>> this is >>>>>>>>> one that I am just now considering for clean-up. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> -- >>>>>>>>> View this message in context: >>>>>>>>> http://n4.nabble.com/Usage-of-SuppressWarnings-serial-tp361041p361041.html >>>>>>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> View this message in context: >>>>>>> http://n4.nabble.com/Usage-of-SuppressWarnings-serial-tp361041p361091.html >>>>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > > > -- View this message in context: http://n4.nabble.com/Usage-of-SuppressWarnings-serial-tp361041p585688.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
