[jira] [Updated] (DERBY-6518) JVMInfo should not use parseFloat() to parse java.specification.version

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-6518:
--------------------------------------

    Attachment: d6518-1a.diff

Attaching d6518-1a.diff which changes JVMInfo so that it compares each component of the version number separately, instead of using parseFloat() on the entire version number. I tested the logic manually by hard-coding the javaVersion variable to values the original logic didn't handle correctly (such as "1.8.1" and "1.10"). All regression tests passed with the patch on JDK 8.

> JVMInfo should not use parseFloat() to parse java.specification.version
> -----------------------------------------------------------------------
>
>                 Key: DERBY-6518
>                 URL: https://issues.apache.org/jira/browse/DERBY-6518
>             Project: Derby
>          Issue Type: Bug
>          Components: Services
>    Affects Versions: 10.10.1.1
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: d6518-1a.diff
>
>
> JVMInfo uses parseFloat() to parse the java.specification.version property. That won't work correctly if the minor version has more than one digit. It should order the versions like this:
> 1.7 < 1.8 < 1.9 < 1.10 < 1.11
> With parseFloat(), they are ordered like this instead:
> 1.10 < 1.11 < 1.7 < 1.8 < 1.9
> The result is that newer Java versions will be classified as older, less capable ones, and some functionality might be disabled because Derby thinks the platform is not capable of providing it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)