Re: serialVersionUID (again)

[Eric Blake]

Your summary seemed good to me.

Mark Wielaard wrote:
> What I don't understand is why it is so hard to specify the actual
> accessor methods. Does anybody know why they were never clearly
> specified?

Partly because it was a hack added in JDK 1.1.  To maintain the most 
possible backward compatibility with 1.0, the whitepaper spec for adding 
inner classes gave recommendations for things like this$0 for the 
enclosing class, Outerclass$<num> for anonymous classes, class$(String) 
as the method to compute class literals, access$<num>() for accessors, 
and val$i for accessing a final local variable in a local class.  But 
none of these were set in stone, in an attempt to avoid polluting the 
user's namespace. Only one naming scheme was required, rather than 
recommended - and that was that member classes (such as Outer.Inner) be 
given the name Outer$Inner, because it affects how a compiler finds 
inner classes when referenced from other .java files. Likewise, the 
specification requires that non-private constructors of non-static 
member classes have an additional first parameter for the enclosing 
class (but parameter names are not specified).  All other 
compiler-generated names are local to a .java file, so the name chosen 
really doesn't matter.

In the 2nd edition JLS, this scheme was maintained - chapter 13 of the 
JLS specifies ONLY the naming scheme of member classes, and leaves 
everything else to the compiler.  It is up to the compiler to avoid name 
clashes with the user's code, and JLS2 does not prohibit a user from 
naming things in his class with names that would clash with the 
whitepaper suggested names.

(In my opinion, the choice of keeping '$' as a legal user identifier 
character is deplorable - if Sun had truly wanted to keep compiler names 
and user names separate, they should have given the compiler a unique 
character or namespace for naming synthetic constructs).

> If both Tom Tromey and Eric Blake say that although theoretical
> possible, it is too difficult for us to ensure compatibility in the free
> compilers with the proprietary Sun javac naming scheme and other
> synthetic stuff I think that are current policy (always add
> serialVersionUID if the class is Serializable) is a good one.
>
> What do others think? Should we try to reverse engineer the naming
> scheme? Or do we keep the current policy? Or we could even ignore being
> serializable compatible with the Sun JDK till this is clearly specified.

I don't think it ever will be clearly specified what accessor methods 
must be named - I think it is up to the compiler to choose its naming 
scheme.

And, if I am correct about compiling the Foo.class literal, jikes will 
never compile serial versions compatibly with javac, because jikes 
relies on class$(String, boolean) to avoid initializing the class, 
whereas javac is still using class$(String) and incorrectly initializing 
classes when evaluating the .class literal.

So I am okay with the proposal to always add a serialVersionUID to all 
Classpath files (with libgcj, I'm not as sure that it is necessary, 
except for the hassle of maintaining two sources).  But I may be a bit 
biased, so I look forward to other's views on the matter.

--
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer