Idea for @ToJson and @FromJson

[Luck]

Hi guys, 

I´d like to develop the follow features, what do you think about this? 

@Getters

@Setters

@AllArgsConstruct

@ToJson

@FromJson

@ToString

public class Customer {

    private Integer id;

    private String name;

}

Use: @ToJson

Customer customer = new Customer(10, "Luck");

System.out.println(customer.toJson());  // this prints -> {"id":10,"name":"Luck"}

Use: @FromJson

Customer customer = Customer.fromJson({"id":10,"name":"Luck"});

System.out.println(customer); // this prints a customer, because fromJson is a factory 

tnx advanced

Luck

[Reinier Zwitserloot]

This doesn't strike me as a good idea; it's essentially not 'lombok territory'.

Yes, in theory, lombok can do something here that a simple library couldn't, which is to marshall/unmarshall an object into JSON without using reflection. However, whilst the benefit for this is fairly obvious when talking about hashCode and equals (performance can be relevant in such cases, and idiomatic java is to write it out; there are also some tricky contexts where reflection is a bad idea or flat out doesn't work, and equals/hashCode is a near universal requirement) - I see no point to that for JSON.

JSONizing is an incredibly complex job, at least, relative to generating equals and hashCode implementations. Lombok features are a lot closer to language features than libraries. I'd consider a baked-into-java-the-language JSON marshaller an incredibly bad idea, which makes it a fairly bad idea for lombok as well. There's way too many configurable things; we'd need to be versioning it a lot, and we'd be adding yet another JSON option amongst an already very occupied field.

Let me put it differently: What makes a hypothetical lombok solution to this any better than GSON or Jackson's marshall/unmarshall options?

Note that this feature would be one of the most complex lombok features imaginable:

* It needs to account for supertypes which lombok currently can't do at all - see wiki page 'resolution'

* Lombok doesn't ship (intentionally!) at runtime, so you have to generate _everything_. You can't use utility methods, in other words, unless they are in the java core libs. This sounds a bit tricky.

* You need to do a lot more work on what this feature looks like. For example, surely you intend for authors to be capable of providing custom JSON serializers/deserializers. Also, which data type(s) do you intend to support out of the box. Surely `LocalDate` is supported, JSONing to e.g. `"2022-11-10"` instead of failing.

* How do you serialize objects that aren't themselves `@ToJson` marked, and how would you know - again, resolution.

In other words:

* Bad idea.

* If it wasn't a bad idea, essentially impossible as a lombok feature.

[Jan Materne]

If you want to write obj.toJson() and are willing to 3rd party libs like Jackson, you could write a simple wrapper and use Lombols extension method mechanism.

Jan

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/3997ea2f-bb4c-4ba4-be9b-a82cefb85744n%40googlegroups.com.