[jira] [Commented] (GEODE-1808) gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java version 1.7.0_101

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on GEODE-1808:
--------------------------------------------------------

Commit e7e372368941dc391669015716e7e03f1e163679 in incubator-geode's branch refs/heads/develop from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=e7e3723 ]

GEODE-1808 Remove broken check for jdk1.7.0_72

The logic for evaluating jdk versions is incorrect for 3-digit builds.
Since we require a jdk1.8 version anyway, remove the check.


> gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java version 1.7.0_101
> ---------------------------------------------------------------------------------------------
>
>                 Key: GEODE-1808
>                 URL: https://issues.apache.org/jira/browse/GEODE-1808
>             Project: Geode
>          Issue Type: Bug
>          Components: general
>            Reporter: Sergio Valenti
>
> We have recently updated out Java version to 1.7.0_101 on our server.
> However, after starting our java component which runs Gemfire version 8, we get the following log line:
> | FATAL | 20160821 18:05:30,626 | main | gemstone.gemfire.internal.cache.MinimumSystemRequirements | Java version older than 1.7.0_72.
> After looking at the source, it is apparent that the issue is in com.gemstone.gemfire.internal.lang.SystemUtils when dealing with java revisions which are 3 digits long
>     public static boolean isJavaVersionAtLeast(String expectedVersion)
>     {
>         String actualVersionDigits = StringUtils.getDigitsOnly(System.getProperty("java.version"));
>         String expectedVersionDigits = StringUtils.padEnding(StringUtils.getDigitsOnly(expectedVersion), '0', actualVersionDigits.length());
>         try
>         {
>             return Long.parseLong(actualVersionDigits) >= Long.parseLong(expectedVersionDigits);
>         }
>         catch(NumberFormatException ignore)
>         {
>             return false;
>         }
>     }
> If you walk through this code with an expected version of java: 1.7.0_72 and an actual version of java: 1.7.0_101, it will create the following two long variables and compare them:
> actualVersionDigits	        "170101"
> expectedVersionDigits	"170720"
> Which causes the comparison check to fail.



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