This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]