Create autoupdater for AdoptOpenJDK binaries

[tellison]

BitRock installers include an auto-update tool.

This issue is to investigate whether the auto-updater is suitable for the project, and write the client and server metadata to represent our releases.

A quick read through the docs implies that the autoupdater has to be invoked by cron / task scheduler on a regular check for updates on some platforms.

[alexhass]

If we think about Windows we need to keep in mind that users are typically not administrators and are not allowed to install software. Automatic update need to be an optional feature that could be enabled by default. Not difficult, just do not forget about this, please.

[maverick74]

Is there anything new in this front?

Would be great to have this for Windows!!!

[karianna]

This work still needs to be scheduled in.

[gjabouley-invn]

Could it be possible to start small and just do a regular check for updates?
Even if it then redirect to download link, at least users would be notified of availability of an update. Something like CCleaner update check for example (i think it is implemented using a scheduled task)

[maverick74]

I'm sorry for bringing this up again, but it's an important feature since being up-to-date is crucial for us, not just for feature reasons, but specially for security reasons!

It's been a few months without any advance in this front... is there any news?

We would like to migrate from Oracle's Java to OpenJDK, but not without this...

[robmosys]

One thing to note is that a web API is already available to query for versions of the openjdk:
https://github.com/AdoptOpenJDK/openjdk-api-v3
So, what is required is tool to:

1. Periodically query the API
2. Compare results against installed jdks.
3. Notify user of status, and handle responses.
4. Download & install API.
5. Handle failures in a responsible manner.
   It's always possible to start with a tool that gets to stage 3, dispatching user to download page to get updated software, before doing 4 and 5.

[jlgager24]

I am currently in the process of writing an updater. Not sure how long it will take because I work full time but I hope to have some sort of beta made soon. I am looking to write it in java8 so it is usable for all versions and and I am using Jackson for the json parser. I am also currently using the github releases api to try to get the download links but I can use the AdoptOpenJDK api if everyone thinks thats better or I can do both if so desired. If anyone has any ideas for things to add that havent been mentioned or any suggestions at all please let me know.

[maverick74]

Happy 2020.

@jlgager24 any update to share with the rest of us? :)

[jlgager24]

Hey everyone sorry I haven't posted an update in a while. I was very sick over the holidays and haven't been able to put in as much time as I have wished. My plan is to have something to show you guys by the end of February. Thanks for being patient.

[maverick74]

No hurry. Health (and family) are always first. Hope you're OK already.

[jlgager24]

I am doing much better now thanks.

[maverick74]

any news?

[Suyashtnt]

any news? I would really like this

[aahlenst]

Sorry, there are no news in that area. I don't want us to get into the business of developing and maintaining an auto updater which is a complex undertaking. I especially dread the support requests caused by the auto updater. Using an existing auto updater would most likely require us to switch from WiX to https://www.installaware.com/ or https://installbuilder.com/ which have solved that problem. That would be a lot of work, too. OSS solutions like Sparkle aren't a drop-in solution, either.

If anyone wants to help or fund development, please get in touch.

[maverick74]

@aahlenst it could, at the very least, notify users when there is a new version available.

I think that much is pretty easy to implement, ain't it?

[aahlenst]

@maverick74 If it was easy, I guess someone would have done it by now.

If you want to inform people when running java, you had to patch that into the java executable. We would have to consistently apply that patch on top of the regular OpenJDK/OpenJ9 changes. So that would be a consistent source of work apart from the fact that there are other executables. How would we deal with jlink'ed binaries? jpackage? Oh my.

The other option is a scheduled task. But what is if you want to keep the specific version? What if there are multiple versions/users? What if it's a per-user install? What if somebody wants to mute it until next boot/next week/next version?

[maettle]

@maverick74 If it was easy, I guess someone would have done it by now.

The other option is a scheduled task. But what is if you want to keep the specific version? What if there are multiple versions/users? What if it's a per-user install? What if somebody wants to mute it until next boot/next week/next version?

Apologies if I did understand something wrong, but the minor releases are always bug-/securityfixes, aren't they? So you just don't have a reason to NOT want the newest version. But if you must keep an old version and want to mute it: why don't remember that choice in a file/variable/etc?
If its a per user install: there are per-user tasks.
Multiple versions: multiple (per user) tasks.

I really don't see a problem with managing your concerns. I would've written my own scheduled task, but I don't know what/which url I should query...

[aahlenst]

@maettle Those are requirements, not insurmountable obstacles. You asked for an URL, there you go: https://api.adoptopenjdk.net/. I‘d be very happy if you can put something together that works well and is easy to maintain. If you have questions, https://adoptopenjdk.net/slack.html, there is a channel called installer. I take Java or C#.

Further requirements:

• Windows 8.1 and up
• Windows Server 2012 R2 and up
• Yell at people if they use a version that has reached its EOL.

[tushev]

Hello guys,

If you want something to be done, do it yourself. Thinking like that (and needing the updater) I created such a tool and I want to share it with you.

It is available at https://github.com/tushev/aojdk-updatewatcher

Its principles and philosophy are well described in Readme.

Ironically, this tool is written in C# + WPF, because I am not a Java developer. I just need the tool for myself because some software I use requires Java. If you find it useful for you too, I will be glad. Stars will be appreciated :)

[Suyashtnt]

Hello guys,

If you want something to be done, do it yourself. Thinking like that (and needing the updater) I created such a tool and I want to share it with you.

It is available at tushev/aojdk-updatewatcher

Its principles and philosophy are well described in Readme.

Ironically, this tool is written in C# + WPF, because I am not a Java developer. I just need the tool for myself because some software I use requires Java. If you find it useful for you too, I will be glad :)

You are an absolut legend, thanks

[aahlenst]

@tushev Do I understand correctly that the tool cannot cope with multiple versions of AdoptOpenJDK being installed on the same machine? Or the other way around: It only updates the JDK at JAVA_HOME?

[tushev]

@aahlenst It's designed primarily as an end-user thing: in most 'everyday' cases there is just one single installation of JRE,not even JDK :). As for JAVA_HOME - you can choose either JAVA_HOME or a specific other path.

If you need to check multiple JDKs, currently you can create a very simple batch script that will rotate user.config files and run this tool several times (I expect that different MSIs will update themselves correctly to different directories). Or maybe I will add such functionality in some future release.

[tushev]

@douph1 the dates look weird, but I cannot say why. Maybe it's an issue with Inno itself or innoextractor.

Checked my machine, the actual compilation dates are:

• for v1 (7B4D8FF0C0ADC168DA4E15EE26812FE5F0CBD273BFEBDEF61B628F167B11D0F9) actual date is 18.06.2020 17:55 UTC
• for v2 (E03ADF1A2D78CEAC319132351201DCADF48079FB2027A83AA7C6864C36758A5A) actual date is 26.09.2020 08:57 UTC

If I install the V2 package, C:\Program Files\AJUpdateWatcher\AJUpdateWatcher.exe has correct 'Modified' date (26.09.2020 08:57 UTC).

As of SecureAge APEX, I've heard that it has lots of FP reported, like this one.

As of binaries, I use third-party stuff like Inno Setup with plugins, libs like DotNetProjects.Extended.Wpf.Toolkit etc. So I cannot be 100% sure about them, but they are generally respected by the community. I checked the DLLs, they all look clean by VT. Only the uninstaller - unins000.exe, generated by Inno setup, is suspicious to one engine.

Also I cannot be 100% sure that there is no super-duper alien worm that dwelled for years in my machine, bypassed all local AV checks and my own InfoSec principles, just to inject itself when I will compile AJUpdateWatcher.exe :) (only 99.99999% percent sure).

But what I can say for 100% sure that I have no intention to create or distribute malicious code :)

---

EDIT: I've released a zip-archive without any installer.
You can confirm that it is 100% clean on VT: https://www.virustotal.com/gui/file/a1ed2b2c6ad6af4c024e8c6f9d2ccd9316ea365b4b865b0a271f0b874b31b779/detection

[alexhass]

Setups schould be Wix toolkit (MSI) based only.

Code signing the files schould stop virus detection. I think this is the only really safe way.

[mziehm]

@tushev @douph1 Thanks for investigating and providing an innosetup/installer free version.

[douph1]

Hi @tushev @jlgager24 can you confirm that your updater see the last version : "openjdk_version": "11.0.9.1+1", "semver": "11.0.9+101" ?

because the last is newer than the first :

{
  "build": 11,
  "major": 11,
  "minor": 0,
  "openjdk_version": "11.0.9+11",
  "security": 9,
  "semver": "11.0.9+11"
},
{
  "build": 1,
  "major": 11,
  "minor": 0,
  "openjdk_version": "11.0.9.1+1",
  "security": 9,
  "semver": "11.0.9+101"
},

[tushev]

@douph1

If we are speaking about API, it seems that "openjdk_version": "11.0.9.1+1", "semver": "11.0.9+101" it is not present (at the time of writing this comment) in https://api.adoptopenjdk.net/v3/assets/latest/11/hotspot. I obtained the JSON both via https://api.adoptopenjdk.net/swagger-ui/#/Assets/get_v3_assets_latest__feature_version___jvm_impl_ and via debugging of my app. Both JSONs do not contain that version.

Concerning API logic, my updater requests https://api.adoptopenjdk.net/v3/assets/latest/11/hotspot, parses the JSON and iterates through array of binaries. Once an item matches the criteria, the updater stops looking for any other binaries and is happy with the first match (I expect that the API will provide the most recent build).

---

If we are speaking about comparing versions in general (say, you have "semver": "11.0.9+101" installed locally), my updater will consider "semver": "11.0.9+11" as more recent, because "build": 1 < "build": 11. Currently it relies on comparing standalone fields in sequence (major>minor>security>build) rather than parsing semver. Is this correct?

[OrangeDog]

@tushev 11.0.9+11 comes before 11.0.9+101, because 11 is less than 101. You should use the semver field for ordering comparisons.

[douph1]

it is not present (at the time of writing this comment) in https://api.adoptopenjdk.net/v3/assets/latest/11/hotspot. I obtained the JSON both
Yes not present in /latest/ because of ordering issue we are currently trying to fix

You can see it here /v3/assets/version/{version}

Currently it relies on comparing standalone fields in sequence (major>minor>security>build)
Yes same problem here because Adopt and you handle only 3 field + build number before this new release.
and now 4 field + build number

If you sort with each uniq attribut yes 11.0.9+11 = 11.0.9.0.(+b)11 has a build=11 and 11.0.9+101 = 11.0.9.1.(+b)1 has a build=1 then your ordering failed
If you sort with semver you must be good because 11<101

[douph1]

see AdoptOpenJDK/TSC#185 (comment)

[tushev]

@douph1 @OrangeDog OK, I have to switch to semver for the API. That's one part of comparison.

As for the other part (local installation), I have:

• Registry: HKEY_LOCAL_MACHINE\SOFTWARE\AdoptOpenJDK\JRE\11.0.7.10\openj9\MSI. Will that version reflect recent changes?
• SEMANTIC_VERSION="11.0.9+6" in release file (see Add missing and useful information to "release" file temurin-build#2049) - I use for user-configured installations (actually for everything that is not auto-discovered via registry)
• legacy builds that do not have one or both sources. But it's simpler, because most likely they will have differences in major/minor/security, so need_update will still be true for them.

[douph1]

Will that version reflect recent changes?

101 like in semver for the reg key

1+1 visible in the installer name
101 in the ProductVersion
101 by default in the path "C:\Program Files\AdoptOpenJDK\jdk-11.0.9.101-hotspot\bin\javaw.exe" -jar "%1" %*
101 in the registry HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\11.0.9.101

[douph1]

Please keep an eye on AdoptOpenJDK/openjdk-api-v3#313 and possible ongoing enhancement if you don't want to switch to semver comparison

[tushev]

upd: what the updater is actually doing: it makes best effort to determine version of local installation. It is guaranteed that it can obtain Major.Minor.Security. If user enables use of windows registry for discovery (as well as for some recent builds - see release file) then it is possible to determine Major.Minor.Security+Build (all numbers are currently treated as integers). Then it compares the numbers with the API (/latest/).

Please correct me if I'm wrong: if I change my API logic so it uses semver like 11.0.9+101 as a source for build number instead of dedicated build field, will it be consistent with the versioning changes that are proposed in AdoptOpenJDK/TSC#185 (comment) ?

From the point of view of updater, it will get api:101 > local:11 and show update dialog.

[tushev]

P.S./offtopic: For legacy builds that are not auto-discovered via registry, it may not always be possible to get build number at all (if build is missing in release file). These installations will not receive any updates unless security or greater field changes. This is a documented feature (that's why I strongly recommend enabling automated discovery via registry).

[douph1]

Yes it will be consistent and the only way "for now" as the "patch" information is not published into the api as a dedicated field : major.minor.security(.patch)+build ( patch doesn't exists on the API )
Only semver include patch into : 4rd number : patch(*100)+build for the adopt semver version.

[douph1]

"build" cannot change without any other major/minor/sec/patch change

[tushev]

@douph1 will this numbering scheme remain in the future?

It's OK for me to switch to semver, just don't want to change the behavior very frequently...

So if all future releases will be versioned like 11.0.10.101 -> 11.0.10.105, this will be ok.

[douph1]

I have no crystal ball :)
Don't be in a hurry to change now as AdoptOpenJDK/openjdk-api-v3#313 is not closed or be prepare to change one more time :)

[tushev]

OK, I will wait :)

101 by default in the path "C:\Program Files\AdoptOpenJDK\jdk-11.0.9.101-hotspot\bin\javaw.exe" -jar "%1" %*
101 in the registry HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\11.0.9.101

But since I will have to parse these as well and compare, I guess semver (or another field that reflects registry version) will be my best option

[tushev]

Just released https://github.com/tushev/aojdk-updatewatcher/releases/tag/2.0.1.0

@douph1 Now the updater should be able to see the latest version of 11 - "openjdk_version": "11.0.9.1+1", "semver": "11.0.9+101".

Currently I tried to implement the versioning to the best of my own understanding, still waiting to get confirmation/clarification from the official team on adoptium/adoptium-support#209 :) So there may be more upcoming updates of the updater...

Also, I switched to WiX, now all the releases are provided as MSIs and ZIPs. No more false positives on VirusTotal caused by Inno Setup.

[RobFosterNYC]

16 was released. I'm waiting for the Adopt team to have their gerbils wake up and update the website 😸

[maverick74]

@AdamBrousseau Hi,

You pushed a commit and referenced this issue.
Can you elaborate more about your push?

Could that work here as well?

[AdamBrousseau]

@maverick74 I believe that is unrelated. Likely a reference to #4 of another fork.