Peter,
I agree with you that the mere presence and shape of an Java interface is
not a sufficient contract. That provides syntax, not semantics. So the
documentation should be expanded to document necessary behavior. And I
don't think that Paul really meant to say that just the shape of the
interface was sufficient. I suspect that he implicitly includes semantics
that are documented for that interface. You just want to make sure that
there are a lot more documented semantics. And I agree with you that
semantics cannot be left undefined within the Framework contracts if they
are to be portable.
You and I ran into a specific problem having to do with undocumented
semantics involving thread pooling. I am pleased that JSR 166 has agreed to
document the semantics in that forthcoming standard. Which is not to say
that thread pooling should be mandated, but I simply point out another
aspect of documenting interface semantics.
I suggest that nothing be mandated for ALL containers that cannot be
expressed within J2ME. If one wants to talk about adding sets that must be
supported IF the environment is J2SE or J2EE, that's fine. But I think that
at a minimum, J2ME containers must be permitted. I haven't looked at its
code, but following up on your thought that Tweety compliance should be part
of the test case, is Tweety J2ME compliant?
Along related lines, I am still unsure of everyone's intentions regarding
meta-info. I'd like more clarity there, especially on what it requires from
a container. I think that it is necessary to allow lightweight container
implementations, even if heavyweight containers turn out to be the most
useful. So if meta-info content must be honored by container authors,
that's one thing. In that role it is basically expanded Javadocs. But I
would be leery about imposing a requirement that containers must machine
process the information. It might be nice in a heavyweight application
platform, but not mandated. Some things are just going to be container
specific, and they should be, because they are not part of the common
contract.
And, of course, we need to understand what all of this would mean in terms
of any required changes to existing client code. In the eagerness to move
forward, there is all of the existing client code to keep in mind. Needless
to say, I feel that existing client code should be supported, as a normative
statement.
> The only way to get a truly multi-container world is precisely to be
> crystal clear about what the Avalon Framework does and does not
> guarantee.
:-)
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
