Closed Bug 1670264 Opened 5 years ago Closed 5 years ago

[macOS 11] ERROR: The program jarsigner was not found.

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
All
macOS
Type:
defect

Tracking

(firefox84 fixed)

Status:
RESOLVED FIXED
Milestone:
84 Branch
Tracking Flags:
Tracking Status
firefox84 --- fixed

People

(Reporter: mstange, Assigned: mhentges)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 2 obsolete files)

full mach build output
12.85 KB, text/plain
Details
Bug 1670264: Validate detected Java directory to ensure it's a JDK
47 bytes, text/x-phabricator-request
Details | Review
Attached file full mach build output —

configure for GeckoView is failing for me on the latest macOS 11 Beta because the auto-detected java search path does not contain a jarsigner binary.

I updated from macOS 10.15 to macOS 11 yesterday. I was able to keep building with my existing GeckoView objdir. But after I pulled a fresh mozilla-central, I'm now hitting the configure error. So I'm not completely sure whether this issue was created by the macOS update or by the mozilla-central update.

My JAVA_HOME environment variable is empty, and my mozconfig does not contain --with-java-home. Reading the code, it seems like we auto-detect the java search path by running /usr/libexec/java_home -v 1.8.

Apparently, the path I get from /usr/libexec/java_home -v 1.8 does not contain a jarsigner binary, but the path I get when running /usr/libexec/java_home without any -v version does contain a jarsigner binary:

% /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home
% /usr/libexec/java_home -v 1.8
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
%
% ls -la "$(/usr/libexec/java_home)"/bin
total 5912
drwxr-xr-x@ 34 mstange  staff    1088 18 Jan  2019 .
drwxr-xr-x@ 10 mstange  staff     320 10 Nov  2019 ..
-rwxr-xr-x@  1 mstange  staff   93584 18 Jan  2019 jaotc
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jar
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jarsigner
-rwxr-xr-x@  1 mstange  staff   93520 18 Jan  2019 java
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 javac
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 javadoc
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 javap
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jcmd
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jconsole
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jdb
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jdeprscan
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jdeps
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jhsdb
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jimage
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jinfo
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jjs
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jlink
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jmap
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jmod
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jps
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jrunscript
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jshell
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jstack
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jstat
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 jstatd
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 keytool
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 pack200
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 rmic
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 rmid
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 rmiregistry
-rwxr-xr-x@  1 mstange  staff   93536 18 Jan  2019 serialver
-rwxr-xr-x@  1 mstange  staff  103168 18 Jan  2019 unpack200
% ls -la "$(/usr/libexec/java_home -v 1.8)"/bin
total 2704
drwxrwxr-x  17 root  wheel     544 27 Apr  2018 .
drwxrwxr-x  12 root  wheel     384 27 Apr  2018 ..
lrwxr-xr-x   1 root  wheel       8 27 Apr  2018 ControlPanel -> jcontrol
-rwxr-xr-x   1 root  wheel  195120 28 Mar  2018 _javaws
-rwxr-xr-x   1 root  wheel  103376 28 Mar  2018 java
lrwxr-xr-x   1 root  wheel      47 27 Apr  2018 javaws -> /Library/Application Support/Oracle/Java/javaws
-rwxr-xr-x   1 root  wheel    3972 28 Mar  2018 jcontrol
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 jjs
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 keytool
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 orbd
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 pack200
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 policytool
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 rmid
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 rmiregistry
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 servertool
-rwxr-xr-x   1 root  wheel  103440 28 Mar  2018 tnameserv
-rwxr-xr-x   1 root  wheel  116640 28 Mar  2018 unpack200
%

So I guess either the path or the directory contents changed in macOS 11?

Hey, thanks for the report!
We've got some interesting Java-related constraints when building Firefox:

  1. We require jarsigner for ... some part of the build, I can't put my finger on it, but it's a requirement for at Android builds at least, if not every build. Jarsigner existing in the Java JDK (dev tools), but not the JRE (Java for runtime)
  2. We require Java 8 because the tool we use to download Android tools didn't (doesn't?) work with newer version of Java.

It looks like /usr/libexec/java_home -v 1.8 finds any Java 1.8 (aka Java 8) installation. In your case, it looks like it found a Java 8 JRE, which is why jarsigner isn't there
And, it looks like /usr/libexec/java_home found any Java installation, and it's leaning towards a newer one - in your case, it found a Java 11 JDK.

Workaround

Is it possible for you to install the Java 1.8 JDK? If you do, does /usr/libexec/java_home -v 1.8 find it?

Flags: needinfo?(mstange.moz)

I can try! How would you like me to install it? Via brew?

Flags: needinfo?(mstange.moz)

Very good question, I think that installing via brew is the best call:

brew tap adoptopenjdk/openjdk
brew cask install adoptopenjdk8

I'm hoping that /usr/libexec/java_home will prefer the full JDK installed via brew than that JRE it located in JavaAppletPlugin.plugin.

Oh, I just realized that adoptopenjdk8 is already installed. mach bootstrap even upgraded it for me today. It was installed from homebrew/cask-versions/adoptopenjdk8.

Oh, so you're saying that it's already installed, yet /usr/libexec/java_home is preferring JavaAppletPlugin.plugin?
Can you try throwing JavaAppletPlugin in the trash and seeing if it then detects the correct Java 8 installation?

If that doesn't solve it, can you share the results of /usr/libexec/java_home -V?
Thanks :)

Flags: needinfo?(mstange.moz)

That seems to indeed work! After throwing it in the trash, I get:

% /usr/libexec/java_home -v 1.8
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
% /usr/libexec/java_home -V
Matching Java Virtual Machines (4):
    11.0.2 (x86_64) "Oracle Corporation" - "OpenJDK 11.0.2" /Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home
    1.8.0_265 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 8" /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
    1.8.0_172 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
    1.8.0_121 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home
Flags: needinfo?(mstange.moz)

That's good news!
I'll update the docs to recommend the use of adoptopenjdk-8 via brew, and to note that JavaAppletPlugin may need to be removed.

Assignee: nobody → mhentges
Status: NEW → ASSIGNED

And after restoring it from the trash, I get:

% /usr/libexec/java_home -v 1.8
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
% /usr/libexec/java_home -V
Matching Java Virtual Machines (5):
    11.0.2 (x86_64) "Oracle Corporation" - "OpenJDK 11.0.2" /Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home
    1.8.172.11 (x86_64) "Oracle Corporation" - "Java" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
    1.8.0_265 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 8" /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
    1.8.0_172 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
    1.8.0_121 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home

(In reply to Mitchell Hentges [:mhentges] 🦀 from comment #7)

I'll update the docs to recommend the use of adoptopenjdk-8 via brew

I think mach bootstrap already installs it.

I think mach bootstrap already installs it.

Perfect, thanks (and thanks for the greater java_home -V, it looks like it tries to find the newest installation matching the provided major version).

I suppose it would be nice if /usr/libexec/java_home had a --skip-jre flag, but it does not. The only way I can get java_home to print the adoptopenjdk path when JavaAppletPlugin.plugin is present, is to specify the full version number:

% /usr/libexec/java_home -v 1.8.0_265
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home

I'm really curious how macOS 11 changed the behavior here. Did they update the plugin to a newer Java version? Or is there a bug here that's worth filing with Apple?

I'll take a look on my Mac to see if I have JavaAppletPlugin installed - perhaps they added it with macOS 11 (I really doubt it) or perhaps yeah, it was updated.

I think that the longer-term solution here is to adjust our JVM-location strategy to use java_home -V and to find the 1.8 installation that is a JDK.

Flags: needinfo?(mhentges)

Ah, that sounds good too.

mitch@Mitchs-iMac-Pro ~ % /usr/libexec/java_home -V
Matching Java Virtual Machines (1):
    1.8.0_265, x86_64:	"AdoptOpenJDK 8"	/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home

I'm on macOS 10.15.7, though.
Two questions:

  1. How did you get set up with that macOS 11 install? You're not on an ARM Mac ... are you? Was that a fresh install/machine, or did you upgrade?
  2. Any chance that you manually installed the JavaAppletPlugin in the past?

These won't really affect the solution here (docs change, eventual JVM-location strategy update), but it would be good to know if we should expect other environments to have JavaAppletPlugin installed.

Flags: needinfo?(mhentges) → needinfo?(mstange.moz)

(In reply to Mitchell Hentges [:mhentges] 🦀 from comment #14)

  1. How did you get set up with that macOS 11 install? You're not on an ARM Mac ... are you? Was that a fresh install/machine, or did you upgrade?

It was an upgrade on an Intel Mac. I followed these instructions to update to the public Beta.

  1. Any chance that you manually installed the JavaAppletPlugin in the past?

Very unlikely. I don't remember ever having had a reason to do that.

Flags: needinfo?(mstange.moz)

Hey :mstange, I'm attempting to get a local reproduce going here so that the added documentation is as helpful as possible.
I've installed the JRE that I've downloaded from here and correctly see an installation in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home, as you saw as well.

However, /usr/libexec/java_home -V is just printing my AdoptOpenJDK installation, not the JRE.
Can you restore that JavaAppletPlugin from the trash, as you did here, and then run:

$ JAVA_LAUNCHER_VERBOSE=1 /usr/libexec/java_home -V

That could hint how it's detecting it :)

Flags: needinfo?(mstange.moz)

The environment variable doesn't seem to have an effect for me:

% JAVA_LAUNCHER_VERBOSE=1 /usr/libexec/java_home -V
Matching Java Virtual Machines (5):
    11.0.2 (x86_64) "Oracle Corporation" - "OpenJDK 11.0.2" /Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home
    1.8.172.11 (x86_64) "Oracle Corporation" - "Java" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
    1.8.0_265 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 8" /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
    1.8.0_172 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
    1.8.0_121 (x86_64) "Oracle Corporation" - "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home
%
Flags: needinfo?(mstange.moz)

It seems that JAVA_LAUNCHER_VERBOSE=1 is just another way of writing -V, similar to how JAVA_VERSION=1.8 is another way of writing -v 1.8.

JAVA_LAUNCHER_VERBOSE should provide additional information about how/where Java environments are located.
Here's what I see when I run JAVA_LAUNCHER_VERBOSE=1 /usr/libexec/java_home -V:

2020-10-15 15:10:32.001 java_home[651:13580] [JVM Detection] AddJVMsFromLibraryPath: Scanning: file:///Users/mitch/Library/
2020-10-15 15:10:32.001 java_home[651:13580] [JVM Detection] AddJVMsFromLibraryPath: Scanning: file:///Users/mitch/Developer/
2020-10-15 15:10:32.001 java_home[651:13580] [JVM Detection] AddJVMsFromLibraryPath: Scanning: file:///Library/
2020-10-15 15:10:32.002 java_home[651:13580] [JVM Detection] AddJVMsFromSampledFile: Checking for a JVM at: libjli.dylib -- file:///Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/MacOS/
2020-10-15 15:10:32.002 java_home[651:13580] [JVM Detection] Match: Could not find constraint for JVMMaximumSystemVersion
2020-10-15 15:10:32.002 java_home[651:13580] [JVM Detection] Match: Could not find constraint for JVMMaximumFrameworkVersion
2020-10-15 15:10:32.002 java_home[651:13580] [JVM Detection] AddJVMsFromSampledFile: JVM has capabilities: (
    CommandLine,
    JNI,
    BundledApp
)
2020-10-15 15:10:32.002 java_home[651:13580] [JVM Detection] AddJVMsFromLibraryPath: Scanning: file:///Developer/
2020-10-15 15:10:32.002 java_home[651:13580] [JVM Detection] AddJVMsFromLibraryPath: Scanning: file:///System/Library/
2020-10-15 15:10:32.004 java_home[651:13580] [JVM Detection] AddJVMsFromLibraryPath: Scanning: file:///Developer/
available JVMs:
    1.8.0_265, x86_64:	"AdoptOpenJDK 8"	/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home

Matching Java Virtual Machines (1):
    1.8.0_265, x86_64:	"AdoptOpenJDK 8"	/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
Flags: needinfo?(mstange.moz)

Accidental re-NI, let me investigate why it's not working as expected 🤔

Flags: needinfo?(mstange.moz)

Just for kicks, I installed the exact same Java installations that you have:

  • Oracle JDK 11.0.2
  • Oracle JDK 1.8.0_172
  • Oracle JRE 1.8.0_172 (for you, it's listed as 1.8.172.11, weirdly)
  • AdoptOpenJDK JDK 1.8.0_265
  • Oracle JDK 1.8.0_121

But, still only four matches:

$ /usr/libexec/java_home -V                        
Matching Java Virtual Machines (4):
    11.0.2, x86_64:	"Java SE 11.0.2"	/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
    1.8.0_265, x86_64:	"AdoptOpenJDK 8"	/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
    1.8.0_172, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
    1.8.0_121, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home

Also note: the format of our java_home invocations are different. You've got (brackets) around your architecture, and the publisher isn't listed for me.

What to do next

There's an easy long-term fix here that we briefly discussed earlier: bootstrap should run libexec and parse out the correct JDK.
However, before committing to it (there's multiple formats! I don't want to parse all those 😉), I'd really like to track down the root cause of our differing java_home output. It could hint towards a cleaner solution , or perhaps it might allow us to make the docs more concrete (if you're JRE is showing up, it's because of <x>).

One theory I'm thinking about is that Big Sur has changed the behaviour of java_home. As a last resort, I can find a spare drive and opt into the public beta, too.
Before jumping into that, though, would you be able to do the following things and comment the results?

  • Run "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java" -version. This will hopefully explain why its version is different than the others (that trailing .11).
  • Do an ls -al "/Library/Internet Plug-Ins" to see if there's any linking going on
  • Do a big ls -al /Developer/Java /System/Library/Java /Library/Java $HOME/Library/Java $HOME/Developer/Java /Developer/Java/JavaVirtualMachines /System/Library/Java/JavaVirtualMachines /Library/Java/JavaVirtualMachines $HOME/Library/Java/JavaVirtualMachines $HOME/Developer/Java/JavaVirtualMachines, which will hopefully explain how that JRE is detected.
Flags: needinfo?(mstange.moz)
% "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java" -version
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
% ls -al "/Library/Internet Plug-Ins"
total 0
drwxr-xr-x   6 root  wheel   192 15 Oct 17:41 .
drwxr-xr-x  72 root  wheel  2304 14 Oct 20:39 ..
drwxr-xr-x   3 root  wheel    96  4 Nov  2017 AdobePDFViewer.plugin
drwxr-xr-x   3 root  wheel    96  4 Nov  2017 AdobePDFViewerNPAPI.plugin
drwxr-xr-x   3 root  wheel    96 22 Feb  2017 JavaAppletPlugin.plugin
drwxr-xr-x   3 root  wheel    96 12 May 12:31 ZoomUsPlugIn.plugin
% ls -al /Developer/Java /System/Library/Java /Library/Java $HOME/Library/Java $HOME/Developer/Java /Developer/Java/JavaVirtualMachines /System/Library/Java/JavaVirtualMachines /Library/Java/JavaVirtualMachines $HOME/Library/Java/JavaVirtualMachines $HOME/Developer/Java/JavaVirtualMachines
ls: /Developer/Java: No such file or directory
ls: /Developer/Java/JavaVirtualMachines: No such file or directory
ls: /System/Library/Java: No such file or directory
ls: /System/Library/Java/JavaVirtualMachines: No such file or directory
ls: /Users/mstange/Developer/Java: No such file or directory
ls: /Users/mstange/Developer/Java/JavaVirtualMachines: No such file or directory
ls: /Users/mstange/Library/Java: No such file or directory
ls: /Users/mstange/Library/Java/JavaVirtualMachines: No such file or directory
/Library/Java:
total 0
drwxr-xr-x   5 root  wheel   160 14 Oct 20:39 .
drwxr-xr-x  72 root  wheel  2304 14 Oct 20:39 ..
drwxr-xr-x   2 root  wheel    64  1 Jan  2020 Extensions
lrwxr-xr-x   1 root  wheel    64 27 Apr  2018 Home -> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
drwxr-xr-x   6 root  wheel   192 14 Oct 20:39 JavaVirtualMachines

/Library/Java/JavaVirtualMachines:
total 0
drwxr-xr-x  6 root     wheel  192 14 Oct 20:39 .
drwxr-xr-x  5 root     wheel  160 14 Oct 20:39 ..
drwxr-xr-x  3 root     wheel   96  9 Oct 11:27 adoptopenjdk-8.jdk
drwxr-xr-x  3 root     wheel   96 22 Feb  2017 jdk1.8.0_121.jdk
drwxr-xr-x  3 root     wheel   96 27 Apr  2018 jdk1.8.0_172.jdk
drwxr-xr-x@ 3 mstange  staff   96 18 Jan  2019 openjdk-11.0.2.jdk
% ls -la /usr/libexec/java_home
-rwxr-xr-x  1 root  wheel  138848  1 Jan  2020 /usr/libexec/java_home
%
Flags: needinfo?(mstange.moz)

Hey, thanks for your help debugging here. Three surprises to note from your logs:

  1. Nowhere in those directories is there a link to JavaAppletPlugin.plugin! How/why is it detecting it?
  2. Your /usr/libexec/java_home is not a link, but mine is (mine points to /S/L/F/JavaVM.framework/Versions/Current/Commands/java_home.
  3. Your /Library/Java has a link from Home, I have no such link.

I'm guessing that your unexpected java_home behaviour is coming from the Big Sur update. I attempted to install the beta here, but the installer would freeze consistently after ~45s while interacting with Disk Utility.

So, I think we're at the end of the thread here of "why do our two java_home binaries behave differently?".
That's ok, though, I think we have enough information to resolve the original issue:

Next Steps

I talked to Ricky and we landed on the following solution:

  • Explicitly verify that the Java located with java_home is a JDK. Tell the user to install the JDK and/or to set JAVA_HOME.
  • (will affect your case less, but) make the bootstrap Java-detection consistent with the configure Java-detection logic.

Also consolidates bootstrap and configure Java-detection logic so
there's less surprises.

Also consolidates bootstrap and configure Java-detection logic so
there's less surprises.

Attachment #9183812 - Attachment is obsolete: true

Also consolidates bootstrap and configure Java-detection logic so
there's less surprises.

Attachment #9185573 - Attachment is obsolete: true
Pushed by mhentges@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f4b6a154609c Validate detected Java directory to ensure it's a JDK r=nalexander
Regressions: 1675306

https://hg.mozilla.org/mozilla-central/rev/f4b6a154609c

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox84: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch
See Also: → 1722492
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: