Re: Bug fix in java.lang.Boolean

[John Keiser]

Perhaps I haven't fully understood the conversation (it happens), but I have
not seen an objection to changing Boolean as proposed and I personally think
that it is nicer and more self-documenting if the field is final.  Does
anyone have objections to doing this and changing the other immutable
java.lang objects as well?  If it does anything to performance, setting the
field to final should improve it.

With regards changing reflection, let me see if I understand the proposal:
you'd like to change some of the fields in Class, Field, Method, etc. to be
final so that people couldn't screw with the objects in illegal ways.
Again, I don't understand why we *shouldn't* make this change.  What is the
actual performance detriment here?  (From what I gather in the discussion
there is one, but it hasn't been shown what it is.)

--John

----- Original Message -----
From: "Eric Blake" <address@hidden>
To: <address@hidden>
Cc: <address@hidden>
Sent: Friday, July 13, 2001 11:47 AM
Subject: RE: Bug fix in java.lang.Boolean


> > -----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
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath