proposing the depreciation of java.beans.beancontext.*

[Philip Race]

Larry,

I submitted https://bugs.openjdk.org/browse/JDK-8321428.
I've assigned it to you, on the assumption you are interested.
Obviously no particular urgency around this.

-phil.

On 9/21/23 4:48 PM, Laurence Cable wrote:
> 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
>>
>