On 8/26/13 11:28 AM, Oliver Heger wrote: > Am 26.08.2013 16:18, schrieb Phil Steitz: >> >> On Aug 26, 2013, at 7:38 PM, Oliver Heger <oliver.he...@oliver-heger.de> >> wrote: >> >>> Am 25.08.2013 18:45, schrieb Adrian Crum: >>>> +1 >>>> >>>> -Adrian >>>> >>>> On 8/25/2013 9:26 AM, James Carman wrote: >>>>> AtomicReference? >>> There are multiple aspects here. One is the safe publishing of a value >>> written into the member field. This can be achieved by atomic >>> references, synchronization, or a volatile field. >>> >>> The other aspect is that such a field of a static utility class is >>> pretty global. You cannot have different values for different threads. >>> >>> So the question is, is it good design to have static utility classes >>> with state? >> Excellent point. The key question to ask is are there use cases where >> different threads in the same JVM are really going to want different default >> factories. I wonder if any actual user of the current code has ever wanted >> this. >> > In this special case, I *assume* that there are hardly any concrete use > cases, but of course, we cannot be sure. > > However, there may be other examples in [configuration]. Would it make > sense to be homogeneous here, i.e. use the same design principles for > all classes?
Yes and the non-static approach is certainly more flexible, so on balance I think you and James are right. Phil > > Oliver > >> Phil >>> For users, it may be more convenient to simply access functionality >>> through static methods, especially if the default values for static >>> member fields are reasonable for most use cases. However, such a design >>> makes it impossible to use the represented functionality with different >>> settings in parallel. >>> >>> Also, I am not sure whether complex class loader scenarios (e.g. an >>> application server or an OSGi container) may cause problems with the >>> static approach. >>> >>> Oliver >>> >>>>> On Sunday, August 25, 2013, Phil Steitz wrote: >>>>> >>>>>> On 8/24/13 11:33 AM, Oliver Heger wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> regarding a principle design question I would like to get your opinion: >>>>>>> >>>>>>> In [configuration] there are a few static utility classes. One of them >>>>>>> is BeanHelper which supports the creation of beans from configuration >>>>>>> data. The actual bean creation is done by a BeanFactory which can be >>>>>>> configured using the static (currently unsynchronized) >>>>>>> setDefaultBeanFactory() method. >>>>>>> >>>>>>> Sebb stated correctly that this approach is thread-hostile [1]. An >>>>>>> alternative could be to make BeanHelper a non-static class which can be >>>>>>> instantiated and configured per instance. This would be more flexible >>>>>>> and would also simplify testing of client code (just pass in a mock >>>>>>> object). The drawback is that clients now always would have to >>>>>>> create an >>>>>>> instance, so the API becomes slightly more verbose - in fact, most >>>>>>> clients will probably never have the requirement to change the default >>>>>>> bean factory. >>>>>>> >>>>>>> So, the question is, what do you prefer? The static approach like >>>>>>> Object myBean = BeanHelper.createBean(...); >>>>>>> >>>>>>> or using an instance as in >>>>>>> BeanHelper helper = new BeanHelper(myFactory); >>>>>>> // or use no-args ctor for default factory >>>>>>> Object myBean = helper.createBean(...); >>>>>> Personally, I would like the static method better as a user. >>>>>> Synchronizing access to the static factory field would seem to fix >>>>>> the problem unless I am missing something. Also, I would not expect >>>>>> lots of concurrent access to the getter/setter for this field in >>>>>> normal use cases , so the performance overhead of the sync would be >>>>>> immaterial. Having the setter there may also be a little easier for >>>>>> dependency injection. >>>>>> >>>>>> Phil >>>>>>> TIA >>>>>>> Oliver >>>>>>> >>>>>>> [1] https://issues.apache.org/jira/browse/CONFIGURATION-486 >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: >>>>>>> dev-unsubscr...@commons.apache.org<javascript:;> >>>>>>> For additional commands, e-mail: >>>>>>> dev-h...@commons.apache.org<javascript:;> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> <javascript:;> >>>>>> For additional commands, e-mail: >>>>>> dev-h...@commons.apache.org<javascript:;> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
