geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hitesh Khamesra (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (GEODE-1808) gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java version 1.7.0_101
Date Fri, 10 Feb 2017 21:34:42 GMT

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

Hitesh Khamesra closed GEODE-1808.
----------------------------------

> 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
>             Fix For: 1.1.0
>
>
> 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.15#6346)

Mime
View raw message