proposing the depreciation of java.beans.beancontext.*

[Laurence Cable]

Hi Phillip, inline ...

On 9/21/23 4:16 PM, Philip Race wrote:
> 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

I mean the latter - eventual removal, return some bytes for better usage 
since its my opinion beancontext is long past being obsolete... its 
pretty much only of historical/archeological interest at this point in 
time! :)

>
> (1) Is any actively supported software still using this ?

I intend to perform some corpus searches to determine this (to the 
degree possible)

> (2) How hard would it be for them to migrate to something else ? And 
> how reasonable is it to expect them to do so?

I would anticipate that any code written after the onset of Spring, 
Guice etc would have already abandoned beancontext!

> (3) What's the ripple effect in the JDK ? Does it impact the 
> java.beans package too in some ways ?

AFIAK/recall the beancontext and beans pkgs are effectively independent 
of each other ... at least in the dependency 'direction' of beans -> 
beancontext.

I do not recall any other packages (e.g awt) using it, but a search of 
the JDK will confirm this.

beancontext did not really gain any significant adoption that I was 
aware of, once DI/IoT became the de facto model for component/bean 
assembly with Spring and that percolated down into SE from EE,
along with OSGi (which also had overlap in the area of service/interface 
brokerage)

Rgds

- Larry

>
> -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
>