Re: crashing Kawa with a boolean field

[Jim White <jim at pagesmiths dot com>]

Per Bothner wrote:
> Jim White wrote:
>
> > > That to me looks like a bug in java.util.Hashtable, not Kawa ...
>
> > Actually that NPE is a null key parameter to Hashtable.get.
>
> My point was that the specification Hashtable.get does not specify any 
> "throws" nor does it say that null is disallowed.  Of course Sun no 
> longer believes in specification:  The implementtion is the 
> specification.  (Sun people have told me this.)

That is a small defect in the doc.  Hashtable is a subclass of 
Dictionary, which does specify NPE for a null key to get:

http://java.sun.com/j2se/1.3/docs/api/java/util/Dictionary.html#get(java.lang.Object)

It also is symetric with Hashtable.put which throws NPE on null key.

> > A side note on the initialization of the mapNameToType static in
> > Type. Using a static initializer would eliminate the null check and
> > provide class loading synchronization for free.
>
> That may be reasonable. I prefer to defer unneeded initialization,
> but that may make synchronization difficult. (There some example of
> "double-locking" in Kawa, which I now read is consider a dubious idiom.)

Yes, I understand about the deferred initialization thing.  But in this 
case there is already a ton of static initialization being done.

And yes, the double-locking thing is a deep flaw in the JVM spec.  Like 
the rest of the bone-headed threading API.  If they'ld just given us 
continuations - which the JVM used internally already - then Schemers 
would be very happy and the JVM would have been formally meaningful.

Jim
--
"I love deadlines. I love the whooshing sound they make as they fly by." 
-- Douglas Adams