Change requests for TMPARCH-9

[alrubinger]

In building upon the work done in TMPARCH-9 to make a VFS Implementation of a storage engine (https://jira.jboss.org/jira/browse/TMPARCH-16), I've come across the following points for discussion/adjustment:

* Seems the only purpose of MemoryMapArchiveImpl is to implement "getActualClass()". This returns the type MemoryMapArchive, which isn't really implementation-specific. Can the done in the MemoryMapArchiveBase (if we even need a base for this, probably just the impl will do).
* MemoryMapArchiveBase.toString(boolean) never checks for if "false" is specified, in which case we should delegate to the no-arg method.
* MemoryMapArchiveBase.toString(boolean) internally does a Comparable implementation (as TODO), though BasicPath provides this. I'll now commit as part of the Path contract that Comparable is extended, so we can do away with this extra bit.
* MemoryMapArchiveBase should be documented as Thread-safe (it appears to be)

S,
ALR

[alrubinger]

"ALRubinger" wrote:
* Seems the only purpose of MemoryMapArchiveImpl is to implement "getActualClass()". This returns the type MemoryMapArchive, which isn't really implementation-specific. Can the done in the MemoryMapArchiveBase (if we even need a base for this, probably just the impl will do).

MemoryMapArchiveImpl also closes the generic context; perhaps this was the intent?

[johnbailey]

The primary purpose of MemoryMapArchiveImpl was to close the generic context. It seemed like MemoryMap would be a good base of storage archives, but the I wanted to make sure the extensions could still benifit from the generic chaining, but also provide a default impl that doesn't require a generic paramer type.

Is there another way you would like to handle this?

[alrubinger]

"johnbailey" wrote:
Is there another way you would like to handle this?

Nah, if you wanna keep the context open that's cool.

S,
ALR