| Re: [el-dev] Question: BeanELResolver behavior without java.beans.* |
Paul,
The only difference an end user of EL should notice is that they can use
EL in a JPMS environment without requiring the java.desktop module.
Scenario 1
For the purposes of this scenario, imagine you have a POJO with
non-standard getter/setter names for properties that you are unable to
change for reasons of backwards compatibility. You define a BeanInfo
class for your POJO that defines the properties you want to manipulate
via EL.
In an environment where java.beans.* is available, EL will be able to
work with your POJO using the property names defined in the BeanInfo. If
java.beans.* isn't available this won't work because the BeanInfo
interface isn't available.
The above is true for both EL 6.0 and 5.0. Because the application
depends on the BeanInfo implementation to map properties for the POJO,
the application requires java.beans.* - i.e. the java.desktop module.
Scenario 2
In this scenario the application uses a POJO with standard getter/setter
names.
In an environment where java.beans.* is available, behaviour with EL 6.0
is unchanged from EL 5.0. java.beans.Introspector will be used to
identify the POJO's properties.
However, java.desktop is not a small module. If the application has no
other requirements to use java.desktop then the developer can remove the
java.desktop module from their project (if they are using EL 6.0) and
the application will continue to work in exactly the same way. In this
case, EL's internal introspection will be used to identify getters and
setters for properties.
Summary
The idea is that applications that do not depend directly on
java.beans.* packages are not required to use the java.desktop module in
a JPMS environment.
The standalone implementation doesn't limit functionality, it removes
the need for a (heavy) dependency. The only difference that should be
observable to the user is that they can remove the dependency on the
java.desktop module
Note: I've only talked about properties above but the standalone
implementation supports all JavaBean specification features that do not
require classes and/or interfaces from the java.beans.* package
HTH,
Mark
On 07/08/2024 20:54, Paul Nicolucci wrote:
> Hey Mark,
>
> Thanks for the reply. I don't understand what an end user of the
> _expression_ Language would miss out on when using BeanSupportStandalone
> <https://github.com/jakartaee/_expression_-language/blob/master/api/src/main/java/jakarta/el/BeanSupportStandalone.java>.
>
> Could you provide an example?
>
> Or will the end user not notice any difference in behavior and the
> _expression_ Language is just providing two different implementations, one
> using java.beans and the other not?
>
> Thanks,
>
> Paul Nicolucci
>
> On Tue, Aug 6, 2024 at 2:32 PM Mark Thomas via el-dev
> <el-dev@xxxxxxxxxxx <mailto:el-dev@xxxxxxxxxxx>> wrote:
>
> On 06/08/2024 15:08, Paul Nicolucci via el-dev wrote:
> > Hi,
> >
> > The _expression_ Language 6.0 BeanELResolver
> >
> <https://jakarta.ee/specifications/_expression_-language/6.0/apidocs/jakarta.el/jakarta/el/beanelresolver <https://jakarta.ee/specifications/_expression_-language/6.0/apidocs/jakarta.el/jakarta/el/beanelresolver>>states the following:
> >
> > If the |java.beans.*| package is available (part of the
> > |java.desktop| module) the JavaBeans implementation provided
> by the
> > JRE is used. If the |java.beans.*| package is not available, a
> > built-in stand-alone implementation is used that just provides
> > getter/setter support (as everything else requires classes from
> > |java.beans.*|).
> >
> >
> > I'm not clear on what support is unavailable when the j/ava.desktop/
> > module is not available. Can anyone clarify? If getter and setter
> > support is available what specifically is missing?
>
> Anything that directly depends on classes/interfaces in java.beans.*
>
> For example:
> - BeanInfo
> - property editors
>
> > Would the TCK pass with the "built-in stand-alone implementation"
> that
> > only "provides getter/setter support"?
>
> Purely based on a search of the current EL TCK code for "java.beans" I
> believe it would.
>
> You can force the EL API to use the stand-alone implementation by
> setting jakarta.el.BeanSupport.useStandalone=true
>
> Note this is NOT part of the public API - it is only intended for unit
> testing so it may change at any point.
>
> Mark
> _______________________________________________
> el-dev mailing list
> el-dev@xxxxxxxxxxx <mailto:el-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/el-dev
> <https://www.eclipse.org/mailman/listinfo/el-dev>
>