classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] [RFC/JDWP] ID management


From: Bryce McKinlay
Subject: Re: [cp-patches] [RFC/JDWP] ID management
Date: Tue, 09 Aug 2005 15:30:30 -0400
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

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  <address@hidden>

        * gnu/classpath/jdwp/vm/IdManager.java: New file describing
        the interface used by the JDWP back-end for object and type
        ID management.

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 implementation which can then be replaced (not overridden) by VMs. Perhaps use that model here?

 /**
  * Reads a numerical ID from the stream, returning
  * the actual ID associated with it.
* * IDs are assumed to be eight bytes.
  *
* @param bb the buffer from which to read the ID * @returns the object id
  * @throws IOException for any errors reading from the stream
  * @throws InvaildObjectException if ID is not found
  */
 public ObjectId readId (ByteBuffer bb)
   throws IOException, InvalidObjectException
 {
   long id = bb.getLong ();
   return get (id);
 }

 /**
  * Reads a numerical ID from the stream, returning
  * the actual reference type ID associated with it.
  *
  * IDs are assumed to be eight bytes.
  *
* @param bb the buffer from which to read the ID * @returns the JdwpId
  * @throws IOException for any errors reading from the stream
  * @throws InvaildObjectException if ID is not found
  */
 public ReferenceTypeId readReferenceTypeId (ByteBuffer bb)
   throws IOException, InvalidClassException
 {
   long id = bb.getLong ();
   return getReferenceType (id);
 }
}
In the comments: s/stream/buffer/

These methods seem a little weird to me - they are pushing management of the buffer into the ID management class, where I don't think it belongs. Perhaps it would be cleaner just to have the client code read from the buffer, then call getReferenceType() etc directly?

Bryce





reply via email to

[Prev in Thread] Current Thread [Next in Thread]