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

Emmeran Seehuber commented on PDFBOX-5664:
------------------------------------------

[~mkl] Copying the class should work, but I would like to avoid that. Yes the 
class does not change much, so as long as there is no radical structure change, 
the copied version should not get out of sync. So this could be a working 
solution.

But thats not the solution I would prefer, as cloning COS-Objects is some 
"internal" operation of PDFBox, which IMHO should not be replicated outside of 
it. Just give me a protected constructor, then I can derive from it in my 
project and can again access the functionality without breaking JPMS rules.

Yes the class and it's usage is not something the usual PDFBox user should 
stumble over, as it's likely going to cause confusion.

> 3.0.0: PDFCloneUtility needs a protected constructor to be useable outside of 
> PDFBox when using Java 9 JPMS
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: PDFBOX-5664
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-5664
>             Project: PDFBox
>          Issue Type: Improvement
>    Affects Versions: 3.0.0 PDFBox
>            Reporter: Emmeran Seehuber
>            Priority: Major
>
> The constructor of PDFCloneUtility is package private. I did not have a 
> problem with this, because I did an ugly workaround in my pdfbox-graphics2d 
> 3.0.0 branch. I created a derived class InternalDeprecatedCOSCloner in the 
> org.apache.pdfbox.multipdf package inside my project. And could access the 
> constructor.
> This works fine as long as you don't plan to use the JPMS modules introduced 
> with Java 9. Which I personally don't plan every to do.
> But it seems Apache POI is going to use those JPMS modules, at least 
> [~fanningpj] is trying to get POI working with PDFBox 3.0.0 and my 
> pdfbox-graphics2d with version 3.0.0. And now he gets a not so nice 
>  
> {{/Users/pj.fanning/svn/poi/poi-ooxml/src/main/java9/module-info.java:18: 
> error: module org.apache.poi.ooxml reads package org.apache.pdfbox.multipdf 
> from both de.rototor.pdfbox.graphics2d and org.apache.pdfbox}}
> As the - to be honest rather dirty - workaround done be me no longer works 
> with JPMS...
> You can find the concrete usage for the cloner here 
> [https://github.com/rototor/pdfbox-graphics2d/blob/master/graphics2d/src/main/java/de/rototor/pdfbox/graphics2d/PdfBoxGraphics2DPaintApplier.java].
>  Just search for PDFCloneUtility. I use it to clone PDShading when I'm 
> "rewriting" PDFs. I.e. I use PDFBox to draw on my Graphics2D adapter to 
> create new PDFs and filter / change stuff in the PDF on the fly. Mostly to 
> split PDFs for Seperation colors and such stuff.
> Just making the PDFClonerUtility constructor public again would of course 
> work. But I'm not sure that this is the right solution. AFAIR it was made 
> package private because of many problems of users which did not really 
> understand what this class was for.
> Maybe a solution could be to make the constructor protected and create a 
> package private getCloner() factory method? That would allow me to derive 
> from the class from outside the original package but would also prevent 
> people who don't know for sure that they really want to use this class from 
> using it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to