JDO
  1. JDO
  2. JDO-540

Support for final modifier on fields of Persistence-Capable classes

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: api
    • Labels:
      None

      Description

      Per changes introduced in Java5 as part of JSR-133, post-construction modification of final fields is now possible when calling setAccessible(true) on a field via reflection.

      Heinz Kabutz gives a good discussion of the feature: http://www.javaspecialists.eu/archive/Issue096.html

      Supporting final on fields would make JDO even less intrusive than it already is, and would allow users to create richer class definitions.

      Let's discuss...

        Activity

        Hide
        Chris Beams added a comment -

        While this remains an interesting issue, I won't be looking into it any time soon. Thus I'm changing the assigned status to 'Unassigned'.

        Show
        Chris Beams added a comment - While this remains an interesting issue, I won't be looking into it any time soon. Thus I'm changing the assigned status to 'Unassigned'.
        Hide
        Craig L Russell added a comment -

        This change request needs more investigation. Deferring to a future release.

        Show
        Craig L Russell added a comment - This change request needs more investigation. Deferring to a future release.
        Hide
        Craig L Russell added a comment -

        Meantime, here is some text from the specification making it clear that certain modifiers are not required to be supported.

        6.2 All class and field modifiers supported by the Java language including A6.2-1 [private], A6.2-2 [public], A6.2-3 [protected], A6.2-4 [static], A6.2-5 [transient], A6.2-6 [abstract], A6.2-7 [final], A6.2-8 [synchronized], and A6.2-9 [volatile], should be supported by JDO instances. There are some known issues with final and static field, therefore implementations are not required to support making final or static fields persistent.

        6.4.4 Static and final fields
        Static fields pose a challenge for implementations. Since they are singletons typically initialized when the class is loaded, there is no convenient time to load the values from the database. Therefore, static fields are not persistent.
        Final fields pose a challenge for implementations. While it is possible to modify the values of static fields, it can only be done via reflection and there are synchronization issues. Therefore, final fields are not persistent.

        6.4.5 Complex enum types
        Complex enum types are enums that contain fields that might change during execution instead of being initialized at class initialization. While it is possible to manage these singleton instances persistent state, there are issues with the transaction isolation of the instances and with the ownership of the instances by a persistence manager. Therefore, dynamically changing fields of enum types are not persistent.

        Show
        Craig L Russell added a comment - Meantime, here is some text from the specification making it clear that certain modifiers are not required to be supported. 6.2 All class and field modifiers supported by the Java language including A6.2-1 [private] , A6.2-2 [public] , A6.2-3 [protected] , A6.2-4 [static] , A6.2-5 [transient] , A6.2-6 [abstract] , A6.2-7 [final] , A6.2-8 [synchronized] , and A6.2-9 [volatile] , should be supported by JDO instances. There are some known issues with final and static field, therefore implementations are not required to support making final or static fields persistent. 6.4.4 Static and final fields Static fields pose a challenge for implementations. Since they are singletons typically initialized when the class is loaded, there is no convenient time to load the values from the database. Therefore, static fields are not persistent. Final fields pose a challenge for implementations. While it is possible to modify the values of static fields, it can only be done via reflection and there are synchronization issues. Therefore, final fields are not persistent. 6.4.5 Complex enum types Complex enum types are enums that contain fields that might change during execution instead of being initialized at class initialization. While it is possible to manage these singleton instances persistent state, there are issues with the transaction isolation of the instances and with the ownership of the instances by a persistence manager. Therefore, dynamically changing fields of enum types are not persistent.
        Hide
        Chris Beams added a comment -

        Action Item for Chris to look deeper into the implementation issues.

        At this point, the cost/benefit ratio looks pretty high for adding this feature. Perhaps it's justifiable after some research. We'll see...

        Show
        Chris Beams added a comment - Action Item for Chris to look deeper into the implementation issues. At this point, the cost/benefit ratio looks pretty high for adding this feature. Perhaps it's justifiable after some research. We'll see...
        Hide
        Chris Beams added a comment -

        Craig's comment from the JDO Conference Call on Sept 28th:

        Attendees: Michelle Caisse, Michael Bouschen, Craig Russell

        Agenda:

        1. Support for final modifier on fields. There are a few issues with
        making final fields persistent. First, the only difference between
        final and private is that final protects the class writer from
        accidentally changing the value of a final field; private protects
        the class writer from external code. Except in both cases, using
        reflection invalidates the protection. Second, the point at which the
        final field is modified by the jdo implementation would need to be
        carefully thought through. The final fields' values would have to be
        changed during specific life cycle events, such as retrieval from the
        datastore, flush, commit, rollback, etc. When exactly would the final
        fields be set? And how does this affect the memory model guarantees?

        Bottom line: We'd like to see some more justification and discussion
        on the open questions raised above.

        Show
        Chris Beams added a comment - Craig's comment from the JDO Conference Call on Sept 28th: Attendees: Michelle Caisse, Michael Bouschen, Craig Russell Agenda: 1. Support for final modifier on fields. There are a few issues with making final fields persistent. First, the only difference between final and private is that final protects the class writer from accidentally changing the value of a final field; private protects the class writer from external code. Except in both cases, using reflection invalidates the protection. Second, the point at which the final field is modified by the jdo implementation would need to be carefully thought through. The final fields' values would have to be changed during specific life cycle events, such as retrieval from the datastore, flush, commit, rollback, etc. When exactly would the final fields be set? And how does this affect the memory model guarantees? Bottom line: We'd like to see some more justification and discussion on the open questions raised above.

          People

          • Assignee:
            Unassigned
            Reporter:
            Chris Beams
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development