Java record

[e.d.pro...@gmail.com]

I just saw they added a new thing called record to Java 16. Is this not a replacement for a DTO or am I missing something?
I create a DTO class like:
public class TestDTO {
private String testField;
public String getTestField() {
return this.testField;
}
public void setTestField(String test) {
this.testField = test;
}
}

I define a matching record definition like:
public record TestRecordDTO(String testField) {

}

Now I try to test them:
public static void main(String[] args) {
TestRecordDTO rec = new TestRecordDTO("testrec");

TestDTO dto = new TestDTO();
dto.setTestField("testrec");

Gson gson = new Gson();
System.out.println(gson.toJson(rec)); // {"testField":"testrec"}
System.out.println(gson.toJson(dto)); // {"testField":"testrec"}
rec.testField();
dto.getTestField();

dto = gson.fromJson(gson.toJson(dto), TestDTO.class);
System.out.println(dto.getTestField()); // testrec
rec = gson.fromJson(gson.toJson(rec), TestRecordDTO.class); // throws AssertionError
System.out.println(rec);
}

In web, we use DTOs on the back end to pass data to and from the Javascript/Typescript on the front end. It looks like passing to the front end works, now how do we use it as a model to get the user input?

[Arne Vajhøj]

On 3/1/2023 2:18 PM, e.d.pro...@gmail.com wrote:
> I just saw they added a new thing called record to Java 16. Is this not a replacement for a DTO or am I missing something?
> I create a DTO class like:
> public class TestDTO {
> private String testField;
> public String getTestField() {
> return this.testField;
> }
> public void setTestField(String test) {
> this.testField = test;
> }
> }
>
> I define a matching record definition like:
> public record TestRecordDTO(String testField) {
>
> }

> In web, we use DTOs on the back end to pass data to and from the
> Javascript/Typescript on the front end. It looks like passing to the
> front end works, now how do we use it as a model to get the user
> input?

Records are just a way to create data classes
with less typing.

You can use them just like the equivalent manually created
data classes.

But there are two caveats:
1) they are immutable (only getter, no setter)
2) the getter does not follow Java bean convention - it is
.xxxx() not .getXxxx()

That may work or may not work with what you need from
your model classes.

Arne

[e.d.pro...@gmail.com]

> You can use them just like the equivalent manually created
> data classes.
>
> But there are two caveats:
> 1) they are immutable (only getter, no setter)
> 2) the getter does not follow Java bean convention - it is
> .xxxx() not .getXxxx()
>
> That may work or may not work with what you need from
> your model classes.
>
> Arne

Yeah, I thought they were trying to make an easier way to do the same thing, I demonstrated the Gson method recognizes them the same for converting to JSON, but it can't send it back, so it can't replace beans for getting web user input unless I'm missing something. It's supposed to be less work but it'll be more work if you have to manually build constructor calls.

[Daniele Futtorovic]

Note: if you do get an exception, you should at least state its message
in your post.

According to the changelog, support for Java records has been added to
Gson in version 2.10:
<https://github.com/google/gson/releases?q=2.10&expanded=true>. Switch
to that and you should be good to go.

--
DF.

[e.d.pro...@gmail.com]

> > In web, we use DTOs on the back end to pass data to and from the Javascript/Typescript on the front end. It looks like passing to the front end works, now how do we use it as a model to get the user input?
> Note: if you do get an exception, you should at least state its message
> in your post.
>
> According to the changelog, support for Java records has been added to
> Gson in version 2.10:
> <https://github.com/google/gson/releases?q=2.10&expanded=true>. Switch
> to that and you should be good to go.
>
> --
> DF.

Aha! So my sample code does work. I hadn't updated my dependencies in a while on my test project. I need to finish that pom and add a site report with the dependency-updates plugin.
I was referencing gson 2.8.6. I switched to 2.10.1 and it solved that error. Now, if we can switch to Java 17 (15+), we use record for all DTOs? This is much more efficient and/or secure than using classes with lombok?

All fields in a record are final, so it can only have the one constructor with parameters for every field? This sounds tedious to instantiate on the back end unless you're using a framework or convenience method that's going to populate, from a ResultSet? Front end data is simple if you can instantiate from JSON using gson. Requiring all values final on instantiation will require a very different DTO structure than the legacy apps I've seen.

[Daniele Futtorovic]

On 08/03/2023 21:14, e.d.pro...@gmail.com wrote:
>>> In web, we use DTOs on the back end to pass data to and from the Javascript/Typescript on the front end. It looks like passing to the front end works, now how do we use it as a model to get the user input?
>> Note: if you do get an exception, you should at least state its message
>> in your post.
>>
>> According to the changelog, support for Java records has been added to
>> Gson in version 2.10:
>> <https://github.com/google/gson/releases?q=2.10&expanded=true>. Switch
>> to that and you should be good to go.
>

> Aha! So my sample code does work. I hadn't updated my dependencies in a while on my test project. I need to finish that pom and add a site report with the dependency-updates plugin.
> I was referencing gson 2.8.6. I switched to 2.10.1 and it solved that error. Now, if we can switch to Java 17 (15+), we use record for all DTOs? This is much more efficient and/or secure than using classes with lombok?
>
> All fields in a record are final, so it can only have the one constructor with parameters for every field? This sounds tedious to instantiate on the back end unless you're using a framework or convenience method that's going to populate, from a ResultSet? Front end data is simple if you can instantiate from JSON using gson. Requiring all values final on instantiation will require a very different DTO structure than the legacy apps I've seen.

I doubt it's going to be much different than Lombok in terms of
performance or reliability. The only difference I can see is in terms of
clarity of intent. If you start your class with `record`, then you make
clear for all to see what you intend the class for. The heuristic value
of that is non-zero.

I haven't had the chance to use records in production yet, so I can but
mostly speculate. A quick lookup however suggests that you can use
Lombok's @Builder on `record` classes.

--
DF.

[e.d.pro...@gmail.com]

> I doubt it's going to be much different than Lombok in terms of
> performance or reliability. The only difference I can see is in terms of
> clarity of intent. If you start your class with `record`, then you make
> clear for all to see what you intend the class for. The heuristic value
> of that is non-zero.
>
> I haven't had the chance to use records in production yet, so I can but
> mostly speculate. A quick lookup however suggests that you can use
> Lombok's @Builder on `record` classes.
>
> --
> DF.

So this is one new feature I think I should try. My current production project is on Java 8, we're moving at the speed of government, but I've asked them to consider 17. For security we should all need at least 11 soon as more dependencies are requiring 11 if not 17. Outdated dependencies tend to be security issues, and government code is pretty strict on patching those. At least a handful I know offhand require Java 11+ on the latest version including hibernate and springframework.

[Arne Vajhøj]

On 3/8/2023 3:14 PM, e.d.pro...@gmail.com wrote:
>>> In web, we use DTOs on the back end to pass data to and from the
>>> Javascript/Typescript on the front end. It looks like passing to
>>> the front end works, now how do we use it as a model to get the
>>> user input?
>> Note: if you do get an exception, you should at least state its
>> message in your post.
>>
>> According to the changelog, support for Java records has been added
>> to Gson in version 2.10:
>> <https://github.com/google/gson/releases?q=2.10&expanded=true>.
>> Switch to that and you should be good to go.
>

> Aha! So my sample code does work. I hadn't updated my dependencies in
> a while on my test project. I need to finish that pom and add a site
> report with the dependency-updates plugin. I was referencing gson
> 2.8.6. I switched to 2.10.1 and it solved that error. Now, if we can
> switch to Java 17 (15+), we use record for all DTOs? This is much
> more efficient and/or secure than using classes with lombok?
>
> All fields in a record are final, so it can only have the one
> constructor with parameters for every field? This sounds tedious to
> instantiate on the back end unless you're using a framework or
> convenience method that's going to populate, from a ResultSet? Front
> end data is simple if you can instantiate from JSON using gson.
> Requiring all values final on instantiation will require a very
> different DTO structure than the legacy apps I've seen.

Getters and setters has been considered too verbose
for a couple of decades.

Some just use their IDE to generate them.

The Lombok thing was invented to autogenerate the
trivial code.

Scala and Kotlin has case class and data class
respectively to do it simpler.

Java after many years got the record thing.

If you can live with the immutable aspect
(which is sort of in fashion today), then
it would make sense to use them for all
sorts of data classes.

Arne

[e.d.pro...@gmail.com]

> The Lombok thing was invented to autogenerate the
> trivial code.
>
> Scala and Kotlin has case class and data class
> respectively to do it simpler.
>
> Java after many years got the record thing.
>
> If you can live with the immutable aspect
> (which is sort of in fashion today), then
> it would make sense to use them for all
> sorts of data classes.
>
> Arne

lombok was a huge help in the giant legacy project.
We took a project with no DTOs, just populating every field on the page as you go using JSP, and changed it to angular with one DTO for the page.
Initially this means instantiate DTO, then call setFirstValue(), setSecondValue(), etc.
Immutable objects would make more sense if you break the DTOs up into logical bits, maybe map a convenience method to instantiate from a RecordSet on the back end, while of course using gson to instantiate from front end data.

[Jason H]

I encountered this when I Googled how to do structs in Java. The answer
was not before 16 (though really, a class with a bunch of public
variables will do, if that's what you need).

[e.d.pro...@gmail.com]

> > In web, we use DTOs on the back end to pass data to and from the Javascript/Typescript on the front end. It looks like passing to the front end works, now how do we use it as a model to get the user input?
> I encountered this when I Googled how to do structs in Java. The answer
> was not before 16 (though really, a class with a bunch of public
> variables will do, if that's what you need).

Sounds like a record is a class with public final variables.