serialVersionUID

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

0

Yes, I noticed this. New in 3177.

0

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

0

In article <csoj26$pu2$1@is.intellij.net>,
"Amnon I. Govrin" <nomail@jetbrains.com> 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


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

0

Robert S. Sfeir wrote:

In article <csoj26$pu2$1@is.intellij.net>,
"Amnon I. Govrin" <nomail@jetbrains.com> 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


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


Very true, I think that the Eclipse version of the intention (quick fix)
is smarter.

Amnon

0


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

0


>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

0

Dave Griffith wrote:

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


In that case may be it should have a // TODO appended and ability to
change the default code (like other automatic code templates).

Amnon

0

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

0

Dave Griffith wrote:
>> 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.


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

0

Outstanding. Thanks Bas!

--Dave Griffith

0

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.

0

Sorry, probably should have quoted the original since it's so old. So, here:

Bas Leijdekkers wrote:

Dave Griffith wrote:

> 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.


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...

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.



0

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.

0

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...

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.


0

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?
>

PsiClass containingClass = psiClass.getContainingClass();

>

"Bas Leijdekkers" <leijdekkers@SPAMBLOCK.carp-technologies.nl> wrote in
message news:42E9F46F.70607@SPAMBLOCK.carp-technologies.nl...

>> 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.
>



0

请先登录再写评论。