Not sure it's a good use case. On the one hand avoiding unnecessary
adapters and data copying is always good, on the other hand mixing aspects
may cause issues. In JPA, having parent-child relationship is common and
this can easily lead to "com.sun.istack.SAXException2: A cycle is detected
in the object graph. This will cause infinitely deep XML". More so, JPA
objects are proxied, so the only way to access class' data is using
accessor methods.
Anyway, I agree that a discussion in this thread became a bit religious ;)
I would assume that each application uses separate layer for accessing
database, sending/receiving data over the wire, yet another for displaying
info in the UI, etc.
I also dare to say that encapsulation, coding practices is not the business
of this JSR. Don't get me wrong I agree with most comments about advantages
of immutable classes, encapsulation etc., however it's not JSON-B's job to
enforce this. We must fit into existing ecosystem seamlessly whether
developers use private fields with setters/getters, or just
public/protected/default scope fields. That's why I like
https://docs.oracle.com/javaee/6/api/javax/xml/bind/annotation/XmlAccessType.html
- it's completely flexible with reasonable default.
11 kwi 2015 9:16 PM "Romain Manni-Bucau" <rmannibucau_at_tomitribe.com>
napisaĆ(a):
> Forgot to mention something super important: what will be the first usage
> at EE level? Retirning a JPA entity in a JAX-RS service IMO so being super
> close to JPA can be nice - wonder about lazy relationships btw...
>
>