You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by "Chris Beams (JIRA)" <ji...@apache.org> on 2007/10/05 19:06:51 UTC
[jira] Created: (JDO-540) Support for final modifier on fields of
Persistence-Capable classes
Support for final modifier on fields of Persistence-Capable classes
-------------------------------------------------------------------
Key: JDO-540
URL: https://issues.apache.org/jira/browse/JDO-540
Project: JDO
Issue Type: New Feature
Components: api2
Reporter: Chris Beams
Fix For: JDO 2 maintenance release 1
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...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-540) Support for final modifier on fields of
Persistence-Capable classes
Posted by "Chris Beams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Beams updated JDO-540:
----------------------------
Assignee: (was: Chris Beams)
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'.
> Support for final modifier on fields of Persistence-Capable classes
> -------------------------------------------------------------------
>
> Key: JDO-540
> URL: https://issues.apache.org/jira/browse/JDO-540
> Project: JDO
> Issue Type: New Feature
> Components: api2
> Reporter: Chris Beams
>
> 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...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-540) Support for final modifier on fields of
Persistence-Capable classes
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-540:
------------------------------
Fix Version/s: (was: JDO 2 maintenance release 1)
This change request needs more investigation. Deferring to a future release.
> Support for final modifier on fields of Persistence-Capable classes
> -------------------------------------------------------------------
>
> Key: JDO-540
> URL: https://issues.apache.org/jira/browse/JDO-540
> Project: JDO
> Issue Type: New Feature
> Components: api2
> Reporter: Chris Beams
> Assignee: Chris Beams
>
> 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...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JDO-540) Support for final modifier on fields of
Persistence-Capable classes
Posted by "Chris Beams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Beams reassigned JDO-540:
-------------------------------
Assignee: Chris Beams
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...
> Support for final modifier on fields of Persistence-Capable classes
> -------------------------------------------------------------------
>
> Key: JDO-540
> URL: https://issues.apache.org/jira/browse/JDO-540
> Project: JDO
> Issue Type: New Feature
> Components: api2
> Reporter: Chris Beams
> Assignee: Chris Beams
> Fix For: JDO 2 maintenance release 1
>
>
> 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...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-540) Support for final modifier on fields of
Persistence-Capable classes
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536374 ]
Craig Russell commented on JDO-540:
-----------------------------------
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.
> Support for final modifier on fields of Persistence-Capable classes
> -------------------------------------------------------------------
>
> Key: JDO-540
> URL: https://issues.apache.org/jira/browse/JDO-540
> Project: JDO
> Issue Type: New Feature
> Components: api2
> Reporter: Chris Beams
> Assignee: Chris Beams
> Fix For: JDO 2 maintenance release 1
>
>
> 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...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-540) Support for final modifier on fields of
Persistence-Capable classes
Posted by "Chris Beams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532730 ]
Chris Beams commented on JDO-540:
---------------------------------
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.
> Support for final modifier on fields of Persistence-Capable classes
> -------------------------------------------------------------------
>
> Key: JDO-540
> URL: https://issues.apache.org/jira/browse/JDO-540
> Project: JDO
> Issue Type: New Feature
> Components: api2
> Reporter: Chris Beams
> Fix For: JDO 2 maintenance release 1
>
>
> 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...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.