pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (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:17:11 GMT

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

Uwe Schindler commented on PDFBOX-3155:
---------------------------------------

We just compare versions, so for us it does not matter if it is 1.9 or 9.0. To detect minimum
java 8 we check for larger than 1.8, for java 9, we compare that it's larger or equal than
1.9 (so we hit old and new variant). When java 10 comes out we compare with 10 and so on.
The gap in versioning does not matter because order is still increasing.

See last line defining the jre-is-minimum... Constants. It's just greater than :)

The getSupressed trick is matching any Java version on or after Java 7. So it should work
for the code here. I don't know what you mean with "too specific".

If you are interested, I have similar tricks for later versions...

> 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