[
https://issues.apache.org/jira/browse/PDFBOX-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900508#comment-13900508
]
John Hewson commented on PDFBOX-1684:
-------------------------------------
I've approached the same problems as the patch, just in a different manner.
Looking at the conversation above the decisions to return dummy dates, and
throw IOExceptions or NullPointerExceptions was based on maintaining
compatibility with 1.8, which I haven't done.
With regards to the NullPointerException, the issue was that PDFBox itself was
throwing a NullPointerException when given a null argument, which is bad.
End users are well aware of the need to check for null when the documentation
clearly says to and this is standard practice. Returning invalid Calendar
objects breaks the contract of what a Calendar object is, Java uses null to
represent "no date". Imagine having invalid dates flowing through the user's
code, silently passing null checks elsewhere, noticed by nobody. Compare this
with the case when a user forgets to check for null, their code throws an
exception, and at the exact point where they need to fix their code.
The reason for making the "internal" methods private is because they are
exactly that, "internal". They are implementation details, which prevent
DataConverter from being refactored within a stable release. There is no need
for end users to be making use of DataConverter, it is only public because it
is shared across many PDFBox packages. If an end user encounters a date format
which DataConverter does not yet support then that is a failing in
DataConverter, and should be fixed within PDFBox by opening a new issue.
> DateConverter source is in three places and has diverged
> --------------------------------------------------------
>
> Key: PDFBOX-1684
> URL: https://issues.apache.org/jira/browse/PDFBOX-1684
> Project: PDFBox
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 2.0.0
> Environment: Win 8, maven 3.0.5, svn 1.7.8 (r1419691), javac 1.7.0_25
> Reporter: Fred Hansen
> Priority: Minor
> Fix For: 2.0.0
>
>
> Versions of DateConverter,java are in three (3) packages: jempbox.impl,
> pdfbox.util, and xmpbox. They have diverged as updates have been made to one
> or the other.
> Date Converter is used in these modules:
> jempbox.xmp.ResourceEvent.java
> jempbox.xmp.XMPSchema.java
> pdfbox.cos.COSDictionary.java
> pdfbox.pdmodel.fdf.FDFAnnotation.java
> preflight.metadata.SynchronizedMetaDataValidation.java
> xmpbox.type.DateType.java
> The smallest library is xmpbox, so let's consider it as a home for
> DateConverter. Preflight already imports xmpbox. Pdfbox requires jempbox, so
> importing xmpbox into jempbox will satisfy both. Since xmpbox defines some
> xmp features, it seems likely that jempbox could take further advantage of
> xmpbox.
> { incorrect: Conclusion and recommendation: have a single copy of
> DateConverter in xmpbox. }
> Conclusion: create another top-level pdfbox package for DateConverter and
> other utilities that do not depend on pdfbox classes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
