Getdown: Custom Java: Configuring a specific build version of a JRE (beyond major, min, revision).

[Robert Gruber]

Hi All,

Is there a way to configure getdown to use a specific build version of a JRE?
The custom Java feature supports version comparison at down to major, minor, and revision level but seemingly not down to build-level.

For example, in our getdown install, we've configured getdown to have a min_java_version of 1080040 to specify 1.8.0_40, but there doesn't seem to be a way to define a specific build version of a JRE. Till now we've been providing build 12 of 1.8.0_04 as the custom JRE, but would like to upgrade our user base to build 23 (the current latest EA version at https://jdk8.java.net/download.html) but there doesn't seem to be a way to achieve this other than asking our users to uninstall and reinstall.

I wondered if anyone in the group had any ideas for this problem.

Many thanks in advance,
Robert Gruber

References:
https://github.com/threerings/getdown/wiki/Getdown-Dot-Text under 'Custom Java Installation'

[Michael Bayne]

On Mon, Feb 16, 2015 at 2:58 AM, Robert Gruber <gruber...@gmail.com> wrote:

Is there a way to configure getdown to use a specific build version of a JRE?
The custom Java feature supports version comparison at down to major, minor, and revision level but seemingly not down to build-level.

Unfortunately Getdown does not currently support specifying the build version. Oracle has gone rather crazy with their version numbers. I wish they would just use the patch level instead of adding YET ANOTHER tier of version numbers.

We already have MAJOR.MINOR.REVISION.PATCH. Do we really need -bBUILD on top of that?

Anyway, my complaining about it doesn't solve your problem. Getdown currently parses the java.version system property, which does not contain the build version. There does appear to be a java.runtime.version property which contains build version information (on my Mac anyway).

However, because of the way Getdown turns Java versions into a monotonically increasing integer, we can't just switch to using the runtime version because that will invalidate all the versions out in the wild (108004025 is larger than 1080040 and worse is larger than a hypothetical patch release 70, 1080070, which should ostensibly represent a newer version than 108004025).

So we'd have to add yet another version related configuration: java_use_runtime_version which would cause Getdown to include the build version information into the version. I'm also not entirely sure whether the java.runtime.version property is standard, and I'm sure the MAJOR.MINOR.REVISION_PATCH-bBUILD format is not standard. However, we could fall back to the java.version property if we fail to find or parse the java.runtime.version property and just use 00 for the build version if it doesn't exist. Presumably if you're installing your own JVM as a result of version mismatch, you can be sure the JVM you install returns the desired value for java.runtime.version (i.e. it's an Oracle JVM).

I'm somewhat inclined to just throw the doors open to arbitrary version parsing configuration. You would then provide:

java_version_property = java.runtime.version

java_version_regex = (\d+)\.(\d+)\.(\d+)(_\d+)-b(_\d+)

And then Getdown would just go left to right over all the matched groups and accumulate them into one long integer value. Then you provide a java_min_version that contains the right number of components (1080004024).

I think I'll probably do that, so that when Oracle adds yet another crazy version tier, or some other JVM does something different, or pigs start flying, we're better prepared to handle it.

-- m...@samskivert.com

[Michael Bayne]

Btw: this is now committed. I don't know when I'll be doing another maven release, but you can build Getdown from source pretty easily.

--
-- m...@samskivert.com

[Sergei Ivanov]

Hello Michael,

We pulled it down last night and built locally, but it appeared that the changes (specifically in the Application class) were not there yet. The last commit in GitHub was on the 4th of December, are you sure you've pushed the latest update in?

Thanks,
Sergei

[Michael Bayne]

On Thu, Mar 5, 2015 at 2:24 AM, Sergei Ivanov <sergei....@gmail.com> wrote:

We pulled it down last night and built locally, but it appeared that the changes (specifically in the Application class) were not there yet. The last commit in GitHub was on the 4th of December, are you sure you've pushed the latest update in?

Oops, perhaps not. I just pushed so it should be there now.

-- m...@samskivert.com

[Sergei Ivanov]

Hi Michael,

Just looked at the diffs: everything looks very promising. We'll give it a spin now.

Thanks again,
Sergei

[Sergei Ivanov]

Hi Michael,

We made it to work eventually, but we had to fiddle a little bit more with the regexp, in order to make it match both GA and EA version strings. Our final version is as follows:

java_version_property = java.runtime.version
java_version_regex = (\d+)\.(\d+)\.(\d+)(_\d+)-?e?a?-?b?(\d+)?

Unfortunately, we could not group the optional elements, because it would have messed up with the group order, which is used for the calculation of the numeric version. Therefore we had to put up with lots of question marks. I would like to join you in extending my thanks to Oracle for their insanely complex version numbering scheme.

Kind regards,
Sergei

[Sergei Ivanov]

Michael,

A slightly off-topic question related to building getdown from sources. What was the reason for that fake repository to host jregistrykey library, was there any advantage in that over simply using a system-scoped dependency with a relative path?

Kind regards,
Sergei

[Michael Bayne]

On Fri, Mar 6, 2015 at 6:02 AM, Sergei Ivanov <sergei....@gmail.com> wrote:

was there any advantage in that over simply using a system-scoped dependency with a relative path?

System scoped dependencies are not allowed to use relative paths. If the path resolved for a system scoped depend is inside the project, Maven complains (and maybe even fails for Maven 3.0 if I recall correctly).

There are apparently other issues with system scoped depends as well, like the Proguard plugin assumes that you don't want that code included in your jar, and other annoyances.

-- m...@samskivert.com

[Michael Bayne]

On Fri, Mar 6, 2015 at 6:17 AM, Michael Bayne <m...@samskivert.com> wrote:

and other annoyances

Ah yes, it's not possible to transitively depend on a project that has a system scoped depend with a relative path. The depend will be resolved relative to the leaf-most project.

The commit that introduces the local repository references this particular drawback:

commit 6f1a6ce78d623b7decaedb89531c029346c7fb89

Author: Michael Bayne <m...@samskivert.com>

Date:   Thu Nov 18 15:54:42 2010 +0000

    Sorted out a way to get Maven to reference a local jar file without rendering

    the pom file hosed for transitive dependencies.

Way back then, I did not have the primary Getdown artifact include everything via Proguard. The Proguard artifact was separate, and the main Getdown artifact was used by tools that wanted to run the digester, so I wanted transitive dependencies to work.

That's no longer how I do things, so I could maybe get away with a relative system depend, but I think Maven will at least still complain, if not reject it.

-- m...@samskivert.com

[Sergei Ivanov]

Thanks for the explanation. I thought there might have been a reason for such exotic set-up, and was curious what that reason was. It gave us a little bit of grief here, because it conflicted with the repository mirror config in our settings.xml (our maven is configured to use the internal repo manager). But we managed to sort it out in the end.
--
Sergei

[Michael Bayne]

On Fri, Mar 6, 2015 at 6:46 AM, Sergei Ivanov <sergei....@gmail.com> wrote:

It gave us a little bit of grief here, because it conflicted with the repository mirror config in our settings.xml (our maven is configured to use the internal repo manager).

I should investigate whether the jRegistryKey DLL dependency is even useful any more. Getdown attempts to read and use proxy settings on Windows, but it may be that such things can be accomplished without an external library as long as Getdown is running on a reasonably modern JVM.

We used to support Java 1.5 which was pretty primitive. Even Java 1.6 was a big improvement in many ways. Perhaps it knows how to read proxy settings on Windows out of the box.

-- m...@samskivert.com

[Sergei Ivanov]

Hi Michael,

I wonder if there is a way to get more detailed diagnostic output for the process of selecting/matching/updating the JDK.
Does getdown support JDK downgrade as well as upgrade? We tried to peg the properties to an earlier JDK build for test purposes, but it still used the later JDK that it pulled down initially.

A fragment of getdown.txt:

java_min_version = 108004023
java_max_version = 108004023
java_exact_version_required = true
java_location = [windows 7] http://xxxxxxx/jre/jre-1.8.0_40-ea-b23-windows_x64-getdown.jar

java_version_property = java.runtime.version
java_version_regex = (\d+)\.(\d+)\.(\d+)(_\d+)-?e?a?-?b?(\d+)?

In the original version of getdown.txt it was b25 (108004025).

--
Sergei

[Michael Bayne]

Getdown should create a launcher.log file in the app root directory with some diagnostic info. I'm not sure how much detail it provides if it decides not to update, as I'm away from the code, but check there.

It should downgrade if max version is not satisfied.

-- m...@samskivert.com

--
You received this message because you are subscribed to the Google Groups "OOO Libs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ooo-libs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sergei Ivanov]

Yes, we checked launcher.log and it helped us resolve some of the problems with auto-update. But when it comes to jdk updates, there was hardly anything related to that in the log. I wonder if you could throw in a bit more diagnostic logging.

Thanks,

Sergei

[Michael Bayne]

On Mon, Mar 9, 2015 at 3:34 PM, Sergei Ivanov <sergei....@gmail.com> wrote:

Yes, we checked launcher.log and it helped us resolve some of the problems with auto-update. But when it comes to jdk updates, there was hardly anything related to that in the log. I wonder if you could throw in a bit more diagnostic logging.

I'm adding some more debugging info to the checking code. However, there should be some useful info in launcher.log already. It reports details on the current JVM, like so:

2013/01/11 17:04:52:326 INFO m.a: ------------------ VM Info ------------------

2013/01/11 17:04:52:328 INFO m.a: -- OS Name: Mac OS X

2013/01/11 17:04:52:328 INFO m.a: -- OS Arch: i386

2013/01/11 17:04:52:328 INFO m.a: -- OS Vers: 10.8.2

2013/01/11 17:04:52:328 INFO m.a: -- Java Vers: 1.6.0_37

2013/01/11 17:04:52:328 INFO m.a: -- Java Home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

2013/01/11 17:04:52:328 INFO m.a: -- User Name: mdb

2013/01/11 17:04:52:328 INFO m.a: -- User Home: /Users/mdb

2013/01/11 17:04:52:328 INFO m.a: -- Cur dir: /Users/mdb/Desktop/Dev Puzzle Pirates.app/Contents/Resources/Java

2013/01/11 17:04:52:328 INFO m.a: ---------------------------------------------

So you should be able to look at the "Java Vers" line to get some idea of what the code will be doing.

Another thing I noticed when looking at the code, right now Getdown currently assumes that if a JVM has been downloaded and unpacked locally, it is the correct version. There's a note in there indicating that we should still check the version of the unpacked JVM, but that is not yet implemented.

So if you previously specified that you needed JVM version A, and then later bumped it up to B, Getdown will not properly upgrade the JVM. That may be causing trouble for you.

I'm going to look into fixing that code now.

-- m...@samskivert.com