[
https://issues.apache.org/jira/browse/PDFBOX-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871018#comment-17871018
]
Michael Klink commented on PDFBOX-5862:
---------------------------------------
Looking at a number of methods of {{COSArray}} it seems that the intention is
to allow actual {{null}} elements in the underlying list. Maybe some hardening
in some methods would be appropriate.
When doing {{COSArray}} cleanups, one should probably also look at other
details. For example, the typed getters (like {{getName}}) with default value
parameter claim to return that default value if the entry in question is
{{null}}; actually, though, they also return it if the entry is of a different
type {like not a {{COSName}} in {{getName}}}.
> is o.a.p.cos.COSArray supposed to contain nulls?
> ------------------------------------------------
>
> Key: PDFBOX-5862
> URL: https://issues.apache.org/jira/browse/PDFBOX-5862
> Project: PDFBox
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 3.0.2 PDFBox
> Reporter: Dieter von Holten
> Priority: Minor
>
> inspection by spotbugs shows a warning at line 573, which references a null
> from the list and compares it with the given value. When the list contains a
> null, and a null is passed by the caller, this is considered a match and the
> index is returned to the caller.
> However, other locations in COSArray cannot deal with null entries in the
> list.
> i propose:
> 1.) update the document to state whether null is a valid list-entry
> 2.) consider the use of COSNull when the caller tries to insert null. in this
> case, the users (those who get() values out) of COSArray need to be aware of
> the change
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
