classpath
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]