make Java install resilient

[mstormi]

Following up on #874, there is a need to make (first & foremost but not exclusively) Java install more resilient.

Need to consider both a short term and a strategic approach in parallel.

On short term, we need to evaluate the list of available packages and select hf ones.
@ecdye I didn't have the time to dissect this in detail at 2am so may be wrong, but unlike what you wrote in #874 the URL OHian requested returned MORE than one package and your code seemed to select the last out of those. So it was bad luck that that was the sf one. Double-check that please
and eventually come up with a (non-hot) fix.

On strategic, see #655. I stand by my opinion to keep copies of latest packages known to be good
(= have a copy in openhabian repo). That we should do at least for Azul and Adopt Java.
[NOTE: we may need to have several copies for different HW architectures]

Mind #692: given AC's 'tie break' that took place there, I'd like to get this implemented asap.
It means we'll have a new "stable" branch in addition to today's master branch.
What it means for this issue here is that changed Java install code should evaluate the branch first and if in 'stable', it should download the known good package off the openHABian repo.
Also mind the connection to #825 (offline install), our image would need to contain a copy as well for that to work. So even with Inet available, on the system is the first place place the code should look for.
If in master it should continue to retrieve the package directly from the source, BUT it should be extended to fall back to the repo cache if the install routine can determine that downloading from source fails or is bad somehow [it obviously cannot detect all instances of 'bad' such as the aarch32sf one, but it can detect some of them].

PS: we should duplicate this approach for other external sources once it has proven to work
PPS: there would have been a chance to spot #874 early: actually all test builds made since the Azul change were failing.

[ecdye]

No, @mstormi I was querying the Latest binary and that is what Azul returns: compare these links:
https://api.azul.com/zulu/download/community/v1.0/bundles/latest/?jdk_version=8&ext=tar.gz&os=linux&arch=arm&hw_bitness=32
https://api.azul.com/zulu/download/community/v1.0/bundles/?jdk_version=8&ext=tar.gz&os=linux&arch=arm&hw_bitness=32

[ecdye]

The builds started failing about two days ago. We could have caught it but I was busy trying to get RL things done and wasn't paying enough attention to make the connection.

What you did to fix it should suffice in all cases except when Azul is in the middle of uploading their latest builds and the hf build is not available. That seems to be a very low chance. I am hoping to get Azul to fix it, but if that doesn't work then I'll work on making static link workarounds for when the API fails to return the correct binary.

[mstormi]

The builds started failing about two days ago. We could have caught it but I was busy [...] and wasn't paying enough attention to make the connection

Same for me. But relying on that is a broken concept. Maintainers cannot be on duty 24x7, 365 days a year. Hence my focus on a strategic approach to mitigate the need for fast reaction.

What you did to fix it should suffice in all cases except

Ok, then skip looking for a final fix and move on to the strategic approach I raised.

[ecdye]

My one worry about keeping local copies is that then we can run into licensing issues with the packages that we include.

[mstormi]

For Zulu Community the Azul website says you can "download and use without restrictions".
[Note: IIRC in the code we use names "Enterprise" and "Embedded" which is wrong as that's the commercial versions. Code we use is the free "Community" however.]
For that, I have not even found an own (Community) licensing file. Links found on g**gling are forwarded to https://www.azul.com/products/zulu-and-zulu-enterprise/zulu-terms-of-use/ which
I would say our use case should be in line with.

Adopt license is Apache 2.0 https://github.com/AdoptOpenJDK/openjdk-build/blob/master/LICENSE which should be fine as well (same as for the Balena sources).

If anyone finds information to deviate, please point me there.

[ecdye]

@mstormi would it be better to consolidate #879 into this issue and make this a thread to track and address all Java issues relating to Zulu?

[mstormi]

For the sake of tracking, no as it's completely different issues.
But any PR can be the fix to several issues at once so just feel free to fix them in one go.

[ecdye]

I would but right now I'm more or less in hurry up and wait mode for a fix from Azul.

[mstormi]

FYI The latest Raspbian (lite) image that is available for download includes Oracle JDK and other packages that require licensing. For their handling see here

[ecdye]

Do we need to worry about the licensing?

[mstormi]

what do you mean ? because we in turn include Raspbian ?

[ecdye]

Yeah

[mstormi]

I think we should leave a reference on the download page like the Raspbian guys did.

[mstormi]

Would you say we're done with this ?

[ecdye]

Yes, until such a time that Azul gets back to me with a proper fix we are done with this.