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? Bob
