jsonb-api
jsonb-api copied to clipboard
jakartaee
Add support for Java Record
Currently Records need to have specific names for the attributes before they are picked up.
public record Person (String name, Integer age)
results in an empty JSON construct due to the rules around what properties are picked up.
You can workaround the issue by defining
public record Person (String getName, Integer getAge)
The specification could be improved by adding a section that describes how Record attributes are treated.
This all depends on the Java SE versions that are supported by the spec.
+1, it is already supported by Apache Johnzon and even if JSON-B only targets Java 8/11, we can mention how records would be handled (constructor with most parameters and accessor methods for ex).
most annotations can now be put on parameter (so inline record constructor) and jsonbcreators don't fail when null is passed so looks like records are supported if we relax the getter naming for serialization for this type of class.
I would love to see records support in JSON-B that just works out-of-the-box (i. e. without any tricks). This includes not only serialization (= uses non-getter-syntax for accessor methods), but also for deserialization (= uses constructor to inject values). I assume this is what most users of records would expect from JSON-B.
Are there any actual plans to mandate that in the spec?
Yes. When Jakarta Platform officially supports Java 14 where records were introduced.
So we all should vote for a JRE 14+ minimum level for EE 11 at the Jakarta EE Steering Committee.
So it means java 17 and it would probably be bad for JakartaEE since 1 or 2 more versions will need to keep Java 11 compatibility. @m0mus what does prevent to define record compatibility as an extension of the spec (often done as appendix in spec)? Behavior is quite straight forward to define and saying it is only supported if java version supports records is more than fine for impls as shown by the current implementations IMHO and it would enable users to use it before the spec baseline upgrades to java 17. Is it an option?
@mkarg Yes, I think we should move Jakarta 11 to Java 17+. I very much doubt that it can be released before next September, so Java 21 is also an option. @rmannibucau Yes, it's another option. I would go this way if Jakarta 11 won't adopt Java 14+.
Another interesting aspect would be, how to place annotations to modify property names for serialization...? An idea could be to re-interpret the annotations found at the constructor's arguments, hence use those not just for deserialization but also for serialization.
It is what was done at johnzon. Indeed ypu could use setters for deserialization too - note it is not only property name but adapter/deserializer, format, ... too - but it is not convenient at all so constructor params is the best option IMHO.
It seems that Yasson supports records already, though I have not tested it yet. https://github.com/eclipse-ee4j/yasson/issues/495 https://github.com/eclipse-ee4j/yasson/pull/499 https://github.com/eclipse-ee4j/yasson/issues/528
Link looks like a partial not ootb support, if true can be better to not need a custom visibility strat. Anyway records model is as defined as pojo ones so look straight forward and since all impl support it, it is just a matter of doing the pr, there is no issue in the spec to support a more recent version of java while baseline is still there.