proposing the depreciation of java.beans.beancontext.*

Philip Race philip.race at oracle.com
Thu Sep 21 23:16:35 UTC 2023


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



More information about the client-libs-dev mailing list