[
https://issues.apache.org/jira/browse/PDFBOX-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved PDFBOX-815.
----------------------------------
Assignee: Jukka Zitting
Fix Version/s: 1.3.0
Resolution: Fixed
I don't see a big thread-safety problem here, as there should be no functional
effect even if two getEncodingManager() calls happened to end up creating
parallel EncodingManager instances.
Anyway, I agree that using static singleton instances is a better approach
here, so I did that in revision 992271. Note that this rendered the
getEncodingManager() method unnecessary, so I decided to simply remove it
instead of keeping it around as a deprecated method. It was introduced in
PDFBOX-601 and should probably never have been non-private to start with.
> PDFont.getEncodingManager is not thread safe; FIX included
> ----------------------------------------------------------
>
> Key: PDFBOX-815
> URL: https://issues.apache.org/jira/browse/PDFBOX-815
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 1.3.0
> Reporter: Timo Boehme
> Assignee: Jukka Zitting
> Fix For: 1.3.0
>
> Original Estimate: 0.17h
> Remaining Estimate: 0.17h
>
> In class PDFont calling static getEncodingManager is not thread safe. Two
> solutions:
> (1) with lazy initialization (thread safe with Java 1.5 and later)
> private static volatile EncodingManager encodingManager = null;
>
> protected static EncodingManager getEncodingManager() {
> if(encodingManager == null) {
> synchronized ( PDFont.class ) {
> if ( encodingManager == null )
> encodingManager = new EncodingManager();
> }
> }
> return encodingManager;
> }
> (2) create singleton at class initialization time
> private static EncodingManager encodingManager = new EncodingManager();
>
> protected static EncodingManager getEncodingManager() {
> return encodingManager;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
