You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Jörg Waßmer (Jira)" <ji...@apache.org> on 2020/09/11 14:15:00 UTC

[jira] [Commented] (PDFBOX-4956) COSName.hashCode initialized after put to cache, instead before

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

Jörg Waßmer commented on PDFBOX-4956:
-------------------------------------

Furthermore, the static fields for the caches should be final, And COSName.clearResources() has no need to be synchronized, since using ConcurrentHashMap.

> COSName.hashCode initialized after put to cache, instead before
> ---------------------------------------------------------------
>
>                 Key: PDFBOX-4956
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-4956
>             Project: PDFBox
>          Issue Type: Bug
>    Affects Versions: 2.0.21
>            Reporter: Jörg Waßmer
>            Priority: Major
>
> In the constructor org.apache.pdfbox.cos.COSName.COSName(String, boolean), the field COSNam.hashCode becomes initialized after the COSName instance has been added to the cache.
> Thus, concurrent threads using the cached instance may see different values in COSName.hashCode().
>  
> Just to mention, that's another problem:
>  The whole caching is quite dirty, because it leaks memory if the application is not aware of calling COSName.clearResources().
>  Ideally, the class COSName would not exist at all, since it has no benefit over using strings directly. Of course, it would be quite a hard work to get rid of it.
>  



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

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