Support for Javaslang's Option as return type of query methods [DATACMNS-937]

[spring-projects-issues]

Darek Kaczynski opened DATACMNS-937 and commented

Spring Data JPA supports JDK 8 and Guava Optional as well as Scala Option so far. Support for JavaSlang Option would be welcome as well.

The issue with JavaSlang is that javaslang.control.Option is an interface, not a class as in all other supported libraries. This in conjunction with compiler source level set to 1.6 rises a problem of calling a static method on an interface that is not supported until Java 1.8. Therefore one cannot simply add support for JavaSlang following the pattern in QueryExecutionConverters, as the compiler will not allow it.

Also current implementation of QueryExecutionConverters is completely closed to extensions. Everything is static and private. Although it's nice Spring Data supports some wrappers out of the box, it'd be even nicer if it allowed adding custom ones in runtime. It'd not be hard to implement using i.e. ServiceLoader.

I created example implementation here: #184

---

Referenced from: pull request #184

Backported to: 1.13 RC1 (Ingalls)

[spring-projects-issues]

Oliver Drotbohm commented

Thanks Derek. I am wondering whether we could create the Option instance via reflection to avoid the rather radical change proposed. I am not even saying, we should eventually end up making that particular path of the codebase for easier extension, I'd just like to decouple that from the JavaSlang support

[spring-projects-issues]

David Welch commented

+1 for opening to extension. We've got a (currently internal) SD implementation that utilizes raw SQL + JDBC. It works great, but getting around the issue of custom "bean" return types on query methods is pretty nasty. It'd be ideal to tap into some facade to determine how to return the object from the actual repository implementation.

Haven't checked out the PR yet but very interested to see it.

[spring-projects-issues]

Oliver Drotbohm commented

David Welch — Would you mind creating a separate ticket for that then? We're only going to introduce support for JavaSlang Option here. What I don't quite understand is why you don't just handle that stuff in your Spring Data implementation then as you actually could do that in contrast to the original poster.

Note that the conversion mechanism hasn't been made publicly configurable as there are other parts of the Spring Data world that need to unwrap those wrappers again (e.g. Spring Data REST) and handing a configurable instance of whatever this new API might look like through all the different parts of the system was quite cumbersome. So I can't guarantee that we're ever going to make this happen if it introduces too much complexity. Complexity that might not be obvious from only the changes in Spring Data Commons.

That said, I have a working prototype for JavaSlang integration here that works based on the current model. Needs some polishing though but will be ready for Ingalls RC1 (due late November)

[spring-projects-issues]

Oliver Drotbohm commented

That's in place now. Feel free to give the snapshots a spin