Hi, While I'm still getting familiar with things here, I'd like to share my thoughts on this issue. In my view, version 2.0 typically signifies a break in backward compatibility, which makes the second solution—changing the supertype's behavior—acceptable. Given the existence of BeanUtilsBean2 and ConvertUtilsBean2, it seems the plan was to modify the behavior in the next major release (2.0).
My question is whether we intend to support the "old" behavior in any capacity. If so, I believe an alternative solution is necessary, rather than relying on the first solution, which involves overriding methods in a subclass. This approach might violate the SOLID principles, specifically the Liskov Substitution Principle, by altering behavior in a subclass. Regards, David Gary Gregory <garydgreg...@gmail.com> ezt írta (időpont: 2024. aug. 31., Szo, 20:09): > Hi All, > > I want us to decide what we want for 2.0 with the classes > BeanUtilsBean2 vs BeanUtilsBean, and ConvertUtilsBean2 vs > ConvertUtilsBean. > > For your convenience: > - > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean2.java > - > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean.java > - > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean2.java > - > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean.java > > I plan on doing a 2.0.0-M1 release in mid-September if we can resolve > this and put the new package out in the wild. > > Possible solutions: > > 1) Do nothing, keep both classes and explain when to use one vs. the other > 2) The "simplest" change is to pull up the "2" classes's method into > their respective supertype and adjust the tests to make the "2" > behavior the _only_ behavior > > What needs addressing no matter what IMO is to remove the global > variable BeanUtilsBean.BEANS_BY_CLASSLOADER. Even with class loader > independence, you can still have multiple libraries and your app > competing for setting and using the default. > > Thoughts? > > Gary > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
