On 1/8/15, 9:17 PM, "John Hewson" <[email protected]> wrote:
>I’d argue the opposite - in Java one expects objects to be shared unless >there is an explicit call to clone(). e.g. can you think of an example >from the Java standard library where explicit copying occurs? I can’t. >There’s just no way to fight this in Java, it’s a fact of life. It’s not >like C++ where there are copy semantics. We’ve been talking about around the (virtual) office today and we do agree with you that philosophically Java assumes objects are always by reference. And while that could well be a useful feature it also (in this example, and others) doesn’t allow you to properly model the underlying system. >>I already asked this sooner, but I'm happy to repeat my question about >>concurrent editing. >> How do we ensure that the whole stuff is "foolproof", so that people >>who don't have a clue about the internals can use it without breaking >>their pdfs by accident? > >You can’t. Objects in Java are passed by reference, and there’s nothing >we can do about it. Today you can use the PDFBox API to take a >COSDictionary from one document and insert it directly into another >document and *it’s fine*, it works. For all the features *currently present* in PDFBox, it works. However, there are features present in other PDF libraries that you may wish to implement - for example, incremental updates - that will not be possible with this model because you’ve lost the connection to the original document. Another good example of why you need to maintain the connection to the document is on-demand decryption. Since the key to decrypt the String or Stream is a combination of the file key, the encryption algorithm specification, AND the object number and revision (all coming from the original document), it’s impossible to decrypt that object data on demand if you’ve “connected” it with another document. Assuming that streams aren’t decrypted until they are accessed - this could be an issue today. >In other words, the current API allows users to shoot themselves in the >foot because it corrupts COS objects from closed documents. All I’m >proposing is to fix that by not clearing the memory the COS objects when >closing their parent document. Is there any way you could reparent it at this point? It might require a back-walk up the object tree, which could be slow, but it should be doable. And at least for simple objects, would then make it work as expected. Leonard
