Re: bug with ConstantValue fields

[Per Bothner <per at bothner dot com>]

Godmar Back <gback@cs.utah.edu> writes:

> I think it would be sufficient to set the _Jv_FIELD_CONSTANT_VALUE flag
> in the _Jv_Field that's emitted.  This would give the run-time system
> the necessary information to assign the field even if there's no
> assignment in a static initializer.  This could be done in
> _Jv_PrepareCompiledClass.  Thinking about it, if this is done before
> <clinit> is invoked, it would even eliminate the need to do these
> assignments in <clinit> at all.

One subtlety to keep in mind is that "final static fields initialized
to compile-time constants" must be initialized first, and in such a way
that the default initial value (null) is never observed, even by
"devious programs".

For numbers, there is no problem;  we can set the initial value at
compile-time.  So the problem is (again) Strings.  I see two solutions:
(1) Do the initialization at the very beginning of <clinit>, or:
(2) do the initialization at some earlier stage, such as "preparation".

My inclination would be (2).  (In other words, I agree with you.)

Reasons:
* Consistency with javac and jikes.
* Save space in <clinit>.
* More consistent with how final static constant number fields
are initialized.
* Might as well do it as the same time we resolve other string literals.
* When/if we in the future allocate (and intern) String literals at
link time, then the problem should go away, since the field can
also be initialized at link time.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/