What is the relationship between (2:1.11-72) and 1.8.0_152-release ?

Java 8 is ancient (that's what 1.8.0 is).

I am on Ubuntu 20.04, so maybe the repos for 20.04 only includes 8

So I'll need to install a newer java I guess to get shadow-cljs working again

apt-get install temurin-17-jdk should get you JDK 17

You may need to do some of the following https://adoptium.net/installation/linux/ (I don't remember what I had to do to prep for apt-get on Ubuntu).

(I also have a bunch of different JDK versions installed manually so I can test against multiple versions -- I have 8, 18, and 19 installed as well as my default of 17)

or if you want to go with open-jdk you can do apt-get install openjdk-17-jdk

it is also on ubuntu 20.04 https://packages.ubuntu.com/focal/java/

you have jdk 11, 16 and 17 on 20.04 repos

ok, installed openjdk-17-jdk

but java -version still reports that ancient version

is their something I need to do make 17 the one that is actually used ?

I'm not a Ubuntu user, I'm on debian but they should be similar

you should do a :

sudo update-alternatives --config javac
sudo update-alternatives --config java

both commands will let you choose the bin version for your java and javac programs (it just update some links under the hood)

(base) [01:00]: stuart@stuart-Z87M-D3H:~$ update-alternatives --config javac
There are 2 choices for the alternative javac (providing /usr/bin/javac).

  Selection    Path                                          Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-17-openjdk-amd64/bin/javac   1711      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/javac   1111      manual mode
  2            /usr/lib/jvm/java-17-openjdk-amd64/bin/javac   1711      manual mode

Press <enter> to keep the current choice[*], or type selection number: 

There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                         Priority   Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-17-openjdk-amd64/bin/java   1711      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java   1111      manual mode
* 2            /usr/lib/jvm/java-17-openjdk-amd64/bin/java   1711      manual mode

Press <enter> to keep the current choice[*], or type selection number: 

wonder if I need a restart to pick up newest verison

run which java

it should say /usr/bin/java , maybe you have something else on your PATH

/home/stuart/anaconda3/bin/java

hmmm

yeah, that is the problem

what is your PATH var echo $PATH?

From my .bashrc

# >>> conda initialize >>>
 124   │ # !! Contents within this block are managed by 'conda init' !!
 125   │ __conda_setup="$('/home/stuart/anaconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/n
       │ ull)"
 126   │ if [ $? -eq 0 ]; then
 127   │     eval "$__conda_setup"
 128   │ else
 129   │     if [ -f "/home/stuart/anaconda3/etc/profile.d/conda.sh" ]; then
 130   │         . "/home/stuart/anaconda3/etc/profile.d/conda.sh"
 131   │     else
 132   │         export PATH="/home/stuart/anaconda3/bin:$PATH"
 133   │     fi
 134   │ fi
 135   │ unset __conda_setup
 136   │ # <<< conda initialize <<<

> /home/stuart/graalvm-ce-java11-20.3.0/bin:/home/stuart/anaconda3/bin:/home/stuart/anaconda3/condabin:/home/stuart/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/stuart/.dotnet/tools:/usr/local/go/bin:/home/stuart/dotnet

so, that is the problem, you have a java bin in /home/stuart/anaconda3/bin

not sure what is that about

think maybe its a python thing

but if you want a quick fix, just remove the java and javac programs from there (maybe just mv them to another name)

or you can change that line: export PATH="/home/stuart/anaconda3/bin:$PATH" into : export PATH="$PATH:/home/stuart/anaconda3/bin"

thank you so much,

that's java now reporting v 17

now you are using /usr/bin/java, /usr/bin/javac, and you can change those links by using the update-alternatives command

I was starting to feel a bit like this xkcd

if you want to try different versions

This might have to do with shadow-cljs requiring java 11 as the minimum version now

Some advice that nobody has given but that has proven to me to be the most valuable over the years and that, I hope, will be useful to you as well: • Never run around nuking stuff, unless it's something with a very narrow scope like some cache, /tmp, ~/.m2, my-proj/node_modules etc. Nuke only when you have a complete understanding of all the whats an whys • Whenever something asks you to add stuff to PATH, really carefully think about it. More often than not, such things deem themselves the center of the Universe and don't care whether there are other things on your PATH that you might've wanted with higher preference. conda is very nasty in this regard given that you can install even Java with it. Among other things, you can make your PATH be directory-dependent, so e.g. the conda PATH appears there only when you're in some subdirectory of ~/projects/python-stuff/ • Prioritize learning over changing. You seem to be performing a lot of guessing followed by a lot of doing - which is fine when your intent is to learn stuff, but it doesn't seem to be the case here when you make a guess and immediately make a global change to your main OS. You might've repaired your current project, but you might've also broken 20 older ones that you will need tomorrow And in the case of using React packages from CLJS, you almost certainly don't need Webpack. That is, unless maybe those packages are distributed as TypeScript (without any JS at all) or as a new version of JS that the platforms that you target don't support, or those packages have some non-JS resources that they require in JS (although I'm fairly certain you can deal with those with a combination of shadow-cljs and manual loading).

This is a top-quality rant! From the very first (well, second) sentence, "In an attempt to get npm working with clojurescript, I've had to nuke graalvm,..." it is prize-worthy material.

I'll just chip in, that IMHO environment variables are the answer and "alternatives" is a complicating factor. Without "alternatives", if worse comes to worst you can (leave your existing user account alone and) create a new user account to try a totally new set of environment variables and dot-directories with. Without "alternatives", you can happily have 3 versions of a tool installed (in distinct directories) and choose among them with environment variables like PATH, which you can vary, task by task or account by account. On the other hand, with "alternatives", you are always in nuke territory because "alternatives" switches your whole computer, all user accounts, and every process that henceforth runs on it, to one specific version of the tool - except insofar as some tools also look at certain environment variables, like JAVA_HOME independent of the PATH. And while you might be able to (or accidentally) wrench control from "alternatives" by setting an environment variable here or there, "alternatives" dooms the central variable, PATH, by putting all tools (each of one version chosen by "alternatives") together in a single directory, /usr/bin or whatever. Moreover, no matter how hard you try, it can be difficult to keep "alternatives" from tripping over its own feet. IIRC there are at least three distinct "alternatives" products for the bits-and-pieces of Java and they easily come unstuck from each other - so "javac" designates 8 while "java" designates 11, etc. In summary, I'm on-board with "alternatives" but only if you have only one version of everything installed. Soon as it come time to upgrade from Java 8 to Java 11, or likewise for any tool, you will have to buy a new machine.

I'd highly recommend https://sdkman.io/, I'm running ubuntu within wsl2 and was very easily able to install and switch java versions versions very quickly and found that temurin 19 loads my clj projects noticeably faster than the alternatives.

also definitely familiar of that feeling of wanting to throw out every computer I own and starting a farm :)

Good points from @U0HG4EHMH definitely. I use JAVA_HOME and JAVA_CMD env vars for local control over what JDK version is run for specific commands (we have one legacy process that still requires Java 8 but I switch between JDK versions a lot for testing different projects). On our staging and production tiers we use "alternatives" for consistency: we can switch everything over to a specific JDK and we don't have to think about where JDKs are installed or environmental changes. Using Docker can also provide that control -- using plain JDK-based images (we use Docker to run services in dev/CI but our core Clojure stuff runs "on the metal" native). I've never really had much problem with things blowing up from a straight up Java stack (including Clojure) but it seems as soon as you venture into Python/Ruby/JS, you end up with a "managed" environment and I have always had terrible luck with such things -- and that was a main reason for me moving away from Octopress/Jekyll for my various static sites to Cryogen! My Octopress/Jekyll setups would just mysteriously "break" one day and I pretty much had to nuke stuff and start over to get it working again 😞