Hi Craig, I wonder whether this is really 100% correct. I wasn't there when this was written but maybe it was meant to mean something slightly different? Some thoughts:
*Alternative interpretations:* 1) I think it possible that it just means "[The system should behave as if] Second class objects of mutable classes ....". I am not sure why we require these classes to be enhanced, it feels like it should be sufficient in this case if JDO specifies _how_ the system should behave, not how it is implemented. 2) As it has been suggested earlier , it may also just mean that a JDO implementation is allowed to provide an own implementation of system classes, that would avoid having to enhance system classes. *Potential Issues:* 3) System classes may be used all over the place (including by the JDO implementation itself). Enhancing these classes can easily have undesirable side effects, from performance issues, to memory issues (requiring more space), to correctness issues (if the application somewhere else serializes system classes it may fail if these classes have additional state (even if it is marked as 'transient'). 4) Forward compatibility and missing bug fixes. If we compile-time-enhance system classes (and generally 3rd party classes), a JDO application that is delivered to a customer will contain system classes. The problem here is that these classes may be incompatible with native system classes if the user uses a later JVM version (potentially containing API changes: remember when streams were added to collections); even if it works, the user will not benefit from bug/security fixes that are delivered in new JVM versions (but not in the compile-time enhanced classes). Of course this could be alleviated by disallowing compile-time enhancement and allowing only runtime-enhancement for system classes, but that would also be a bit 'inconsistent'. *Proposal**:* 5) I propose to rephrase this to "allow" JDO implementations to enhance system classes when they want to, but not require it. Instead it should be sufficient if an owning object tracks access and updates where possible. *Assumed impact of spec change:* 6) For JDO implementations that have implemented this, I assume that such a change would have little to no impact. It is backwards compatible because implementations do not need to change anything unless they want to. 7) For users it is a bit more complex. Personally I always assumed that a direct change of a SCO would not be tracked, so there would be no change (in my personal case). What I did assume is that the owning object of an embedded class would keep track of updates to the embedded class. In my experience this would usually work because it would only break if an owning object returns its embedded object for others to modify it, which I think has a bit of a code smell to it (again my personal opinion). This logic is similar to other internal fields, if an owning objects returns mutable internal state (or makes its fields public) then it basically gives up any control and anything can happen. *Final words:* 8) I understand that enhanced system classes would be required to ensure 100% tracking of dirty embedded objects. However, since this comes with its own problems, see 3) and 4). I think requiring the owning object to track changes is usually sufficient and probably also easier to implement. Sorry for the rant :-) Cheers, Til On 06/05/2021 23:58, Craig Russell wrote:
While researching Second Class Object behaviors, I found this in the specification 6.3: Second Class Objects of mutable system classes and persistence-capable classes track changes made to them, and notify their owning FCO that they have changed. Since converted classes most resemble persistence-capable classes, I proposed this change to 6.3: Second Class Objects of mutable system classes, converted classes, and persistence-capable classes track changes made to them, and notify their owning FCO that they have changed. But this implies that we enhance converted classes. So: 1. What does JPA do about converted classes? Does it enhance them so they track changes made to mutable instances? 2. What are the requirements for converted classes in JDO? Just follow whatever JPA does? If we really want to require enhancing converted classes, we should be specific about it. And add a test case or three to the TCK. To test this, we will need a mutable converted class, perhaps by adding a mutator method for the x value. Then, modify the x value and see if the instance is marked as dirty. Craig L Russell c...@apache.org
