Previously Linux x86_64 binaries weren't built from sources, they were
extracted from CentOS 6 RPM packages instead. See:
- initial issue: https://github.com/ojdkbuild/ojdkbuild/issues/1
- notice about Linux binaries in readme:
- script to create bundles:
> What was the reason to separate Linux and Windows builds?
Reasons (in arbitrary order):
- no 8u171 packages in CentOS 6 at the time of windows release
- EC Crypto was disabled in those bundles, because it is linked with a
specific NSS version and in non-CentOS env there always a good chance
that it will crash with incompatible NSS version
- CentOS packages are done specifically to be better integrated with
other system libs/resources (CA certificates, fontconfig etc); when
bundling them separately these benefits are lost, but the resulting
binaries are much less portable than a "vanilla" build
- jdk8+ linux builds are trivial to do
- I was asked for jdk8-linux build script (
and instead of preparing a bash script, decided to configure Travis builds
Old procedure, extract from RPMs:
New procedure, build from vanilla upstream sources:
Please note, that upstream sources are pre-imported here
to not deal with multi-repo
mercurial checkout on Travis.
> tests / etc and we can confidence it like the old location?
Hm, testing details were never publicized (the reason for that is in FAQ
point 3 - https://github.com/ojdkbuild/ojdkbuild#faq
), but deserve some
CentOS RPM Linux builds have zero testing, but they built from exactly
the same revision (there may be nuances with branding/labeling, but
generally that is correct), from which RHEL RPMs are built. And RHEL
RPMs are thoroughly tested - there is a quite experienced QA team
working on that.
ojdkbuild windows x86_64 builds have zero testing, but they are built
from exactly the same revision, from which Red Hat jdk-windows binaries
) are built.
And Red Hat jdk-windows x86_64 binaries are thoroughly tested (by the
same team that works on RHEL packages).
These jdk8u builds (
) have zero
testing, but they are built from the untouched "vanilla" upstream
sources and just because of that they are likely to be more stable, than
the "vendor-customized" downstream builds mentioned above. There are
dozens of companies (including Oracle, Google, Twitter etc), who build
there internal jdks based on these sources.
> Thank you in advance for your help,