You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@cayenne.apache.org by Bob Harner <bo...@gmail.com> on 2011/10/02 23:47:17 UTC

Cayenne-generated classes need @SuppressWarnings("serial")

Hi everybody,

Here's a noob question that has probably been asked before, but I
didn't see any answers that I liked...

I prefer to keep all compiler warnings in my code to a minimum. One of
the very few things that I don't like about Cayenne is that the
auto-generated entity classes always have the "The serializable class
_Foo does not declare a static final serialVersionUID field of type
long" compiler warning.

I suppose *not* defining a serialVersionUID (and letting the compiler
do it automatically) is the best choice for common Cayenne use cases,
so it'd be nice to just suppress the warning.

The @SuppressWarnings("serial") annotation will get rid of the
warnings, but of course I don't want to manually update the generated
classes.

I could configure my IDE to ignore these warnings (yuk), but then
other team members will still see them.

I guess I could set up a custom velocity template to include this
annotation, right?

But my real question is: why doesn't Cayenne's default template
already add this @SuppressWarnings("serial") annotation? Is it simply
that none of the Cayenne developers happen to feel as I do that code
(especially library code) should not produce compiler warnings?

Anyway, thanks for a great framework!

RE: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.

>> In that case, it may help to declare the generated classes abstract. Abstract classes cannot be deserialized, so the compiler should not complain.
> 
> Oh and BTW, generated classes are abstract (at least in 3.1), and the compiler still complains - separately about superclass and subclass. So there's more work to do for us to figure out how to handle this correctly.

Oh dear. That's just nonsensical.

Ah well. It might be useful to have a SerialVersionUID in the superclass anyway; I just registered on the dev list, once the registration process is complete I'll elaborate there.

Regards,
Jo

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Andrus Adamchik <an...@objectstyle.org>.

On Oct 4, 2011, at 12:48 PM, Durchholz, Joachim wrote:

> In that case, it may help to declare the generated classes abstract. Abstract classes cannot be deserialized, so the compiler should not complain.

Oh and BTW, generated classes are abstract (at least in 3.1), and the compiler still complains - separately about superclass and subclass. So there's more work to do for us to figure out how to handle this correctly.

Andrus

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Andrus Adamchik <an...@objectstyle.org>.

FYI: we took this discussion to the dev list: http://markmail.org/message/hqtlopjmruxw6ty4

@SuppressWarnings is out of the picture now, but the rest is still up for discussion.

Andrus

On Oct 4, 2011, at 12:48 PM, Durchholz, Joachim wrote:

> Are generated classes ever instantiated via new?
> If not, SerialVersionUID does not serve any useful purpose, it's the programmer-written subclass that gets asked for the SerialVersionUID.
> In that case, it may help to declare the generated classes abstract. Abstract classes cannot be deserialized, so the compiler should not complain.
> 
> An aside note:
> Adding @SuppressWarnings might not be the best way to go, most warning names are not standardized and hence differ between compilers.
> I'm not sure whether "serial" is a standardized warning. I think it isn't but don't know the reference doc to use for checking.
> 
> Regards,
> Jo
>

RE: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.

> The serialization process seems
> to serialize the superclass state based on their own SerialVersionUIDs
> -- that seems like the logical way to do it in any case as otherwise a
> subclass would have to know the implementation details for all
> superclasses.

Ah.
I agree, but can't easily verify myself (looking it up in the JDK's serialization code would probably be a good idea, but I have no idea where to look first).

Agreeing to the rest as well.

Regards,
Jo

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Mike Kienenberger <mk...@gmail.com>.

I wrote the wrong thing in my message.  It should have been "generated
superclass" rather than "generated subclass" -- hopefully it was still
obvious we're talking about the generated class from the context.

While it's true that SerialVersionUID is not useful for the subclass's
serialization, as far as I can tell, it is still necessary for the
generated superclass class itself.   The serialization process seems
to serialize the superclass state based on their own SerialVersionUIDs
-- that seems like the logical way to do it in any case as otherwise a
subclass would have to know the implementation details for all
superclasses.  And in our specific case, where in the common case all
of the state is in the generated class, it's the only place it really
matters.

Please correct me if I'm wrong.

And I see now that the JIRA contains a working fix based on the
ObjModel, which I think is a better solution than using the default
serial generation.

On Tue, Oct 4, 2011 at 10:25 AM, Durchholz, Joachim
<Jo...@hennig-fahrzeugteile.de> wrote:
>> -- SerialVersionUID seems to matter on the generated subclass,
>> especially since this is where all of the state of CayenneDataObject
>> exists.  But I can only infer this -- I cannot find a specific
>> statement.  [1] [2]
>
> I can ;-)
>
>> [1] http://download.oracle.com/javase/1,5.0/docs/api/java/io/Serializable.html
>
> Last sentence on the page:
>
> "It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members."
>
> Actually, I slightly disagree with that sentence: a class could build its SerialVersionUID working off the superclass' SerialVersionUID.
> But the serialization mechanism itself does not use superclass SerialVersionUIDs AFAIK.
>
> Regards,
> Jo
>

RE: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.

> -- SerialVersionUID seems to matter on the generated subclass,
> especially since this is where all of the state of CayenneDataObject
> exists.  But I can only infer this -- I cannot find a specific
> statement.  [1] [2]

I can ;-)

> [1] http://download.oracle.com/javase/1,5.0/docs/api/java/io/Serializable.html

Last sentence on the page:

"It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members."

Actually, I slightly disagree with that sentence: a class could build its SerialVersionUID working off the superclass' SerialVersionUID.
But the serialization mechanism itself does not use superclass SerialVersionUIDs AFAIK.

Regards,
Jo

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Mike Kienenberger <mk...@gmail.com>.

I am not an expert on serialization, and it's been a long time since I
looked into it.

By a strange coincidence, the only cayenne project I wrote involving
serialization is the legacy Cayenne 1.2 app I am doing maintenance on
this week, after having not touched it in four or more years.

However, a quick google on the subject turns up these facts:

-- SerialVersionUID seems to matter on the generated subclass,
especially since this is where all of the state of CayenneDataObject
exists.  But I can only infer this -- I cannot find a specific
statement.  [1] [2]

- Having no SerialVersionUID is better than having a wrong or
unmaintained SerialVersionID since by default "the serialization
runtime will calculate a default serialVersionUID value for that class
based on various aspects of the class". [1]

- The default SerialVersionUID is only "bad" in that different JVM
runtimes may not return the same UID.   Here is a simpler methodology
for generating a SerialVersionUID than building it ourselves which
should do what is necessary, so long as two compile processs do not
return the same value for a specific changed class.

        Class cl = generatedClass.getClass();
        long uid = ObjectStreamClass.lookup(cl).getSerialVersionUID();

        The value of uid will be the same as the value printed out by
'serialver'. [3]

And this value would in turn be the same value used by the runtime
serialization.


[1] http://download.oracle.com/javase/1,5.0/docs/api/java/io/Serializable.html
[2] http://java.sun.com/javase/technologies/core/basic/serializationFAQ.jsp#serialsuper
[3] http://www.jguru.com/faq/printablefaq.jsp?topic=Serialization

On Tue, Oct 4, 2011 at 5:48 AM, Durchholz, Joachim
<Jo...@hennig-fahrzeugteile.de> wrote:
> Are generated classes ever instantiated via new?
> If not, SerialVersionUID does not serve any useful purpose, it's the programmer-written subclass that gets asked for the SerialVersionUID.
> In that case, it may help to declare the generated classes abstract. Abstract classes cannot be deserialized, so the compiler should not complain.
>
> An aside note:
> Adding @SuppressWarnings might not be the best way to go, most warning names are not standardized and hence differ between compilers.
> I'm not sure whether "serial" is a standardized warning. I think it isn't but don't know the reference doc to use for checking.
>
> Regards,
> Jo
>

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Andrus Adamchik <an...@objectstyle.org>.

On Oct 4, 2011, at 12:48 PM, Durchholz, Joachim wrote:

> In that case, it may help to declare the generated classes abstract. Abstract classes cannot be deserialized, so the compiler should not complain.

Oh and BTW, generated classes are abstract (at least in 3.1), and the compiler still complains - separately about superclass and subclass. So there's more work to do for us to figure out how to handle this correctly.

Andrus

RE: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.

Are generated classes ever instantiated via new?
If not, SerialVersionUID does not serve any useful purpose, it's the programmer-written subclass that gets asked for the SerialVersionUID.
In that case, it may help to declare the generated classes abstract. Abstract classes cannot be deserialized, so the compiler should not complain.

An aside note:
Adding @SuppressWarnings might not be the best way to go, most warning names are not standardized and hence differ between compilers.
I'm not sure whether "serial" is a standardized warning. I think it isn't but don't know the reference doc to use for checking.

Regards,
Jo

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Bob Harner <bo...@gmail.com>.

Submitted -- https://issues.apache.org/jira/browse/CAY-1622
("Generated classes shouldn't produce serialVersionUID compiler
warning")

On Mon, Oct 3, 2011 at 3:34 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Appreciate if someone could jira that.
>
>
> On Oct 3, 2011, at 8:57 AM, Christian Grobmeier wrote:
>
>>>> The @SuppressWarnings("serial") annotation will get rid of the
>>>> warnings, but of course I don't want to manually update the generated
>>>> classes.
>>
>>>
>>> Yeah, that one kind of bothers me as well. Why wouldn't you just generate a
>>> default serial number? Or a random one?
>>>
>>
>> Actually generating serials is the better choice when thinking on remote objects
>>
>> Cheers
>> Christian
>>
>
>

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Andrus Adamchik <an...@objectstyle.org>.

Appreciate if someone could jira that.


On Oct 3, 2011, at 8:57 AM, Christian Grobmeier wrote:

>>> The @SuppressWarnings("serial") annotation will get rid of the
>>> warnings, but of course I don't want to manually update the generated
>>> classes.
> 
>> 
>> Yeah, that one kind of bothers me as well. Why wouldn't you just generate a
>> default serial number? Or a random one?
>> 
> 
> Actually generating serials is the better choice when thinking on remote objects
> 
> Cheers
> Christian
>

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Christian Grobmeier <gr...@gmail.com>.

>> The @SuppressWarnings("serial") annotation will get rid of the
>> warnings, but of course I don't want to manually update the generated
>> classes.

>
> Yeah, that one kind of bothers me as well. Why wouldn't you just generate a
> default serial number? Or a random one?
>

Actually generating serials is the better choice when thinking on remote objects

Cheers
Christian

Re: Cayenne-generated classes need @SuppressWarnings("serial")

Posted by Richard Frovarp <rf...@apache.org>.

On 10/2/2011 4:47 PM, Bob Harner wrote:
> Hi everybody,
>
> Here's a noob question that has probably been asked before, but I
> didn't see any answers that I liked...
>
> I prefer to keep all compiler warnings in my code to a minimum. One of
> the very few things that I don't like about Cayenne is that the
> auto-generated entity classes always have the "The serializable class
> _Foo does not declare a static final serialVersionUID field of type
> long" compiler warning.
>
> I suppose *not* defining a serialVersionUID (and letting the compiler
> do it automatically) is the best choice for common Cayenne use cases,
> so it'd be nice to just suppress the warning.
>
> The @SuppressWarnings("serial") annotation will get rid of the
> warnings, but of course I don't want to manually update the generated
> classes.
>
> I could configure my IDE to ignore these warnings (yuk), but then
> other team members will still see them.
>
> I guess I could set up a custom velocity template to include this
> annotation, right?
>
> But my real question is: why doesn't Cayenne's default template
> already add this @SuppressWarnings("serial") annotation? Is it simply
> that none of the Cayenne developers happen to feel as I do that code
> (especially library code) should not produce compiler warnings?
>
> Anyway, thanks for a great framework!

Yeah, that one kind of bothers me as well. Why wouldn't you just 
generate a default serial number? Or a random one?