OHDSI Home | Forums | Wiki | Github

Which Java version(s) do we support?

Developers
#1

Moving the discussion from here to this forum.

What is the Java version we want to support in our tools? @msuchard and me are currently keeping our tools (e.g. DatabaseConnector, SqlRender) at Java 1.6 because

  1. It works
  2. Some users might still be running old versions of Java. Especially Mac users will find their default is 1.6

I can understand some people might want additional features that are only supported in newer Java versions. Personally I think people can use whatever version they want, but for some tools we want to keep the requirements as low as possible. I currently have these tools in mind:

  1. DatabaseConnector
  2. SqlRender
  3. WhiteRabbit

I’m fine with people using different versions throughout OHDSI.

#2

Java has very strict backwards-comparability testing right? so as long as you are careful not to use any @deprecated functions/classes, there shouldn’t be any issues supporting Java 8. If you want to have your app work across multiple JDKs, you could just take additional steps to ensure you are not using any JDK8 specific features.

-Chris

#3

I like your strategy. There are some versions of Java 6 that have security concerns so most folks with Linux servers will probably run 7 or 8. However, I agree that its probably best to stay away from features unique to those versions.

#4

I would like the community to consider moving our web API to JDK 1.8. I found this libary:
http://www.jinq.org/

It seems to emulate linq from ms.net. It needs jdk1.8 because of a ‘stream’ api and the use of lambda expressions. But what’s very nice about it is you can do things like this:

database.customerStream().where(
  customer -> customer.getName().equals("Alice"));

This gets translated (from the jdbc provider) into a query finding customers with name == Alice.

It doesn’t look like much, but this query capability is very powerful.

I think that for our external libraries we should try to be as accessible as possible (such as libs that may be leveraged in R packages), but some of the new features in Jdk1.8 are very handy, and I’d like to consider ourselves very progressive developers.

-Chris

#5

I’ll add this discussion an agenda item on the architecture call. I can see this discussion spilling over to the broader group in the technical breakout at the f2f meeting before we can make a decision.

#6

Hi @Chris_Knoll. If I understand you correctly, you’re saying that if we compile SqlRender to the Java 1.8 VM, it will also run on Java 1.6 VMs as long as we don’t use any functions specific to 1.8? That doesn’t sound right, although I never tested it.

#7

It’s true! it’s the reason why JDK releases come about once every 6 years: they spend a lot of time enforcing backwards bytecode compatablity.

As long as you don’t use any libraries or APIs that are exclusive to JDK 1.8 (or 1.7) you can run the bytecode that only uses 1.6 APIs on 1.8 (provided the 1.6 methods you invoke were not removed from the 1.8 release due to deprecation)…

Here’s some information on it:
http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html

Long story short, if you want to enforce that you do not ‘link’ to any jdk 1.7/1.8 objects you can set that flag. The resulting code will run in 1.7/1.8 but will also run in 1.6 (because that’s what you targeted in your compile flags).

-Chris

#8

Ok, but isn’t that already what we’re doing? (see this line)

#9

Yes. And that’s perfect for SqlRender. My proposal is to allow WebApi to target 1.8 to use some of the more current functionality. SqlRender targeting 1.6 will run inside a WebAPI that is compiled against 1.8.

I’m not saying we do this right away, just asking people to think on it.

-Chris

#10

Ok, then I think we’re actually in agreement. I agree it would not make sense to force WebApi to target 1.6 as well.

t