RE: Cocoon and JCS (on Gump)

["Adam R. B. Jack" <aj...@apache.org>]

On Mon, 9 Aug 2004, Travis Savo wrote:

> According to the change log Aaron Smuts made this change on 6/28/2004 in
> order to make .dispose() visible to the clients of the JCS class.
>
> I expect it will be a permanent change because it's reasonable that clients
> of the JCS class will want to dispose of a region themselves.
>
> The only problems I foresee with upgrading this in the field is if there's a
> class that extends CacheAccess (which you appear to be doing). In this case
> you will need to upgrade your code, but I expect this to be an isolated and
> rare occurrence. Assuming that's not the case, I see no problems mixing jars
> in the field in relationship to this change.
>
> Does that answer your question?

First, thanks for the answer. Second, API changes happen (fact of life), and Gump (and my questions) are just trying to see if we can mitigate against issues in the field, be early detection and discussion/etc.

Frankly, my low level java is insufficient to know if subtleties of access contraints (on a method) make it into the signature, and/or otherwith affect runtime. I could imagine that such a change annoys compilers, but slides through at runtime (in many case).

I don't think there is an easy way for anybody to allow a transition path, given this type of change. As such, I suspect the correct approach is to note it, and try to move on. BTW: What would really help is notice of what releases the old 'signature' is in, and what release the new one might be in. Having this be in the RELEASE NOTES could help also. Could you answer that question, and try to remember it for the CHANGES notification.

BTW: I'll CC the cocoon community on this one, to see if they are comfortable changing their code.

Thanks for your help.

regards

Adam