RE: Bug fix in java.lang.Boolean

[Eric Blake]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf
> Of Tom Tromey
> Sent: 13 July 2001 18:12
> To: Eric Blake
> Cc: address@hidden
> Subject: Re: Bug fix in java.lang.Boolean
>
>
> >>>>> "Eric" == Eric Blake <address@hidden> writes:
>
> Eric> Unless java.lang.Boolean.value is final, reflection is free to
> Eric> modify the field given sufficient permission.
> Eric> [ ... ]
> Eric> Immutable objects must be immutable!  Classpath ought to
> Eric> have better security than Sun, so here is the patch for Boolean.
>
> I wonder if compatibility with Sun is important here.
> (I doubt it.)

I haven't reported this to Sun, so I wonder what their take on it would be.
But, with JSR 133 looking to redo the memory model, I know that Sun intends
to clarify the rules regarding final fields so that immutable objects behave
as expected in user programs (they already do in most implementations, but
in a multi-processor weak memory model environment, it is possible to show
that even "immutable" Strings can change contents after creation with the
current memory model of JLS 17, without using reflection to break the
rules).

The way I see it, making a private field final is binary compatible in
.class files, and causes no further overhead to the VM.  In fact, making a
field final allows the JIT to make optimizations that are otherwise not
possible.  All the wrapper classes should be made explicitly immutable by
having their value be final, rather than being implicitly immutable because
of language access restrictions alone; it might offer a performance
speed-up.  Same thing goes for the contents of a String - the char[] should
be final (although reflection can be abused to change the contents of that
array).  Someone correct me if this change would cause problems with
Serialization, where I don't have much experience.

>
> Eric> (in particular, we need to make sure that reflection cannot be
> Eric> used to change how reflection will behave
>
> While I agree that this is nicer conceptually, why is it a
> requirement?  In theory the only cases where it matters will be those
> where a SecurityManager is installed anyway.

OK, I can agree here.  Although it would be nice in theory to make sure that
reflection cannot be used to alter the behavior of java.lang.reflect, we
don't need to add anything to Classpath to enforce this that will cause a
performance penalty unless it is specified by Sun.  The only restriction on
reflection that I see in Sun's javadoc is that setAccessible(true) on the
java.lang.Class Constructor must fail regardless of permissions.

Notice that this restriction is lame, as you can make the Constructor
accessible by setting the field java.lang.reflect.AccessibleObject.override
to true via reflection; but even after this trick execution fails with an
IllegalAccessException in Sun's native code, so it is still not possible to
create a Class object illegally in the JDK.  However, because reflection
lets trusted code screw with non-final private fields, you can destroy
existing Class objects!  Fortunately, as you pointed out, the permissions in
the SecurityManager adequately control
java.lang.reflect.AccessibleObject.setAccessible, and that is the only entry
point I know to subverting language access restrictions - that method must
be called at least once before you can violate any normal language
restrictions; and any environment where abusing reflection is likely to be a
problem, a SecurityManager should already be in place.

>
> Tom

--
Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK
address@hidden   tel:+44(0)117 917 5611