- assigned_to: nobody --> caplet
At
http://www.eros-os.org/pipermail/e-lang/2004-January/009487.html
Kevin Reid writes
? [].asMap()[<import:java.lang.Object>()]
# problem: <IndexOutOfBoundsException:
java.lang.Object@5f209c not found>
In 0.8.26c, this specific problem is fixed:
? [].asMap()[<import:java.lang.Object>()]
# problem: <IndexOutOfBoundsException: <an Object> not
found>
but I'm leaving this bug open because there are many
other occurrences of
this bug. This bug occurs whenever Java code implicitly
or explicitly
invokes .toString() on an object that may not have
overridden
Object.toString(). Because the tools we currently use
to check for all
callers of a given method (IntelliJ's "Find Usage")
doesn't show implicit
calls, these are hard to find. Note that we need to
find both calls in the E
implementation itself, as well as calls in Java code
reachable from the
entry points enabled by our taming decisions.
We don't expect to plug this anytime soon. Once we have
fixed bug
http://bugs.sieve.net/bugs/?func=detailbug&bug_id=125579&group_id=16380
and removed the otc- prefix, and until we fix the
present bug, we will make
clear that the E-on-Java implementation has this source
of non-loggable
non-determinism, and therefore an adversary can easy
write code that cannot
be replayed. So long as this bug seems to threaten only
determinism, I don't
think it need be considered high priority. In
particular, I think even E 1.0
can ship with this caveat.