Usage of @SuppressWarnings("serial")
Locked
Usage of @SuppressWarnings("serial")
 
|
Re: Usage of @SuppressWarnings("serial")
|
|
Re: Usage of @SuppressWarnings("serial")
|
|
Re: Usage of @SuppressWarnings("serial")
Administrator
|
Re: Usage of @SuppressWarnings("serial")
|
|
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" <[hidden email]> >> >> 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. > > |
smime.p7s (4K)
Re: Usage of @SuppressWarnings("serial")
|
Administrator
|
Re: Usage of @SuppressWarnings("serial")
|
Administrator
|
Re: Usage of @SuppressWarnings("serial")
|
|
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. 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 :-) 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" <[hidden email]> >> 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" <[hidden email]> >>> 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" <[hidden email]> >>>>> >>>>> 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. >>>> >>>> >>> >>> >> > > |
Re: Usage of @SuppressWarnings("serial")
|
Administrator
|
Re: Usage of @SuppressWarnings("serial")
|
|
| Free forum by Nabble | Edit this page |