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
_______________________________________________
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches