David E Jones wrote: > > On Sep 8, 2009, at 11:58 AM, Adam Heath wrote: > >> Adrian Crum wrote: >>> Adam Heath wrote: >>>> Adrian Crum wrote: >>>>> Adam Heath wrote: >>>>>> adri...@apache.org wrote: >>>>>>> Author: adrianc >>>>>>> Date: Sun Aug 9 18:04:26 2009 >>>>>>> New Revision: 802567 >>>>>>> >>>>>>> URL: http://svn.apache.org/viewvc?rev=802567&view=rev >>>>>>> Log: >>>>>>> Refactored GenericDelegator: >>>>>>> >>>>>>> 1. Converted GenericDelegator to an interface. We already have >>>>>>> DelegatorInterface, but it isn't being used anywhere. Removed >>>>>>> DelegatorInterface.java. >>>>>>> >>>>>>> 2. Extracted the static, cached data from the GenericDelegator >>>>>>> implementation and put it in its own class - DelegatorData. The >>>>>>> GenericDelegator implementation holds a reference to the >>>>>>> DelegatorData instance. This makes it possible to have per-thread >>>>>>> instances of GenericDelegator. >>>>>>> >>>>>>> 3. Replaced the ThreadLocal variables with regular variables. >>>>>>> ThreadLocal variables are no longer needed. Client code doesn't need >>>>>>> to be concerned with pushing and popping the GenericDelegator state. >>>>>>> >>>>>>> This commit paves the way for the forthcoming ExecutionContext. >>>>>>> >>>>>>> User modifications will have to replace >>>>>>> GenericDelegator.getGenericDelegator(...) with >>>>>>> DelegatorFactory.getGenericDelegator(...). Also, replace the push >>>>>>> code with the new setXxx methods, and remove the pop code. If >>>>>>> modifications used DelegatorInterface, replace that with >>>>>>> GenericDelegator. >>>>>>> >>>>>>> Aside from those changes, this commit is backwards compatible. >>>>>> No, it is not backwards compatible. >>>>>> >>>>>> When a java class is compiled, the bytecode requests an interface >>>>>> named 'foo', or a class named 'foo'. If 'foo' changes from class to >>>>>> interface, then pre-compiled classes will *not* load. >>>>>> >>>>>> Please, change GenericDelegator back to a class. >>>>>> >>>>>> If DelegatorInterface wasn't used, and was just not uptodate with the >>>>>> method signatures, wouldn't the simpler thing have been to improve >>>>>> DelegatorInterface, then to change the class itself? It seems more >>>>>> work to change the class to an interface. >>>>>> >>>>>> I have external code(webslinger) that needs to support multiple >>>>>> versions of ofbiz(one all the way back to 512946). This change makes >>>>>> that impossible. I have to have multiple versions of ofbiz >>>>>> installed(pre/post this change), and compile the class once for each >>>>>> ofbiz version. >>>>> Which is easier: rewrite all your Webslinger code to reference >>>>> DelegatorInterface instead of GenericDelegator, or just recompile your >>>>> existing code without making any changes? >>>> >>>> That's just it, I wouldn't have to recompile *at all*, if >>>> GenericDelegator stayed a class. Nor would anyone else. >>> >>> I don't have a problem with reverting it, but GenericDelegator will >>> become an interface eventually. If you take a look at David's >>> ExecutionContext branch, that is what he has planned. >> >> Why? We already had DelegatorInterface, that has existed for years; >> it was just never fleshed out. > > There was a lot of discussion about this in the context of the > reasons/goals behind the executioncontext branch(es). The basic idea is > to move the framework to be accessible through a set of interfaces that > are in a single place, a low-level component that other framework > components will depend on, and then all code will use the framework > through the interfaces instead of going directly to classes (which will > just be internal implementations of the framework interfaces and not > generally used directly). > > For the rationale behind this, please see the write up I sent to this > mailing list a few weeks ago about the ExecutionContext and related stuff.
Sure, understand all that. But this broke ABI. And I understand that such a set of changes will *have* to break ABI. If this change is to support the ExecutionContext branch, then it should stay in that branch, 'til it is ready. I'm seeing this done in the reverse order. Introduce a *new* interface, that existing implementations will use. Alter all users to use the interface. When all users are so modified, rename the implementation to whatever. What has happened, is that the last step was done first.
