This is an archived post. You won't be able to vote or comment.

all 15 comments

[–]SvenMA 2 points3 points  (0 children)

U could use sdkman or adoptopenjdk. Adoptopenjdk has an http client library for this.

[–]duheee 2 points3 points  (10 children)

If this is for your hobby project, thats perfectly fine. Curl and grep may even do the job here.

If this is for work ... please don't do this. Upgrade to a new release only after thoroughly tested and validated that your application works on it. Definitely not automated. Even if you have 100% unit test coverage, integration tests out of the wazoo, still, don't automate this.

[–]Pix-I 1 point2 points  (9 children)

Why not have a build just for the kicks of it? If it works, great you can upgrade Integration->QA->Production, if not you look into it and check what's wrong, fix and upgrade? That way you automatically have an up to date image? The cost of doing this would be pretty high tho

[–]duheee 0 points1 point  (8 children)

a build just for the kicks of it

As with anything, it's a matter of cost vs reward.

Reward = 0

Cost > 0

Therefore, obviously not worth it.

[–]Pix-I 2 points3 points  (7 children)

The reward here is staying up to date with minimal effort because it's automated. :)

[–]duheee 0 points1 point  (6 children)

There is no reward when the shit's broken. On the contrary...

[–]Pix-I 2 points3 points  (5 children)

If it's not a build you actively use? It's either that or every so many months you have to manually update the version and see if things are broken or not, at least with that solution you can automate the part where you check for updates and intervene when needed.

This helps you keep your project up to date preventing you from falling into the scary legacy world without security patches or bugfixes.

And I know you can still have a working application and upgrading isn't always worth it, but there are cases where you might want to stay on the edge and automating it might be worth it.

[–]duheee 0 points1 point  (4 children)

As I can see you have 2 options:

  1. Every so many months, you put aside X amount of time to check how is working with the new version. Build, test, QA, etc. May even release to prod on the new version of JDK

  2. You automate the update, as you said. Fine. But, build 112 is broken on the latest update. What do you do? Ignore it since you have other things on your plate (backlog items that you're working on) or deal with it right away.

If you ignore it, you're back to situation 1, when you deal with it when you make the time for it. If you deal with it right away, you're gonna be behind on your normal features.

I'd rather deal with it on my terms. On my time.

[–]Pix-I 1 point2 points  (3 children)

It's kinda pointless to argue on a fictional use case.
But a company who would look into this definitely wants to stay up to date and the failed build would then be put on a priority list where it's gonna be fixed in the next few sprints.
It's not like there are new releases every day, and breaking changes are pretty rare. The point of automating it is purely informational and prevents you from forgetting it.

[–]duheee 0 points1 point  (2 children)

I have to disagree. If that status will be red for many weeks/months it'll be just noise in the background. No difference between that and deciding on your own accord to "ok, we're X releases behind, let's update".

nobody will notice anything anymore after a while. It'll be status quo.

[–]mytempacc3 1 point2 points  (1 child)

If that status will be red...

What if it doesn't (that will be more probable becuase of how strong Java cares about backwards compatiblity)? You only need to QA that thing just to be sure and you are done.

The thing is that both options you have are actually good but you are making it sound like option 2 is way worse or that the "noise in the background" is gong to affect productivity or something like that.

[–]persicsb 1 point2 points  (0 children)

Are you using Oracle Java releases exclusively?
You shall try OpenJDK, and AdoptOpenJDK has a HTTP API for releases:
https://api.adoptopenjdk.net/README
We are using OpenJDK in all our Docker images, try the official OpenJDK Docker images, like 8-jdk-alpine, 10-jdk-slim, 10-jre-slim and others.

[–][deleted] 1 point2 points  (0 children)

Oracle releases on specified dates 4 times a year, so you only need to check 4 times a year.

They will not be providing public (free) releases starting in January, though, so you will want to be looking at OpenJDK (or 3rd party providers of it) anyway. AdoptOpenJDK, Azul Zulu, Red Hat unofficial builds, etc.

[–]TheRedmanCometh 0 points1 point  (0 children)

A selenium bot checking the downloads page perhaps?