Skip to content

SpEL no longer supports lists for varargs invocations #33315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sbrannen opened this issue Aug 4, 2024 · 3 comments
Closed

SpEL no longer supports lists for varargs invocations #33315

sbrannen opened this issue Aug 4, 2024 · 3 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: regression A bug that is also a regression
Milestone

Comments

@sbrannen
Copy link
Member

sbrannen commented Aug 4, 2024

The changes made in conjunction with #33013 resulted in a regression for varargs support in SpEL expressions.

Specifically, before #33013 one could supply an inline list as the varargs array when invoking a varargs constructor, method, or function within a SpEL expression. However, after #33013 an inline list (or collection in general) is no longer converted to an array for varargs invocations. Instead, the list is supplied as a single argument of the resulting varargs array.

See #33013 (comment) and subsequent comments for details.

Although it was never intended that one could supply an inline list as the set of varargs, we concede that this is a regression in existing behavior and will therefore restore this support. However, we do not intend to restore support for converting arbitrary single objects to an array for varargs invocations if the single object is already an instance of the varargs array's component type. In other words, we only intend to restore support for converting a single inline list to a varargs array.

@sbrannen sbrannen added type: regression A bug that is also a regression in: core Issues in core modules (aop, beans, core, context, expression) labels Aug 4, 2024
@sbrannen sbrannen added this to the 6.1.12 milestone Aug 4, 2024
@sbrannen sbrannen self-assigned this Aug 4, 2024
@sbrannen sbrannen changed the title SpEL no longer supports inline list for varargs invocations SpEL no longer supports lists for varargs invocations Aug 5, 2024
@sbrannen
Copy link
Member Author

sbrannen commented Aug 5, 2024

After further analysis, it would be possible to limit "list to array conversion" to InlineList for FunctionReference but not for ConstructorExecutor and MethodExecutor, since the latter are generic APIs that do not have access to the child SpelNode.

In light of that, I am repurposing this issue to convert any java.util.List to an array for the purpose of varargs invocations in SpEL.

In addition, I will apply this not only to method and constructor invocations but also to MethodHandle-based function invocations.

In other words, we now intend to restore support for converting a single java.util.List to a varargs array for reflection-based method and constructor invocations and introduce that same support for MethodHandle-based function invocations.

@weiw005
Copy link

weiw005 commented Aug 6, 2024

@sbrannen Thanks for all the communication!

Is it possible to update the documentation (https://docs.spring.io) and call out the nuances, and more importantly for us users to understand the expected behavior that we can safely rely on?

@sbrannen
Copy link
Member Author

sbrannen commented Aug 6, 2024

Hi @weiw005,

Thanks for all the communication!

You're welcome.

Is it possible to update the documentation (docs.spring.io) and call out the nuances, and more importantly for us users to understand the expected behavior that we can safely rely on?

I don't believe we actually document varargs support at all in SpEL.

So, yes, we can document that. I created #33332 to address that in 6.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: regression A bug that is also a regression
Projects
None yet
Development

No branches or pull requests

2 participants