> > I don't believe it is correct that reflection can
> set 'final' fields.
>
> Just to be complete...
>
What Lloyd meant was it is not "correct" (not possible) that reflection can set (blank)
finals. It's just wrong to do it.
>
>
> Final is both a runtime and compile time check. The
> "setAccessible" call resets the flag to prevent the
> runtime exception (otherwise the following set gives
> an exception). But you still can't actually compile
> Java source code that accesses final field due to a
> compile time check.
What has the code you attached to do with variables being "final"? Any private
field can be modified with that deplorable pattern of setAccessible(true).
> > For that matter, 'final' is incompatible with
> serialization.
>
> Actually, this whole mechanism is there for
> serialization. There's no mention of final being
> incompatible with serialization. Deserializing an
> object can be, for most intents and purposes, similar
> to constructing a new object, so there's no reason we
> shouldn't be able to serialize objects with final
> fields.
To quote Joshua Bloch -- Deserialization is an "extralinguistic" feature to construct the
instances of classes. Whether or not a class is Serializable should be decided at the class
level and has to be a conscious decision.
- Kedar
[Message sent by forum member 'km' (km)]
http://forums.java.net/jive/thread.jspa?messageID=246339