Install-jdk.sh failing for openjdk9 and 10

Installing openjdk10
$ export JAVA_HOME=~/openjdk10
$ export PATH="$JAVA_HOME/bin:$PATH"
$ ~/bin/install-jdk.sh --target "/home/travis/openjdk10" --workspace "/home/travis/.cache/install-jdk" --feature "10" --license "GPL" --cacerts
Ignoring license option: GPL -- using GPLv2+CE by default
install-jdk.sh 2019-07-01-BETA
Variables:
  feature = 10
  license = GPL
       os = linux-x64 // os_name=linux os_arch=x64
      url = https://api.adoptopenjdk.net/v2/binary/releases/openjdk10?type=jdk&os=linux&arch=x64&release=latest&heap_size=normal&openjdk_impl=hotspot
   status = 302
Downloading JDK from https://api.adoptopenjdk.net/v2/binary/releases/openjdk10?type=jdk&os=linux&arch=x64&release=latest&heap_size=normal&openjdk_impl=hotspot...
mv: cannot stat ‘/home/travis/openjdk10/lib/security/cacerts’: No such file or directory
The command "~/bin/install-jdk.sh --target "/home/travis/openjdk10" --workspace "/home/travis/.cache/install-jdk" --feature "10" --license "GPL" --cacerts" failed and exited with 1 during .

https://travis-ci.org/coala/coala-bears/jobs/553065996

2 Likes

Looks like the archive from AdoptOpenJDK doesn’t contain a lib/security/cacerts directory by default.

Tracking progress in https://github.com/sormuras/bach/issues/60

Is there an estimate when this will be fixed?

How is https://github.com/sormuras/bach/ related?

It has only a single job

Is that in production on Travis CI? Or has my jobs been pushed to some alpha version of Travis.

Same error encountered by me. Is there any solution?

install-jdk.sh is hosted there, and Travis CI decided to use a copy of that script to install JDKs on-the-fly. See https://github.com/travis-ci/travis-cookbooks/issues/976 and related links.

Fixed install-jdk.sh already last night – Travis CI needs to update their copy the script.

/cc @BanzaiMan et al

Having said that: JDK 9 and 10 “dead”, “end-of-life”, archived…

Move to JDK 11 (LTS) or 12 (until September), please.

I’ve deployed travis-build again.

1 Like

Should work now without trying to copy non-existing cacerts directory.

Still not working in my repository: https://travis-ci.org/alibaba/nacos/jobs/553146511

There is lots of very important software that is still stuck on JDK 7 and 8, and 9 and 10, and coala wraps them. I don’t get to choose the priorities of all our dependencies, and they are usually unfunded open source.

OpenJDK 9 and 10 were working last week.
openjdk10 is listed many times on https://docs.travis-ci.com/user/languages/java/

Only oraclejdk10 is mentioned as not supported by Travis CI, and I hope that Travis CI will continue to have a pragmatic approach of continuing to provide unsupported versions long past their EOL, and not intentionally break stuff, or neglect to test and let them rot without a conscious decision that the support cost vs benefit is too high.

1 Like

Also not working for me https://travis-ci.org/coala/coala-bears/jobs/553187482 (rebuild just now)

Installing openjdk10
$ export JAVA_HOME=~/openjdk10
$ export PATH="$JAVA_HOME/bin:$PATH"
$ ~/bin/install-jdk.sh --target "/home/travis/openjdk10" --workspace "/home/travis/.cache/install-jdk" --feature "10" --license "GPL" --cacerts
Ignoring license option: GPL -- using GPLv2+CE by default
install-jdk.sh 2019-07-02-II
Variables:
  feature = 10
  license = GPL
       os = linux-x64 // os_name=linux os_arch=x64
      url = https://api.adoptopenjdk.net/v2/binary/releases/openjdk10?type=jdk&os=linux&arch=x64&release=latest&heap_size=normal&openjdk_impl=hotspot
   status = 502
Downloading JDK from https://api.adoptopenjdk.net/v2/binary/releases/openjdk10?type=jdk&os=linux&arch=x64&release=latest&heap_size=normal&openjdk_impl=hotspot...
The command "~/bin/install-jdk.sh --target "/home/travis/openjdk10" --workspace "/home/travis/.cache/install-jdk" --feature "10" --license "GPL" --cacerts" failed and exited with 8 during .

It’s 502 from the server. https://travis-ci.org/coala/coala-bears/jobs/553187482#L430

Even oraclejdk11 is 502

https://travis-ci.org/jayvdb/bach/builds/553307121

We’ll have to wait for the services to be restored.

I see there is some testing of this install script using GitHub actions ; last run at https://github.com/sormuras/bach/runs/160154663

And a quick read of the script suggests it always picks Java.net for 13+ , and always picks AdoptJDK for 12 and lower.

If so, that will not be fixed by restoring services, whatever that means.

When the service on api.adoptopenjdk.net is restored, I expect the script to work. Do you have reasons to believe otherwise?

Yes, I do not expect software to work correctly unless it has been tested adequately, and these days the assurance that it was tested adequately for a purpose is initially its CI matrix and code coverage of its tests.

I’ve restarted https://travis-ci.org/coala/coala-bears/jobs/553187482 right now and the API is 302 but the result is still ln: failed to create symbolic link ‘/home/travis/openjdk10/lib/security/cacerts’: No such file or directory

As I indicated in earlier posts, bach & especially install-jdk.sh are not being QA’d on all jdk versions that Travis is expected to work. The GitHub action CI mentioned above only really hits the AdoptJDK API. It does not test the majority of the logic in install-jdk.sh. It only does install-jdk.sh --dry-run, which bales out before the section of code which has the problems we are experiencing. And even if it had 100% test coverage, then it still needs additional QA for switching betwen jdk’s, as that is a completely different function point from adding a new jdk, and the ability switch jdk in an adhoc manner is sprinkled liberally through the Travis CI docs.

Moved the failing call to ln into the guarded block via https://github.com/sormuras/bach/commit/c185fb8aa2d406517228341e3d25168decb5b9ab – version 2019-07-03 needs to be copied over to Travis CI. Again.

As stated here https://github.com/travis-ci/travis-build/pull/1347#issuecomment-385885801 and in various other places, the install-jdk.sh script was designed to just download and extract the latest-and-greatest JDK (from jdk.java.net) into a clean (CI) environment. Nothing more, nothing less.
I (still) don’t want to support more complex scenarios within the script. There are better solutions available, but I don’t know how if/whether Travis CI may make use of them: http(s) caching proxy techniques like http://www.squid-cache.org does is one option. The archived and released JDK URLs are very stable and should be pre-installed within Travis CI images, the EA releases change every 1-3 weeks. Supporting the latter was and is the main goal of install-jdk.sh.

Perhaps switching to a more complete Java Version Manager like https://github.com/shyiko/jabba is an option (for archived/released JDKs) for Travis CI.

Cheers,
Christian

I appreciate your predicament, and that you are trying to get your tool working according to the needs of Travis CI, GmbH.