serialVersionUID Follow
Does anyone else have problems with the serialVersionUID inspection?
code: "private static final long serialVersionUID=1L;"
insp.: "serialVersionUID field of a Serializable class is not declared private static final long"
heh?
Didn't enter request yet as this seems so... strange.
Messi
Please sign in to leave a comment.
Yes, I noticed this. New in 3177.
This reminds me of the parallel Eclipse discussion (I think it was new
in 3.1 M4)
Bernhard Messerer wrote:
In article <csoj26$pu2$1@is.intellij.net>,
"Amnon I. Govrin" <nomail@jetbrains.com> wrote:
Just having it generate 1L is just dense in the first place, what's the
value of a serVerUID if it's always the same value???
R
Robert S. Sfeir wrote:
>>This reminds me of the parallel Eclipse discussion (I think it was new
>>in 3.1 M4)
>>
>>Bernhard Messerer wrote:
>>
>>>Does anyone else have problems with the serialVersionUID inspection?
>>>code: "private static final long serialVersionUID=1L;"
>>>insp.: "serialVersionUID field of a Serializable class is not declared
>>>private static final long"
>>>heh?
>>>Didn't enter request yet as this seems so... strange.
>>>
>>>Messi
Very true, I think that the Eclipse version of the intention (quick fix)
is smarter.
Amnon
The current implementation is just a placeholder (it's only in the EAP, so I get to do that). The final implementation will fit the (really, really annoying) default serialVersionUID specification.
On newly created Serializable classes, setting serialVersionUID to 1 is actually a best practice. It means that you are promising to implement your own versioning for the object, and that the built-in versioning support should be ignored. Since the built-in versioning doesn't support backward compatability of versioned objects, and it's pretty easy to roll your own versioning that does support backward compatability, this is a win.
--Dave Griffith
>Very true, I think that the Eclipse version of the intention (quick fix) is smarter.
If anyone feels particularly ambitious, a method that takes a PsiClass and returns the correct default serialVersionUID would be greatly appreciated, and gleefully integrated into this quickfix. Otherwise, for a while, this particular flavor of free ice cream will be of slightly lower quality than those other flavors of free ice cream.
--Dave Griffith
Dave Griffith wrote:
In that case may be it should have a // TODO appended and ability to
change the default code (like other automatic code templates).
Amnon
How about a radio button on the inspection configuration panel that lets you pick between the calculated default value and some constant of your choosing? (I would simply hardcode the constant as 1L, but that would break one of my coworkers charming quirks of scattering
private static final long serialVersionUID= 0xFEEDDEADBEEFD00D;
throughout his code.)
--Dave Griffith
Dave Griffith wrote:
>> Very true, I think that the Eclipse version of the intention (quick
>> fix) is smarter.
I have an initial implementation that works correctly for classes
without synthetic methods or fields. That is for classes that don't have
synthetic accessors to allow inner classes access to private data and
don't use class literals. In my test on jdk classes about 197 of 435
have synthetic members.
I'm hoping synthetic member generation is following the same rules for
all compilers (or at least javac and jikes), in which case I will
probably have a complete implementation next week or so.
Bas
Outstanding. Thanks Bas!
--Dave Griffith
Did you ever finish this? If so, is it in the IG source somewhere? I haven't been able to find it. Apparently, there's still some people using the old GenerateSerialVersionUID plugin and I would like to update it with your implementation.
Sorry, probably should have quoted the original since it's so old. So, here:
Bas Leijdekkers wrote:
> If anyone feels particularly ambitious, a method that takes a
I have an initial implementation that works correctly for classes
without synthetic methods or fields. That is for classes that don't have
synthetic accessors to allow inner classes access to private data and
don't use class literals. In my test on jdk classes about 197 of 435
have synthetic members.
I'm hoping synthetic member generation is following the same rules for
all compilers (or at least javac and jikes), in which case I will
probably have a complete implementation next week or so.
"Brad Lane" <no_mail@jetbrains.com> wrote in message
news:1979259.1122608129394.JavaMail.javamailuser@localhost...
Yes, it is included in Inspection Gadgets now. It is used as a quick fix
to the "Serializable class without serialVersionUID" and "Serializable
non-static inner class without 'serialVersionUID'". Both inspections can
be found in the "Serialization issues" category of the
Errors/Inspections dialog.
Let me know how it works for you.
Bas
Brad Lane wrote:
I need to make this plugin 4.5 friendly. How can I do the following with the
4.5 openapi?
PsiClass containingClass = psiClass.getContainingClass();
"Bas Leijdekkers" <leijdekkers@SPAMBLOCK.carp-technologies.nl> wrote in
message news:42E9F46F.70607@SPAMBLOCK.carp-technologies.nl...
>
>
>> Did you ever finish this? If so, is it in the IG source somewhere? I
>> haven't been able to find it. Apparently, there's still some people
>> using the old GenerateSerialVersionUID plugin and I would like to
>> update it with your implementation.
Nevermind. Got it. The plugin works much better now with your code. Thanks a
lot!
"Brad" <brad@somewhere.com> wrote in message
news:dcmogq$nfm$1@is.intellij.net...
>I need to make this plugin 4.5 friendly. How can I do the following with
>the 4.5 openapi?
>
>
>> Yes, it is included in Inspection Gadgets now. It is used as a quick fix
>> to the "Serializable class without serialVersionUID" and "Serializable
>> non-static inner class without 'serialVersionUID'". Both inspections can
>> be found in the "Serialization issues" category of the Errors/Inspections
>> dialog.
>> Let me know how it works for you.
>>
>> Bas
>>
>> Brad Lane wrote:
>>> Did you ever finish this? If so, is it in the IG source somewhere? I
>>> haven't been able to find it. Apparently, there's still some people
>>> using the old GenerateSerialVersionUID plugin and I would like to
>>> update it with your implementation.
>