You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by "Nathan Beyer (JIRA)" <ji...@apache.org> on 2008/08/04 03:25:44 UTC

[jira] Created: (ABDERA-193) [core] AtomDate hardening - clone java.util.Date, make non-null a requirement

[core] AtomDate hardening - clone java.util.Date, make non-null a requirement
-----------------------------------------------------------------------------

                 Key: ABDERA-193
                 URL: https://issues.apache.org/jira/browse/ABDERA-193
             Project: Abdera
          Issue Type: Improvement
            Reporter: Nathan Beyer
         Attachments: ABDERA-193.patch

The class AtomDate contains a java.util.Date field and in several cases, the underlying field can be modified unexpectedly, since java.util.Date is mutable. The patch being attached compensates for this by cloning the java.util.Date instances to make safe copies. Additionally, the patch makes non-null values a requirement, which is already required by some of the current code. There are also a few style tweaks that I believe make the code more clear; use AssertionError in clone method to indicate it will never happen, replace "GMT" with "UTC" to make the intent more obvious. The patch also includes a unit test for the code that was changed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (ABDERA-193) [core] AtomDate hardening - clone java.util.Date, make non-null a requirement

Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ABDERA-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nathan Beyer updated ABDERA-193:
--------------------------------

    Attachment: ABDERA-193.patch

> [core] AtomDate hardening - clone java.util.Date, make non-null a requirement
> -----------------------------------------------------------------------------
>
>                 Key: ABDERA-193
>                 URL: https://issues.apache.org/jira/browse/ABDERA-193
>             Project: Abdera
>          Issue Type: Improvement
>            Reporter: Nathan Beyer
>         Attachments: ABDERA-193.patch
>
>
> The class AtomDate contains a java.util.Date field and in several cases, the underlying field can be modified unexpectedly, since java.util.Date is mutable. The patch being attached compensates for this by cloning the java.util.Date instances to make safe copies. Additionally, the patch makes non-null values a requirement, which is already required by some of the current code. There are also a few style tweaks that I believe make the code more clear; use AssertionError in clone method to indicate it will never happen, replace "GMT" with "UTC" to make the intent more obvious. The patch also includes a unit test for the code that was changed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (ABDERA-193) [core] AtomDate hardening - clone java.util.Date, make non-null a requirement

Posted by "David Calavera (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ABDERA-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Calavera resolved ABDERA-193.
-----------------------------------

    Resolution: Fixed
      Assignee: David Calavera

> [core] AtomDate hardening - clone java.util.Date, make non-null a requirement
> -----------------------------------------------------------------------------
>
>                 Key: ABDERA-193
>                 URL: https://issues.apache.org/jira/browse/ABDERA-193
>             Project: Abdera
>          Issue Type: Improvement
>            Reporter: Nathan Beyer
>            Assignee: David Calavera
>         Attachments: ABDERA-193.patch
>
>
> The class AtomDate contains a java.util.Date field and in several cases, the underlying field can be modified unexpectedly, since java.util.Date is mutable. The patch being attached compensates for this by cloning the java.util.Date instances to make safe copies. Additionally, the patch makes non-null values a requirement, which is already required by some of the current code. There are also a few style tweaks that I believe make the code more clear; use AssertionError in clone method to indicate it will never happen, replace "GMT" with "UTC" to make the intent more obvious. The patch also includes a unit test for the code that was changed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (ABDERA-193) [core] AtomDate hardening - clone java.util.Date, make non-null a requirement

Posted by "David Calavera (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ABDERA-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Calavera closed ABDERA-193.
---------------------------------


> [core] AtomDate hardening - clone java.util.Date, make non-null a requirement
> -----------------------------------------------------------------------------
>
>                 Key: ABDERA-193
>                 URL: https://issues.apache.org/jira/browse/ABDERA-193
>             Project: Abdera
>          Issue Type: Improvement
>            Reporter: Nathan Beyer
>            Assignee: David Calavera
>         Attachments: ABDERA-193.patch
>
>
> The class AtomDate contains a java.util.Date field and in several cases, the underlying field can be modified unexpectedly, since java.util.Date is mutable. The patch being attached compensates for this by cloning the java.util.Date instances to make safe copies. Additionally, the patch makes non-null values a requirement, which is already required by some of the current code. There are also a few style tweaks that I believe make the code more clear; use AssertionError in clone method to indicate it will never happen, replace "GMT" with "UTC" to make the intent more obvious. The patch also includes a unit test for the code that was changed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.