On Sat, 31 Aug 2024 at 20:45, Dávid Szigecsán <sige...@gmail.com> wrote:
> 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).
>
The only reason the 2nd beans were added was to preserve compatibility at
the time
https://issues.apache.org/jira/browse/BEANUTILS-285
Original JIRA:
https://issues.apache.org/jira/browse/BEANUTILS-258
> 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.
>
No, we should IMO remove it - there were only downsides in the old
behaviour that limited users. The new behaviour allowed the users to
configure whatever they want. A user could register converters which
reproduce the old behaviour if they wanted.
IMO we should definitely go with Gary's second option:
"pull up the "2" classes's method into their respective supertype and
adjust the tests to make the "2" behavior the _only_ behavior"
Niall
>
> 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
> >
> >
>
