RE: String/Hashtable bootstrapping problem

[Patrick Doyle]

On Thu, 5 Jul 2001, Cierniak, Michal wrote:

> In ORP (http://orp.sf.net) we intern all strings in a hash table implemented
> in C++, so we don't run in the problem described by you because our ldc
> doesn't call any Java code.  

Ok, thanks for the info.

My theory was that it would be best for ldc to call String's constructor
and its intern.  This should just make everything work properly, and I
don't even have to think about what that means because it will just work.
It turns out that using the constructor and intern does three things I
can think of:

1. It causes String to be initialized, running its <clinit>, which I had
   totally forgotten about.
2. It calls constructors from String's superclasses--though there don't
   happen to be any right now.
3. It interns things exactly how Java code would expect them to be
   interned.

There may even be more things that get done properly this way, and I don't
know what they are, but I don't have to.

In contrast, doing things behind the scenes seemed error-prone, but at
this point, it seems preferable.  :-)  Also, calling Java code to make
Strings may be slow.  I don't know how important that is.

> We will fix it by providing our own, native implementation of
> String.intern() which will use the same hash table as ldc.

That sounds reasonable.  It makes sense to me that something as
fundamental as String shouldn't depend on other classes for its
initialization, because you get a can of worms if one of those other
classes needs a String for its own initialization.

So, should String be reorganized to encourage this?

--
Patrick Doyle
address@hidden