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.
