jalview

Agree this is just touching on a much bigger task.
However...
The reason I /needed/ to do this rather than just /wanted/ to do this is that several of the classes I've been working on (e.g. jalview.bin.Launcher, jalview.bin.HiDPISetting, jalview.bin.MemorySetting) run very early on (especially jalview.bin.Launcher!). This means Cache.log has perhaps not yet been initialised, so a Cache.log.debug doesn't log (unless you count reams of NullPointerExceptions as logging!).

In the case of HiDPISetting and MemorySetting that also get used in Getdown, where there is no jalview.bin.Cache, they currently have to use System.out and System.err [or maybe I could stub jalview.bin.Cache too]. I'd prefer them to use Cache.log when they can so this is an attempt at starting to decouple jalview.bin.Cache from other jalview things so it can be used standalone within Getdown. The main reason for wanting to do that is to have shared code to read the preferences between Jalview and Getdown.

Ben Soares as far as I can see the only thing missing after this branch is merged to develop is this logic. I just did a quick test and it appears 'Platform.isAMac()' returns false under JalviewJS, so probably not a dealbreaker. Do you agree ?

I'll add a Test.

Perhaps this stems from me misunderstanding a comment in the issue: "We should provide a way to find out what the latest version available from a channel is. I suggest we have a build details URL for each channel".
For non-Release/Test channel versions the "remote" build_properties will be a local file://.../getdown/website/11/alt/build_properties (which works if you're on the machine you built it on).
For Release/Test channel versions, the remote build_properties will be the most recent one available in https://www.jalview.org/getdown/release/11/release/build_properties (or test/1.8/alt etc). It is true that if this is the case then getdown SHOULD have already updated the jalview.jar. This is fine, and you would expect nothing to be reported anyway.
If you're using the shadowJar or an otherwise non-updatable version of Jalview or for whatever reason getdown has not auto-updated then you will get the message saying what the most recent version (in your channel) is. [This is perhaps the main part of the target audience for this message now???]
If we just want to check the current release version, this simplifies things quite a lot and I don't mind making that change at all (it means we don't have to pass any properties in to jalview to suggest a different appbase etc).

I can only think a bad copy and paste but why I did that I don't know (possibly I leant on "p" by accident after a "yy"? I need to be careful about my copy and pastes.) I'll remove.

Yes this should be removed. Cache.log.debug doesn't work (NullPointer) because (I think) log hasn't been initialised yet. I thought this System.out had been there before, but it wasn't so I'll remove it!

Why reading twice ?

this should be a debug statement ? Seeing 'LATEST_VERSION=' on stdout seems a bit strange, also.

doesn't matter for 2.11.1.1 but should be dropped for 2.11.2 unless it really is needed.

Ben Soares - I don't think you need this. The logger provides a overload to pass exceptions which will give the full stack trace - e.g. catch (Exception ex) { Cache.log.debug("ignored raised exception during blah",ex); }