Having spent some time deploying instances of Java for Solr servers recently, I came across two things that wasted my time. So...
Since Oracle started demanding license fees for use of their main java builds, I find myself having to deploy the OpenJDK builds much more often. It's usually the v1.8 JDK/JRE you need, as that's what's supported by Solr, and that's available from GitHub at: https://github.com/ojdkbuild/ojdkbuild/releases/ (Ignore the "debug" ones)
You can pick the approriate release from there, and click through to get the list of downloadable files to choose from. If you're downloading manually, you can just pick the archive you need – but if you're automating it you have to be a bit careful. My initial thought was:
Start-BitsTransfer "https://github.com/ojdkbuild/ojdkbuild/releases/download/18.104.22.168-1/java-1.8.0-openjdk-22.214.171.124-1.b04.ojdkbuild.windows.x86_64.zip" "jdk.zip"
But that doesn't work:
Start-BitsTransfer : The resource loader cache doesn't have loaded MUI entry. (Exception from HRESULT: 0x80073B01) At line:1 char:1 + Start-BitsTransfer "https://github.com/ojdkbuild/ojdkbuild/releases/d ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Start-BitsTransfer], COMException + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.BackgroundIntelligentTransfer.Management.NewBitsTransferCommand
After a lot of tedious googling, it turns out GitHub hosts downloads in Amazon's cloud, and that involves some redirects that don't play nicely with BITS transfers...
So – BITS is out, unless you're able to mess with system-level settings. And, you probably don't. So it's simpler to stick with a simple web request:
Invoke-WebRequest "https://github.com/ojdkbuild/ojdkbuild/releases/download/126.96.36.199-1/java-1.8.0-openjdk-188.8.131.52-1.b04.ojdkbuild.windows.x86_64.zip" -OutFile "jdk.zip"
That will get you your download without any pesky errors...
Configuring and running SolrCloud code requires assorted bits of Java to run – and it turns out that different bits of the setup process make different assumptions about how the runtime gets found. And it's your environment variables that control this. The main Solr search engine seems happy with just #1 below, but aspects of configuring ZooKeeper don't seem to work quite the same way. So if you don't configure both of these, you can end up with odd "can't find java" related errors while you're trying to configure your cluster...
So if you're not using an installer for Java, you have to make two key settings for SolrCloud to be happy:
JAVA_HOMEenvironment variable is set
BINfolder to the path
For both of these, you need to take note of scope. Make sure you understand whether you are (or want to) be setting them for the current user, or for the system overall. Generally, if you're running stuff as a service, you need the environment variables it depends on set in system scope, so they're available when the code is not running as your user. And remember that changes to environment variables are not automatically reflected in any other windows you have open already – so you may need to re-open stuff, or reboot to make sure everything ends up in the state you want.
variable, you need to make sure it points to the JRE folder. If you downloaded the Java JDK then this is a child folder of what you unzipped. But if you only downloaded the JRE package then the environment variable needs to point to the folder you've extracted. In both cases, the
folder you're adding to your path is a child of the JRE folder.
If you download the "JRE only" archive then that looks like:
But if you pick the "full JDK" one then the JRE one here will have siblings containing all the other bits of the JDK. (And it will just be called "JRE" rather than having the full release name)