Please use below command :-

export JAVA_HOME=`/usr/libexec/java_home -v 1.8.0_261`

Nothing strange so far.. everything you listed works as before on my one-day-of-work.

Reason: In ~/.bash_profile, JAVA_HOME= $(/usr/libexec/java_home), after upgraded, $(/usr/libexec/java_home) link to /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java which doesn't exist in my disk, so jdk is missing.

Solution: I delete jdk in /Library/Java/JavaVirtualMachines and reinstall jdk8, and then set JAVA_HOME as:

/Library/Java/JavaVirtualMachines/jdk1.8.0_271.jdk/Contents/Home

instead of soft link and source ~/.bash_profile to let it work.

My full settings:

kevinMacBook-Pro:bin kevin$ cat ~/.bash_profile
export M2_HOME=/usr/local/apache-maven-3.6.3
#Mac OSX 10.5 or later version need this configure
#export JAVA_HOME=$(/usr/libexec/java_home)
#Mac 11 need this configure
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_271.jdk/Contents/Home
export MySQL_HOME=/usr/local/mysql

Now, jdk works, after mac os upgraded, it indeed update the soft link of $(/usr/libexec/java_home) and link to a not existed link, so i think you don't need to delete your jdk, just update env variables and re-open terminal to check if jdk reset correctly.

I have Big Sur 11.2.1 from 18.02.2021. I had the same issue with JAVA_HOME path configuration. After reading a lot of information I solved my problem with next:

Install JDK 8: https://www.oracle.com/java/technologies/javase/javase-jdk8-downloads.html Java SE Development Kit 8u281

Install it as usual on your MacOS Big Sur.

Check JDK version:

java -version
java version "1.8.0_281"
Java(TM) SE Runtime Environment (build 1.8.0_281-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)

Check what versions of JDK are already installed on your machine:

/usr/libexec/java_home -V 
Matching Java Virtual Machines (2):
    1.8.281.09 (x86_64) "Oracle Corporation" - "Java" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
    1.8.0_281 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_281.jdk/Contents/Home
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home

Get only one that you need:

/usr/libexec/java_home -v 1.8.0_281
/Library/Java/JavaVirtualMachines/jdk1.8.0_281.jdk/Contents/Home

On Catalina and Big Sur - there is Z-shell , to add Environment variables like JAVA_HOME there are two files for that: ~/.zshenv and ~/.zshrc, I couldn't make it work with first one. It worked for me like this:

nano ~/.zshrc

Add to that file this line:

export JAVA_HOME=$(/usr/libexec/java_home -v 1.8.0_281)

Press Ctrl+X and save changes.

Then run command to apply that changes to current terminal:

source ~/.zshrc

After that you can check if everything is working with command:

echo $JAVA_HOME
it will print you: /Library/Java/JavaVirtualMachines/jdk1.8.0_281.jdk/Contents/Home

Restart your terminal and programs which will be using JAVA_HOME variable. For me it was Android Studio. Now everything works fine. I am new to Mac OS and it took me with 4hours to solve this. With Windows it's just done in a minute:)

Can confirm this is still happening on adoptopenjdk14, as well as openjdk early access build for j16.

You can file a bug if you want, but I bet it'll be denied. At this point, the name Mac OS X is not so much 'the name of the OS' as a 'globally agreed upon keyword identifying that unix-based mac operating system', where I mean globally literally (as in, 'around the planet', not 'across your source base/VM'). Changing it would just break stuff needlessly. The same applies, to a lesser degree, to version 10.16: The thing before the dot is not so much 'this is how the OS identifies itself' and more a 'globally agreed upon versioning scheme for Mac OS, identifying a wide and ill defined set of capabilities'.

There is no meaningful difference between the transition between big sur and catalina, other than the fact that apple made a marketing decision. If you want to point at an OS transition that might warrant the entirely nebulous choice to consider it a 'major change', surely it was the one to catalina, as that made by far the largest changes (including removing support for 32-bit entirely) in the last bunch of releases.

This leaves you with the challenge of: Okay, great, I can use System.getProperty("os.name") to get the globally agreed upon keyword that means unix-like Mac OS, and os.version for a string I can break into bits to figure out some nebulous batch of capabilities, but what if I need the actual name of the OS to e.g. show to a user?

Then you have three major options:

1. The easy one is to just write mapping code. Acknowledge that os.name and os.version give you (rather arguably) useful intent and not so much official names, and therefore, write some mappings. These would map name/version pairs to rendering strings, falling back to just printing the name string and the version string, concatenated, verbatim. You could add a mapping: Mac OS X/10.16 → Mac OS Big Sur in this table.

2. The hard way: Figure out you're on a mac (which is now easier; os.name returns Mac OS X, or just check for the existence: Files.isExecutable(Paths.get("/usr/bin/sw_vers"))), and then use ProcessBuilder to execute /usr/bin/sw_vers, picking up all output into a big string, and then parse it. Its output looks like:

ProductName:    macOS
ProductVersion: 11.1
BuildVersion:   20C69

which, crucially, doesn't even include the words Big Sur, but does give you 11.1. I don't know how to run a command line tool that actually gives you Big Sur. Maybe system_profiler, but note that this takes many minutes to run, I really doubt you want to run that.

NB: you can also run .command("/usr/bin/sw_vers", "-productVersion") which gives you just 11.1, this may be a lot simpler to parse. -productName also works, gives you just macOS.

3. If you need this information to scan for OS capabilities, then stop doing this. It doesn't work with browsers, and it's not a good plan for OS releases either. What capability are you scanning for? Imagine, for example, if it is 'Can I run /usr/bin/sw_vers to figure stuff out', as a hypothetical example. The right strategy is NOT to check os.name/os.version, conclude that the command must exist, and then run it, failing catastrophically if it is not there. The right move is to check if /usr/bin/sw_vers exists, and then execute it, falling back to some non-mac based solution (perhaps /usr/bin/uname) in other cases. Scan for the capability, don't scan for the OS/version.