initialization of final fields

[Jerry Kramskoy]

Good points ...  I wonder how carefully Sun thought about the implications
of their statement.  Taking this to the limit means making the compiler
"reflection aware", doesn't
it (since one could manipulate a field via Java reflection APIs) ?

I haven't been following everything that's been happening with gcj, but if
the environment is
going to support dynamic class loading in general, and these bytecodes
are interpreted, the same issue crops up again (along with a hoarde of
others).

Reminds me of a similar, vaguely related problem that arises with
accessibility of objects of some class X across threads.
One thread hasn't finished running the clinit for X, but has made a
reference to an instance of X available to another
thread by placing the reference in a static ... the other thread uses this
object with a
polymorphic invokevirtual (which resolved to a superclass method which is
overriden in X). This invoke
shouldn't be allowed to run until the first thread completes the clinit.
So, should the runtime implementation
of invokes arrange to check this where appropriate?  (Or equivalently,
compiled java?)

Keeps life interesting !!

cheers, Jerry

----- Original Message -----
From: Martyn Pearce <m.pearce@inpharmatica.co.uk>
To: Jerry Kramskoy <Jerry.Kramskoy@insignia.com>
Cc: Martyn Pearce <m.pearce@inpharmatica.co.uk>; Godmar Back
<gback@cs.utah.edu>; <java-discuss@sourceware.cygnus.com>; <vgp@dms.at>
Sent: Thursday, November 04, 1999 2:47 PM
Subject: Re: initialization of final fields


>
>
> Jerry Kramskoy writes:
> | Hi Martyn,
> |
> | I agree that the write*should* be performed just once, but again, the
> | pragmatic approach taken by Sun is as I stated to avoid penalising the
> | runtime (interpreter/JIT'd code) ... so if gcj provides this, it will
> | be offering something that probably no other Java runtime does.
>
> Ah, but that we were talking of runtimes.
>
> I believe that original suggestion (and I'm sure that my comments) were
> directed at the compiler, not the runtime.
>
> The JLS (1.0), 8.3.1.2 `final Fields' states that:
>
> `Any attempt to assign to a final field results in a compile-time
> error'.  (paragraph 2)
>
> http://java.sun.com/docs/books/jls/html/1.1Update.html
> D.1.2 `New Uses for final' states:
>
> `You can defer initialization of a final field or variable, as long as
> you initialize it before it is used and assign a value to it exactly
> once. The compiler will check for proper assignment, as will the
> verifier before code is executed.' (paragraph 3)
>
> So it seems that there's a case to be answered for how Sun's runtime
> behaves, given that the jdk compiler does not adhere to Sun's
> specification.
>
> But then, if the jdk runtime is broken too, do we really want to follow
> that for the sake of compatibility, or indeed, pragmatism.  I'm inclined
> to think that we should fix bugs, not clone them.
>
> Mx.
>