Add support for Java Record

[rdebusscher]

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.

[rdebusscher]

This all depends on the Java SE versions that are supported by the spec.

[rmannibucau]

+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).

[rmannibucau]

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.

[mkarg]

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?

[m0mus]

Yes. When Jakarta Platform officially supports Java 14 where records were introduced.

[mkarg]

So we all should vote for a JRE 14+ minimum level for EE 11 at the Jakarta EE Steering Committee.

[rmannibucau]

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?

[m0mus]

@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+.

[mkarg]

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.

[rmannibucau]

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.

[nlisker]

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

[rmannibucau]

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.

[mkarg]

What is the current status of this issue?

[mkarg]

Again: What is the current status of this issue?

[greek1979]

Same question and worry here... Java 21 LTS is out already, Java 22 and Java 23 are out, and records are full-time citizens of Java world. They are not going anywhere anytime soon.

[mkarg]

@ivargrimstad I really do wonder why neither @rmannibucau nor @m0mus do react upon this really urging question, re-triggered twice within the past years (plural!). Is JSON-B considered dead or are records simply of no interest for anybody or are we, the community, simply not worth getting answered? 🤔 Ivar, you are very well connected among vendors, could you please privately ask the JSON-B vendors for a reply in the name of the EF? Thanks! 👍

[rmannibucau]

@mkarg or the other "or" ;): it is supported by all vendors and there is no activity in EE yet so not something blocking anyone nor really fixable short term I'd say from my window.

[jungm]

Sure not fixable short term, but is there actually anything blocking a 3.1 spec that is basically 3.0 and defines how records are handled on Java 14+ while keeping the baseline on 11 (or maybe even raise it to 17)? There's 100+ open issues, I'm confident there's other improvements as well that could be put in a new spec release

Right now users that want to use records can't rely on the spec and instead have to trust vendors to do the right thing. Even if vendors implement this already it would be beneficial for users to specify the intended behavior

[rmannibucau]

is there actually anything blocking a 3.1 spec that is basically 3.0 and defines how records are handled

from my experience a new EE release coming, it is rare sub-specs release without it (guess the whole thing must stay consistent and not become a freeze at a time + people time is allocated relatively to that)

hope it changes a bit but seems EF made it worse than it was before for now so no big hopes from my side for now (hoping to be wrong)

[mkarg]

@rmannibucau Thank you for picking up the thread! 👍

So actually it was Jakarta EE which hold everybody back from reacting to this thread? REALLY?! 😉

IIUC understand that the sole blocker is the Java 11 baseline of Jakarta EE? So the solution would be trivial: Make the json-b-api a multirelease JAR and write in the spec how records works like when executing on JRE 16+. Nobody is holding back the JSON-B team from doing that and publishing it ASAP as JSON-B 3.1 -- nobody is forced to wait for Jakarta EE mandating JRE 17 and there is not rule at all forbidding minor releases between Jakarta EE releases! 😏

[jungm]

Is there even a need to touch the API? Think it should be enough just to add a chapter to the spec itself on how records should be handled

I think what generally has been holding this back for literal years now is how little to no time is dedicated towards the JSON-B spec from the ones that are actually involved, which is sadly pretty obvious IMO and probably won't change short term

[rmannibucau]

IIUC understand that the sole blocker is the Java 11 baseline of Jakarta EE?

AFAIK this can't be it since several spec already integrated with java > baseline so it is really a matter of having people planning a new release or not IMHO.

Make the json-b-api a multirelease JAR and write in the spec how records works like when executing on JRE 16+

No idea how you see this as a trivial solution yet, from a spec perspective updating the doc is sufficient so no reason to do a multirelease jar IMHO.

Nobody is holding back the JSON-B team from doing that and publishing it ASAP as JSON-B 3.1

While it is the theory it wasn't proven right in much spec (actually it is wrong for most spec). Nothing related to java once again but to the EE "train" - once again from my window and understanding.

[njr-11]

Jakarta EE 11 (current release that is nearing completion) requires support for Java SE 21 and Java SE 17, and not Java SE 11. Throughout the development cycle of Jakarta EE 11, specifications were encouraged to take advantage of newer Java features, including Java records. It is correct that JSON-B has missed the EE release train as you said for Jakarta EE 11. However, Jakarta EE specifications are encouraged to release new versions whenever they consider it appropriate to do so. The release train only determines when a specification gets brought into an overall Jakarta EE platform release, not whether/when specifications can release new versions. They have very recently started discussing and planning for Jakarta EE 12, and it would make sense for a new release of JSON-B to be brought into that if the community wants to pursue releasing a new version to add features like this. There should be nothing blocking this on the Jakarta EE side.

[m-reza-rahman]

I do think developers will expect to use Records as DTOs with JSON (granted it’s too late for Jakarta EE 11, but this specification could do a standalone point release; there is plenty of precedent for that).

[njr-11]

Was it by simply having optional sections in the TCK that aren’t run in case of Java SE 11?

This question wasn't directed to me, but it has incorrect assumptions in it. With only the Java SE 17 and Java SE 21 levels supported (for EE 11) there is no expectation or requirement for the TCK to build or run against Java SE 11. In other specs, we switched the TCK's build level to Java SE 17 (as well as the specification's) and wrote tests that rely on Java records. No part of the TCK is made optional. A TCK for a spec that supports Java SE 17+ should never be attempted on Java SE 11 because it is no longer a supported level.

[rmannibucau]

@nrj-11 to answer on

The release train only determines when a specification gets brought into an overall Jakarta EE platform release, not whether/when specifications can release new versions.

Think the point was not this one but human power and priorities. Everyone agreed on the feature - even implemented it - so it is just a matter of finding somebody who wants to take time to do "eclipse paperworks" IMHO.

[njr-11]

Think the point was not this one but human power and priorities. Everyone agreed on the feature - even implemented it - so it is just a matter of finding somebody who wants to take time to do "eclipse paperworks" IMHO.

Yes, that's fine. That sort of thing happens all the time and it's typical for other specifications that I've worked as well on that there are more good ideas than development resource to implement them all. I was only clearing up what appeared to be confusion over Jakarta EE requirements.

[mkarg]

Think the point was not this one but human power and priorities. Everyone agreed on the feature - even implemented it - so it is just a matter of finding somebody who wants to take time to do "eclipse paperworks" IMHO.

@m0mus @njr-11 Kindly asking for performing a minor release ASAP, so people can use this existing feature. Thanks!

@ivargrimstad As the projects leads are overwhelmed with the paperworks, could the EF chime in here as a proxy?

[mkarg]

@njr-11 If paperworks is a frequent problem here, I can offer myself as a stand-in manager. I would be happy to help. I managed the first few releases of JAX-RS, so I know what it's about. The side effect would be that the members need to vote for me as a committer. WDYT?

[m0mus]

@mkarg I am on vacation until Sep 5th. I'll take a look on it when I get back. We can plan it for Jakarta 12.

[mkarg]

@mkarg I am on vacation until Sep 5th. I'll take a look on it when I get back. We can plan it for Jakarta 12.

@m0mus Thank you for considering a release. What is the reason for waiting for Jakarta 12? The release could be done before already.

[ivargrimstad]

@mkarg I am on vacation until Sep 5th. I'll take a look on it when I get back. We can plan it for Jakarta 12.

@m0mus Thank you for considering a release. What is the reason for waiting for Jakarta 12? The release could be done before already.

Yes @mkarg, you're right. The release can be done at any time. The Platform project will pick it up for the next Platform release.

[njr-11]

@njr-11 If paperworks is a frequent problem here, I can offer myself as a stand-in manager. I would be happy to help. I managed the first few releases of JAX-RS, so I know what it's about. The side effect would be that the members need to vote for me as a committer. WDYT?

I wouldn't say that paperwork/process was specifically the problem, but more so a general lack of resource across all the areas of designing, writing, implementing, testing, as well as paperwork/process, and developers are stretched thin across lots of Jakarta specs. If you are interested in helping with the process and paperwork, it could help to free up others to contribute in the other areas, so I'd be all for it. It would be nice to have more committers. I know other specs I've worked on in the past have had committers other than the spec lead do a lot of the release process for the spec, so there's definitely a precedent for it.

[mkarg]

Feel free to nominate myself. I would be happy to help.

[ivargrimstad]

@njr-11 If paperworks is a frequent problem here, I can offer myself as a stand-in manager. I would be happy to help. I managed the first few releases of JAX-RS, so I know what it's about. The side effect would be that the members need to vote for me as a committer. WDYT?

I wouldn't say that paperwork/process was specifically the problem, but more so a general lack of resource across all the areas of designing, writing, implementing, testing, as well as paperwork/process, and developers are stretched thin across lots of Jakarta specs. If you are interested in helping with the process and paperwork, it could help to free up others to contribute in the other areas, so I'd be all for it. It would be nice to have more committers. I know other specs I've worked on in the past have had committers other than the spec lead do a lot of the release process for the spec, so there's definitely a precedent for it.

That is an excellent point @njr-11. All committers on a project have the same access to the resources needed for a release, so the practical work can be carried out by any of them.

[njr-11]

Feel free to nominate myself. I would be happy to help.

Let's look into that when Dmitry returns (Sept 5th), because we'll want to ensure his vote is included.