As some of you might know, we upgraded to java 8 in the master branch of openmrs-core, we want to know if you are aware of any issues or inconveniences that you might run into while working on your modules to support newer versions of the platform?
@mogoodrich & @mseaton, i’m aware you oversee modules that support multiple versions of openmrs Platform, do you anticipate any issues when you attempt to add support for Platform 2.0 and later which will be requiring java 8?
@wyclif, could you be a little bit more specific about what you’re asking here?
As I read these two messages, you’re suggesting that HFE and Reporting will be expected to support openmrs-core 2.0 (which will use Java 8) and based
on your test this will mean they can’t be compiled with Java 6. So the implication is that HFE and Reporting will be expected to drop Java 6
That seems like a dealbreaker to do anytime before openmrs-core 2.0 has been released, at the very least.
@wyclif, you can’t compile the whole module with Java 8 target, because it won’t work on older versions of OpenMRS platform, but you should be able to configure maven-compiler-plugin to compile with Java 6 target all submodules except for the 2.0 submodule that needs to be compiled with Java 8 target. I haven’t tried that yet.
It practice it means you will have to have JDK 8 to compile the whole module, but you will set target and source of maven-compiler-plugin for 1.6 and 1.8 respectively. Using source and target is not ideal as you may leak JDK 8 API into Java 6 code, however there’s an animal sniffer maven plugin that breaks the build when you do so.
Assuming I can simply change my JDK to build using Java 8, and set up the pom of all of my modules to compile with Java 6 compatibility (which is what is already in place in most modules as far as I know), then there shouldn’t be any issues unless there are particular known backwards-incompatibilities that we should all be aware of. I already use a Java 7 JDK under the hood…
Mike is correct, and that is what i meant, they will still need jdk 8 to build the entire project since anyways they will need it for to build the 1.12 submodule, but they can’t build the entire project with jdk6 which is think shouldn’t be a problem. The jdk that spawns maven is what matter here, setting target and source properties for the compiler plugin doesn’t enforce which jdk should be used to compile the code, if you need to enforce that, that’s when the animal sniffer plugin comes in.
FYI, i posted a question about the 1.12-SNAPSHOT jar file missing in the final omod when i add a 1.12 sub module to webservice.rest, it could be related to why the build fails on java 6. The specific failure when i build with java 6 was that if i have a new class in 1.12, it can’t be found at compile time. @raff any ideas?
I managed to create and test a 1.12 sub module and i can say modules like webservices.rest and HFE etc will still be able to support multiple versions, the only things is that the module developers will need to have and use jdk 8 to build the project which i think is fair and they can actually use the new java 8 features within the 1.12 sub module.
@raff by the way i tested the animal sniffer configuration and it doesn’t seem to catch the scenario where i use a java 8 only API in the 1.12 sub module when building the module, and am starting to think it is un-necessary because i would imagine devs are allowed to use the java 8 APIs in the 1.12 sub module
Looking through this thread it looks like we’re in pretty good shape.
I’d assume that there’ll be a 6-12 months period during which users in both Java 6 and Java 8 environments will want to be able to run modules like HTML Form Entry and Reporting. It looks like @mseaton is already supporting Java 6 reporting while using a Java 7 JDK, so switching to JDK 8 shouldn’t be a big deal.
If anyone discovers any new Java 8-related issues for module developers, please add them to this thread.