JDK lookup breaks after homebrew openjdk change

[joewiz]

Homebrew recently added an openjdk recipe, which is installed automatically as a dependency of Java-based command-line utilities like ant and maven. Specifically, the new homebrew recipe installs OpenJDK 13 from openjdk.net and symlinks this version to /Library/Java/JavaVirtualMachines/openjdk.jdk.

This change causes appbundler-based apps to fail to discover the JDK, and raise the dreaded error:

I believe this issue is caused by the absence of a version number in the JDK's filename in /Library/Java/JavaVirtualMachines/openjdk.jdk. Appbundler expects to find a version number in the JDK's filename, e.g., jdk-12.0.1.jdk or zulu-8.jdk; see https://github.com/TheInfiniteKind/appbundler/blob/master/appbundler/native/main.m#L837-L938.

Renaming the homebrew JDK symlinked filename to openjdk-13.0.2.jdk fixes the issue, but ideally we could adjust appbundler to recognize openjdk.jdk as a valid JDK.

To reproduce, run brew install openjdk, brew cask install exist-db, and then start /Applications/eXist-db.app. If eXist starts, be sure no other symlinked JDKs are in /Library/Java/JavaVirtualMachines. (I'm even able to reproduce the error with zulu-8.jdk present, so it seems appbundler's code really trips up on openjdk.jdk when it tries to parse it.)

// cc: @reitermarkus

[reitermarkus]

Using the java_home command definitely works correctly:

$ sudo ln -sfn /usr/local/opt/openjdk/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk.jdk
$ ls /Library/Java/JavaVirtualMachines
openjdk.jdk

$ /usr/libexec/java_home -v '1.8+'
/Library/Java/JavaVirtualMachines/openjdk.jdk/Contents/Home

[FranklinYu]

I think we should update the function findJREDylib() to use java_home instead of the deprecated “Internet Plug-Ins”. java_home should also be able to resolve #59.

@reitermarkus Does Apple recommend tools to make use of java_home or is it meant to be used only by Apple internally? Is it documented anywhere?

[FranklinYu]

Wait, by default jrePreferred is false:

appbundler/appbundler/src/com/oracle/appbundler/AppBundlerTask.java

Line 84 in 9811366

private boolean jrePreferred = false;

So JDK should have been searched:

appbundler/appbundler/native/main.m

Lines 740 to 752 in 9811366

	// If JRE not found or if JDK preferred, look for an acceptable JDK
	// (probably in /Library/Java/JavaVirtualMachines if so). If found,
	// return return address of dylib in the JRE within the JDK.
	if (jrePreferred) {
	Log(@"A JRE is preferred; will not search for a JDK.");
	}
	else {
	NSString * dylib = findJDKDylib (required, isDebugging, exactMatch);
	if (dylib != nil) { return dylib; }
	Log(@"No matching JDK found.");
	}

And findJDKDylib() does use java_home. What went wrong? It should have found the path.

[reitermarkus]

For the formula it is irrelevant what Apple recommends regarding java_home, since we cannot install to the location java_home uses without sudo.

[reitermarkus]

If you create the /Library/Java/JavaVirtualMachines/openjdk.jdk symlink as mentioned in the caveats, java_home will find it, however.

[FranklinYu]

Found more by reading the source. It is already using java_home, but it thinks Java path looks like this:

appbundler/appbundler/native/main.m

Lines 890 to 892 in 9811366

	// ... and outRead will include something like
	// "/Library/Java/JavaVirtualMachines/jdk-12.0.1.jdk/Contents/Home" or
	// "/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home"

In addition, Java version is decided by folder name (like jdk-12.0.1.jdk). Is there a better way to tell the Java version?

[reitermarkus]

You can run e.g. /usr/libexec/java_home -v '12' to get version 12.

[rschmunk]

I'm the one who a few years ago submitted some of the changes to IK's appbundler for treating jrepreferred vs jdkpreferred, and also trying to parse the JDK version. And yes, it needs to be cleaned up, whether due to Oracle's change in Java numbering but more likely due to the way the numerous alternative Javas name their folders.

As @FranklinYu notes, trying to parse the Java version based on folder name has become progressively more difficult. So as @reitermarkus suggests, it seems that calling java_home -v NN could provide an easier to manage result.