> >> John Hewson <j...@jahewson.com> hat am 8. Januar 2015 um 00:38 geschrieben: >> >> >> >>> On 7 Jan 2015, at 15:01, Leonard Rosenthol <lrose...@adobe.com> wrote: >>> >>> I admit to never actually looking a the PDFBox Cos implementation, but >>> every other implementation that I’ve worked with (and it’s been quite a >>> few) have a VERY deep connection between the object and the source >>> document. This is necessary in order to enable various features such as >>> “on-demand read” (especially important for large arrays and streams), >>> incremental updates and more. >>> >>> It’s your library, but I would personally strongly recommended NOT going >>> in this direction… >> >> Thanks, however I’m not proposing any changes to how PDFBox works. We >> already do on-demand reading for COS streams. When I say that there >> is nothing about a COS object that is specific to a given document, I mean >> only that there’s no problem sharing our Java COSStream instances between >> two or more COSDocument instances. This is somewhat similar to the issue >> of sharing PDPage instances between threads in Java (not safe). It’s a >> specific detail of PDFBox, rather than something to do with COS in general. > What about concurrent accesses and I'm not talking about multiple threads. > One could import a pdf to another and alter parts of the resulting one or > the source pdf which may lead to broken docs. > > > BR > Andreas Lehmkühler
That's the benefit of the current approach that after the deep cloning the imported page is independent from the source page.
