Make conversion framework extensible for non-Java classes [SPR-10887]

[spring-projects-issues]

Stefan Gheorghiu opened SPR-10887 and commented

As of 3.2.4, the architecture of converters and related environment is very Java-centric and as such doesn't allow extending it with support of other JVM-based languages with different class hierarchies, such as Scala. Scala support provided by the Spring Scala project is rather limited and does not cover many use cases and native idiomatic concepts. Particularly, it is not applicable for binding web request data to controller/form parameters declared as Scala classes. This is not about the mismatch of the bean definitions which can be eliminated by annotations, but mostly about binding to Scala collections and monadic classes like Option.

The problem is caused by the fact that the hierarchy of classes descending from org.springframework.core.convert.AbstractDescriptor is designed in a way that much of intermediate information obtained from the type system with reflection is lost and, due to package-level access scope of classes, there is no "legal" way to capture it somewhere so to later use in custom converters.

Nevertheless, I managed to overcome these design flaws with a minimum intervention into descriptor classes. The main idea was to introduce descriptor extensions ‒— classes globally registered in a static collection of the TypeDescriptor class. When a certain descriptor implementation creates the TypeDescriptor instance, extensions get invoked with access to raw reflection data and can store additional data in a new TypeDesctiptor field of type Map<String,Object>. Custom converters that rely on this additional data can later extract it directly from source/target descriptors passed to their method convert().

The mentioned changes allowed me to implement many problematic scenarios like initialization of Option[Option[Int]] from a String by introducing a descriptor extension that digs deeply into type definition using Scala reflection API and stores this data as a custom attribute of TypeDescriptor. The algorithm is implemented lazily and is only executed when some converter demands the appropriate data.

The improvements can be found in the attachment as a diff based on version 3.2.4. So please consider incorporating them into some future version or at least learn my approach and make something more suitable.

Please don’t ignore this request as it can make Spring Framework more open to Scala adepts who might otherwise choose other frameworks which are more friendly to their language of choice.

---

Affects: 3.2.4

Attachments:

• descriptor-extensions.diff (3.74 kB)

Referenced from: commits e80b7d1

[spring-projects-issues]

Stefan Gheorghiu commented

proposed changes

[spring-projects-issues]

Phil Webb commented

Hi Andrei Stefan,

The org.springframework.core.convert.AbstractDescriptor class and subclasses have been removed in Spring 4.0 [1]. We now have a new ResolvableType class which we use instead.

Is there anything that we can change in the new code structure that might help with your use-case?

[1] 57a36f3

[spring-projects-issues]

Stefan Gheorghiu commented

Phil,

I've reviewed shortly the changes and really appreciate your effort, however I'm still not very sure that my problem can be solved within the new architecture.

The Scala type system is much wider than that of Java and thus many features cannot be expressed within the JVM class file format. So, beside usual Java generic type erasure, there's also kind of Scala-to-Java type erasure. In order to overcome these limitations, the Scala compiler embed advanced class definitions into a class annotation @scala.reflect.ScalaSignature which can later be used by the compiler and reflection API. This extra information cannot be extracted from a java.lang.Class instance. This can only be done by having access to low-level descriptors such as org.springframework.core.MethodParameter or java.lang.reflect.Field from implementations of org.springframework.core.convert.converter.GenericConverter. Unless this is possible, the problem will persist. I suppose, if TypeDescriptor.resolvableType were accessible from outside, I'd be able to extract some info from ResolvableType.getType(), however this wouldn't be sufficient as it doesn't cover all the cases like the one with MethodParameter.

So my suggestion would be to make org.springframework.core.MethodParameter and org.springframework.core.convert.Property implement marker interface java.lang.reflect.Type, store their instances in TypeResolver.type and make them accessible via GenericConverter#convert() -> TypeDescriptor#getTypeResolver().getType()

[spring-projects-issues]

Phil Webb commented

/cc Arjen Poutsma from the Spring Scala project.

[spring-projects-issues]

Phil Webb commented

Stefan Gheorghiu,

Would something like this change:

https://github.com/philwebb/spring-framework/compare/SPR-10887

Give you enough access?

You should be able to use getSource() to access the Field MethodParameter or original Class.

[spring-projects-issues]

Stefan Gheorghiu commented

Phil,

It seems this will help, though I cannot guarantee it with 100% accuracy until I re-implement my current approach based on 3.2.4. Just in case, will it be possible to make a similar grade of changes in 4.0.1 or later, in case I'm not able to check the feasibility before the release of 4.0.0?

And thanks a lot for paying attention to my issue.

[spring-projects-issues]

Phil Webb commented

We can certainly make changes for 4.0.1 (as long as they are not too risky). I will merge this one into master before we release RC1 next week.

[spring-projects-issues]

Phil Webb commented

The getSource() methods are now in master. I will close this bug, please reopen a new issue (and reference this one) if you find the new methods are not enough.

[spring-projects-issues]

Stefan Gheorghiu commented

Please find follow-up issues in #15927