Well, according to Oracle we will not get any public updates for their JDK 8 anymore. Unfortunately, OpenHAB 2 and as such Eclipse Smarthome heavily builts on top of this version.
I’m not that deep involved in the current discussion (if there is any). But what’s the status in this area, what JDK will we able to use in the near future?
I mean, no public updates also include security update. And security questions should be taking seriously in a serious smarthome development community.
Oracle Java has already sort of been depreciated, Zulu is the current recommendation.
There’s work going on to make the openHAB code ready for Java 11 but this will still take some time, particularly as there’s more important stuff upfront (ESH reintegration) and there’s nothing wrong with staying on Java 8.
No more updates does not mean it doesn’t work any more (it’s rather the opposite).
There is an issue that will be used to track progress:
I think there should be some push in the future to make openHAB fully compatible with Java 11 as it will be the default installed Java on later OS distributions.
Wow, thanks Benjy
Hi Markus.
This wasn’t a question about if the JDK8 is working or not, but that it’s not getting any security updates anymore. Sorry, but for me that’s the most important thing in this matter.
Well, I will follow this up and make my decision if I should stay (and recommend) OpenHAB and Eclipse smarthome based on how the maintainers prioritize security questions. However, your answer’s not really encouraging, though.
I wouldn’t put too much emphasis on it. I believe Zulu will continue to maintain Java 8 for at least some time (it’s their business).
Also the predominant mode of installation is to run on a dedicated box with no users and no internet connection, standalone network if needed. The risk associated with that is far lower than anything to require a Cloud service.
There is no project lead and no developers for eclipse smarthome at the moment, so the java situation will not change over there. For openhab most bundles work with java>8 already. Some like the xtext/xtend depending bundles (.thing/.item/.rule file parser) don’t.
You can use openHAB 2.4.0 with Java 11 today if you:
If you do run into some other new issue, please report it so we can keep track of it.
To keep things simple, it’s better to currently recommend everyone Java 8. We depend on the contributors/maintainers of these other projects to get these issues fixed.
Wow. Didn’t know that. That’s pretty bad. I mean OpenHAB seam to be their reference implementation (according to their web site) and is building on their architecture. When you say their have no project lead nor developers, is right to conclude OpenHAB has no architectural lead either?
No problem in my specific case. However, wouldn’t it be better to jump onto the Java 11 train and cut the lines those parts not compatible? E.g. by setting a deadline?
Thanks for the info Scott. Now this makes sense to me. How could one help during the reintegration process?
I don’t think there’s much to do during the reintegration, unless you want to jump in to help. There are a lot of bindings pending review/approval… you may be able to help with those during the framework freeze/thaw cycle.
It may be better to ask in the other thread though! 
It’s a bit pointless to build an openHAB release without all bindings that use serial devices just because openHAB doesn’t work well with Java 11 on Windows (nrjavaserial#131). Let’s hope this show stopper is fixed in time for openHAB 2.5.0. 
Amazon looks like they are taking over the torch from Oracle. They will be providing a supported versions of OpenJDK 8 for a few years: https://aws.amazon.com/corretto/
Hi,
I just saw this thread, and thought to share my info on this. I’m OpenHAB user, and I work at Red Hat, open source company which many of you likely know. This Oracle Java question is big discussion now at our customers too, and I’d like to comfort there is likely no need for any panic (likely, due as mentioned not all features work on it). OpenJDK will remain supported also by Red Hat, and as we have upstream first policy, it will be maintained open in upstream. So there is no hurry to get away from it. Of course, such Oracle dependencies should be dropped away. OpenJDK11 support is also coming up.
Here’s a bit more info into the subject: https://developers.redhat.com/oracle-java-support-openjdk/
I’m not here to advertise the company, but also as a user of OpenHAB, just to offer my view that there will be open source OpenJDK for future too.
BR,
ikkeT
Well, as I see it there will be more and more commercial players popping up, now that Oracle dropped public support for Java SE 8. Question is: Which one can we trust (Amazon? seriously?) and which one will provide “free” support (RedHat? Probably only for
their Enterprise customers using their Enterprise Linux version).
This is pretty much the old dilemma of Java since the very beginning: It was never really Open Source. From the software engineering perspective, I really like OpenHAB. However, I take information security quiet serious even at home. And together with the previous
experience with Oracle, I will not base my smart home and security appliance on a platform driven by companies like Zulu, Amazon or similar offering “free” support, without knowing about what they get for it.
I know this isn’t OpenHAB specific (we face the very same problem at work). This is Java (Oracle) specfic. And this will last as long Oracle still claim their ownership.
I think you confuse open source and support. Open source is development method, where as support is what happens after the development release. OpenJDK is open source upstream. And yes, companies do sell support for it with different terms. Source is free open source, but support varies, can be free or paid. And have different terms. But upstream first policy keeps it evolving openly.
I see OpenJDK is very core piece of e.g. RH middleware offering, and will have good lifecycle and roadmaps. There are heavy weight users for that.
Let’s see. Was on JFocus19 in Stockholm, and from Oracle this is how I understand it will be.
Java is developed in/by OpenJDK, which is not Oracle. It has a release schedule of 6 month, and that is not negotiable. And yes, Oracle are and probably will still be the main contributor. There will be Long Time Supported versions though, but Oracle will not be supporting OpenJDK LTS, others will do that, like Red Hat. Oracle will support their version of OpenJDK, and give support to their paying customers. As others also will do.
Oracle JDK are and will be based on OpenJDK, there will be no differences as it was before OpenJDK 9. But if you want to have Oracle JDK, you have to pay for their support.
So no, it will not be a big issue, just use OpenJDK and/or others compilations, like those mentioned here in this thread, like Oracle, RedHat etc.
OpenJDK will have long time supported versions, which OpenJDK 11 will be one.
So the choice is the blue or red pill, as they said. Go on the rolling 6 month schedule, and have the latest. OR go for the LTS, which will be at least supported to then next LTS and probably longer.
OpenJDK are based on modules, and THIS is the big thing. The rest of the changes is just nice to have additions.
But modules ARE changes, so there have and will be removed methods, classes, packages and modules. Some notable is java.EE, which is Java Enterprise Edition, and web server support. You can get those from other support though, like today with many different Java Servlet Containers.
Modules are basically a collection of packages, where you tell which other modules you uses and need.
So, the main thing is Modules. And so OpenHAB should transfer to use modules, even if other libraries have not done the transfer yet. Yes, there are ways of temporarily ignore those module warnings, but they WILL stop to work, but for now we get warnings. So, warnings now will be fatal later.
There are gradual ways of transfers to use modules, but it need to be done.
Modules have the nice property that you can collect modules that your program uses, and create a Java RE that only have those needed modules. Which will make a smaller RT and a Java that uses less memory in distribution and when running. Yes, you can make a RT which IS your program. And that will probably be the preferably way of distributing programs.
That is with modules it will be like linking in GCC and other program languages.
BTW, heads up to Quarkus: https://developers.redhat.com/blog/2019/03/07/quarkus-next-generation-kubernetes-native-java-framework/
This one path Java development will be taking. Check out the boot time