Netlify bundles Java 8 (source) by default in the build image. I have a build tool that requires Java 11+. Generally, it seems Netlify supports customizing included tooling version, however, I have not been able to find any resources on customizing the version of Java the CI uses. How have folks change the version of Java from 8 to 11+?
The big hammer that would (probably) work would be to install java 11 at build init every single time the build runs. This would greatly slow down build time though. Other ideas?
We’ve spoken about this as a team and one option you could try is to include the binary of your desired JVM version and include that in your repo. From there, you could reference the path to that binary to ensure you’re getting the right version for your build tool to run, while eliminating the necessity to install it from scratch every time.
That said, the ability to specify a particular Java version is an excellent idea – if you file a feature request on our build image GitHub repo, we might be able to include this in future versions of our build image
Let us know if you have any other questions and we’d be happy to help!
Thanks for the suggestion @amelia. It sounds like it could work. We would like to avoid that solution for now since it will bloat our repo size until the end of time
Hi @jacobemcken , Welcome to the forums! Our developers that look at the build image repo will respond on the open issue if they have further questions or information. Thank you so much for taking the time to share those details. We really appreciate it. (:
I also came looking for help with upgrading the Java version. I saw that the build-image repo is now archived. Is the feature request still active, or abandoned?
Yup, feature request is still open. We transferred it from the build-image repo. Not much requested though, so not clear that we’ll implement it anytime soon since we don’t generally build features for 2 customers.
Further, there is a workaround you can already use! You can commit a copy of whatever JDK you want to your repo, then we’ll pull it in while we clone, and your build script could install it and use it instead of our default version as Amelia mentions back here: Java 11 support? - #3 by amelia
Not ideal, but should unblock your use case, today
Completely understandable that this is not a priority if there are only two users asking for it
I’ll try the workaround, if I can manage it. I just don’t really know what are all the files I need to include from a JDK. Any pointers regarding that would be much appreciated.
I’m not sure if these are what I should be looking for and I’m not sure if I need an amd64 or arm64 version, or something completely different. Update: found from the GitHub issues, that I need amd64 (Debian).
And once I have the right files in my project, what else remains? My first guess would be to redefine the JAVA_HOME system property, and point that to the local file in the project. What’s the best way to do that?
Java 11 isn’t even the current long-term-support release of Java any longer; that is now Java 17. I appreciate all that Netlify has done over the years in terms of providing a build and hosting environment for my user guides, but this is really holding back my ability to use vaguely current libraries. (The idea of committing an entire JDK into my project repositories to work around this is just crazy.)
I understand this isn’t a priority, so this weekend I have figured out how to build my user guides in Github Actions, and securely rsync them from there to my own web server. So I am gradually migrating my projects to that approach, and deleting the corresponding Netlify sites. Thanks again for all you’ve offered over the years, I truly do appreciate it. And now thanks in a different way for motivating me to remove an external dependency.
Hi, @DeepSymmetry. I also personally wouldn’t recommend committing the JDK into your repo.
There is a way to download Java during the build and to cache it to reuse it for future builds without adding it to your repo at Netlify. However, as you state that you are using GitHub Actions to deploy now, I have another suggestion if you want to continue deploying to Netlify which is:
Continue to use GitHub Actions for builds and then use the Netlify CLI tool to push those builds to Netlify using the manual deploy feature.
The Netlify CLI tool is designed to be used within third-party scripts and CI/CD systems. It “plays well” with GitHub Actions as it was designed with that exact use-case in mind.
So, you can continue deploying to your own server if you want to. However, if you want to continue to use Netlify, you should be able to add this to your GitHub Actions without much effort. If there are any questions about how to do so, please let us know and we’ll be ready to answer.
There is a way to download Java during the build and to cache it to reuse it for future builds without adding it to your repo at Netlify.
Any chance of sharing an example of doing this? my team is also close to leaving netlify because the default java version is so old. I understand that its a pain to support multiple java versions but can’t you at least update the version you do support to the lts release (currently version 17). Not even using java 11 is pretty crazy IMO.
Thanks, @luke, manual deploy from Github Actions to Netlify is an interesting option to keep in mind, if I want to retain the benefits of your content distribution network, but keep my builds simple by having the user guides built in the same environment that the libraries and applications themselves are already building. I think for now I am leaning towards simplifying things by removing this dependency, but I will remember it as a plan if my server ever feels underpowered or too isolated.
I ended up spending some hours looking into this which resulted in the following script that I now run as part of my built script:
#!/bin/bash
CACHE_DIR=$NETLIFY_BUILD_BASE/cache
JAVA_DOWNLOAD_URL="https://download.java.net/java/GA/jdk17.0.2/dfd4a8d0985749f896bed50d7138ee7f/8/GPL/openjdk-17.0.2_linux-x64_bin.tar.gz"
JAVA_RELEASE=jdk-17.0.2 # Must match directory inside archive in JAVA_DOWNLOAD_URL
currentver="$(java -version 2>&1 |head -n1 | cut -d'"' -f2 |cut -d'.' -f1)"
requiredver="11" # Shadow-cljs requires a minimum of Java 11
# Version check shamelessly copied from StackOverflow:
# https://unix.stackexchange.com/a/285928
if [ ! "$(printf '%s\n' "$requiredver" "$currentver" | sort -V | head -n1)" = "$requiredver" ]; then
echo "Java version 11 is required as minimum by Shadow-cljs (found Java version $currentver)"
if [ ! -d "$CACHE_DIR/$JAVA_RELEASE" ]; then
echo "Downloading $JAVA_RELEASE since it isn't available in cache"
wget --quiet -O openjdk.tar.gz $JAVA_DOWNLOAD_URL
tar xf openjdk.tar.gz --directory $CACHE_DIR
fi
echo "Enabling $JAVA_RELEASE from cache, by making it available on PATH"
export PATH=$CACHE_DIR/$JAVA_RELEASE/bin:$PATH
fi
Whenever a “new enough” version of Java is missing Java 17 is downloaded and the PATH is updated to make use of this Java version, otherwise, nothing happens. This way I can run the same built-scripts locally (where my Java version is good) and on Netlify where it isn’t. The download is also cached causing only the PATH to be updated most times (adding next to zero additional built-time).
Notice: the script needs to be “sourced” (with a preceding dot) like so in package.json:
This is required for the updated PATH environment variable to be passed along to the next script(s) in line (in the above example run-s frontend:release css:release).
