Community
Participate
Working Groups
According to two users, Eclipse 2020-06 fails to launch on MacOS with latest Big Sur update. https://www.eclipse.org/forums/index.php?t=msg&th=1104820&goto=1830978&#msg_1830978
Some people seem to have gotten it working again, so I'm not sure if this is caused by the specific Java version or the inability to find a correct Java version properly...
(In reply to Ed Merks from comment #1) > Some people seem to have gotten it working again, so I'm not sure if this is > caused by the specific Java version or the inability to find a correct Java > version properly... Hi there, I am one of the users, who have problems running eclipse on MacOS Big Sur Beta 4. You wrote, that some people seem to have gotten it working again. Do you have a link to the forum, where these people share their experience?
(In reply to Uli Schmidt from comment #2) > Do you have a link to the forum, where these people share their experience? https://www.eclipse.org/forums/index.php?t=msg&th=1104820&goto=1831020&#msg_1831020
I wonder if this is related to /usr/libexec/java_home behaviour changing with the Big Sur Beta 4 upgrade... I have two JVMs installed, 11 and 1.8: ➜ ~ /usr/libexec/java_home -V Matching Java Virtual Machines (2): 11.0.8 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 11" /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home 1.8.0_252 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 8" /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home But note the response to asking for a 1.8 VM: ➜ ~ /usr/libexec/java_home -v 1.8 /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home ➜ ~ /usr/libexec/java_home -v 1.8.0 /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home ➜ ~ /usr/libexec/java_home -v 1.8.0_252 /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
(In reply to Karl von Randow from comment #4) > I wonder if this is related to /usr/libexec/java_home behaviour changing > with the Big Sur Beta 4 upgrade... > > I have two JVMs installed, 11 and 1.8: > > ➜ ~ /usr/libexec/java_home -V > Matching Java Virtual Machines (2): > 11.0.8 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 11" > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > 1.8.0_252 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 8" > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > > > But note the response to asking for a 1.8 VM: > > ➜ ~ /usr/libexec/java_home -v 1.8 > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > ➜ ~ /usr/libexec/java_home -v 1.8.0 > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > ➜ ~ /usr/libexec/java_home -v 1.8.0_252 > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home So I just installed Eclipse Jave EE IDE for Web Developers and changed the plist to <string>-vm</string><string>/Library/Java/JavaVirtualMachines/adoptopenjdk-11-openj9.jdk/Contents/Home/bin</string> It starts no with no error messages. So I tried again to do the same with Eclipse for JAVA. Installer and Package. Changed the plist. MacOS tells me the Application is damaged...
Try using xattr -cr <the-application>.app from a terminal window to remove the extended attributes; that should get rid of the damaged application complaint.
(In reply to Ed Merks from comment #6) > Try using xattr -cr <the-application>.app from a terminal window to remove > the extended attributes; that should get rid of the damaged application > complaint. Thank you! That did it!
(In reply to Uli Schmidt from comment #5) > (In reply to Karl von Randow from comment #4) > > I wonder if this is related to /usr/libexec/java_home behaviour changing > > with the Big Sur Beta 4 upgrade... > > > > I have two JVMs installed, 11 and 1.8: > > > > ➜ ~ /usr/libexec/java_home -V > > Matching Java Virtual Machines (2): > > 11.0.8 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 11" > > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > > 1.8.0_252 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 8" > > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home > > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > > > > > > But note the response to asking for a 1.8 VM: > > > > ➜ ~ /usr/libexec/java_home -v 1.8 > > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > > ➜ ~ /usr/libexec/java_home -v 1.8.0 > > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > > ➜ ~ /usr/libexec/java_home -v 1.8.0_252 > > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home > > So I just installed Eclipse Jave EE IDE for Web Developers and changed the > plist to > <string>-vm</string><string>/Library/Java/JavaVirtualMachines/adoptopenjdk- > 11-openj9.jdk/Contents/Home/bin</string> > > It starts no with no error messages. > > > So I tried again to do the same with Eclipse for JAVA. Installer and > Package. Changed the plist. > > MacOS tells me the Application is damaged... You have saved my life (With this fix I've been able to run Spring Tool Suite 4 and Eclipse 2020-06) This is what I did based on your comment: Environment: Running macOS BigSur (10.16) and java version "14.0.1" 2020-04-14. Steps: Go to Applications folder -> Right click on Eclipse/STS4 -> Click on Show Package Content -> Click on Contents -> open info.plist -> Paste this code replacing the <Array> tags. <array> <!-- to use a specific Java version (instead of the platform's default) uncomment one of the following options, or add a VM found via $/usr/libexec/java_home -V --> <string>-vm</string><string>/Library/Java/JavaVirtualMachines/jdk-14.0.1.jdk/Contents/Home/bin/java</string> <string>-keyring</string> <string>~/.eclipse_keyring</string> </array> Works like magic.
I only have a virtual box for testing Mac and it's super hard to find a virtual disk image for such a thing. So I cannot test the latest MacOS... But I've been working on enhancing the Eclipse Installer so that it contains an embedded JRE such that it should run out-of-the box regardless of which version of Java is installed on the OS and should run even if there is no version of Java installed. The folks on the CC list could do me a huge favor if they could test it. It can be download using either of these two links: https://www.eclipse.org/downloads/download.php?file=/oomph/products/latest/eclipse-inst-jre-mac64.dmg https://download.eclipse.org/oomph/products/latest/eclipse-inst-jre-mac64.dmg It works for me on my virtual box...
(In reply to Ed Merks from comment #9) > I only have a virtual box for testing Mac and it's super hard to find a > virtual disk image for such a thing. So I cannot test the latest MacOS... > > But I've been working on enhancing the Eclipse Installer so that it contains > an embedded JRE such that it should run out-of-the box regardless of which > version of Java is installed on the OS and should run even if there is no > version of Java installed. > > The folks on the CC list could do me a huge favor if they could test it. It > can be download using either of these two links: > > https://www.eclipse.org/downloads/download.php?file=/oomph/products/latest/ > eclipse-inst-jre-mac64.dmg > https://download.eclipse.org/oomph/products/latest/eclipse-inst-jre-mac64.dmg > > It works for me on my virtual box... Hi again! I've downloaded the installer and a soon as I attempt to execute it it shows this error "Can’t be opened because Apple cannot check it for malicious software" is not a hard stop. By right-clicking and clicking on Open it will bypass that warning, but then I get an "Alert": Failed to load the JNI shared library "/Applications/Eclipse Installer.app/Contents/Eclipse/plugins/org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.macosx.x86_64_11.0.2.v20200815-0835/jre/lib/jli/libjli.dylib".
Thank you for testing! I suspect that yet more entitlements are needed for signing and notarization but I have no way to testing any of that. And so far, no one on the platform seems to be paying any attention to this bug.
*** This bug has been marked as a duplicate of bug 565691 ***
I'm not sure this is really a duplicate. The thing you duplicated this against is an umbrella bug that's supposed to list (depend on) specific issues.
I've been able to run the installer on macOS 10.15.6 (Catalina) with no JVMs in the /Library/Java/JavaVirtualMachines folder, which is definitely a bonus, because before Eclipse would complain that a JRE was required and attempt to install one. 96ae3b2655d63197333fad6a063d3c4cce40e9bc eclipse-inst-jre-mac64.dmg I'll see if I can find a machine to test on Big Sur.
*** Bug 566038 has been marked as a duplicate of this bug. ***
(In reply to Ed Merks from comment #11) > Thank you for testing! > > I suspect that yet more entitlements are needed for signing and notarization > but I have no way to testing any of that. > > And so far, no one on the platform seems to be paying any attention to this > bug. Sorry that is not the case we noticed bug 566038 and started investigations on that. I can clearly see the problem in Big Sur public beta. At this point we don't have any update on why this is happening, but we are investigating.
(In reply to Alex Blewitt from comment #14) > I've been able to run the installer on macOS 10.15.6 (Catalina) with no JVMs > in the /Library/Java/JavaVirtualMachines folder, which is definitely a > bonus, because before Eclipse would complain that a JRE was required and > attempt to install one. > > 96ae3b2655d63197333fad6a063d3c4cce40e9bc eclipse-inst-jre-mac64.dmg > > I'll see if I can find a machine to test on Big Sur. Alex, Notice too that when using the installer, the JVM field offers choices of JustJ JREs (11.0.2 and 14.0.2) for use in the installation, so users can run the installer and can create an installation without ever having installed Java manually. :-)
(In reply to Sravan Kumar Lakkimsetti from comment #16) > (In reply to Ed Merks from comment #11) > > Thank you for testing! > > > > I suspect that yet more entitlements are needed for signing and notarization > > but I have no way to testing any of that. > > > > And so far, no one on the platform seems to be paying any attention to this > > bug. > > Sorry that is not the case we noticed bug 566038 and started investigations > on that. I can clearly see the problem in Big Sur public beta. > > At this point we don't have any update on why this is happening, but we are > investigating. Sorry, no offense intended! I always appreciate that I can look to the platform to solve problems such as this one. It was super helpful, for example, to look at how the platform uses Tycho to build the Mac version of the products. I didn't even know that was supported and it let me completely rewrite the Oomph build steps which were doing this manually using shell scripts. I would do more on the Mac front, but my virtual box environment is just not helpful for Mac issues.
Based on the stack trace I see in bug 566038, here is my analysis in our method findSymbol, we are calling appkit framework methods, I think in one of the calls we have a null getting passed. here is the code https://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/features/org.eclipse.equinox.executable.feature/library/cocoa/eclipseCocoaCommon.c#n150
I tried to launch eclipse using launcher jar and I am able to launch it. Looks to me the problem is with launcher executable. Here is the specific command line I used java -Dosgi.requiredJavaVersion=11 -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx2048m --add-modules=ALL-SYSTEM -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -jar /Applications/Eclipse.app/Contents/Eclipse/plugins/org.eclipse.equinox.launcher_1.5.800.v20200727-1323.jar
(In reply to Ed Merks from comment #13) > I'm not sure this is really a duplicate. The thing you duplicated this > against is an umbrella bug that's supposed to list (depend on) specific > issues. I agree.
using ./eclipse -vm <path to java executable> is working. also you can add this to eclipse.ini this is also working.
(In reply to Sravan Kumar Lakkimsetti from comment #22) > using ./eclipse -vm <path to java executable> is working. also you can add > this to eclipse.ini this is also working. So it's pointing at "jre/lib/jli/libjli.dylib" that stops working with Big Sur which is also what the native launcher tries to do and why it fails unless someone changes the -vm or the info.plist... I think this way current it doesn't launch a new process but pointing at the java executable would launch a new process... I would need to regenerate all the JustJ JREs to use that different approach, though it seems less ideal. Perhaps the native launcher will be fixed to address whatever is going wrong on Big Sur? I suppose that will be needed in general for the platform's products and the EPP products to launch from whatever Java version is install, right? THANKS for all the investigative work!!
I just tested "/usr/libexec/java_home" on a fresh Big Sur Beta (20A5343j) with AdoptOpenJDK 1.8, 11 and 14 installed, and can confirm that there is something wrong with it. A bug report has been filed at Apple. Attempting to run the Eclipse installer from download.eclipse.org results in a hard crash. Running it from the command line returns "zsh: illegal hardware instruction ./eclipse-inst".
(In reply to Ed Merks from comment #23) > (In reply to Sravan Kumar Lakkimsetti from comment #22) > > using ./eclipse -vm <path to java executable> is working. also you can add > > this to eclipse.ini this is also working. > > So it's pointing at "jre/lib/jli/libjli.dylib" that stops working with Big > Sur which is also what the native launcher tries to do and why it fails > unless someone changes the -vm or the info.plist... Not exactly. As far as I remember, when we point to java executable, we strip out java executable and load libjli.dylib from the java executable path in Mac. I still need to do some more investigations on that. Give me couple of days before you start on JustJ Thanks
Launcher is looking for java library in /System/Library/Frameworks/JavaVM.framework which is path for java browser plugin. Investigating for a fix now.
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/167943
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/167943 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=02552e059ba37c673e9ba01c99e50eec3a3641cb
Merged the code to master and launcher has been rebuilt and committed https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=a1b8dec16a714598e8ea3917ab96c6f4aeef30da
(In reply to Sravan Kumar Lakkimsetti from comment #29) > Merged the code to master and launcher has been rebuilt and committed > https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/ > ?id=a1b8dec16a714598e8ea3917ab96c6f4aeef30da Awesome. The fix looks simple. If I rebuild with the next platform IBuild to produce new installers with the new executables we will (someone will) be able to retest.
Verified in Eclipse SDK Version: 2020-09 (4.17) Build id: I20200819-0600 OS: Mac OS X, v.10.15.6, x86_64 / cocoa Java version: 14.0.2 and Eclipse SDK Version: 2020-09 (4.17) Build id: I20200819-0600 OS: Mac OS X, v.10.16, x86_64 / cocoa Java version: 14.0.2
I've rebuilt the installer using the latest 4.17 integration build so the following now contain the latest equinox launcher. https://www.eclipse.org/downloads/download.php?file=/oomph/products/latest/eclipse-inst-jre-mac64.dmg https://download.eclipse.org/oomph/products/latest/eclipse-inst-jre-mac64.dmg It would be super helpful and much appreciated if someone could try this on Big Sur.
Created attachment 283912 [details] Error dialog Just tried with binary from the latter link. Using the command line I got the following error message: torkild@macos-big-sur MacOS % ./eclipse-inst dlopen(/Applications/Eclipse Installer.app/Contents/Eclipse/plugins/org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.macosx.x86_64_11.0.2.v20200815-0835/jre/lib/jli/libjli.dylib, 2): no suitable image found. Did find: /Applications/Eclipse Installer.app/Contents/Eclipse/plugins/org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.macosx.x86_64_11.0.2.v20200815-0835/jre/lib/jli/libjli.dylib: code signature in (/Applications/Eclipse Installer.app/Contents/Eclipse/plugins/org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.macosx.x86_64_11.0.2.v20200815-0835/jre/lib/jli/libjli.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. Unable to create basic Accelerated OpenGL renderer. Unable to create basic Accelerated OpenGL renderer. Core Image is now using the software OpenGL renderer. This will be slow.
That's different than before but still not good. I would expect that library validation is turned off: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation We use that here: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/releng/org.eclipse.oomph.releng/hudson/installer.entitlements#n13 The fact that this works on older MacOS but not on Big Sur suggests that perhaps there is some new entitlement needed or that the hardening/signing process needs to do something else/more because it's become more strict.
(In reply to Ed Merks from comment #34) > That's different than before but still not good. > > I would expect that library validation is turned off: > > https://developer.apple.com/documentation/bundleresources/entitlements/ > com_apple_security_cs_disable-library-validation > > We use that here: > > https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/releng/org. > eclipse.oomph.releng/hudson/installer.entitlements#n13 > > The fact that this works on older MacOS but not on Big Sur suggests that > perhaps there is some new entitlement needed or that the hardening/signing > process needs to do something else/more because it's become more strict. I did some analysis the justj libraries are based on Java 11.0.2. java libraries are not signed in this particular version. I am using java 14.0.2 and java 11.0.8. both have signed libraries. Is it possible for you to create justj libraries based on 11.0.8?
No, I can only consume from https://jdk.java.net/ and they don't provide LTS versions. And Java 14 doesn't provide unpack200 so is less than ideal especially for an installer. And only Mac is a problem. I have bad feeling that the entitlements aren't being picked up. I did a build with -X: https://ci.eclipse.org/oomph/job/integration/4780/consoleFull And here it show this, and I see no evidence that the entitlements are configure: [DEBUG] ----------------------------------------------------------------------- [DEBUG] Goal: org.eclipse.cbi.maven.plugins:eclipse-macsigner-plugin:1.1.7:sign (default) [DEBUG] Style: Regular [DEBUG] Configuration: <?xml version="1.0" encoding="UTF-8"?> <configuration> <baseSearchDir default-value="${project.build.directory}/products/">${cbi.macsigner.baseSearchDir}</baseSearchDir> <continueOnFail>${cbi.macsigner.continueOnFail}</continueOnFail> <deprecatedBaseSearchDir default-value="${project.build.directory}/products/">${baseSearchDir}</deprecatedBaseSearchDir> <deprecatedContinueOnFail default-value="false">${continueOnFail}</deprecatedContinueOnFail> <deprecatedFileNames>${fileNames}</deprecatedFileNames> <deprecatedRetryLimit default-value="3">${retryLimit}</deprecatedRetryLimit> <deprecatedRetryTimer default-value="10">${retryTimer}</deprecatedRetryTimer> <deprecatedSignFiles>${signFiles}</deprecatedSignFiles> <fileNames> <fileName>Eclipse Installer.app</fileName>${cbi.macsigner.fileNames}</fileNames> <retryLimit default-value="3">${cbi.macsigner.retryLimit}</retryLimit> <retryTimer default-value="10">${cbi.macsigner.retryTimer}</retryTimer> <signFiles>${cbi.macsigner.signFiles}</signFiles> <signerUrl default-value="http://build.eclipse.org:31338/macsign.php">http://172.30.206.146:8282/macosx-signing-service/1.0.1-SNAPSHOT</signerUrl> <timeoutMillis default-value="0">300000</timeoutMillis> </configuration> Also here: [DEBUG] Configuring mojo org.eclipse.cbi.maven.plugins:eclipse-macsigner-plugin:1.1.7:sign from plugin realm ClassRealm[plugin>org.eclipse.cbi.maven.plugins:eclipse-macsigner-plugin:1.1.7, parent: jdk.internal.loader.ClassLoaders$AppClassLoader@799f7e29] [DEBUG] Configuring mojo 'org.eclipse.cbi.maven.plugins:eclipse-macsigner-plugin:1.1.7:sign' with basic configurator --> [DEBUG] (f) baseSearchDir = /jobs/genie.oomph/integration/workspace/git/products/org.eclipse.oomph.setup.installer.product/target/products/ [DEBUG] (f) deprecatedBaseSearchDir = /jobs/genie.oomph/integration/workspace/git/products/org.eclipse.oomph.setup.installer.product/target/products/ [DEBUG] (f) deprecatedContinueOnFail = false [DEBUG] (f) deprecatedFileNames = [] [DEBUG] (f) deprecatedRetryLimit = 3 [DEBUG] (f) deprecatedRetryTimer = 10 [DEBUG] (f) deprecatedSignFiles = [] [DEBUG] (f) fileNames = [Eclipse Installer.app] [DEBUG] (f) retryLimit = 3 [DEBUG] (f) retryTimer = 10 [DEBUG] (f) signFiles = [] [DEBUG] (f) signerUrl = http://172.30.206.146:8282/macosx-signing-service/1.0.1-SNAPSHOT [DEBUG] (f) timeoutMillis = 300000 [DEBUG] -- end configuration -- Does 1.1.7 not sign with entitlements? Surely I should see it being configured...
(In reply to Ed Merks from comment #36) > > Does 1.1.7 not sign with entitlements? Surely I should see it being > configured... 1.1.7 does not have capability to sign with entitlements. Here is the summary of changes we did https://bugs.eclipse.org/bugs/show_bug.cgi?id=549836#c16. for hardened runtime and entitlements you need to use 1.1.8-SNAPSHOT.
(In reply to Sravan Kumar Lakkimsetti from comment #37) > (In reply to Ed Merks from comment #36) > > > > Does 1.1.7 not sign with entitlements? Surely I should see it being > > configured... > > 1.1.7 does not have capability to sign with entitlements. > Here is the summary of changes we did > https://bugs.eclipse.org/bugs/show_bug.cgi?id=549836#c16. > > for hardened runtime and entitlements you need to use 1.1.8-SNAPSHOT. THANKS! That looks better now: [DEBUG] Configuring mojo 'org.eclipse.cbi.maven.plugins:eclipse-macsigner-plugin:1.1.8-SNAPSHOT:sign' with basic configurator --> [DEBUG] (f) baseSearchDir = /jobs/genie.oomph/integration/workspace/git/products/org.eclipse.oomph.setup.installer.product/target/products/ [DEBUG] (f) deprecatedBaseSearchDir = /jobs/genie.oomph/integration/workspace/git/products/org.eclipse.oomph.setup.installer.product/target/products/ [DEBUG] (f) deprecatedContinueOnFail = false [DEBUG] (f) deprecatedFileNames = [] [DEBUG] (f) deprecatedRetryLimit = 3 [DEBUG] (f) deprecatedRetryTimer = 10 [DEBUG] (f) deprecatedSignFiles = [] [DEBUG] (f) entitlements = /jobs/genie.oomph/integration/workspace/git/products/org.eclipse.oomph.setup.installer.product/../../releng/org.eclipse.oomph.releng/hudson/installer.entitlements [DEBUG] (f) fileNames = [Eclipse Installer.app] [DEBUG] (f) retryLimit = 3 [DEBUG] (f) retryTimer = 10 [DEBUG] (f) signFiles = [] [DEBUG] (f) signerUrl = http://172.30.206.146:8282/macosx-signing-service/1.0.1-SNAPSHOT [DEBUG] (f) timeoutMillis = 300000 I've produced yet another build to produce this new version: https://download.eclipse.org/oomph/products/latest/eclipse-inst-jre-mac64.dmg This version does show that it has the expected entitlements. Hopefully someone can test it...
(In reply to Ed Merks from comment #38) > Hopefully someone can test it... Thanks Ed. This build works just fine and I successfully installed the Java IDE. It correctly picked up the Java 14 JDK I had installed. However I got the "Can’t be opened because Apple cannot check it for malicious software" message and had to explicitly allow the installer to run using "System Preferences... > Security & Privacy". I guess notarisation is not fully in order.
(In reply to Torkild Resheim from comment #39) > (In reply to Ed Merks from comment #38) > > Hopefully someone can test it... > > Thanks Ed. This build works just fine and I successfully installed the Java > IDE. It correctly picked up the Java 14 JDK I had installed. > > However I got the "Can’t be opened because Apple cannot check it for > malicious software" message and had to explicitly allow the installer to run > using "System Preferences... > Security & Privacy". I guess notarisation is > not fully in order. I assumed that the Tycho build did the notarization, but this is not the case. So I think the scripts for that are still needed. Sravan, please correct me if I'm wrong... So I'm trying to enable the notarization scripts, but notarization fails with issues such as these on the executables in the JRE's bin folder: The executable does not have the hardened runtime enabled. And this for various *.dylibs: The binary is not signed. So I think 11.0.2 is too old. I'm not sure that the 14.0.2 JustJ JREs would avoid that problem, but 14.0.2 is very recent so perhaps is more Mac friendly. So I'll have to test if those have been signed such that I can notarize them. But Java 14 doesn't include unpack200 which is kind of bad for an installer...
(In reply to Ed Merks from comment #40) > (In reply to Torkild Resheim from comment #39) > > (In reply to Ed Merks from comment #38) > > > Hopefully someone can test it... > > > > Thanks Ed. This build works just fine and I successfully installed the Java > > IDE. It correctly picked up the Java 14 JDK I had installed. > > > > However I got the "Can’t be opened because Apple cannot check it for > > malicious software" message and had to explicitly allow the installer to run > > using "System Preferences... > Security & Privacy". I guess notarisation is > > not fully in order. > > I assumed that the Tycho build did the notarization, but this is not the > case. So I think the scripts for that are still needed. Sravan, please > correct me if I'm wrong... > > So I'm trying to enable the notarization scripts, but notarization fails > with issues such as these on the executables in the JRE's bin folder: > > The executable does not have the hardened runtime enabled. > > And this for various *.dylibs: > > The binary is not signed. > > So I think 11.0.2 is too old. > > I'm not sure that the 14.0.2 JustJ JREs would avoid that problem, but 14.0.2 > is very recent so perhaps is more Mac friendly. So I'll have to test if > those have been signed such that I can notarize them. But Java 14 doesn't > include unpack200 which is kind of bad for an installer... Notarization still script based. Here is the method we use https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/scripts/common-functions.shsource#n47 This is based on your work but slightly enhanced to retry 3 times in case of failures. Java 11.0.2 is quite old(dylibs are not signed at all). adoptopenjdk 11.0.8 has proper signatures on all executables and libraries. I did a sanity check on the executables and libraries of openjdk 14.0.2 they are signed with hardened runtime.
Sravan, Thanks so very much for your continued support!! Yes, I assume that 14.0.2 would be okay because the EPP packages have included this and they must have successfully notarized... So now the question for me with the installer is, use 14.0.2 because Mac specifically only works for that newer version, or use 11.0.2 because pack.gz files are much smaller and most users are on Windows: https://dev.eclipse.org/committers/committertools/stats.php?filename=/oomph/epp/2020-06/R I personally have a 1G internet connection so I don't really care... I'm not sure what's really best for the community... If the adoptium project would make progress faster in getting board approvals, I would be able to consume from that to get 11.0.8. But I can't. :-(
I've read through this issue but remain unclear what the real issue is. We have an RCP application, "Archi" that bundles Java AdoptOpenJDK 11.0.3 inside of the "Archi.app" app bundle. The Archi.ini file contains this line: -vm jre/lib/jli/libjli.dylib Will this work on Big Sur? Or do we need to change this line to point to jre/bin/java or use a different Java version? Or something else? Thanks for any help.
The Eclipse Install app includes an embedded JRE so I think you only need to build with the latest released version of the platform to use the fixed native launcher for your application to work on the latest Mac OS.
(In reply to Ed Merks from comment #44) > The Eclipse Install app includes an embedded JRE so I think you only need to > build with the latest released version of the platform to use the fixed > native launcher for your application to work on the latest Mac OS. The RCP app is built on Eclipse 4.15. So do we need to build using 4.17 to get the fixed native launcher? Is it these files? -startup ../Eclipse/plugins/org.eclipse.equinox.launcher_1.5.800.v20200727-1323.jar --launcher.library ../Eclipse/plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.1300.v20200819-0940 Thanks for replying, Ed, I appreciate it. :-)
Yes, building with 4.17 fixed the problem with the installer. If I understand correctly, it's the things (with *.executable.* in the name) in the binary folder of the p2 repo that contain the actual executable: https://download.eclipse.org/justj/?file=eclipse/updates/4.17/R-4.17-202009021800/binary So assuming you're doing a Maven/Tycho build, yes using 4.17 in your target platform (or repository lists) is needed.
(In reply to Phil Beauvoir from comment #43) > I've read through this issue but remain unclear what the real issue is. > > We have an RCP application, "Archi" that bundles Java AdoptOpenJDK 11.0.3 > inside of the "Archi.app" app bundle. > > The Archi.ini file contains this line: > > -vm > jre/lib/jli/libjli.dylib > > Will this work on Big Sur? Or do we need to change this line to point to > jre/bin/java or use a different Java version? Or something else? > > Thanks for any help. This issue occurs when you don't use -vm option. Launcher executable resolves JAVA_HOME assuming /usr/bin/java as symbolic link. This is true till MacOS 10.15. But with Big Sur /usr/bin/java is universal binary with x86_64 and arm64 slices in it. This caused launcher executable to fail. if you have -vm specified in ini file, my suggestion is to point it to java executable path 'jre/bin/java'. Launcher deduces dylib location based on path provided in -vm and loads java libraries in to eclipse process You'll need this fix if you want to use default java installed on the system. If you want to use java from non default locations, using -vm option, you should be good. Hope this helps
Thanks very much for the help, Ed and Sravan. I have some pointers now. I'll test when Big Sur is released and see if I need to target Eclipse 4.17 and/or change the -vm to jre/bin/java.
I downloaded MacOS Big Sur Public Beta 5 (20A5384c) and tested our RCP app with its bundled JRE. I didn't need to do anything with the `-vm` settings and it launched OK. However, trying to open any diagrams built on GMF/GEF/Draw2d/Sirius (and any Sirius based diagrams in the Ecore digram tooling in Eclipse, see #567722) totally crashes on Big Sur with a EXC_BAD_ACCESS (SIGABRT) crash. Might be an SWT issue - not sure how/where to report this.
(In reply to Phil Beauvoir from comment #49) > I downloaded MacOS Big Sur Public Beta 5 (20A5384c) and tested our RCP app > with its bundled JRE. I didn't need to do anything with the `-vm` settings > and it launched OK. > > However, trying to open any diagrams built on GMF/GEF/Draw2d/Sirius (and any > Sirius based diagrams in the Ecore digram tooling in Eclipse, see #567722) > totally crashes on Big Sur with a EXC_BAD_ACCESS (SIGABRT) crash. Might be > an SWT issue - not sure how/where to report this. can you please attach a reproducible snippet if possible and crash log?
> can you please attach a reproducible snippet if possible and crash log? See Bug 543796
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/173772
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/173772 was merged to [R4_15_maintenance]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=baa4a40fb190b731969798aa3e44eef56dd622e4
(In reply to Eclipse Genie from comment #53) > Gerrit change > https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/173772 was merged > to [R4_15_maintenance]. > Commit: > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/ > ?id=baa4a40fb190b731969798aa3e44eef56dd622e4 Back ported to 4.15 maintenance branch and launchers have been rebuilt
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/182526
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/182526 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=632254d2fbe62a6ff1be315b16623f3ca28c4fdf
