[
https://issues.apache.org/jira/browse/PDFBOX-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14279915#comment-14279915
]
John Hewson edited comment on PDFBOX-2596 at 1/16/15 7:27 AM:
--------------------------------------------------------------
As an aside, the code which calls close() in the finalizer of COSDocument is
something which we might want to rethink. As we've just seen, people may try to
depend on the behaviour, despite it breaking the well-documented contract of
close(). Looking at SVN the close() call has been there since before PDFBox was
an Apache project, and was originally accompanied with the code:
{code}
Throwable t = new Throwable( "Warning: You did not close the PDF Document" );
t.printStackTrace();
{code}
Which is definitely not best practice; neither is calling close() in a
finalizer, which leads me to suspect that the downside of the close() call was
not really considered at the time. Note that calling close() in a finalizer is
not recommended practice in Java, and comes with [few
guarantees|https://www.securecoding.cert.org/confluence/display/java/MET12-J.+Do+not+use+finalizers]
was (Author: jahewson):
As an aside, the code which calls close() in the finalizer of COSDocument is
something which we might want to rethink. As we've just seen, people may try to
depend on the behaviour, despite it breaking the well-documented contract of
close(). Looking at SVN the close() call has been there since before PDFBox was
an Apache project, and was originally accompanied with the code:
{code}
Throwable t = new Throwable( "Warning: You did not close the PDF Document" );
t.printStackTrace();
{code}
Which is definitely not best practice; neither is calling close() in a
finalizer, which leads me to suspect that the downside of the close() call was
not really considered at the time. Note that calling close() in a finalizer is
not recommended practice in Java.
> NullPointerException in RandomAccessFileInputStream
> ---------------------------------------------------
>
> Key: PDFBOX-2596
> URL: https://issues.apache.org/jira/browse/PDFBOX-2596
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 1.8.8
> Reporter: John Roche
>
> Line 94 contains a synchronized(file) that throws a NullPointerException
> under some strange circumstances that I haven't been able to fully identify
> yet. I have downloaded the 1.8.8 source and the fix I used is simply to add
> "&& file != null" to the previous if statement.
> I can reproduce this bug with live user data, but I haven't been able to with
> test data yet. It happens when I try to create a pdf with 36 pages that have
> an image, some drawn coloured boxes and some text, on each page. If I remove
> some of the pages before I call save(File) it doesn't happen - depending on
> which pages I remove it can be ok with up to 26 pages, or break with fewer.
> Quite strange. I suspect it's to do with the size of the data as opposed to
> the number of pages.
> I will continue to investigate, since there seems to be some underlying
> issue, but for now I guess the null protection should be ok to add?
> Thanks,
> John
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
