[ 
https://issues.apache.org/jira/browse/PDFBOX-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14279915#comment-14279915
 ] 

John Hewson commented on PDFBOX-2596:
-------------------------------------

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 is accompanied with the code:

{code}
Throwable t = new Throwable( "Warning: You did not close the PDF Document" );
t.printStackTrace();
{code}

Which is a long way from best practices, as is calling close() in a finalizer, 
which leads me to suspect that the downside of the close() calls was not really 
considered. 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)

Reply via email to