Change Java providers and add support for Java 17

[ecdye]

Replaces #1603 Fixes #1602

Signed-off-by: Ethan Dye mrtops03@gmail.com

[ecdye]

err I don't get that. Do you throw out Zulu ? Why ?

Primarily simplicity, it solved the problem of Java 17 in arm32 and allows for better integration with APT. I contacted Zulu and they ignored me when I asked about arm32 support.

And we haven't been testing against OpenJDK lately, have we ?

We have, Zulu was a build of OpenJDK the main difference is that this PR switches to using the builtin package repo. At some point when Adoptium (formerly AdoptOpenJDK) creates their package repo for Debian I plan to add support for that as well to give the user some more options.

As for testing in general, I have been using the APT install that this PR changes it to for a little while now and have observed no issues. In then end I primarily comes down to the simplicity and ease of use that using the builtin package provides.

We couldn't do this in the past because there was never an up to date package that supported what we needed in the repos but now there is and unless Debian vastly changes the way they do packaging should continue to be.

But a single word answer: Simplicity :)

[ecdye]

@mstormi As a side note, this PR will require a new image build, but existing installations should continue to work like normal. Guess we are just getting a lot of releases for the new year 🤷

[ecdye]

Yes, I was planning to do that once I got the general approval from you.

[ecdye]

@mstormi Any chance for a review?

[mstormi]

too much to do ATM sorry

[mstormi]

Still a lot of references to zulu in the sources. Either keep those and add an option to install Zulu, or at least remove all of them. But as said I don't like doing that while driving.

[ecdye]

I understand your concern, however like I said before the only difference is the provider and Debian packages are almost guaranteed to be stable.

The whole idea of the main branch is that it is a testing branch so I don't feel bad about merging there for the moment as well. If it ends up not working out for a bunch of people then we can always revert before we have the next patch day.

As for Zulu references I thought I got them all, I'll work on double checking them all.

[ecdye]

@mstormi I'm not seeing any references to Zulu outside of the ones in the CHANGELOG from a past announcement which should stay there.

[ecdye]

Force-Pushed to fix conflicts after rebasing my branch on head.

[mstormi]

@mstormi I'm not seeing any references to Zulu outside of the ones in the CHANGELOG from a past announcement which should stay there.

Ok. I looked in the wrong place when I saw those.

[ecdye]

However, we need to prepare for the eventual need to roll back a user's system. Let's say someone switches main and there's an issue with openJDK. Ok, no big deal, the guy is on the testing branch and this can happen. But now what ? We also need to tell that poor guy how he is supposed to get rid of it again to get his system back working. If we have to tell him there's no possibility to fall back (to Zulu, which is what he had been using) and even if it's only one or very few to people to be affected, that might nonetheless escalate into some PR desaster. This is why I'm asking to keep the ability to install Zulu for a transition phase as a safety net (for us, not the user). (and yeah I'm ok with you calling me paranoid ;-) )

Perhaps you are paranoid however, I think of it like a Band-AID you have to just rip it off quickly. We already have a safety net of returning to the openHAB3 branch until we forward. If it turns out that I am wrong and there are stability issues with it that I am not observing in my tests then it is fairly trivial to revert this one PR and go back to the way it has always been.

Note this is independent of the branch: should we decide to forward main to openHAB3 at some stage, we can still run into the same situation later on, no matter how well this is tested.

Perhaps so, but if we refrain from forwarding changes for a period until we are reasonably confident that there will be no issues on a typical install then we should have no problem with pointing out the fact that in most cases any errors are going to be caused by a modified base system.

Mind that it's not necessarily only potential issues with openJDK. Issues could also rise because we (openHABian) use Zulu specific parameters like heap mem size. Or other stuff we don't spot or think about right now.

Those are actually parameters are actually universal in java so there should be no issues.

[mstormi]

Your band aid may be infectious and worsen your injury or illness (and without that you notice right away). Unwrapping it = uninstalling Java leaves a user with a non functional system and no idea how to get his old system state back. Also, if someone wants to determine if an issue is due to the Java version, he must be able to quickly change Java providers forth and back (and nothing else like also the branch). Also please do not overestimate your own testing and people's of main. There's not many to test, and they're not representative for the mass of users.

I've been an IT professional in operating other people's IT for decades and I've seen soooo many edge cases and incarnations of Murphy's law. I learned that acting professionally means providing a full (and quickly and reliably applicable) rollback option to users on every change that comes with a risk of major issues. Independent of how low I myself consider that risk to be (that latter makes up for the 'professional' attitude in this).

Also, risk = probability impact. It isn't us to get hit by issues (in the first place). We can estimate and minimize the probability but we cannot judge or ease the impact hence not the total risk our change means to the user. Acting professionally also means to change pov at times, i.e. evaluate our (developer) work from a user pov. Users have different priorities. They don't want the system to change unless they decide to change it. See how many OH 2.5.x (x older than current) users are still out there that now suffer from bintray. Users want to have a 100% fallback capability for any changes, at all times, and even more so when it isn't them themselves to take the decision to change. Once the Java change is out people will start blaming it and us for all sorts of issues the change didn't cause just because they don't know better. A rollback will prove them wrong and silence them. Not* providing any rollback option OTOH will make them turn angry. Don't underestimate this. I've seen this pattern escalate quickly several times in my professional life, and I'm not keen on seeing it again. Switching branches (+ reinstall Zulu) isn't an acceptable rollback, it is just a temporary hack until we forward the branch.

Why take the risk of bad PR (even if technically speaking wrongly attributed) ? Just to prove your work, testing and risk assessment are perfect ? They might be I'm not questioning that, but the risk we don't have to take nonetheless, and I don't want to waste my time on support discussions and justifications.

Switch to OpenJDK as default but keep offering Zulu as an option. That's all I ask for.

[ecdye]

Very well, I will reimplement it. It should make it so that we don't need a new image build as well. I don't plan to readd AdoptOpenJDK for the reasons outlined in the changelog already. I also don't plan to readd the tests for Zulu as it is only a safety net by your description until we are ready to remove it completely.

[mstormi]

Thanks. I'm fine with that plan and yes you may remove Zulu again as soon as we're convinced we're on the safe side.

[mstormi]

I forgot to ask: what does OpenJDK do w.r.t. 32/64 bit ?

[ecdye]

It is a apt based install which means it goes the architecture that most closely matches the hardware the user is running on. So if a user is on the 64 bit beta image they will git a 64bit install otherwise it will got with 32bit.

[hmerk]

@ecdye @mstormi Sorry to step in late, but our docs still recommend Zulu as Java provider, so referencing it as deprecated is a bad idea.

[ecdye]

I don't see any problem with that. My one concern is that openHABian is moving towards using the integrated package repository to install Java ultimately removing Zulu as the default for openHABian. I can see how this would cause some confusion but perhaps it would be better to rework the docs a little bit.

We are moving away from Zulu for the increased usability and reduced maintenance required for the non integrated install because of the lack of APT support. I believe that it is not a bad thing to keep recommending Zulu for users who choose to manually install on their own system as it has been great for us. Over time, however, it has become clear that the closed and commercial oriented nature of Zulu/Azul's distribution system does not fit well with the goals of the openHABian project.

I would love to hear more thoughts on this as I do think it is an issue, however I don't think that supporting Zulu forever in openHABian is the right solution.

[hmerk]

@ecdye Has this ever been discussed with the core-maintainers ? Such a change should be in sync with the openHAB project, so as long as we recommend Zulu 11, openHABian should have this as the default/only Java provider. Nature of Azuls/Zulu distribution and future use of it should be discussed on a different place before introducing changes here.

[ecdye]

This was never discussed with the core maintainers. I don't fully understand why it is related, why should openHABian be forced to use a specific distribution of java, isn't that part of the modularity of openHAB, that it doesn't need to be run on a certain platform but just Java.

The real issue with Azul is that there is no support for our use case in openHABian requiring an extensive api routine that fails at times and does not offer the most ideal packages for small systems like RPis. The advantage of switching to the Debian/Raspberry Pi OS offering is that they are easier to maintain and have better support for the Raspberry Pi systems we primarily support.

My point being, would it not just be better to say in the docs that many users have found Zulu to be a very good option for Java but any full java 11 JVM should work fine?

[mstormi]

@ecdye Has this ever been discussed with the core-maintainers ?

As Ethan said no it hasn't, then again, to the best of my knowledge, Zulu was never chosen or approved by core maintainers but only ever decided for by our openhabian maintainer predecessors. @hmerk please let us know where our docs reference Zulu. If I was to guess that docs part was written by our predecessors or maybe even myself and not by any core member. I'd think our best option is to change that recommendation in those docs to OpenJDK so we don't confuse users who read this.

[ecdye]

I believe that @hmerk is referring to the reference in general that openHAB prefers Zulu as its java provider here @mstormi.

[mstormi]

In the 3.2 release thread some said using the menu to revert to Zulu doesn't work so I tried and yes it didn't work for me either. Ethan could you please check that out ?

[ecdye]

Fixed it should work now. I forgot to change the rejection of custom Java to support our change of default providers.

[hmerk]

I believe that @hmerk is referring to the reference in general that openHAB prefers Zulu as its java provider here @mstormi.

That's exactly my reference.

[hmerk]

I'd think our best option is to change that recommendation in those docs to OpenJDK so we don't confuse users who read this.

No @mstormi that is a really bad idea, as we still see some issues with OpenJDK, that could be solved by switching to Zulu 11. If there is a need for a change, AdoptOpenJDK would be a better option. But this needs to be discussed at a different place with a broader audience (maintainers).

[mstormi]

No @mstormi that is a really bad idea, as we still see some issues with OpenJDK, that could be solved by switching to Zulu 11.

I agree that we should not change the official recommendation in the docs before we've sorted out existing issues so let's postpone that. In and for the meantime, I've removed the DEPRECATED from the menu as that indeed has a potential for misunderstandings for the time being.

On the other hand that does not mean at all that it's a bad idea to change to OpenJDK. To date I've only seen that one forum thread, and that is not even confirmed to be an issue with OpenJDK. What we see and what we will keep seeing more of is just the expected, and our method of slow and controlled introduction via main on new installs only gives us the time to sort out issues should they really show up.

If there is a need for a change, AdoptOpenJDK would be a better option.

No, clearly not. That's just even less used and tested so essentially not better just unknown.

I believe that @hmerk is referring to the reference in general that openHAB prefers Zulu as its java provider here @mstormi.

It's me who wrote that long ago but I wasn't aware of it any more. So it's also me to be the authority to change this once more I guess.

But this needs to be discussed at a different place with a broader audience (maintainers).

I disagree because it is an openHABian maintainer's decision that technically does not affect core or addons, and undisputed in itself.

I'd nonetheless like to put it at the notice of the openHAB architecture council to see if they have comments or objections. That however should be discussed with them and us (openHABian maintainers) only and not be done here in public Github. @ecdye could you raise it ? (I think there's a means to create a closed discussion topic on the maintainers page).

[hmerk]

On the other hand that does not mean at all that it's a bad idea to change to OpenJDK.

If there are no issues anymore, than fine.

No, clearly not. That's just even less used and tested so essentially not better just unknown.

So why is it listed in our docs as an alternative then ?

It's me who wrote that long ago but I wasn't aware of it any more. So it's also me to be the authority to change this once more I guess. I disagree because it is an openHABian maintainer's decision that technically does not affect core or addons, and undisputed in itself.

I disagree. If such a change has effects on running openHAB, this needs to be decided at another stage.

I'd nonetheless like to put it at the notice of the openHAB architecture council to see if they have comments or objections.

That's a really good idea.