harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Lee <littlee1...@gmail.com>
Subject Re: interesting commentary via android bug report
Date Wed, 13 Jan 2010 06:14:25 GMT
On Wed, Jan 13, 2010 at 1:49 PM, Jesse Wilson <jessewilson@google.com> wrote:
> On Tue, Jan 12, 2010 at 7:47 PM, Charles Lee <littlee1032@gmail.com> wrote:
>> What's the reason of bad idea? limited memory?
> A cache that cannot be cleared is a disservice to users. It's an error in
> our implementation (and the RI!) to assume that an application requesting
> the canonical path two times wants to receive the same result. If the
> application wants the same value, why doesn't the *application* cache the
> result?!
> If we want to make Harmony faster, there are better ways to do so. The
> simpler optimization is to streamline the code that looks up the canonical
> path *the first time*. Reducing the number of times we cross a JNI boundary
> is one of many opportunities here.

IIRC, the reason we add the cache to the File is because RI seems much
faster than harmony. And reduce the number of times we cross a JNI
boundary improve the performance indeed, but still has a lot to
improve comparing with RI.
There is still a concern here: people who is using RI will not cache
the result in their application because getCanonicalPath() is fast in

> What's the reason of bad implement? Anyone knows?
> The canonical path cache code we shipped with Android 2.0 occasionally
> caused applications to crash with a NoSuchElementException.

Yeah. It is a bug which has been fixed recently (HARMONY-6414). It
seems too late :-(

Yours sincerely,
Charles Lee

View raw message