installer icon indicating copy to clipboard operation
installer copied to clipboard

Create autoupdater for AdoptOpenJDK binaries

Open tellison opened this issue 6 years ago • 66 comments

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.

tellison avatar Jul 27 '18 21:07 tellison

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.

alexhass avatar Sep 29 '18 08:09 alexhass

Is there anything new in this front?

Would be great to have this for Windows!!!

maverick74 avatar Mar 23 '19 11:03 maverick74

This work still needs to be scheduled in.

karianna avatar Mar 25 '19 19:03 karianna

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)

gjabouley-invn avatar May 13 '19 18:05 gjabouley-invn

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...

maverick74 avatar Oct 16 '19 14:10 maverick74

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.

robmosys avatar Oct 29 '19 17:10 robmosys

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.

jlgager24 avatar Nov 10 '19 13:11 jlgager24

Happy 2020.

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

maverick74 avatar Jan 02 '20 12:01 maverick74

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.

jlgager24 avatar Jan 18 '20 22:01 jlgager24

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

maverick74 avatar Jan 19 '20 00:01 maverick74

I am doing much better now thanks.

jlgager24 avatar Jan 19 '20 03:01 jlgager24

any news?

maverick74 avatar Mar 31 '20 22:03 maverick74

any news? I would really like this

Suyashtnt avatar May 14 '20 17:05 Suyashtnt

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.

aahlenst avatar May 14 '20 17:05 aahlenst

@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?

maverick74 avatar May 15 '20 10:05 maverick74

@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?

aahlenst avatar May 15 '20 10:05 aahlenst

@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...

maettle avatar May 16 '20 17:05 maettle

@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.

aahlenst avatar May 16 '20 20:05 aahlenst

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.

update_dialog config_dialog

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 :)

tushev avatar May 17 '20 08:05 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.

update_dialog config_dialog

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

Suyashtnt avatar May 17 '20 08:05 Suyashtnt

@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?

aahlenst avatar May 17 '20 10:05 aahlenst

@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 avatar May 17 '20 11:05 tushev

@tushev Thanks for your willingness to contribute to AdoptOpenJDK! This is what OSS is all about :-). I've added it to the TSC agenda to review and then discuss with you further (will be the end of the week)

karianna avatar May 17 '20 17:05 karianna

@tushev this is amazing!!! Thank you!!!

It would be great to have this "integrated" with AdoptOpenJDK installation!

I still have a question, however: if i have OpenJDK v.10 and OpenJDK v.11 gets out will i also get notified? Or does it notify me only on minor releases ( OpenJDK v.10.1 -> OpenJDK v.10.2 )?

maverick74 avatar May 18 '20 09:05 maverick74

@maverick74 In current version, you set the release (like 10, 11) in my GUI and the updater then routinely checks API that looks like /v3/assets/latest/10/hotspot. If that API will tell no new versions for 10, you won't get any new notifications and probably you will have to switch manually (AFAIK, this is what happening now).

If the API will tell something like no new versions for 10, EOL reached: true, recommended new branch: 11 then I will add corresponding functionality to the app (sure no automatic updates, informed consent to switching to another branch required). This is to be suggested and discussed with AdoptOpenJDK TSC.

It would be great to have this "integrated" with AdoptOpenJDK installation!

I think it's possible to create some kind of 'configuration' (like release number and installation path) that will be provided by AdoptOpenJDK MSI installer, so when you install AdoptOpenJDK, the updater begins using this provided configuration and don't asks user for anything. As @karianna wrote, this is to be discussed as well.

I think I can add support for multiple configurations, both user-configured and provided by installers.

tushev avatar May 18 '20 10:05 tushev

@maverick74 In current version, you set the release (like 10, 11) in my GUI and the updater then routinely checks API that looks like /v3/assets/latest/10/hotspot. If that API will tell no new versions for 10, you won't get any new notifications and probably you will have to switch manually (AFAIK, this is what happening now).

@tushev Suggestion: Would be good to have an option to always keep up with the latest release (without having to choose it manually)

It would be great to have this "integrated" with AdoptOpenJDK installation!

I think it's possible to create some kind of 'configuration' (like release number and installation path) that will be provided by AdoptOpenJDK MSI installer, so when you install AdoptOpenJDK, the updater begins using this provided configuration and don't asks user for anything. As @karianna wrote, this is to be discussed as well.

Yes, but what i meant to say was that it would be good if the AdoptOpenJDK installer would also offer the option to automatically install your updater as an extra feature for those who might want that function

maverick74 avatar May 18 '20 11:05 maverick74

The minimum bar to clear for bundling from my point of view (apart from TSC decision):

  • Apache License 2.0
  • Automated tests
  • Works with multiple AdoptOpenJDK installations
  • Removal of all mentions of OpenJDK, Java and similar terms that are copyrighted by Oracle as well as all related artwork.

This does not mean that you have to do everything on your own (except the licensing).

aahlenst avatar May 18 '20 12:05 aahlenst

all mentions of OpenJDK, Java and similar terms that are copyrighted by Oracle

Pretty sure you mean trademark, not copyright. And AdoptOpenJDK is fine?

By the guidelines you can use phrases like "OpenJDK update check", but calling your own product AdoptOpenJDK is disallowed (assuming "OpenJDK" is actually an Oracle trademark).

OrangeDog avatar May 18 '20 13:05 OrangeDog

Pretty sure you mean trademark, not copyright.

👍

By the guidelines you can use phrases like "OpenJDK update check", but calling your own product AdoptOpenJDK is disallowed (assuming "OpenJDK" is actually an Oracle trademark).

@karianna is the expert in this area. Generally speaking, we should strive to stay away from anything that is a TM/R of Oracle or could be potentially misleading. "OpenJDK update check" could be considered to be misleading (it's AdoptOpenJDK, you cannot obtain an OpenJDK MSI), and a non-starter if OpenJ9 can be obtained through it because OpenJ9 is not OpenJDK (Oracle's stance).

aahlenst avatar May 18 '20 14:05 aahlenst

I used "OpenJDK" because that was you're example, and I'm not sure whether it is actually a trademark. "Java" definitely is, but you're still allowed to say "Java update check", or "current Java version" etc. which you said have to be removed.

If "OpenJDK" is a trademark, it's pretty clear you're not allowed to call yourself AdoptOpenJDK.

Do not use Oracle trademarks or potentially confusing variations as all or part of your company, product or service names.

OrangeDog avatar May 18 '20 15:05 OrangeDog