Hi Larry,
Deprecation happens either because there is a preferred replacement or
because something
is dangerous or obsolete. This is a slightly blurred case, since it
seems to be obsoleted by
a preferred pattern that doesn't involve a JDK replacement API.
I guess the first question I have is do you mean just "deprecate" and
provide pointers, or
do you mean "deprecate for removal". The latter needs more
consideration, like
(1) Is any actively supported software still using this ?
(2) How hard would it be for them to migrate to something else ? And how
reasonable is it to expect them to do so?
(3) What's the ripple effect in the JDK ? Does it impact the java.beans
package too in some ways ?
-phil.
On 9/20/23 5:18 PM, Laurence Cable wrote:
The BeanContext.* package was added (by me) quite early in the
lifetime of java beans (1.2); based loosely on some of the concepts of
the opendoc component framework,
it was intended to provide a "container" for JavaBeans components to
collaborate with each other by exposing both their presence (within a
context)
and to provide/consume 'services' expressed as interfaces.
(we even demoed this functionality in the "beanbox" for those that
recall that)
This package pre-dated the invention/discovery of Inversion of Control
and (annotation based) Dependency Injection by a good number of years;
and as those latter design patterns
and their implementations became popular, Bean Context did not evolve,
and I would argue, became rapidly irrelevant if not actually an
anti-pattern!
Now some 25 yrs later, it is probably beyond definition as an
anachronism and long overdue to be depreciated from the JDK.
Therefore I would like to propose doing so, and open the discussion
regarding this here.
Regards
- Larry
