Core: 1.11.x doesn't build anymore (with Java 7)

Development
1

@dkayiwa,

As discussed on IRC earlier, I’m facing a weird issue when building Core branch 1.11.x with Java 7:

Failed tests: 
  getTimeZoneOffset_shouldReturnTimezoneForGivenDateAndNotTheCurrentDate(org.openmrs.hl7.HL7UtilTest)

Sounds like it could be linked to my time zone? It strangely reminds me of EA-76 again. Full log here.

2

@mksd What is your maven configuration, I have been able to build on mine with no issues

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T19:41:47+03:00) Maven home: /usr/local/Cellar/maven/3.3.9/libexec Java version: 1.7.0_80, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: “mac os x”, version: “10.12.3”, arch: “x86_64”, family: “mac”

3

Here:

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.7.0_95, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-59-generic", arch: "amd64", family: "unix"
4

@mksd Can you try Oracle JDK instead of open-jdk. You can use http://www.jenv.be/ to maintain multiple JDK versions on your machine and switch between them

5

By the way, what is your time zone?

6

GMT+7 (I used to be on GMT+2).

7

I can build it with the oracle jdk, looks like the travis build is failing too for the 1.11.x banch and it’s using opendk too but when I look at the logs the failure is because of something else.

8

Tangential fyi–we just switched many of our implementations from Oracle JDK 7 to OpenJDK 7 because of a securtiy recommendation we received. Oracle JDK 7 in EOL, so OpenJDK 7 has more recent releases with security patches that Oracle JDK 7 does not.

9

@mksd i mean something that i can use in a call like this: DateTimeZone.forID(“Europe/Moscow”);

10

Try Asia/Saigon.

-Darius

11

Then yes as @darius said or "Asia/Phnom_Penh".

12

Did you get this resolved? If not, does it still fail for platform 1.10.x and 1.12.x?

13

I just tried 1.10.x and 1.12.x and I get the same error.

I debugged a little bit I can confirm that these instructions return different results in OpenJDK 7 vs OpenJDK 8:

Calendar cal = Calendar.getInstance();
cal.setTime(givenDate);
timeZoneOffset = new SimpleDateFormat("Z").format(cal.getTime());

And this is for the exact same givenDate:

Fri Dec 25 00:00:00 GMT 2009

The effects are consistent with OpenJDK 7 ignoring the temporary setting to "EST" here:

TimeZone.setDefault(TimeZone.getTimeZone("EST"));
14

And just to cross check, has this ever compiled successfully for you on Java 7?

15

Yes sure, when I was using my Mac. So there are two main differences between now and then:

  1. Oracle JDK vs OpenJDK
  2. GMT+2 vs GMT+7 (I was on a different time zone)

I will try to find the time to install Oracle JDK 7 on my Linux laptop, and confirm whether changing the JDK implementation is the culprit. I’m not sure when I’ll be able to do that though…

16

The culprit seems to be OpenJDK, I could successfully build Core 1.11.x with Oracle JDK 1.7.0_80 (while it fails with OpenJDK 1.7.0_95).

17

Looking at 1.11.x’s .travis.yml I see

jdk:
 - openjdk6
 - oraclejdk7

When it comes to Java 7 it is clear that OpenJDK has been filtered out…

18

Thanks @mksd for the update. It must be the same OpenJDK 7 problem that is resulting into this CI failure https://ci.openmrs.org/browse/TRUNK-LATEST/latest

19

I’m running OpenJDK 7 (on Ubuntu 16.04), and just tried building 1.11 and can confirm I experience these build failures.

So I looked into this a bit, using the HL7UtilTest. I was able to fix the issue by changing this line:

TimeZone.setDefault(TimeZone.getTimeZone(“EST”));

To this:

TimeZone.setDefault(TimeZone.getTimeZone(“GMT-05:00”));

My hunch is that at some point the Timezone data was updated, and EST became an invalid value to retrieve a timezone. If you look at the way the Timezone.getTimeZone(String) method works, you’ll see that will fall back to GMT if it fails to parse the passed in ID (the method below is called by the above public method with fallback==true):

private static TimeZone getTimeZone(String ID, boolean fallback) {
    Object tz = ZoneInfo.getTimeZone(ID);
    if(tz == null) {
        tz = parseCustomTimeZone(ID);
        if(tz == null && fallback) {
            tz = new ZoneInfo("GMT", 0);
        }
    }

    return (TimeZone)tz;
}

If someone wants to take this on and commit this fix (and backport / forward port as relevant to other branches), that’d be awesome.

Thanks, Mike

2 Likes
20

I have committed using: https://issues.openmrs.org/browse/TRUNK-5079 Thanks @mseaton :slight_smile:

1 Like