Hi, as the following error describes, java records (preview feature) deserialization isn't working in gson, Jackson is adding support in its very soon release 2.12, is there going to be same support/fix in gson ?
java.lang.AssertionError: AssertionError (GSON 2.8.6): java.lang.IllegalAccessException: Can not set final java.lang.String field JsonGsonRecordTest$Emp.name to java.lang.String
Here's a sample test
record Emp(String name) {}
@Test
void deserializeEngineer() {
Gson j = new GsonBuilder().setPrettyPrinting().create();
var empJson = """
{
"name": "bob"
}""";
var empObj = j.fromJson(empJson, Emp.class);
}
The problem seems to exist only in Java 15 with preview enabled. Running your test under Java 14 with preview enabled and printing the empObj gives Emp[name=bob].
JDKs used,
This is due to changes in Java 15 that makes final fields in records notmodifiable via reflection. More information can be found here:
The relevant part on handling them going forward:
This change impacts 3rd-party frameworks including 3rd-party
serialization framework that rely on core reflectionsetAccessibleor
sun.misc.Unsafe::allocateInstanceandobjectFieldOffsetetc to
construct records but not using the canonical constructor.
These frameworks would need to be updated to construct records via its
canonical constructor as done by the Java serialization.
I see this change gives a good opportunity to engage the maintainers of
the serialization frameworks and work together to support new features
including records, inline classes and the new serialization mechanism
and which I think it is worth the investment.
A current workaround is to write a Deserializers that uses the records constructor instead of reflection.
Most helpful comment
The problem seems to exist only in Java 15 with preview enabled. Running your test under Java 14 with preview enabled and printing the
empObjgivesEmp[name=bob].JDKs used,
This is due to changes in Java 15 that makes final fields in records notmodifiable via reflection. More information can be found here:
The relevant part on handling them going forward:
A current workaround is to write a Deserializers that uses the records constructor instead of reflection.