* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [020627 12:55]:
> I may just be "iggrn't," but it has always seemed to me that the whole
> "weak reference" functionality in Java should have been a language
> feature rather than an API thing. Creating a new Reference object on
> the Java heap to track when some other object needs to be disposed
> seems like a very heavyweight solution. In the present case, the
> Tokens in the memory are themselves small, and so having a Reference
> object to track each one would fairly double the memory consumption by
> tokens. But as I said, maybe it's just me -- I've never really done
> any work with the reference APIs.
No, that's a very good point. A one->one mapping between lightweight
objects and Reference objects probably wouldn't gain you much. Typically
one does some kind of "chunking" of lightweight objects (that is, find
a good way to group related objects together, then stick groups of
objects in some container, then do a Soft/WeakReference to the container).
Of course this is only necessary if someone has shown that this kind
of caching is necessary in Jess, which hasn't happened to my knowledge.
> Usually when (call) returns a String unexpectedly the String is "nil"
> -- what (call) will return if the method returns null. Adding special
> cases to the error messages (or some other similar change) so that
> this is easier to see is someplace on my list of things to do. But
> anyway, let's say you call something like
>
> (call (call ?hashmap get MyReaderObject) close)
>
> If there's no MyReaderObject key in the hash map, Jess's error message
> will indicate that there's no "close" method in java.lang.String. This
> is because HashMap.get() will return null, which Jess turns into the
> symbol "nil", and then the outer call has to deal with that
> symbol. First it looks for a class named "nil" with a static method
> named close(). When it doesn't find such a class, the last attempt is
> to call close() on the java.lang.String "nil", and that's where the
> error message comes from.
Yeah, I figured that part out on my own. :) The underlying problem is
that Jess seems to be resolving values to null in situations where it
really shouldn't/couldn't based on looking at our code (and yours).
The biggest problem is that it's an elusive bug and I don't have a
100% reproducible case. I run the exact same code twice and only see
the problem once, which leads me to believe it's a race condition
of some kind.
c
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
