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

[Bryce McKinlay]

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

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 an service-provider approach would force everything 
to aquire the implementation object and make a virtual call, which is 
clearly much too heavy in some cases.

For JDWP, you don't have to use this model, of course. If you think it 
makes development/maintainance easier then you could use an SPI. For one 
thing, you'd be able to build both, say, the reference and gcj-specific 
implementations at the same time. I just wanted to make sure you were 
aware of the alternative :)

> > 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.
>  
Ah, yes. And the sizes are VM-specific. Good point!

Bryce