[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-2602:
-

Thanks for all the work. I'll have a look again.

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-5061:
-

What I mean is that we're not using all of the DatetypeConverter methods so the 
rest is untested. I could delete all that are unused, but that would mean more 
work and that would possibly have to be repeated if there is an update. And 
some of the code might be useful too...

 !screenshot-1.png! 

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Task
>Reporter: Oliver Kopp
>Priority: Minor
> Fix For: 2.0.23, 3.0.0 PDFBox
>
> Attachments: screenshot-1.png
>
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Tilman Hausherr (Jira) 


 [ 
https://issues.apache.org/jira/browse/PDFBOX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-5061:

Attachment: screenshot-1.png

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Task
>Reporter: Oliver Kopp
>Priority: Minor
> Fix For: 2.0.23, 3.0.0 PDFBox
>
> Attachments: screenshot-1.png
>
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2138) Corrupted words when using PDFTextStripper

2020-12-29 Thread Michael Klink (Jira) 


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

Michael Klink commented on PDFBOX-2138:
---

If you want to get a text extraction mechanism that extracts exactly the text 
visible, you have to do that (consider clipping paths) and more: In particular 
you also have to take into account that text may be hidden under other stuff, 
e.g. paths or bitmaps, text may have the same color as the background to start 
with or the colors may be later made equal by some operation in a funny blend 
mode. This includes some interesting decisions like how to deal with glyphs 
whose respective area is partially subject to clipping, covering, or color 
equalization.

In my opinion all this is beyond the scope of text extraction. Text extraction 
is more akin to copy&paste in Adobe Reader, and that also catches invisible 
text. E.g. in the document at hand, depending on how you mark text, you can 
copy&paste invisible text.

> Corrupted words when using PDFTextStripper
> --
>
> Key: PDFBOX-2138
> URL: https://issues.apache.org/jira/browse/PDFBOX-2138
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.8.5, 1.8.6, 2.0.0
> Environment: Windows 7 / 64 bit
>Reporter: Walter Kehl
>Priority: Major
> Fix For: 4.0.0
>
> Attachments: PDFBOX-2138-noClip.pdf, PDFBOX-2138-noClip.png, 
> PDFBOX-2138.pdf, PDFBOX-2138.txt, banking-banana-skins-2014.pdf, 
> banking-banana-skins-2014.txt
>
>
> >> I am using PDFTextStripper (embedded into another application) to get 
> >> the raw text of PDFs so far with good results but recently a PDF file 
> >> has appeared where the output of the PDFTextStripper was corrupted. I 
> >> got sentences like:
> >>
> >>
> >>
> >> "There is al o con ern that b nkers may be pushed to misprice risk 
> >> (No. 6) by the pres ures of c mpetition and an abunda ce of central b 
> >> nk-provided liquidity."
> > Additionally some portions of text appear 
> > twice in the output: first correctly and then corrupted. I have 
> > attached an output created with PDFBox's command line options.
> > If you compare lines 357- 365 with lines 421-429 you see that it is 
> > the same paragraph, first ok and then with characters missing. In the 
> > original source this paragraph is unique.
> > The same seems to happen for the other instances where text is corrupted.
> I also tried it directly on the command line with the same results: input and 
> output files are attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Jira 


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

Andreas Lehmkühler edited comment on PDFBOX-5061 at 12/29/20, 10:50 PM:


On the contrary, there are some tests, see 
org.apache.xmpbox.DateConverterTest.testDateConversion(). It's all about 
org.apache.xmpbox.DateConverter.toCalendar(String)


was (Author: lehmi):
On the contrary, there are some tests, see 
org.apache.xmpbox.DateConverterTest.testDateConversion()

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Task
>Reporter: Oliver Kopp
>Priority: Minor
> Fix For: 2.0.23, 3.0.0 PDFBox
>
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Jira 


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

Andreas Lehmkühler commented on PDFBOX-5061:


On the contrary, there are some tests, see 
org.apache.xmpbox.DateConverterTest.testDateConversion()

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Task
>Reporter: Oliver Kopp
>Priority: Minor
> Fix For: 2.0.23, 3.0.0 PDFBox
>
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-5061:
-

The files are here:
https://github.com/eclipse-ee4j/jaxb-api/tree/master/jaxb-api/src/main/java/jakarta/xml/bind

I'm working on it a bit... sadly it will drive down our test coverage. There 
are no direct unit tests.

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Task
>Reporter: Oliver Kopp
>Priority: Minor
> Fix For: 2.0.23, 3.0.0 PDFBox
>
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-2359) Lines show on top of image

2020-12-29 Thread Jira 


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

Andreas Lehmkühler edited comment on PDFBOX-2359 at 12/29/20, 6:45 PM:
---

[~tilman] I guess Johns patch never made it into the trunk? The issue is still 
there. And it looks like other renderer are still affected as well. I've tried 
Edge, Firefox (both on Win10) and Evince on Linux.


was (Author: lehmi):
[~tilman] I guess Johns patch never made it into the trunk? The issue is still 
there. And it looks like other renderer are still effected as well. I've tried 
Edge, Firefox (both on Win10) and Evince on Linux.

> Lines show on top of image
> --
>
> Key: PDFBOX-2359
> URL: https://issues.apache.org/jira/browse/PDFBOX-2359
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: Simon Steiner
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
> Attachments: 3.pdf
>
>
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage 
> 3.pdf



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2138) Corrupted words when using PDFTextStripper

2020-12-29 Thread Jira 


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

Andreas Lehmkühler commented on PDFBOX-2138:


[~mkl] thanks for the explanation. I already saw those clipping path operations 
but I hoped that there maybe some other mechanism to choose the right marked 
content. Hence we have to adjust the extraction code to take the clipping path 
information into account so that the "invisible" text isn't extracted anymore

> Corrupted words when using PDFTextStripper
> --
>
> Key: PDFBOX-2138
> URL: https://issues.apache.org/jira/browse/PDFBOX-2138
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.8.5, 1.8.6, 2.0.0
> Environment: Windows 7 / 64 bit
>Reporter: Walter Kehl
>Priority: Major
> Fix For: 4.0.0
>
> Attachments: PDFBOX-2138-noClip.pdf, PDFBOX-2138-noClip.png, 
> PDFBOX-2138.pdf, PDFBOX-2138.txt, banking-banana-skins-2014.pdf, 
> banking-banana-skins-2014.txt
>
>
> >> I am using PDFTextStripper (embedded into another application) to get 
> >> the raw text of PDFs so far with good results but recently a PDF file 
> >> has appeared where the output of the PDFTextStripper was corrupted. I 
> >> got sentences like:
> >>
> >>
> >>
> >> "There is al o con ern that b nkers may be pushed to misprice risk 
> >> (No. 6) by the pres ures of c mpetition and an abunda ce of central b 
> >> nk-provided liquidity."
> > Additionally some portions of text appear 
> > twice in the output: first correctly and then corrupted. I have 
> > attached an output created with PDFBox's command line options.
> > If you compare lines 357- 365 with lines 421-429 you see that it is 
> > the same paragraph, first ok and then with characters missing. In the 
> > original source this paragraph is unique.
> > The same seems to happen for the other instances where text is corrupted.
> I also tried it directly on the command line with the same results: input and 
> output files are attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2138) Corrupted words when using PDFTextStripper

2020-12-29 Thread Michael Klink (Jira) 


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

Michael Klink commented on PDFBOX-2138:
---

There is no magic involved in these marked content sequences. What's 
responsible for which text shows and which not, are clipping path definitions.

To demonstrate this I've removed clipping path definitions from the page 
content stream: [^PDFBOX-2138-noClip.pdf]

As you can see, now multiple versions of the text are shown.

!PDFBOX-2138-noClip.png!

> Corrupted words when using PDFTextStripper
> --
>
> Key: PDFBOX-2138
> URL: https://issues.apache.org/jira/browse/PDFBOX-2138
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.8.5, 1.8.6, 2.0.0
> Environment: Windows 7 / 64 bit
>Reporter: Walter Kehl
>Priority: Major
> Fix For: 4.0.0
>
> Attachments: PDFBOX-2138-noClip.pdf, PDFBOX-2138-noClip.png, 
> PDFBOX-2138.pdf, PDFBOX-2138.txt, banking-banana-skins-2014.pdf, 
> banking-banana-skins-2014.txt
>
>
> >> I am using PDFTextStripper (embedded into another application) to get 
> >> the raw text of PDFs so far with good results but recently a PDF file 
> >> has appeared where the output of the PDFTextStripper was corrupted. I 
> >> got sentences like:
> >>
> >>
> >>
> >> "There is al o con ern that b nkers may be pushed to misprice risk 
> >> (No. 6) by the pres ures of c mpetition and an abunda ce of central b 
> >> nk-provided liquidity."
> > Additionally some portions of text appear 
> > twice in the output: first correctly and then corrupted. I have 
> > attached an output created with PDFBox's command line options.
> > If you compare lines 357- 365 with lines 421-429 you see that it is 
> > the same paragraph, first ok and then with characters missing. In the 
> > original source this paragraph is unique.
> > The same seems to happen for the other instances where text is corrupted.
> I also tried it directly on the command line with the same results: input and 
> output files are attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-2138) Corrupted words when using PDFTextStripper

2020-12-29 Thread Michael Klink (Jira) 


 [ 
https://issues.apache.org/jira/browse/PDFBOX-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Klink updated PDFBOX-2138:
--
Attachment: PDFBOX-2138-noClip.png

> Corrupted words when using PDFTextStripper
> --
>
> Key: PDFBOX-2138
> URL: https://issues.apache.org/jira/browse/PDFBOX-2138
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.8.5, 1.8.6, 2.0.0
> Environment: Windows 7 / 64 bit
>Reporter: Walter Kehl
>Priority: Major
> Fix For: 4.0.0
>
> Attachments: PDFBOX-2138-noClip.pdf, PDFBOX-2138-noClip.png, 
> PDFBOX-2138.pdf, PDFBOX-2138.txt, banking-banana-skins-2014.pdf, 
> banking-banana-skins-2014.txt
>
>
> >> I am using PDFTextStripper (embedded into another application) to get 
> >> the raw text of PDFs so far with good results but recently a PDF file 
> >> has appeared where the output of the PDFTextStripper was corrupted. I 
> >> got sentences like:
> >>
> >>
> >>
> >> "There is al o con ern that b nkers may be pushed to misprice risk 
> >> (No. 6) by the pres ures of c mpetition and an abunda ce of central b 
> >> nk-provided liquidity."
> > Additionally some portions of text appear 
> > twice in the output: first correctly and then corrupted. I have 
> > attached an output created with PDFBox's command line options.
> > If you compare lines 357- 365 with lines 421-429 you see that it is 
> > the same paragraph, first ok and then with characters missing. In the 
> > original source this paragraph is unique.
> > The same seems to happen for the other instances where text is corrupted.
> I also tried it directly on the command line with the same results: input and 
> output files are attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-2138) Corrupted words when using PDFTextStripper

2020-12-29 Thread Michael Klink (Jira) 


 [ 
https://issues.apache.org/jira/browse/PDFBOX-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Klink updated PDFBOX-2138:
--
Attachment: PDFBOX-2138-noClip.pdf

> Corrupted words when using PDFTextStripper
> --
>
> Key: PDFBOX-2138
> URL: https://issues.apache.org/jira/browse/PDFBOX-2138
> Project: PDFBox
>  Issue Type: Bug
>  Components: Text extraction
>Affects Versions: 1.8.5, 1.8.6, 2.0.0
> Environment: Windows 7 / 64 bit
>Reporter: Walter Kehl
>Priority: Major
> Fix For: 4.0.0
>
> Attachments: PDFBOX-2138-noClip.pdf, PDFBOX-2138.pdf, 
> PDFBOX-2138.txt, banking-banana-skins-2014.pdf, banking-banana-skins-2014.txt
>
>
> >> I am using PDFTextStripper (embedded into another application) to get 
> >> the raw text of PDFs so far with good results but recently a PDF file 
> >> has appeared where the output of the PDFTextStripper was corrupted. I 
> >> got sentences like:
> >>
> >>
> >>
> >> "There is al o con ern that b nkers may be pushed to misprice risk 
> >> (No. 6) by the pres ures of c mpetition and an abunda ce of central b 
> >> nk-provided liquidity."
> > Additionally some portions of text appear 
> > twice in the output: first correctly and then corrupted. I have 
> > attached an output created with PDFBox's command line options.
> > If you compare lines 357- 365 with lines 421-429 you see that it is 
> > the same paragraph, first ok and then with characters missing. In the 
> > original source this paragraph is unique.
> > The same seems to happen for the other instances where text is corrupted.
> I also tried it directly on the command line with the same results: input and 
> output files are attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-sonar2 #252

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-sonar2 » Apache PDFBox tools #252

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-trunk » Apache PDFBox tools #390

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-trunk #390

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-Trunk-jdk15 #162

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-Trunk-jdk15 » Apache PDFBox tools #162

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-Trunk-jdk16 #157

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-Trunk-jdk16 » Apache PDFBox tools #157

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread Maruan Sahyoun (Jira) 


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

Maruan Sahyoun commented on PDFBOX-2602:


I'm done here with the initial changes needed. Let me know if you find any 
glitches or you'd like to see additional changes. There is still room for 
improvement regarding help messages, consistent naming etc. but I think that 
can also be changed later in a new ticket.

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-2602:
-

Commit 1884910 from Maruan Sahyoun in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1884910 ]

PDFBOX-2602: fix name registration for command

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread Maruan Sahyoun (Jira) 


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

Maruan Sahyoun commented on PDFBOX-2602:


I've grouped some commands using a prefix:
{noformat}
  export:images  Extracts the images from a PDF document
  export:textExtracts the text from a PDF document
  export:fdf Exports AcroForm form data to FDF
  export:xfdfExports AcroForm form data to XFDF
  import:fdf Imports AcroForm form data from FDF
  import:xfdfImports AcroForm form data from XFDF
{noformat}

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-2602:
-

Commit 1884909 from Maruan Sahyoun in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1884909 ]

PDFBOX-2602: fix test; remove obsolete test method

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-trunk #389

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-trunk » Apache PDFBox tools #389

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-sonar2 #251

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-sonar2 » Apache PDFBox tools #251

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-Trunk-jdk15 #161

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-Trunk-jdk15 » Apache PDFBox tools #161

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-Trunk-jdk16 #156

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-Trunk-jdk16 » Apache PDFBox tools #156

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-2602:
-

Commit 1884908 from Maruan Sahyoun in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1884908 ]

PDFBOX-2602: use options instead or parameters as suggested by clig.dev

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[GitHub] [pdfbox] lehmi edited a comment on pull request #102: Add build using GitHub actions

2020-12-29 Thread GitBox 


lehmi edited a comment on pull request #102:
URL: https://github.com/apache/pdfbox/pull/102#issuecomment-752068241


   IMHO it doesn't make that much sense as we don't use github as primary 
repository, but as readonly mirror. So that those github actions are just 
another tool to verify our builds **after** a checkin. As Tilmans pointer shows 
the number of ASF runners are limited so that we shouldn't allocate them at all 
for a redundant process.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[GitHub] [pdfbox] lehmi commented on pull request #102: Add build using GitHub actions

2020-12-29 Thread GitBox 


lehmi commented on pull request #102:
URL: https://github.com/apache/pdfbox/pull/102#issuecomment-752068241


   IMHO it doesn't make that much sense as we don't use github as primary 
repository, but as readonly mirror. So that those github actions are just 
another tool to verify our builds **after** a checkin. As Tilmans pointer shows 
the number of ASF runners are limited so that we shouldn't not allocate them 
for a redundant process.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-2602:
-

it works, thanks

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[GitHub] [pdfbox] THausherr commented on pull request #102: Add build using GitHub actions

2020-12-29 Thread GitBox 


THausherr commented on pull request #102:
URL: https://github.com/apache/pdfbox/pull/102#issuecomment-752063239


   "The ASF maxes out its runner allocation quite often, so a project needs to 
plan carefully to make best use of them for everyone's sake."
   
   So to me this looks as if "no, won't do" is the answer for now.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[GitHub] [pdfbox] msahyoun commented on pull request #102: Add build using GitHub actions

2020-12-29 Thread GitBox 


msahyoun commented on pull request #102:
URL: https://github.com/apache/pdfbox/pull/102#issuecomment-752061527


   See https://infra.apache.org/github-actions-secrets.html



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-2.0.x #187

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox » PDFBox-2.0.x » Apache PDFBox examples #187

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[GitHub] [pdfbox] THausherr commented on pull request #102: Add build using GitHub actions

2020-12-29 Thread GitBox 


THausherr commented on pull request #102:
URL: https://github.com/apache/pdfbox/pull/102#issuecomment-752057238


   Does this mean that each commit will trigger 8 builds, besides the Jenkins 
builds and the github travis builds? And same for everybody who has forked the 
project?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-2602:
-

Commit 1884904 from Maruan Sahyoun in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1884904 ]

PDFBOX-2602: fix calling PDFDebugger from pdfbox app

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-5056:
-

I've also adding comments warning not to modify after construction, although I 
don't see a reason to do so.

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-5056:
-

Commit 1884902 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1884902 ]

PDFBOX-5056: remove double-checked locking, as suggested by Mike Kaplinskiy

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-5056:
-

Commit 1884903 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1884903 ]

PDFBOX-5056: remove double-checked locking, as suggested by Mike Kaplinskiy

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox » PDFBox-2.0.x #186

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox » PDFBox-2.0.x » Apache PDFBox examples #186

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-5061:
-

Then it would be great. One PITA less 😂

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Task
>Reporter: Oliver Kopp
>Priority: Minor
> Fix For: 2.0.23, 3.0.0 PDFBox
>
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Tilman Hausherr (Jira) 


 [ 
https://issues.apache.org/jira/browse/PDFBOX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-5061:

Fix Version/s: 3.0.0 PDFBox
   2.0.23

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Task
>Reporter: Oliver Kopp
>Priority: Minor
> Fix For: 2.0.23, 3.0.0 PDFBox
>
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Tilman Hausherr (Jira) 


 [ 
https://issues.apache.org/jira/browse/PDFBOX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-5061:

Issue Type: Task  (was: Wish)

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Task
>Reporter: Oliver Kopp
>Priority: Minor
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5061) Migrate to jakarta APIs

2020-12-29 Thread Jira 


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

Andreas Lehmkühler commented on PDFBOX-5061:


The lib uses the Eclipse Distribution License which is a 
[Cat-A-License|http://www.apache.org/legal/resolved#category-a], so no problem 
at all. But I'd prefer to replace the code as we are using just one class from 
that dependency which btw has some additional dependencies on its own

> Migrate to jakarta APIs
> ---
>
> Key: PDFBOX-5061
> URL: https://issues.apache.org/jira/browse/PDFBOX-5061
> Project: PDFBox
>  Issue Type: Wish
>Reporter: Oliver Kopp
>Priority: Minor
>
> {{javax.}}-dependencies have been superseeded by jakarta dependencies.
> To be able to use Apache PDFBox in Java projects using newer JDKs, it would 
> be feasable to use the new jakarta dependencies. I think, only 
> jakarta.xml.bind is affected. [https://eclipse-ee4j.github.io/jaxb-ri/]
> See also https://issues.apache.org/jira/browse/SHIRO-750



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-2.0.x #185

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox » PDFBox-2.0.x » Apache PDFBox examples #185

2020-12-29 Thread Apache Jenkins Server 
See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-5056:
-

[~mikekap] I'll use the first suggestion in a few minutes. The names "cache" 
was introduced in PDFBOX-2262 as part of a huge commit and there's no text why 
it was needed.

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-5056:
-

Commit 1884901 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1884901 ]

PDFBOX-5056: remove unused imports

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-5056:
-

Commit 1884900 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1884900 ]

PDFBOX-5056: remove unused imports

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-5056:
-

Commit 1884899 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1884899 ]

PDFBOX-5056: remove JVM bug related workaround that is no longer needed, as 
suggested by Andreas Lehmkühler

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on PDFBOX-5056:
-

Commit 1884898 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1884898 ]

PDFBOX-5056: remove JVM bug related workaround that is no longer needed, as 
suggested by Andreas Lehmkühler

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-5056:
-

Yes, good idea, lets try it. The code at the time of PDFBOX-2184 was different, 
toRGB() used the sRGB colorspace directly.

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread Jira 


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

Andreas Lehmkühler commented on PDFBOX-5056:


[~tilman] I had a look at PDDeviceRGB. You have removed the unneeded field, but 
shouldn't it be safe to remove the whole init stuff? We don't need a 
preinitialized colorspace anymore neither in toRGB nor in toRGBImage. This 
seems to be a relic from older implementations. Or am I missing something?

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread Mike Kaplinskiy (Jira) 


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

Mike Kaplinskiy commented on PDFBOX-5056:
-

If you just mark contains synchronized that will work. The “bad” code is still 
broken, assuming there are multiple threads involved (I’m not sure exactly how 
that can happen - I don’t know pdfbox well enough).

The solution you committed seems correct. I think sonar just isn’t smart enough 
to figure out the set is immutable after assignment. There’s several other ways 
to fix the problem that might also please sonar. Here’s some ideas:
{code}
public boolean contains(String name)
{
return inverted.contains(name);
}
{code}

Because {{inverted}} has keys that are the values in {{codeToName}}. I’m a 
little suspect of synchronization in the entire class (Encoding) generally - 
like why puts and other gets aren’t synchronized - but that’s a separate 
problem. I don’t have enough context to know whether instances of encoding are 
mutable shared between threads.

Other solutions:
{code}
private Set names;

public synchronized boolean contains(String name)
{
// we have to wait until all add() calls are done before building the 
name cache
// otherwise /Differences won't be accounted for
if (names == null)
{
names = new HashSet(codeToName.values());
}
return names.contains(name);
}
{code}

That is - don’t do double checked locking. Realistically this is testing an 
element in a set - the critical section is tiny cpu time wise and the lock is 
unlikely to hurt.

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For addit

[jira] [Commented] (PDFBOX-2602) Enhance command line tools

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-2602:
-

Not from pdfbox-app:

 

picocli.CommandLine$ExecutionException: Parsed command 
(org.apache.pdfbox.debugger.PDFDebugger[frame0,318,237,1013x526,invalid,hidden,layout=java.awt.BorderLayout,title=Apache
 PDFBox 
Debugger,resizable,maximized,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,0,0,0x0,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true])
 is not a Method, Runnable or Callable
 at picocli.CommandLine.executeUserObject(CommandLine.java:1973)
 at picocli.CommandLine.access$1200(CommandLine.java:145)
 at 
picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2332)
 at picocli.CommandLine$RunLast.handle(CommandLine.java:2326)
 at picocli.CommandLine$RunLast.handle(CommandLine.java:2291)
 at 
picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2159)
 at picocli.CommandLine.execute(CommandLine.java:2058)
 at org.apache.pdfbox.tools.PDFBox.main(PDFBox.java:71)

> Enhance command line tools
> --
>
> Key: PDFBOX-2602
> URL: https://issues.apache.org/jira/browse/PDFBOX-2602
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
>Priority: Minor
> Fix For: 3.0.0 PDFBox
>
>
> The command line tools shall be enhanced to have the same behavior across all 
> tools.
> From the discussion on the dev mailing list
> - add an -h option to print the usage
> - print the usage to System.err and use an exit code of 1 if there was an 
> invalid command line parameter
> - print messages on exceptions to System.err
> - rethrow the exception so java can handle it if it will terminate afterwards 
> anyway
> - use an exit code of 1if rethrowing doesn't make sense
> Additional input:
> https://clig.dev/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-5056) Double checked locking done wrong in several places

2020-12-29 Thread Tilman Hausherr (Jira) 


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

Tilman Hausherr commented on PDFBOX-5056:
-

I just tried the "bad" code from my previous comment and no deadlock. This is 
bad because it means we can no longer reproduce the problem. Maybe because of 
newer jdk, or faster computer.

> Double checked locking done wrong in several places
> ---
>
> Key: PDFBOX-5056
> URL: https://issues.apache.org/jira/browse/PDFBOX-5056
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.22
>Reporter: Mike Kaplinskiy
>Priority: Major
>
> There's several places inside pdfbox where double-checked locking is done 
> wrong. Specifically, double checked locking is the pattern of:
> {code:java}
> private volatile boolean doneInit = false;
> if (!doneInit) {
> synchronized (this) {
> if (!doneInit) {
> ... do init
> doneInit = true;
> }
> }
> }{code}
> Common issues are - lack of {{volatile}} or the volatile set not being last. 
> Here are the cases I found so far:
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceCMYK.java#L60]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/graphics/color/PDDeviceRGB.java#L48]
>  - {{volatile}} set isn't the last statement in the block.
>  * 
> [https://github.com/apache/pdfbox/blob/e409f25009702be8889ce586b8f6dd7274201f0a/fontbox/src/main/java/org/apache/fontbox/ttf/TrueTypeFont.java#L162-L167]
>  - {{initialized}} isn't {{volatile}}
>  * 
> [https://github.com/apache/pdfbox/blob/947966ea830ff91c61a6740ca1787eb795b5ca95/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/encoding/Encoding.java#L132-L149]
>  - {{names}} isn't {{volatile}} and the second check is missing (which might 
> be harmless)
>  * 
> [https://github.com/apache/pdfbox/blob/6c8526bab8b7ca399721e067d065c1f272f97644/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/Standard14Fonts.java#L172-L190]
>  - {{fonts}} isn't even locked and it's a vanilla hashmap that can be 
> modified by other threads.
>  * 
> [https://github.com/apache/pdfbox/blob/7984a52ad4d475886568593614ce566a88bf6bdd/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java#L632-L637]
>  - (tricky to see, but the constructor adds itself to the map) - the map 
> isn't locked before the blind {{put}}, so unclear which invocation "wins" 
> (not sure if this is an issue, logic wise).
>  * 
> [https://github.com/apache/pdfbox/blob/61d6a53eacdee6a40d352509105e1c8d51cfb5dc/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/FontMapperImpl.java#L415-L419]
>  - {{fontProvider}} isn't volatile, though is used as a double checked lock 
> marker. (Not sure if this an issue, concurrency wise).
> Fixing these one-by-one is possible and what I started doing around 
> [https://github.com/apache/pdfbox/pull/90] - but would it make sense to make 
> a class that does this properly? Guava has {{Suppliers.memoize}} which does 
> the right thing - it's trivial to make an equivalent without the dep in 
> pdfbox as well if necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-5062) IllegalBlockSizeException when loading the file

2020-12-29 Thread Zubair Uddin Farooqui (Jira) 
Zubair Uddin Farooqui created PDFBOX-5062:
-

 Summary: IllegalBlockSizeException when loading the file
 Key: PDFBOX-5062
 URL: https://issues.apache.org/jira/browse/PDFBOX-5062
 Project: PDFBox
  Issue Type: Bug
  Components: Crypto, PDModel
Affects Versions: 2.0.22
Reporter: Zubair Uddin Farooqui
 Attachments: Medical services-1 (dup-keywords) (1).pdf

Getting _IllegalBlockSizeException_ when loading the file 

*Code:*
{code:java}
PDDocument pdDoc = PDDocument.load(file);{code}
*Exception:*
{code:java}
java.io.IOException: javax.crypto.IllegalBlockSizeException: Input length must 
be multiple of 16 when decrypting with padded cipherjava.io.IOException: 
javax.crypto.IllegalBlockSizeException: Input length must be multiple of 16 
when decrypting with padded cipher at 
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptDataAESother(SecurityHandler.java:315)
 at 
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:201)
 at 
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:510)
 at org.apache.pdfbox.pdfparser.COSParser.parseFileObject(COSParser.java:929) 
at 
org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:886)
 at 
org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:806)
 at org.apache.pdfbox.pdfparser.COSParser.parseDictObjects(COSParser.java:766) 
at org.apache.pdfbox.pdfparser.PDFParser.initialParse(PDFParser.java:187) at 
org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:226) at 
org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1099) at 
org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1082) at 
org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1041) at 
org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:989)
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org