Spring-framework: Proposal for IN operator in SpEL

[davidjgoss]

Affects: current/all

---

Currently SpEL does not have an IN operator. If you want to test whether a value is contained in a collection, you can do things like:

thingies.contains("foo")
// or, for literals
{"foo", "bar", "baz"}.contains("foo")

Use case

A tool with a target audience of non-technical users who nonetheless are familiar with SQL and similar query syntax.

Proposal

"foo" IN thingies
// or, for literals
"foo" IN {"foo", "bar", "baz"}

This would add support for an IN operator that (roughly) would resolve to true if the right-hand operand is an Iterable and has an element that passes equals with the left-hand operand.

Notice I'm not proposing to change how list literals are done or anything; the intention is this would not be a breaking change.

Prior art

SpEL already has a few things like this that provide a more relatable syntax instead of Java methods and operators, e.g:

foo AND bar
// effectively same as
foo && bar

foo == bar
// effectively same as
foo.equals(bar)

There was an issue #12500 that was closed due to years of inactivity. At this point I'd be pleased to just do the pull request but want to first gauge whether it would be desirable from the project's point of view.

[sbrannen]

@aclement, what do you think about introducing an IN operator?

[aclement]

Back when originally created, SpEL was based on the Spring .net expression language. You can see here https://www.springframework.net/doc-latest/reference/html/expressions.html that the .net version has in, like, between, is and matches. The java version had those originally but we removed them to simplify it when finally integrating it into the framework. I feel like it is something we would add back in if there were stronger demand but that issue from 2010 didn't seem to collect any interest.

Taking into account the workaround of using contains (although I recognize it may not be as familiar to some) and that ideally you'd need to not only implement the parsing and interpretation but also the compilation support (otherwise it would always be a second class citizen with contains being the more optimal way) which adds up to a not insignificant amount of work, it doesn't feel worth it right now (IMHO).

[davidjgoss]

@aclement thanks for the response and background.

Would it be fair to say then that you’d be open to seeing a PR for this (done right) but just not something the core team would take on?

[aclement]

I think we'd absolutely be open and supportive for a PR if there was demand. I think without the demand it is just going to add code that needs maintaining that we don't know if anyone wants or uses. If this issue received lots of votes/comments/interest, that would be a key indicator for me that we need to do it.