Re: [cp-patches] Stupid spec constant values

[Stuart Ballard]

On 10/5/05, Jeroen Frijters <address@hidden> wrote:
> They never change. They only exist because of an historical accident,
> way back. I don't have a strong opinion on whether we should copy them
> or not, but I certainly have no objection against it (and I'd like the
> Japi scores to be as high as reasonably possible).

They do change - if you look in the japi results they're different in
different versions (I checked 1.2, 1.4 and 1.5). But I don't think
they change between minor releases, only major ones. Presumably they
change with each edit of the file. But they're showing versions 1.2
and 1.6 respectively in JDK1.5 - if they've only seen single-digit
numbers of versions *total*, what are the chances they'd get edited in
a minor release?

I'd prefer not to implement an override in japi because I'd be afraid
of people overusing it. People seem to tend to forget the real reason
why constant field values have to match - because they're inlined at
compiletime and you really don't want your bytecode disagreeing with
its class library about the value.

Putting the values in, stupid and ridiculous as they are, costs us
nothing, but it eliminates a false positive in the errors so that the
*real* errors stand out more.

> > The LoaderHandler.packagePrefix is also a bit subtle. The
> > only way I can see why/how people are using it is to check whether
> > a LoaderHandler is actually the system LoaderHandler implementation.
> > So changing it to something that isn't actually the package that we
> > define it in might break code (not seen actual code that does that
> > though).
>
> This one is very subtle. Since it is a compile time constant, the
> compiler will inline the value, so if a piece of code is compiled
> against GNU Classpath and then run on Sun's JDK (or vice versa) you get
> incorrect results. So I'd argue for changing our constants to match
> Sun's.

Exactly - in other words, code working as you (Mark) described would
fail anyway, unless we actually moved our implementations into a
sun.rmi.server package. Since this is purely hypothetical code we're
talking about, I'd not bother, but if any actual such code showed up,
that's what we'd have to do.

LoaderHandler is deprecated, but RemoteRef isn't.

Sun has a whole "constant field values" page in their documentation
and all these values are listed there - even the RCSIDs.
http://java.sun.com/j2se/1.5.0/docs/api/constant-values.html#javax.swing.undo.StateEditable.RCSID

Stuart.

--
http://sab39.dev.netreach.com/