Adrian Crum wrote: > Adam Heath wrote: >> Adrian Crum wrote: >>> Adam Heath wrote: >>>> [email protected] 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.
