On 2/23/2011 6:26 PM, Peter Firmstone wrote:
Patricia Shanahan wrote:
On 2/22/2011 12:16 AM, Peter Firmstone wrote:
Patricia Shanahan wrote:
I want to get going on some performance tuning, but believe it is best
guided and controlled by well-organized benchmarks. To that end, I
propose adding a place for benchmarks to the River structure.
...
Each module would be considered a separate build, the tests would
include unit and integration tests. Other modules yours depends on are
like libraries, you wouldn't be concerned with their implementation. The
existing qa harness would be a separate library module (similar to how
junit or jtreg is a separate component). Jini Platform tests would be
separated from implementation tests. (We also need to consider how to
best utilise the discovery and join test kit.)
If the changes are localised to your module, meaning the public API
doesn't change, which is like an independent build, you could just
duplicate the original module, modify it, then run performance tests
against both the new and original modules, your new module name would
have a different version number to reflect the experimental changes.
If the changes to involve changing public API in the module, in a non
backward compatible manner, and this API is not part of net.jini.*
(which must remain backward compatible), then other modules that are
dependent can be migrated to the new module over time, proxy's that
utilise the new module will need to use preferred class loading to
ensure the correct classes are loaded. The module version number would
be incremented to show it is not backward compatible.
How would you propose handling a case like outrigger.FastList?
It is package access only, so changing its interface to the rest of
outrigger did not affect any public API. Several classes needed to be
changed to handle the interface change.
Patricia
