AbstractMappingContext not compatible with JDK 17 anymore and violates open JDK security policy.

[amidukr]

The latest Java guideline mandates that the library should not use the reflection of setAccessible(true) on java., sun., com.sun.* package and this is what is done by AbstractMappingContext, which violates security guidelines and makes Spring Data legacy framework not compatible with JDK 17 anymore.

You can see more about that on the official java page.
https://docs.oracle.com/en/java/javase/17/migrate/migrating-jdk-8-later-jdk-releases.html#GUID-12F945EB-71D6-46AF-8C3D-D354FD0B1781

Any chance that Spring Data become compatible with a later version of JDK starting with JDK 9 and so?

[mp911de]

This is a duplicate of #2844.

Spring Data 2.x is compatible with newer Java runtimes. Spring Data 3.x uses Java 17 as baseline. Please note that Spring Data doesn't distinguish between encapsulated and open types. If you choose to use a non-simple type that is encapsulated (e.g. java.time, BigInteger, BigDecimal, any type from your module path) then Spring Data continues to inspect constructors because in the end, the type needs to be constructed somehow.

Alternatively, you must provide a Converter that allows construction for Spring Data.

If you feel there's more we can do, then let us know about the details.

[amidukr]

@mp911de Hi Mark, thank you for your reply.

If there is a way for me to write a custom Converter to overcome this issue, I would appreciate using it. I've tried following code snippet, didn't helped:

@Bean fun bigIntegerToStringConvertor() = BigIntegerToStringConvertor
@Bean fun stringToBigIntegerConvertor() = 

object BigIntegerToStringConvertor: Converter<BigInteger, String> {...}

Is that Converter that you suggesting, is needed for JPA or noSQL? What I see issue is happening with Spring Data support for noSQL like MongoDB, CosmosDB.

• I am currently working with CosmosDB data module which is supported by the Microsoft team, for bean construction they use mainly Jackson mapper which can convert string values into POJO. They use AbstractMappingContext to scrabble annotation from pojo, quite possible that @ID can be embedded somewhere in the nested field-object.
• Regarding MongoDB, that is supported by you guys, not sure if MongoDB is using Jackson mapper approach, I've tried to dig into the code, but didn't figure out. However, I see people complain on Stackoverflow about the same issue with MongoDB.

[mp911de]

Converters aren't beans, converters need to be registered through CustomConversions with the Spring Data module this converter applies to.

Spring Data MongoDB has its own MappingMongoConverter that isn't based on Jackson but rather we apply conversions and mapping on our own. Jackson isn't flexible enough to apply conversion rules for Query and Update objects for partial updates. Also, it is very easy to configure something in Jackson that doesn't then work for the Spring Data infrastructure.