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

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

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> 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>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
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/el-dev

Back to the top