Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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>

Back to the top