This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Java finality
- From: "Jeroen Frijters" <jeroen at sumatra dot nl>
- To: <tromey at redhat dot com>,"Chris Burdess" <dog at bluezoo dot org>
- Cc: <java at gcc dot gnu dot org>
- Date: Fri, 11 Feb 2005 09:29:27 +0100
- Subject: RE: Java finality
Tom Tromey wrote:
> "final" was always weird, really. I've seen some texts out there say
> that blank finals could only be set in <init> or <clinit>... but this
> contradicts what many compilers actually do. And afaik no runtime
> ever checked that a blank final was only assigned once.
The original VM spec had only one requirement of final fields: Only the
defining class can set them. It said nothing about how many times or
where you could set them. In JSR-133 they've made the rules more strict
and now you can only set them in <init> or <clinit>, but there is still
no requirement that you only set them once. JDK 1.5 doesn't implement
this new strictness though. It still alows any method to modify final
fields. Note that the result of this has always been undefined, because
the JIT can inline final field values (even for blank finals, if it
knows that the <clinit> has already been run).
> Also, System.{in,out,err} are final but you've always been able to
> change them. So there's at least one weird case to handle.
Ha! You haven't always been able to change them. setIn/setOut/setErr
only appeared in JDK 1.1. It vaguely remember that the 1.1 betas had
problems with this because the JIT would inline the values.
Regards,
Jeroen