As I’m getting into the home automation game, and getting to like openHAB more and more, I’m questioning the Java implementation slightly. While it’s not a huge issue, having to rely on a VM forces me to have to worry about maintaining two versions (that of the JRE, and that of openHAB itself), while if the openHAB server was a standalone binary I would have only to worry about one. Furthermore, the community wouldn’t have to rely on the Java Runtime implementation to support architectures, if the binaries could be compiled for them directly. I also think younger developers are increasingly growing reluctant to get into Java, so using something that is considered more modern would in my opinion make the project more attractive to get into for newcomers.
As Rust is getting more established I feel it would be a great candidate for a platform on which openHAB could have an alternative implementation, and now I’m wondering: Do any such efforts exist?
Rewriting a whole thing from one language to another just because second one is getting close to 0.5% in TIOBE is not a valid reasoning.
This is not really against rust nor any other language reaching some level of adoption but the idea itself.
First we have to exercise if we have reached limits of existing platform. Does it cause any major troubles for users and/or developers? Are there problems which we can not solve with present setup? What potential benefits for end users will new platform bring? What kind of troubles new platform will give to both users and devs?
Moving such large project from one language to another is really hard and anyone who ever tried to rewrite software knows that. It takes lots of effort and patience to complete such challenging task. If you take a look on openhab stats at ohloh you will find that existing codebase of OH is same if not more lines of code than Rust itself.
If your primary problem is necessity of installing JVM instead openHAB alone there are ways to avoid that. Many commercial applications ship JRE bundled in single installer. For OH project it doesn’t make much sense for now as it would result in extra 50-80 MB in download size, extra build steps and maintenance burden.
I wasn’t thinking about even recompiling anything myself, but if there was a vulnerability or a bug in the JRE, I would have to update that, or if an updated version of openHAB needed a newer version of Java then I would have to update my JRE in addition to updating the openHAB binary.
Now you’re mixing the system design, and the tools with which to implement it. I think a very low fraction of the world would consider developing anything even in Rust simple, I just think from experience with both Java and Rust that for a system like this Rust does have some benefits so I got interested in exploring the idea. The architecture seems great to me and I wouldn’t want to change it.
I totally agree. I don’t think that anyone has to worry about Java support.
Also I think that if this will be agreed by most of the developers it would take a huge amount of time, thus slowing down or completely stopping again the bindings development (new bindings, bug fixes), which will be visible for even “simple” users, where migrating to a new language will not be very visible (at least from that perspective that it would make more bugs in the beginning than openHAB has now).
However, does anyone considered Kotlin support? If one problem is that ‘Java’ is too old and not so popular, adding Kotlin support could help on this. And if I’m right this would not require anything to be reimplemented again, but new bindings and bigger refactors could use Kotlin, mainly for its simplified syntax…
Thank you very much for your reply. A followup question of mine is now answered as I was wondering how big of an effort it would be to embark on the endeavor.
Changing the base language would be a ground up reimplementation of OH. As such, it really wouldn’t be openHAB anymore. Keep in mind that openHAB is more than just the code. It’s an architectural, a community, and a system built upon more than a decade’s worth of development. This makes openHAB older than Rust btw. But even if you just look at the code, you are looking at rewriting everything. The core, the bindings, the rest of the add-ons, the UIs, … everything!
And then choosing a language like Rust will be a relatively big hit to our cross platform support. Right now we can run openHAB on pretty much anything. With Rust, at a minimum we would have to maintain separate builds for every supported platform (which would be a smaller list because of that) and potentially separate versions of the code for each.
Your listed benefits to moving to another language simply do not justify the effort in my opinion.
Ok, thanks a lot for the insight. I was playing with the idea of starting on a re-implementation myself, but I think I’ll take some time to get more familiar first. I hope nobody took any offense, and I hope my question can been seen as a symptom of my enthusiasm for openHAB!
What don’y you like?
The User interfaces all use the REST API so you should be able to design your own UI to manage and use OH without using Java, if you desire.
I just don’t like the fact that I have to install Java first, if possible I always like to be able to just run an executable. The Web UI and apps are of course separate from this, and that’s why I was kind of hoping the core part wasn’t too big and would be relatively easy to implement in a different language, seeing as the architecture has already been designed and laid out in the current implementation.
I run OpenHAB in a docker on my Centos 7 home “server”. I don’t have to worry about package dependencies, which java version is installed, and whether there’s any conflict. In my opinion, this set up is the ideal, unless you want to run openhab on a raspberry pi, in which case you would just use openhabian.
If you don’t like to have the adoptation to different os in a different software, JRE, and instead have to write that yourself, then you are right.
But there are sollutions to that, you can extract from JRE and OH and create a new binary which contain only the needed parts, in one binary.
But then, if you have a bug in Java, you need to rebuild it all.
If you find an bug in OH, you need to rebuild it all.
You have to rebuild it for different OS and different CPU, as with other binaries. Now the jre contain all that adoptions.
As someone wrote, it isn’t worth the work and pain to rewrite OH in another language. Better to start with something new.
No, Java are a stable language, compared to Rust. Java is backward compatible,and STILL add new features. It is an Enterprice language, Rust is not.
I wouldn’t say Rust in itself brings any major technical reasons to the table that would make rewrite of OpenHAB sensible. The only reason to consider Rust at all would be if developers and maintainers of OpenHAB decided they need a rewrite in the first place, whatever reason they might have had for that.
Even then, there are many other very reasonable language choices out there to a project like OpenHAB. Most of this project is not security sensitive as it never gets exposed to the external world… unless you’re a fool of a sysadmin and fail to follow the deployment instructions; and for safety conscious portions of it Java is a similarly sensible choice, for it is a reasonably safe language itself.
All that being said, I do agree that Java has less than ideal experience in deploying it. Effective Java deployments are a full time job in itself. Java’s runtime defaults are unlikely to be anywhere near ideal for a typical single home openhab deployment, for instance. Still not something over what I’d spend multiple man-years in rewriting a project.
