pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tilman Hausherr (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PDFBOX-3155) org.apache.pdfbox.util.PDFTextStripper class initialization throws NumberFormatException with recent Verona-enabled Java 9 JVMs
Date Tue, 08 Dec 2015 22:05:10 GMT

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

Tilman Hausherr commented on PDFBOX-3155:
-----------------------------------------

Ok, I get it. The Lucene code would still have the major version as 9, but the last line takes
this into account. I misunderstood "it did not break". You meant it only in the way that it
didn't throw an exception.

I'll use something similar to the lucene code tomorrow, so that it can be reused at other
places if needed. The "getSuppressed" is too specific for 7.

> org.apache.pdfbox.util.PDFTextStripper class initialization throws NumberFormatException
with recent Verona-enabled Java 9 JVMs
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: PDFBOX-3155
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-3155
>             Project: PDFBox
>          Issue Type: Bug
>    Affects Versions: 1.8.8, 1.8.10
>            Reporter: Uwe Schindler
>            Priority: Critical
>
> Lucene/Solr runs its whole testsuite also with Java 9 EA releases to trigger bugs early.
In our tests (Solr + TIKA) we found out that org.apache.pdfbox.util.PDFTextStripper throws
a NumberFormatException in its static initializer when parsing the "java.version" system property.
The reason for failure is a change in Java 9, where version numbers got a new format.
> There are 3 problems:
> - It should not assume that all components are really a number. So it should try/catch
NumberFormatException and assign some "unknown" version
> - The code should really use "java.specification.version". This is standardized and only
contains digits.
> - The code should also be prepared to handle version numbers without minor version! E.g.
Java 9 only has "9" instead of "1.9" as its main version number.
> For the use case I would nuke this check and find a better workaround.
> Relying on String parsing for non-standardized system properties in a static class initializer
is the reason why this bug is raised to level "Critical".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message