Is there a library anyone can recommend for checking checksums for my clients auto-updater?
Would like to be able to integrate it into the distribution build process as well by having it create the checksums on a filetree during the distribution build and spit out a text file that I could include on the update server.
I have not ever used this before with the exception of manually checking a file using windows cmd line a couple times.
Thought there may be something like a library I could depends in gradle and run a simple command to write out a file or files in a dir and also use it to check from the client when downloading.
Guava may have some utilities that make it easier to work with the IO and stuff. I haven’t look to see if newer java has added anything streams related for checksums.
I was just making sure there wasn’t a reason you were steering away from the built in Checksum stuff other than not knowing it was there.
but I use none of this code in the updater. I use javafx, he uses swing also.
I used the java io classes mentioned in the eugenep/tutorials ResumableDownload.java file as an example of how you can download but not as written.
I went with a different approach where if the file did not download fully its considered a critical error and the program will bail, starting over on the next try initiated by the user rather than resuming where it left off.
I don’t know how helpful any of that is as I have spent 8 months writing the updater. I found it was extremely complicated to do it in a way that was safe and cross platform.
In case people are wondering why go to all that trouble, I didn’t feel comfortable with the free options available and the pay ones are scary expensive for a closed source project.
I want to actually open it up to the public once finished but for selfish reasons. The main one being I believe the more eyes that see it the better and safer it will be. Key word here is safe.
I had no idea how complicated this was when I started but that’s why they charge what they do I found out.
Its not as simple as it sounds and once you pull that string, it leads you into some real crazy places, or at least it did for me. Its been a hell of a ride.
I just looked at update4j again and it looks like they have done alot of work recently updating it.
They seem to take a different approach than me as I made my updater agnostic of java, modules, class path or anything really. I use paths. I write the paths used by an archive to a version file when building the app or updater. This allowed me to use jpackage or any distribution method, like zip files built by the distribution plugin, interchangeably. The calling app uses jpackage and the updater is a standard distribution created by the distribution plugin that gets extracted into the calling app’s image during build via gradle.
All I have to do to force an update is extract the archive of either one of these on the update server. Only different versions of any file gets downloaded though. I added an extra files download argument for un-versioned files that must be downloaded, like startscripts for example. They will always change when a version of some jar changes.
As for starting the app after download, the calling app is responsible for moving any new updater files and starting the updater and the updater is responsible for moving the calling app files and starting the calling app, each using a path to a start scripts or exe that either jpackage or the distribution plugin builds. The updater does all the downloading for both.
Each uses the exact same paths found in whatever version file it’s interested in to locate the file on the update server and move the downloaded file on the local machine.
This method requires you to know where the calling app lives though, like on windows I force install into AppData and other os in user home.
Forgot I changed the updater to be packaged using jpackage. Have been busy for two months with life.
Still doesn’t change anything I wrote much, just different folder structure vs standard zip. The updater is modular but the calling app is non-modular.
Anyway, works anyway you want it to as its path based.
Edit: The updater app image still gets zipped and extracted into the calling apps jpackage image prior to running final jpackage build command as explained above. This allows the updater to be installed when the calling app is installed on the users machine the first time.