RFR: JDK-8210962 Deprecate jdk-variant

[Aleksey Shipilev]

On 09/20/2018 07:24 PM, Magnus Ihse Bursie wrote:
> Currently the default format looks like this: "linux-x86_64-normal-server-release", that is
> <OS>-<CPU>-<JDK_VARIANT>-<JVM_VARIANT>-<DEBUG_LEVEL>. The selection of these configuration
> parameters feels a bit arbitrary. Some examples of other parameters we could have included, but
> don't, are:  abi-profile, jvm-features, version-string, static-build, headless-only.
> 
> The relevance of including any of these parameters in the build output name depends on some
> thought-up scenario were the alternative configurations that reasonably could be built at the same
> time. For instance, in a cross-compilation scenario, os and cpu makes sense to include, but perhaps
> not otherwise. The jvm-variant is more or less reduced to server or zero at this time, and it's
> unclear if this needs to be part of the build output directory name.

I guess the question is how much variability is there in day-to-day builds. As the guy who builds
lots of different configurations, I see great simplicity in maintaining current static label that
captures most of the usual variability. For example, my current scripts have:

   build_dir_base = 'build/' + os + '-' + target_oj + '-normal-' + variant + '-' + mode + '/'

The only oddity here is "normal", which I would be happy to see going, even if this requires me to
special case jdk-12+ build configs.

Granted, scripts could be changed to accept whatever configuration label we come up with. I do not
see any benefit of including the version-string (the really dynamic parameter?), that would justify
additional work in build scripts. jvm-features-wise, I think most builders stick with the static set
of features anyway. Headless/headful might be interesting, but I guess most builders do not care
about headless anyway. ABI is interesting, but different-ABI-ed builds are is probably built in
separate containers/machines anyway.

-Aleksey