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

[Keith Seitz]

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

I think I understand what you mean -- classpath uses a very unusual (at
least to me) method for dealing with this. So let me see if I
understnad...

If I have code in some package that requires use of the "id manager", it
does not ask for a class which provides this functionality (via a
defined interface). Instead, it just _assumes_ that some interface with
a given name (e.g., gnu.classpath.jdwp.id.IdManager or something) exists
and imports that directly. It is up to the VM supplier to write this
file, with this given package and class name. Essentially, there *is* an
interface, but it's defined by an implementation in vm/reference. It's
not a real java interface. Am I close?

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

These were simply provided as a convenience to the back-end. If you take
a peek at Aaron's command set patches, it's often reading IDs from a
buffer.

My only hesitation with moving it out of IdManager is that IdManager is
the one place where sizes for IDs are (or at least should/could be)
known. The rest of the code (IDSizes excepted right now) knows nothing
about this.

Of course, it's not that big a deal to me, and I can certainly change
(or get Aaron to change ;-) every place this is currently done.

Keith