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
