[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: String/Hashtable boostrapping (again)
From: |
Eric Blake |
Subject: |
RE: String/Hashtable boostrapping (again) |
Date: |
Mon, 16 Jul 2001 09:46:55 +0100 |
> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf
> Of Patrick Doyle
> Sent: 15 July 2001 15:24
> To: Stuart Ballard
> Cc: address@hidden
> Subject: Re: String/Hashtable boostrapping (again)
>
>
> However, I don't think that's the central issue. There really is a
> fundamental initialization problem here:
>
> - Constant pool strings NEED intern().
> - Intern() USES a Hashtable.
> - Instantiating Hashtable NEEDS Hashtable.<clinit> to be executed.
> - Hashtable.<clinit> USES constant pool strings.
>
The 0.2 snapshot of Classpath has this dependency, because there are string
literals referenced in <clinit>, but the current version of Hashtable in CVS
does not have the dependency. I browsed CVS - the change to
java/util/Hashtable.java was committed on Feb 15, and the ChangeLog claims a
rewrite of the Hashtable class. The strings that were in the static
initializer are related to serialization issues, so I don't know why they
were removed.
> As classpath stands, I can't see any way to do this correctly. Am I
> missing it? What is the sequence of events which causes these things to
> be initialized properly?
I don't think there IS a correct sequence for initializing the official 0.2
classpath snapshot, short of having special VM support. But I do think that
it is possible to write Classpath in such a way that cyclic initialization
issues are not a problem, and so that special VM support is not required.
For the 0.2 snapshot, I think you can get around the problem by breaking the
cycle and ensuring that Hashtable.<clinit> does not use the ldc bytecode.
One way to do this, as I pointed out in an earlier message, is by using the
String(char[]) ctor instead of a string literal. Also, try the CVS version,
to see if there is any other cyclic dependency issue we need to resolve.
>
> Then, assuming there is such a correct sequence, doesn't this code still
> seem somewhat obscure? Should it be rewritten so as not to rely so
> heavily on Java's precise initialization semantics, just for clarity?
>
> --
> Patrick Doyle
> address@hidden
>
--
Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK
address@hidden tel:+44(0)117 917 5611