...
This is a behavior of our Java implementation of the OsidRuntimeManager interface and called for in the interface definition. The OSIDs do tightly specify the following:
- no nulls are to be passed or returned
- only those errors specified in the interface definition may be thrown (or those specified on the Java OSID Binding)
- the OSID Providers are encapsulated and implementations not to be accessed by OSID Consumers
...
The OSID Specifications evolve slowly. There will be additions and changes that cause compatibility problems between older and newer code. OsidRuntimeManager provides the hooks for version negotiation to preserve compatibility across minor releases.
Runtime Management
TBD.
Performance
A method invocation through the OsidRuntime proxy adds approximately 150µs per call for repeated calls. The initial call may be significantly higher but varies greatly upon the kind of interface due to both the JVM and OsidRuntimeManager implementation behaviors.
We wouldn't use OSIDs for hard core number crunching. However, as an encapsulation tool for databases, servers, and other software modules it's a small price to pay.
Performance is a concern for layering OSIDs. An OSID stack 100 deep sounds a bit extreme. However, a performance cost should be judged against the complexity at hand. Adding an extra millisecond or two to a manageable and organized stack may be a drop in the bucket compared to the amount of heavy lifting accomplished within the OSID Providers.