Mark Wielaard wrote:
I had hoped that the VM interface for Class, Object, Thread and
Throwable was usable for most VMs. What isn't in your case?

Although this question wasn't asked at me I'll answer on behalf of the JC implementation in case it may add something useful. This is just one data point and surely these reasons don't apply universally.

- I avoid VMFoo instances (i.e, shadow objects). It seems to me that
  storing VM specific info in a shadow object serves no (runtime) purpose:
  if it can be represented in Java, store it in the original object,
  if it can't store it in a native C structure or whatever.

- I used the type byte[] for all vmData fields.

- I prefer to avoid the extra method call overhead for important
  methods like Object.wait() imposed by the VMFoo split. In Classpath
  every Object.wait() requires calling VMObject.wait(). That makes
  the code separation cleaner but doesn't make implementation any
  easier - it's just as easy to implement Object.wait() as a native
  method as it is to implement VMObject.wait() as a native method.

- My Thread class uses private objects to implement sleep() and join()
  in terms of Object.wait(). The VM notify()'s this object when the
  thread exits. This means all the complexity of sleeping (and handling
  Thread.interrupt()) can be put   in Object.wait() and not duplicated
  elsewhere.

- I folded VMThrowable into Throwable to get rid of VMThrowable.
  Same reasons as mentioned above.

- These bugs (not fixed in Classpath 0.07):
  http://savannah.gnu.org/bugs/?func=detailitem&item_id=6938
  http://savannah.gnu.org/bugs/?func=detailitem&item_id=7084

- Classpath's reflection implementation is/was incomplete and
  required modifications to work.

Hope these don't sound like complaints - using Classpath has worked
out great and I'm very appreciative of it!!

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath

Reply via email to