[ https://issues.apache.org/jira/browse/PDFBOX-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated PDFBOX-3155: ---------------------------------- Description: 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". was: 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 2 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". > 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-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org