Bryce McKinlay wrote:
Keith, this is fine.
Okay, thanks. I've committed this.
By the way, you don't need to get approval for every JDWP patch that you
submit. I'm certainly happy to look at any RFCs, but you are really the
"owner" of this code and its your call whether something can go in.
Keith Seitz wrote:
Any better?
Keith
ChangeLog
2005-08-10 Keith Seitz <[EMAIL PROTECTED]>
* vm/reference/gnu/classpath/jdwp/VMIdManager.java: New file
with example implementation of ID-management for JDWP back-end.
* gnu/classpath/jdwp/id/JdwpIdFactory.java: Removed.
On Tue, 2005-08-09 at 13:23 -0700, Keith Seitz wrote:
> I am refactoring my code now and I will post a follow-up shortly.
Well, after quite a bit of refactoring and distraction, I've finally
gotten everything in the next stage of satisfied. I've checked this over
several times, and I think I've a
On Tue, 2005-08-09 at 16:12 -0400, Bryce McKinlay wrote:
> Right. These "special" classes are all clearly identified by having VM
> prefixed to their name. They're also found in a separate location in the
> classpath build tree (vm/reference). It's done this way mostly for
> efficiency - using
Keith Seitz wrote:
On Tue, 2005-08-09 at 15:30 -0400, Bryce McKinlay wrote:
Keith, this looks reasonable to me, although see comments below. Note
that using an abstract class is a little different to how most of the
VM* classes are implemented in classpath. Typically, classpath provides
a
On Tue, 2005-08-09 at 15:30 -0400, Bryce McKinlay wrote:
> Keith, this looks reasonable to me, although see comments below. Note
> that using an abstract class is a little different to how most of the
> VM* classes are implemented in classpath. Typically, classpath provides
> a reference implem
Keith Seitz wrote:
I'll post a ChangeLog, but this is really more an RFC than an RFA
(request for comment/request for approval). But who knows, even a blind
man occasionally hits the target! ;-)
ChangeLog
2005-08-04 Keith Seitz <[EMAIL PROTECTED]>
* gnu/classpath/jdwp/vm/IdManager.ja
Hello,
When we last left off with the drama surrounding ID management, I
believe the biggest concern was performance and allowing the possibility
of the VM to replace the ID management classes I had posted with
something more performance-oriented (and consequently VM-specific).
Taking that into a
