harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Lee" <crazy...@crazybob.org>
Subject Re: My first submission! java.lang.ThreadLocal
Date Sat, 28 Jun 2008 18:23:49 GMT
My 2 cents: Aleksey is right to point out that this was developed as part of
the core library and therefore belongs there. As the person responsible for
the core libraries on a different VM, I've run into many cases where I
wished code from the DRLVM library was actually part of the core library.
java.lang.Class and Thread are just two examples. If a given VM doesn't want
to reuse some code in the core libs, they can always replace the class like
they do today. As it stands, manually copying over perfectly generic code
from the DRLVM library is kind of a pain.

I'm not sure how IBM works, but if they're anything like us, we needn't
worry about breaking them. We use a specific version of the core libs w/
various tweaks. Switching to a new version already requires a bit (OK, a
lot) of manual effort. In this case, we'd get a compile error in Thread or
ThreadLocal and we'd simply go fix it up and move forward.

Putting a perfectly generic class in the DRLVM library just creates more
work in the long term given that we're eventually going to move it into the
core lib anyway.

Ideally, we'd have package-private AbstractThread and AbstractClass classes
in the core library which VM-specific Thread and Class implementations could
extend and fill out. In the Javadocs, Thread and Class would still appear to
extend Object. However, Thread.class.getSuperclass() would return
AbstractThread.class. Is this a problem?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message