Community
Participate
Working Groups
Created attachment 269533 [details] Disabled Menu All of the Menu Bar has been disabled. I've attempted updating my Java. I've attempted downloading a new version of Eclipse. None of this has worked. I've reinstalled Eclipse. I cannot find why this is an issue.
Comment on attachment 269533 [details] Disabled Menu OS - Mac OS High Sierra - Version 10.13 Beta (17A306f).
Not sure if I can help, but... - did yo check if other packages show the same error, or - did you try to download a pristine Eclipse SDK from [1], or - did you try to use the installer? [1] http://download.eclipse.org/eclipse/downloads/drops4/R-4.7-201706120950/
I did yes. And I have downloaded the SDK yes. I've tried the installer. I also downloaded Oxygen, and it didn't work.
Moving to Platform because this problem is also in the SDK. I don't have access to High Sierra so I cannot confirm the issue.
I don't have access to High Sierra yet to try this. Is the Eclipse menu also disabled? Do any of the menu shortcuts work?
Bryan, can you reference the Apple bug you created for this? (https://twitter.com/BryanHunt/status/890372680284868608)
Gunnar, that is not me. I contacted Apple Support and they recommended talking to Eclipse support. And that's when I've created this thread.
(In reply to Gunnar Wagenknecht from comment #6) > Bryan, can you reference the Apple bug you created for this? > > (https://twitter.com/BryanHunt/status/890372680284868608) Gunnar, that is not me. I contacted Apple Support and they recommended talking to Eclipse support. And that's when I've created this thread.
I can confirm that the Eclipse menus are all disabled on High Sierra public beta 2 and 3. The actions still work, toolbars still work, and context menus still work. All of the main menus except for the Eclipse menu are disabled. I'm not a developer so I don't have access to Apple's bug database. I submitted the report using the public beta feedback tool. Note that this is reproducible on the public beta.
I have just tested on a fresh install of High Sierra 10.13 Beta (17A315i) (Beta 4) and the menus works just as expected. I installed the following using the Eclipse Installer. Eclipse IDE for Eclipse Committers Version: Oxygen Release (4.7.0) Build id: 20170620-1800 It appears the problem was fixed.
(In reply to Torkild Resheim from comment #10) > I have just tested on a fresh install of High Sierra 10.13 Beta (17A315i) > (Beta 4) and the menus works just as expected. I installed the following > using the Eclipse Installer. I'm running the same version of High Sierra and Eclipse. It is NOT working for me.
The problem seems to affect Java apps. Are you guys on the same Java version?
(In reply to Gunnar Wagenknecht from comment #12) > The problem seems to affect Java apps. Are you guys on the same Java version? Good point. I'm using JDK: java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
(In reply to Bryan Hunt from comment #9) > I'm not a developer so I don't have access to Apple's bug database. I > submitted the report using the public beta feedback tool. I'm a registered Apple developer, but cannot find the report related to this. I believe you only get access to your own reports.
java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
(In reply to Bryan Hunt from comment #15) > java version "1.8.0_144" > Java(TM) SE Runtime Environment (build 1.8.0_144-b01) > Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) Bryan, do you have any other JVMs installed?
Can you guys try the workaround in bug 519724 comment 3?
(In reply to Gunnar Wagenknecht from comment #17) > Can you guys try the workaround in bug 519724 comment 3? Installing JDK 6 works around the problem. The Eclipse menus are now enabled for me. Prior to this, I only had JDK 8u131 and 8u144 installed.
(In reply to Bryan Hunt from comment #18) > (In reply to Gunnar Wagenknecht from comment #17) > > Can you guys try the workaround in bug 519724 comment 3? > > Installing JDK 6 works around the problem. The Eclipse menus are now > enabled for me. > > Prior to this, I only had JDK 8u131 and 8u144 installed. This is really strange. On my clean macOS 10.13 machine I had only 8u144 and everything worked just fine. Bryan, is it possible that the Eclipse installation was picking up 8u131? I've noticed the Eclipse installer likes to specify which VM to use in eclipse.ini.
Good catch. My eclipse.ini does specify JDK 8u131.
(In reply to Bryan Hunt from comment #20) > Good catch. My eclipse.ini does specify JDK 8u131. I manually removed 8u144 from my test machine by deleting/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/ (hopefully that is sufficient) and created a new installation with 8u131. All menus still works as expected. I wonder if this could be related to bug #457921.
Are there any other working hotfixes? JDK6 doesn't solve the problem here (macOS 10.13 Beta 17A352a with Eclipse Oxygen 4.7.0 20170620-1800). Removing all JDKs, installing JDK6 and 1.8.0_144 still results in disabled menus. Fresh eclipse install with fresh workspace still results in disabled menus. Update to macOS 10.13 Beta 17A358a still has disabled menus. I always used the Oomph installer, still tried a standalone download with no changes (no surprise, but was desperate). Pointing the eclipse.ini VM to the right JDK or to remove the option doesn't solve the problem here. There is a small workaround which should be mentioned here, for those who might not know: Using the "Quick Access menu" and keyboard shortcuts offers some of the functions.
*** Bug 521716 has been marked as a duplicate of this bug. ***
Created attachment 270182 [details] jdk6_install_dlg screenshot As another data point, it's been working fine for me -- my environment: - OSX 10.13 public beta 7 (17A358A) in Virtualbox - Rootfs is HFS+ (and *not* APFS); clean install (*no* upgrade) - Eclipse C/C++ Package Oxygen.R - Oracle JDK 8u144 On High Sierra freshly installed from scratch, I had first downloaded the Eclipse C/C++ package and launched it; which gave me attached "you have to install JDK6" dialog. I ignored that dialog and installed Oracle JDK 8u144 instead (not the JRE). Since then, things have been working mostly OK from an Eclipse point of view. The virtualbox as a whole hung a couple times, but I suspect that's due to virtualbox and not OSX. See also bug 519886 comment 7 ff.
*** Bug 522250 has been marked as a duplicate of this bug. ***
After upgrading my workstation to macOS 10.13GM I can confirm that this is a problem. For some reason it did not occur on my virtual machines running macOS 10.13. I'm worried that when the new macOS will be released in a week or so, we'll get a lot of complaints about this.
Simply installing the legacy Java distribution from Apple did not solve the problem.
(In reply to Torkild Resheim from comment #26) > I'm worried that when the new macOS will be released in a week or so, we'll > get a lot of complaints about this. Yes, this issue should be top-priority. If something like that happens to any SWT based application, the users will blame the application, not Apple (for having changed again some tiny thing risking applications to break).
I just tried the SAME (stored on Dropbox) eclipse installation (LUNA SR2) on two different Macs. One has High Sierra GM, the other High Sierra newest public beta and the problem only occurs with the newer one, sadly the GM. -.- Both Macs have Oracle SDK 1.8.144.
Maybe some race condition that occurs only on real hardware, but not in virtual machines? I'm not sure if it might be related -- in the past, I've also been unable to use the global menu bar on any Eclipse instances launched from Eclipse PDE as a debuggee. This happened on El Capitan already, and also Sierra. The symptoms were slightly different though -- the global menu never reacted at all. So I wouldn't be able to show eg the "File" menu at all. I always assumed that this was due to the menu still being owned by the parent PDE (which could still use the menu) while the debuggee wouldn't take it over. After switching context to the parent Eclipse and then back to the debuggee Eclipse it would work. So didn't bother reporting this so far...
(In reply to Martin Oberhuber from comment #30) > I'm not sure if it might be related -- in the past, I've also been unable to > use the global menu bar on any Eclipse instances launched from Eclipse PDE > as a debuggee. This happened on El Capitan already, and also Sierra. The Martin, I believe that would be bug 457921
I've done some testing. The RCP application I'm working on exhibits the same behaviour, but the most basic SWT-application, Snippet29, does not. So I'm still leaning towards 457921 being related.
(In reply to Torkild Resheim from comment #32) > I've done some testing. The RCP application I'm working on exhibits the same > behaviour, but the most basic SWT-application, Snippet29, does not. So I'm > still leaning towards 457921 being related. Do you also see the problem with the IDE, i.e. http://download.eclipse.org/eclipse/downloads/drops4/M-4.7.1RC4-201709061700/download.php?dropFile=eclipse-SDK-4.7.1RC4-macosx-cocoa-x86_64.dmg ?
(In reply to Dani Megert from comment #33) > (In reply to Torkild Resheim from comment #32) > > I've done some testing. The RCP application I'm working on exhibits the same > > behaviour, but the most basic SWT-application, Snippet29, does not. So I'm > > still leaning towards 457921 being related. > > Do you also see the problem with the IDE, i.e. > http://download.eclipse.org/eclipse/downloads/drops4/M-4.7.1RC4-201709061700/download.php?dropFile=eclipse-SDK-4.7.1RC4-macosx-cocoa-x86_64.dmg > ? Forget it. Comment 0 already says so.
(In reply to Torkild Resheim from comment #32) > I've done some testing. The RCP application I'm working on exhibits the same > behaviour, but the most basic SWT-application, Snippet29, does not. So I'm > still leaning towards 457921 being related. Which JRE/JDK are you using? Can you try with the one that Martin used in comment 24?
(In reply to Torkild Resheim from comment #32) > I've done some testing. The RCP application I'm working on exhibits the same > behaviour, but the most basic SWT-application, Snippet29, does not. That is not surprising because Snippet29 does not set the display's menubar.
(In reply to Thomas Singer from comment #36) > (In reply to Torkild Resheim from comment #32) > > I've done some testing. The RCP application I'm working on exhibits the same > > behaviour, but the most basic SWT-application, Snippet29, does not. > > That is not surprising because Snippet29 does not set the display's menubar. What am I missing? public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); Menu bar = new Menu (shell, SWT.BAR); shell.setMenuBar (bar); MenuItem fileItem = new MenuItem (bar, SWT.CASCADE); fileItem.setText ("&File"); Menu submenu = new Menu (shell, SWT.DROP_DOWN); fileItem.setMenu (submenu); MenuItem item = new MenuItem (submenu, SWT.PUSH); item.addListener (SWT.Selection, e -> System.out.println ("Select All")); item.setText ("Select &All\tCtrl+A"); item.setAccelerator (SWT.MOD1 + 'A'); shell.setSize (200, 200); shell.open (); while (!shell.isDisposed()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); }
I've installed the 10.13 public beta on a VirtualBox VM, but I'm unable to see the problem. Eclipse uses jdk1.8.0_144.jdk on the VM. I don't have access to the GM build yet, but will try to get one and investigate the issue. (In reply to Torkild Resheim from comment #37) > (In reply to Thomas Singer from comment #36) > > (In reply to Torkild Resheim from comment #32) > > > I've done some testing. The RCP application I'm working on exhibits the same > > > behaviour, but the most basic SWT-application, Snippet29, does not. > > > > That is not surprising because Snippet29 does not set the display's menubar. > > What am I missing? The snippet doesn't use display.getMenuBar() which returns the application menubar on mac. Can you try Snippet347 which uses the application menubar (http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet347.java)?
(In reply to Lakshmi Shanmugam from comment #38) > I've installed the 10.13 public beta on a VirtualBox VM, but I'm unable to > see the problem. Eclipse uses jdk1.8.0_144.jdk on the VM. I don't have > access to the GM build yet, but will try to get one and investigate the > issue. I have tested with various versions of both Eclipse and JDK using VMWare Fusion, but have so far been unable to reproduce the problem in the virtual machine. Note that I created fresh machine instances. > The snippet doesn't use display.getMenuBar() which returns the application > menubar on mac. Ah, thanks. Upon visual inspection I cannot see any difference between creating a new menu bar and getting an instance from Display. > Can you try Snippet347 which uses the application menubar > (http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/ > org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet347.java)? Yes, that 347 and 348 works just fine.
(In reply to Torkild Resheim from comment #39) > (In reply to Lakshmi Shanmugam from comment #38) > > I've installed the 10.13 public beta on a VirtualBox VM, but I'm unable to > > see the problem. Eclipse uses jdk1.8.0_144.jdk on the VM. I don't have > > access to the GM build yet, but will try to get one and investigate the > > issue. > I have tested with various versions of both Eclipse and JDK using VMWare > Fusion, but have so far been unable to reproduce the problem in the virtual > machine. Note that I created fresh machine instances. > > > The snippet doesn't use display.getMenuBar() which returns the application > > menubar on mac. > Ah, thanks. Upon visual inspection I cannot see any difference between > creating a new menu bar and getting an instance from Display. > > > Can you try Snippet347 which uses the application menubar > > (http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/ > > org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet347.java)? > Yes, that 347 and 348 works just fine. I assume this is based on testing on a non-virtual box where you see the menu issues for RCP? Do you use 1.8.0_144.jdk?
Over at [1], it looks as if a similar (but not identical) problem with the menu bars for Java applications on the High Sierra betas was fixed upstream. It might be worth to re-test with the latest High Sierra release candidate. [1] https://youtrack.jetbrains.com/issue/JRE-434#comment=27-2424694
(In reply to Dani Megert from comment #40) > (In reply to Torkild Resheim from comment #39) > > (In reply to Lakshmi Shanmugam from comment #38) > > > I've installed the 10.13 public beta on a VirtualBox VM, but I'm unable to > > > see the problem. Eclipse uses jdk1.8.0_144.jdk on the VM. I don't have > > > access to the GM build yet, but will try to get one and investigate the > > > issue. > > I have tested with various versions of both Eclipse and JDK using VMWare > > Fusion, but have so far been unable to reproduce the problem in the virtual > > machine. Note that I created fresh machine instances. > > > > > The snippet doesn't use display.getMenuBar() which returns the application > > > menubar on mac. > > Ah, thanks. Upon visual inspection I cannot see any difference between > > creating a new menu bar and getting an instance from Display. > > > > > Can you try Snippet347 which uses the application menubar > > > (http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/ > > > org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet347.java)? > > Yes, that 347 and 348 works just fine. > > I assume this is based on testing on a non-virtual box where you see the > menu issues for RCP? Do you use 1.8.0_144.jdk? Yes to both questions. I was also using JDK 1.8.0_121, showing the same issue.
(In reply to Thomas Wolf from comment #41) > Over at [1], it looks as if a similar (but not identical) problem with the > menu bars for Java applications on the High Sierra betas was fixed upstream. > > It might be worth to re-test with the latest High Sierra release candidate. > > [1] https://youtrack.jetbrains.com/issue/JRE-434#comment=27-2424694 That's interesting. However I am using the latest High Sierra release candidate (17A362a). Although I expect at least one more to be published as this one is not as stable as I would expect.
I tried to reproduce using the sample Eclipse 4 RCP application but could not get it to fail. When simply creating a new Eclipse Application launch configuration and starting the "org.eclipse.platform.ide" product I run into bug 457921, so as usual, I switch focus to the original window then back again – and now all menus works just as expected in the launched product. The launching IDE still have all it's menu items disabled.
Maybe you can try easier SWT-based applications, too? For SmartSVN this bug has been reported 2 times, for SmartGit we haven't got a report. SmartGit uses a launcher script, SmartSVN a binary launcher - though it should be able to start easily using a script, too. If you like to try and need more support, you may contact us at support@syntevo.com.
(In reply to Thomas Singer from comment #45) > Maybe you can try easier SWT-based applications, too? For SmartSVN this bug > has been reported 2 times, for SmartGit we haven't got a report. SmartGit > uses a launcher script, SmartSVN a binary launcher - though it should be > able to start easily using a script, too. If you like to try and need more > support, you may contact us at support@syntevo.com. I think you're on to something. I tried starting Eclipse not using the executable: java -XstartOnFirstThread -jar ./Eclipse.app/Contents/Eclipse/plugins/org.eclipse.equinox.launcher_1.4.0.v20161219-1356.jar. And all the menus now works as expected.
So I've created a separate partition to install the High Sierra GM natively on my Mac - and I cannot reproduce the issue! My environment: - OSX 10.13 GM (17A362a) installed as an "Update" of a genuine 10.12.5, APFS - JDK 1.8.0_144 - Eclipse SDK Oxygen.1 RC4 , Smartgit v.17 , SmartSVN 9.2 -- all working fine My hardware is a 13-inch 2017 MBP (Iris+ 650 Graphics), Core i5 dual, 16GB RAM and I've given 60GB of the internal SSD to High Sierra... Sysinfo says "Metal: Supported, feature set OSX_GPUFamily1 v2" @Torkild, do you have any ideas what might be different for you to show the error? Maybe "fresh install" versus "updated an old install" ? Then you might want to try resize your partition in diskutil and install fresh to see if it helps you... Anything else I should try?
Or maybe the issue is triggered by having both a JRE and a JDK installed ... and the native launcher picking the JRE erroneously?
(In reply to Martin Oberhuber from comment #47) > @Torkild, do you have any ideas what might be different for you to show the > error? > Maybe "fresh install" versus "updated an old install" ? Then you might want > to try resize your partition in diskutil and install fresh to see if it > helps you... > Anything else I should try? Maybe try installing a couple of different Java versions? It could be related that I've had a few different versions of Java installed, including early Java 9 builds, but when I check the configuration listing in installation details, everything looks good to me: eclipse.vm=/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/bin/../jre/lib/server/libjvm.dylib java.endorsed.dirs=/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/endorsed java.ext.dirs=/Users/torkild/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre java.io.tmpdir=/var/folders/r0/pfdgrrn11798bc1tnxy1jv2c0000gn/T/ java.library.path=/Users/torkild/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:. java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.8.0_144-b01 java.specification.name=Java Platform API Specification java.specification.vendor=Oracle Corporation java.specification.version=1.8 java.vendor=Oracle Corporation java.vendor.url=http://java.oracle.com/ java.vendor.url.bug=http://bugreport.sun.com/bugreport/ java.version=1.8.0_144 java.vm.info=mixed mode java.vm.name=Java HotSpot(TM) 64-Bit Server VM java.vm.specification.name=Java Virtual Machine Specification java.vm.specification.vendor=Oracle Corporation java.vm.specification.version=1.8 java.vm.vendor=Oracle Corporation java.vm.version=25.144-b01 I'm pretty sure I haven't installed a separate JRE and when looking I cannot find any.
Martin, can you provide the same output for your setup as given in comment 49? We can then compare whether something is different.
Same Problem here. Upgraded from Sierra to High Sirra and menu is disabled in Eclipse Oxygen.
(In reply to Torkild Resheim from comment #46) > I think you're on to something. I tried starting Eclipse not using the > executable: java -XstartOnFirstThread -jar > ./Eclipse.app/Contents/Eclipse/plugins/org.eclipse.equinox.launcher_1.4.0.v20161219-1356.jar. > And all the menus now works as expected. Can you provide the complete command line? And, can others seeing the problem confirm this is a potential workaround?
(In reply to Dani Megert from comment #52) > Can you provide the complete command line? And, can others seeing the > problem confirm this is a potential workaround? Those were the only command line arguments required.
Does anyone on this bug have a contact to Apple and ask them to take a look?
I had the same issue. With the command line it works like a charm. Only issue is with the default size of the font. Adding -Dorg.eclipse.swt.internal.carbon.smallFonts solves the issue. In fact you can add all the params from eclipse.ini to get the same behaviour as launching the app, it works if you add what is after "-vmargs" before "-jar" and what is before "-vmargs" after the "-jar"
(In reply to Dani Megert from comment #54) > Does anyone on this bug have a contact to Apple and ask them to take a look? Dani, I have a contact from an unrelated High Sierra problem. If someone could summarize everything into a single comment here that I can point them to, I'm happy to send the email.
(In reply to Bryan Hunt from comment #56) > (In reply to Dani Megert from comment #54) > > Does anyone on this bug have a contact to Apple and ask them to take a look? > > Dani, I have a contact from an unrelated High Sierra problem. If someone > could summarize everything into a single comment here that I can point them > to, I'm happy to send the email. I also got hold to a contact at Apple but he can't reproduce it. It seems that this only happens for some people and we do not have a reliable test case yet. It could be a race condition caused by the power of the machine - nobody could see it yet on a virtual machine.
(In reply to Dani Megert from comment #50) > Martin, can you provide the same output for your setup as given in comment > 49? We can then compare whether something is different. Hi Dani, my About : Config is exactly the same as Torkild's from comment 49. (In reply to Torkild Resheim from comment #49) > > Anything else I should try? > Maybe try installing a couple of different Java versions? It could be > related that I've had a few different versions of Java installed, including > early Java 9 builds After installing the latest Java 9, Eclipse won't launch any more (I guess that's expected because -vmargs --add-modules=java.se.ee is not specified). But looking at the workspace/.metadata/.log , I see something interesting from the previous sessions using Java 8 (all of which were fine in terms of the menu). About every 2nd invocation shows this NPE ... maybe indicating some sort of a race condition: !SESSION 2017-09-17 21:21:31.134 ----------------------------------------------- eclipse.buildId=4.7.1.M20170906-1700 java.version=1.8.0_144 java.vendor=Oracle Corporation BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -keyring /Users/mober/.eclipse_keyring Command-line arguments: -os macosx -ws cocoa -arch x86_64 -keyring /Users/mober/.eclipse_keyring !ENTRY org.eclipse.core.net 1 0 2017-09-17 21:21:42.668 !MESSAGE System property http.nonProxyHosts has been set to local|*.local|169.254/16|*.169.254/16 by an external source. This value will be overwritten using the values from the preferences !ENTRY org.eclipse.ui 4 0 2017-09-17 21:21:54.397 !MESSAGE Unhandled event loop exception !STACK 0 java.lang.NullPointerException at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3695) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
(In reply to Torkild Resheim from comment #49) > Maybe try installing a couple of different Java versions? It could be > related that I've had a few different versions of Java installed, including > early Java 9 builds How did you get rid of the Java 9 installs?
(In reply to Martin Oberhuber from comment #59) > How did you get rid of the Java 9 installs? I cannot remember, but I'm pretty sure is was something like this: https://stackoverflow.com/questions/19039752/removing-java-8-jdk-from-mac – I believe I reinstalled Java 8 afterwards to make sure the browser plugins were would work.
I can reproduce the problem, too, with "10.13 beta 17A362a", which is what you join the beta program today (probably the same as the GM?) I can also get the menu working with a java command line launch. As interesting detail (don't know if this will help in any way): If I add -showsplash to the java command line, the menu bar is inactive until I deactivate the process and reactivate it (like bug 457921)
(In reply to Till Brychcy from comment #61) > As interesting detail (don't know if this will help in any way): If I add > -showsplash to the java command line, the menu bar is inactive until I > deactivate the process and reactivate it (like bug 457921) BTW: unfortunately, adding -nosplash to the eclipse.ini doesn't solve this bug
(In reply to Till Brychcy from comment #61) > I can reproduce the problem, too, with "10.13 beta 17A362a", which is what > you join the beta program today (probably the same as the GM?) Yes. (In reply to Martin Oberhuber from comment #58) > But looking at the workspace/.metadata/.log , I see something interesting > from the previous sessions using Java 8 (all of which were fine in terms of > the menu). About every 2nd invocation shows this NPE ... maybe indicating > some sort of a race condition: I see the same in my logs, they go back to late June – feeling suspicious, I installed Eclipse for Committers (Mars.2) but saw the same problem there. I also tried installing multiple Java versions, including a plain JRE on my virtual machine. That did not provoke the error. My workstation has a 2,9 GHz Intel Core i7 and the virtual machine is noticeably sluggish. So I guess a race condition in relation to the native launcher is not off the table. I've tried starting from the command line (avoiding the native launcher) multiple times, and the menu works every time. (In reply to Till Brychcy from comment #62) > BTW: unfortunately, adding -nosplash to the eclipse.ini doesn't solve this > bug Yes, just tried the same :-)
Created attachment 270248 [details] dtruss.zip Attached is the output of cd sudo dtruss /Applications/Eclipse.app/Contents/MacOS/eclipse > dtruss.log 2>&1 on my machine where I can't reproduce the problem. Maybe if somebody can reproduce the issue with dtruss logging on, comparing the logs might give a hint what's going on...
Created attachment 270249 [details] dtruss log where the menus are disabled Here are mine, where the menus are disabled.
Maybe it could also be helpful to compare the output of "lsof" to see if any libraries/frameworks are different.
As per https://youtrack.jetbrains.com/issue/JRE-434#comment=27-2424694 the issue should be fixed (I know they are not using SWT, but...) by Apple. Can those who see the problem please tell whether they only/directly upgraded to the latest or whether they installed previous 13.03 betas (one of which introduced the bug)? There might be some left-overs that aren't cleared when just installing the latest patch. This might explain why some people see it and some don't. Installing the final GA is supposed to do the clearing.
(In reply to Dani Megert from comment #67) > As per https://youtrack.jetbrains.com/issue/JRE-434#comment=27-2424694 the > issue should be fixed (I know they are not using SWT, but...) by Apple. > > Can those who see the problem please tell whether they only/directly > upgraded to the latest or whether they installed previous 13.03 betas (one > of which introduced the bug)? There might be some left-overs that aren't > cleared when just installing the latest patch. This might explain why some > people see it and some don't. Installing the final GA is supposed to do the > clearing. I installed the current beta (which should be the same as the GM) yesterday evening as upgrade to 10.12.6 and I do see the problem.
(In reply to Dani Megert from comment #67) I upgraded to the GM directly (17A362a) and do see the problem. But I have tested on virtual machines using beta versions, where I did not see the problem. Note that the IDEA problem is not the same as what we see.
I installed the latest beta (10.13 beta 17A362a) on top of Sierra on a older Macbook Pro and I'm not able to reproduce the problem with Eclipse Oxygen build. Another co-worker tried Eclipse Oxygen on the latest 10.13 beta on his machine, but was unable to reproduce the problem as well.
The pattern seems to be: on virtual machines and old macs the problem cannot be reproduced... My guess is that it is a timing issue. I wonder what happens if someone puts a high load on one of the macs where the problem can be reproduced (run something that uses all cores and stresses the machine).
I found it! I just had the idea that maybe it some setting in the Info.plist and so I simply removed it, started the binary from the commandline and it worked! With a restored Info.plist, a simple binary search then revaled that it is the CFBundleLocalizations key: If I remove all values except "en", it works (including launching the app by double-click). If I e.g. have "de" as value, the bug appears.
So the reason for the different behaviour is: If the user's language is english it works, otherwise not. (Just confirmed by temporarily changing the language in the system settings)
(In reply to Till Brychcy from comment #73) > So the reason for the different behaviour is: > If the user's language is english it works, otherwise not. > (Just confirmed by temporarily changing the language in the system settings) I am not saying Eclipse will try to workaround this, but it definitely looks like an Apple bug.
(In reply to Dani Megert from comment #74) > (In reply to Till Brychcy from comment #73) > > So the reason for the different behaviour is: > > If the user's language is english it works, otherwise not. > > (Just confirmed by temporarily changing the language in the system settings) > > I am not saying Eclipse will try to workaround this, but it definitely looks > like an Apple bug. Well done Till! So it appears Eclipse declares that it supports locale other than English, and when macOS does a request for a different locale, it fails. https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-109552
I can confirm: - Originally (English primary locale) I could not reproduce the issue - OSX Prefs: Language: Primary Locale German, reboot --> Eclipse menus disabled! - Edit Eclipse.app/Contents/Info.plist, removing all locales except en: works again! Great work Till - well done - looks like we have a workaround that can be published!!! Remaining questions: - Why are so many locales listed in Info.plist in the first place? - Do we agree with removing the locales as a fix, or is there a better fix? - Can (and should?) the Info.plist be updated for an Oxygen.1a respin?
I had a problem with a missing menu bar in a Swing application when run from an .app bundle. Once I read the suggestion about a problem with missing nib files, I tried to copy the file /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/French.lproj/DefaultApp.nib from a Sierra system to a High Sierra system (I'm a French user), and the menu bar of my application appeared again. The same trick enabled menu items in Eclipse again (note that your High Sierra system mustn't be the one in use to be able to copy files in JavaVM.framework subfolders). So it seems that Apple forgot those DefaultApp.nib files, or the solution they chose as replacement doesn't work! But will they fix this issue before the final release of High Sierra? That's the question...
Also see bug 327512
(In reply to Martin Oberhuber from comment #76) > Remaining questions: > - Why are so many locales listed in Info.plist in the first place? I guess because no harm was done and Eclipse could potentially support all > - Do we agree with removing the locales as a fix, or is there a better fix? I think we can just remove all, or leave "en". I tested and that worked just fined. I think there is a clue in the documentation mentioned above: >CFBundleLocalizations (Array - iOS, macOS) identifies the localizations handled manually by your app. If your executable is unbundled or does not use the existing bundle localization mechanism, you can include this key to specify the localizations your app does handle. And from the iOS documentation (https://developer.apple.com/library/content/qa/qa1828/_index.html) > If none of the user’s preferred languages are supported by your app, iOS chooses the language matching your app's development region (CFBundleDevelopmentRegion). > Note: Be sure to set CFBundleDevelopmentRegion for your app. If you adopt Base Localization, make sure that the value of CFBundleDevelopmentRegion matches the language used by your content in the Base.lproj folder. > - Can (and should?) the Info.plist be updated for an Oxygen.1a respin? I really hope we can do that.
Had this problem with High Sierra betas. Just installed GM build & menus are back.
(In reply to Till Brychcy from comment #73) > So the reason for the different behaviour is: > If the user's language is english it works, otherwise not. > (Just confirmed by temporarily changing the language in the system settings) Great find Till, thanks! I can now reproduce the problem on my VM as well with the primary language changed to non-English. And removing the CFBundleLocalizations entry from Info.plist fixes the problem. I did some testing by launching Eclipse with the modified Info.plist in German locale, but didn't see any problems. I also installed the language pack on it and didn't find any immediate problems. (In reply to Emmanuel Puybaret from comment #77) > So it seems that Apple forgot those DefaultApp.nib files, or the solution > they chose as replacement doesn't work! But will they fix this issue before > the final release of High Sierra? That's the question... I confirmed that the DefaultApp.nib files are missing in the /System/Library/Frameworks/JavaVM.framework/Resources/*.lproj folders for all locales except en. I compared with my 10.12.6 installation and see that DefaultApp.nib files are present for all the locales.
(In reply to Nigel Boor from comment #80) > Had this problem with High Sierra betas. > Just installed GM build & menus are back. What is the primary language on your mac? The problem doesn't seem to happen with the GM build if primary language is English.
New Gerrit change created: https://git.eclipse.org/r/105545
New Gerrit change created: https://git.eclipse.org/r/105546
I am glad to see that there is a workaround possible for existing users. But I am extremely worried about people having an existing install, upgrade to macOS 10.13, and every existing Eclipse or STS install is broken for them. I think it would be good if we could get a blog post or a wiki page up that documents the workaround in a few words. And maybe have a news banner on the homepage to point people to that doc. Then people could tweet and blog about it to avoid a huge shitstorm or just hundreds of duplicates of this bug... :-) WDYT?
New Gerrit change created: https://git.eclipse.org/r/105553
As mentioned in comment#81, the DefaultApp.nib files are no longer available in /System/Library/Frameworks/JavaVM.framework/Resources/*.lproj folders except in en.lproj. This seems to be causing the problem for Eclipse. There is code in SWT Display.java (line 5341) which looks for DefaultApp.nib in the specific locale lproj folder and if it doesn't find it looks for it in English.lproj. Then it looks for it under Resources/*.lproj in java home path. In 10.13, DefaultApp.nib is not found in any of these locations and hence loading the nib file fails when on a non-English locale. And createMainMenu() is invoked to create the menu items. Will upload a gerrit patch shortly that addresses the problem.
(In reply to Lakshmi Shanmugam from comment #87) > As mentioned in comment#81, the DefaultApp.nib files are no longer available > in /System/Library/Frameworks/JavaVM.framework/Resources/*.lproj folders > except in en.lproj. This seems to be causing the problem for Eclipse. > > There is code in SWT Display.java (line 5341) which looks for DefaultApp.nib > in the specific locale lproj folder and if it doesn't find it looks for it > in English.lproj. Then it looks for it under Resources/*.lproj in java home > path. > In 10.13, DefaultApp.nib is not found in any of these locations and hence > loading the nib file fails when on a non-English locale. And > createMainMenu() is invoked to create the menu items. > > Will upload a gerrit patch shortly that addresses the problem. Thank you for this detailed analysis. Please also think about non-Eclipse applications that might ship with a private JRE and without any nib files.
(In reply to Lakshmi Shanmugam from comment #87) > Will upload a gerrit patch shortly that addresses the problem. Please also take note of https://git.eclipse.org/r/105553. The current Info.plist contains erroneous information.
New Gerrit change created: https://git.eclipse.org/r/105582
(In reply to Lakshmi Shanmugam from comment #87) > As mentioned in comment#81, the DefaultApp.nib files are no longer available > in /System/Library/Frameworks/JavaVM.framework/Resources/*.lproj folders > except in en.lproj. This seems to be causing the problem for Eclipse. > > There is code in SWT Display.java (line 5341) which looks for DefaultApp.nib > in the specific locale lproj folder and if it doesn't find it looks for it > in English.lproj. Then it looks for it under Resources/*.lproj in java home > path. > In 10.13, DefaultApp.nib is not found in any of these locations and hence > loading the nib file fails when on a non-English locale. And > createMainMenu() is invoked to create the menu items. Has this been reported that explicitly to Apple already? - I'm not an Apple developer myself, but it does sound like a backward compatibility breakage that Apple should consider fixing. I agree with Martin Lippert that fixing Oxygen.1+ is nice, but there is also a huge concern about older Eclipse/RCP based applications that would break when a user upgrades to OSX 10.13.
(In reply to Martin Oberhuber from comment #91) > > Has this been reported that explicitly to Apple already? - I'm not an Apple > developer myself, but it does sound like a backward compatibility breakage > that Apple should consider fixing. I've not reported this problem explicitly. I think we were using the hardcoded paths that were not documented or part of any specification. Apple has now moved around the files and I'm not sure if they would consider it as bug or consider fixing it. We have a fix now and plan to push it in the 4.7.1a build. > > I agree with Martin Lippert that fixing Oxygen.1+ is nice, but there is also > a huge concern about older Eclipse/RCP based applications that would break > when a user upgrades to OSX 10.13. I agree that the most important thing now is to communicate to the users/community about the bug and the possible workarounds. I've requested Ian's help to communicate this to the user community.
A quick workaround for existing users is to launch eclipse with '-nl en' option. This works when run from the command line as ./eclipse -nl en (or) when specified in eclipse.ini with -nl en on separate lines. But, the problem with this workaround is that eclipse is forced to launch with English even when the locale language pack is installed.
Why this problem does not occur when launching from a script inside the .app structure (like SmartGit) though the code in Display is the same?
Seems to me this is a bug of High Sierra rather than Eclipse. I got this issue on macos beta version 17A315i and reported it to Apple (https://bugreport.apple.com/web/?problemID=33507576). Actually not only STS/Eclipse suffered the issues, ALL the Java apps incl. visualvm, netbeans, intellij I tried got the disabled menus. The bug got fixed in the following beta versions during which I didn't update my STS at all. But don't know why, it regressed on version 17A362a (GM). I opened a new bug to Apple (https://bugreport.apple.com/web/?problemID=34508258)
Gerrit change https://git.eclipse.org/r/105582 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3bbf8ceb7a8b1dc656dc26fbb2bed9f0c94015e8
(In reply to Thomas Singer from comment #94) > Why this problem does not occur when launching from a script inside the .app > structure (like SmartGit) though the code in Display is the same? I think the bug happens in combination with the Eclipse Info.plist which lists the supported locales.
(In reply to Lakshmi Shanmugam from comment #97) > (In reply to Thomas Singer from comment #94) > > Why this problem does not occur when launching from a script inside the .app > > structure (like SmartGit) though the code in Display is the same? > > I think the bug happens in combination with the Eclipse Info.plist which > lists the supported locales. This might be the reason for Eclipse, but this does not explain why the same problem has been reported against SmartSVN.
(In reply to Thomas Singer from comment #88) > Thank you for this detailed analysis. Please also think about non-Eclipse > applications that might ship with a private JRE and without any nib files. I've created Bug 522690 with a fix for the case when the nib is not found.
Gerrit change https://git.eclipse.org/r/105553 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=e12b6881d244e3ac214c67decf01c36012b7c678
(In reply to Eclipse Genie from comment #100) > Gerrit change https://git.eclipse.org/r/105553 was merged to [master]. > Commit: > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=e12b6881d244e3ac214c67decf01c36012b7c678 > Info.plist change is in master. Thanks for the patch, Torkild!
Can we get this fix into Oxygen.1a?
(In reply to Eclipse Genie from comment #96) > Gerrit change https://git.eclipse.org/r/105582 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3bbf8ceb7a8b1dc656dc26fbb2bed9f0c94015e8 > Verified that the problem is fixed in build-I20170924-2000. (http://download.eclipse.org/eclipse/downloads/drops4/I20170924-2000/) Can everyone with 10.13 beta setup, please try out the build and confirm that the problem is the fixed.
(In reply to Martin Lippert from comment #102) > Can we get this fix into Oxygen.1a? I think for Oxygen.1a, it's safe to push the minimal fix from comment#90. Will create a gerrit patch and request for PMC approval.
(In reply to Lakshmi Shanmugam from comment #103) > Verified that the problem is fixed in build-I20170924-2000. > (http://download.eclipse.org/eclipse/downloads/drops4/I20170924-2000/) > > Can everyone with 10.13 beta setup, please try out the build and confirm > that the problem is the fixed. Confirmed.
I just tried eclipse in eclipse-platform-I20170924-2000-macosx-cocoa-x86_64.dmg under macOS 10.13 GM with a primary language set to French, and could select enabled menus.
New Gerrit change created: https://git.eclipse.org/r/105690
(In reply to Eclipse Genie from comment #107) > New Gerrit change created: https://git.eclipse.org/r/105690 Dani, can you please approve the change for 4.7.1a?
(In reply to Till Brychcy from comment #105) > Confirmed. (In reply to Emmanuel Puybaret from comment #106) > I just tried eclipse in > eclipse-platform-I20170924-2000-macosx-cocoa-x86_64.dmg under macOS 10.13 GM > with a primary language set to French, and could select enabled menus. Thanks for the quick confirmation!
(In reply to Lakshmi Shanmugam from comment #109) > (In reply to Till Brychcy from comment #105) > > Confirmed. > (In reply to Emmanuel Puybaret from comment #106) > > I just tried eclipse in > > eclipse-platform-I20170924-2000-macosx-cocoa-x86_64.dmg under macOS 10.13 GM > > with a primary language set to French, and could select enabled menus. > > Thanks for the quick confirmation! I've just installed the High Sierra release version. The build number is 17A365 and they didn't fix the problem :-( eclipse-platform-I20170924-2000-macosx-cocoa-x86_64.dmg works fine.
Gerrit change https://git.eclipse.org/r/105690 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=1791b02320b95f6c7dadb27451c29757ce30dfe3
Today just installed the final version of High Sierra (17A365). The same problem using both Oxygen and Neon... The build http://download.eclipse.org/eclipse/downloads/drops4/I20170924-2000/ brings the menus back. Do you plan to bring this fix into the official Oxygen version? Thanks!
copy /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/en.lproj/DefaultApp.nib to /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/English.lproj/DefaultApp.nib
(In reply to Toli W from comment #112) > > Do you plan to bring this fix into the official Oxygen version? > The fix will be available in Oxygen 4.7.1a release and later.
There is an official announcement on the Eclipse home page about the bug and possible workarounds for existing users --> https://www.eclipse.org/org/press-release/20170925criticalbug.php. Please share and help spread the news.
(In reply to Lakshmi Shanmugam from comment #115) > There is an official announcement on the Eclipse home page about the bug and > possible workarounds for existing users --> > https://www.eclipse.org/org/press-release/20170925criticalbug.php. > Please share and help spread the news. Unfortunately, http://www.eclipse.org shows the oxygen page (content of https://www.eclipse.org/oxygen/) and you have to click "Continue to eclipse.org" to see "https://www.eclipse.org/home" where the anouncement is visible.
(In reply to Till Brychcy from comment #116) > Unfortunately, http://www.eclipse.org shows the oxygen page (content of > https://www.eclipse.org/oxygen/) and you have to click "Continue to > eclipse.org" to see "https://www.eclipse.org/home" where the anouncement is > visible. Forget that, either I had a caching problem or it has just been changed.
(In reply to Lakshmi Shanmugam from comment #114) > (In reply to Toli W from comment #112) > > > > Do you plan to bring this fix into the official Oxygen version? > > > > The fix will be available in Oxygen 4.7.1a release and later. this bug fixed? i have insall the new version Eclipse Java EE IDE for Web Developers. Version: Oxygen.1 Release (4.7.1) Build id: 20170914-1200 but the bug There has always been
(In reply to xinxin he from comment #118) > (In reply to Lakshmi Shanmugam from comment #114) > > (In reply to Toli W from comment #112) > > > > > > Do you plan to bring this fix into the official Oxygen version? > > > > > > > The fix will be available in Oxygen 4.7.1a release and later. > > this bug fixed? i have insall the new version > > Eclipse Java EE IDE for Web Developers. > > Version: Oxygen.1 Release (4.7.1) > Build id: 20170914-1200 > > but the bug There has always been The fix is not available in Oxygen.1 Release (4.7.1), it'll be in the Oxygen.1a Release (4.7.1a) to be released on October 11. Please see the announcement in comment#115 for workarounds.
I don't see this change: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=e12b6881d244e3ac214c67decf01c36012b7c678 applied to the 4.7 maintenance branch. Any plans to do that? I know that there is the fix in Display that already made it into the 4.7 maintenance branch, just wondering about the other change.
(In reply to Martin Lippert from comment #120) > I don't see this change: > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=e12b6881d244e3ac214c67decf01c36012b7c678 > > > applied to the 4.7 maintenance branch. Any plans to do that? > I know that there is the fix in Display that already made it into the 4.7 > maintenance branch, just wondering about the other change. The changes in Display fixes the problem. The equinox changes were not pushed to keep the changes minimal for 4.7.1a. Will push the equinox changes to maintenance branch for 4.7.2.
This is my experience: The problem of the disabled menus can be solved by adding <key>CFBundleLocalizations</key> <array> <string>en</string> </array> But with this change you are not able to solve the localization problem at all. For example I have a SWT-based application and bundled it. The Resource folder contains subfolders like de.lproj and en.lproj with Localizable.strings. If I start my app, all menus will be disabled. Now I set the Info.plist CFBundleLocalizations. "en" is the only item that works. With other locales the menus will be disabled agian. With CFBundleLocalizations set to "en" it works. But now there's another conflict: The whole UI is f.e. in German, but the system menu is still in English (About, Preferences, Quit, ...). It would be not so important for Eclipse because the IDE is only in English, but maybe it could be interested for the SWT hot fix...
*** Bug 519724 has been marked as a duplicate of this bug. ***
*** Bug 525749 has been marked as a duplicate of this bug. ***
*** Bug 525760 has been marked as a duplicate of this bug. ***
-Right click on Eclipse.app -Select Show Package Contents -Open Contents folder -Open Info.plist file -If opened with XCode, remove the entry for ‘Localizations’ -If open with a Text Editor, remove the complete entry for ‘CFBundleLocalizations’ <key>CFBundleLocalizations</key> <array> <string>ar</string> <string>cs</string> <string>da</string> <string>el</string> <string>en</string> <string>es</string> <string>de</string> <string>fi</string> <string>fr</string> <string>hu</string> <string>it</string> <string>iw</string> <string>ja</string> <string>ko</string> <string>nl</string> <string>no</string> <string>pl</string> <string>pt_BR</string> <string>pt</string> <string>ru</string> <string>sv</string> <string>tr</string> <string>zh_HK</string> <string>zh_TW</string> <string>zh</string> </array> -save the Info.plist file -Launch Eclipse.app
All of the Menu Bar has been disabled on Mac newst OS，this bug has been fixed?
(In reply to xinxin he from comment #127) > All of the Menu Bar has been disabled on Mac newst OS，this bug has been > fixed? This is fixed in 4.7.1a http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.1a-201710090410/ Otherwise, see https://www.eclipse.org/org/press-release/20170925criticalbug.php for workarounds
This appears to have come back in the latest beta of 10.13.1 (17B42a). I noticed it in Code Composer Studio 7.3, which is based on Eclipse 4.6.0. The workarounds don't appear to work this time.
Seeing this problem as well. OS X: 10.13.1 Beta (17B42a) Eclipse: Version: Oxygen.1a (4.7.1a) Build id: M20171009-0410
(In reply to Steve Green from comment #130) > Seeing this problem as well. > > OS X: > 10.13.1 Beta (17B42a) > > Eclipse: > Version: Oxygen.1a (4.7.1a) > Build id: M20171009-0410 I don't have 10.13.1 beta yet. Can you please check if the DefaultApp.nib file is available at this location - /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/en.lproj/DefaultApp.nib?
It is not $ ls -l /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/en.lproj/ total 0 -rw-r--r-- 1 root wheel 85 Oct 1 03:52 Menu.strings
(In reply to Steve Green from comment #132) > It is not > > $ ls -l > /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/en.lproj/ > total 0 > -rw-r--r-- 1 root wheel 85 Oct 1 03:52 Menu.strings Do any of the *.lproj have DefaultApp.nib file?
> Do any of the *.lproj have DefaultApp.nib file? There are no nibs at all. $ find /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources -name \*.nib $
(In reply to Steve Green from comment #134) > > Do any of the *.lproj have DefaultApp.nib file? > > There are no nibs at all. > > $ find /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources > -name \*.nib > $ Unfortunately the fix in Oxygen.1a or the suggested workarounds will not work now as it depends on the DefaultApp.nib file to be available. I think the fix from Bug 522690 will fix the problem. The change is already in master and will be available in 4.8M3. Can you please try a recent I-build and see if the problem is fixed? - http://download.eclipse.org/eclipse/downloads/drops4/I20171019-2000/download.php?dropFile=eclipse-SDK-I20171019-2000-macosx-cocoa-x86_64.dmg
(In reply to Lakshmi Shanmugam from comment #135) > (In reply to Steve Green from comment #134) > > > Do any of the *.lproj have DefaultApp.nib file? > > > > There are no nibs at all. > > > > $ find /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources > > -name \*.nib > > $ > > Unfortunately the fix in Oxygen.1a or the suggested workarounds will not > work now as it depends on the DefaultApp.nib file to be available. > > I think the fix from Bug 522690 will fix the problem. The change is already > in master and will be available in 4.8M3. Can you please try a recent > I-build and see if the problem is fixed? - > http://download.eclipse.org/eclipse/downloads/drops4/I20171019-2000/download. > php?dropFile=eclipse-SDK-I20171019-2000-macosx-cocoa-x86_64.dmg That build works. As well, I managed to figure out how to build eclipse.platform.swt from source and replace that jar in 4.7, and that also works.
> Unfortunately the fix in Oxygen.1a or the suggested workarounds will not > work now as it depends on the DefaultApp.nib file to be available. > > I think the fix from Bug 522690 will fix the problem. The change is already > in master and will be available in 4.8M3. Can you please try a recent > I-build and see if the problem is fixed? - > http://download.eclipse.org/eclipse/downloads/drops4/I20171019-2000/download. > php?dropFile=eclipse-SDK-I20171019-2000-macosx-cocoa-x86_64.dmg Can we get this fix backported for 4.7.2? I think it is extremely important, since people will update to macOS High Sierra 10.13.1 as soon as it comes out. And I expect this update to arrive rather sooner than later due to expected important security fixes that are included in it. Is there anything we can do for Eclipse users that update to 10.13.1 ?
(In reply to Steve Green from comment #136) > (In reply to Lakshmi Shanmugam from comment #135) > > (In reply to Steve Green from comment #134) > > > > Do any of the *.lproj have DefaultApp.nib file? > > > > > > There are no nibs at all. > > > > > > $ find /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources > > > -name \*.nib > > > $ > > > > Unfortunately the fix in Oxygen.1a or the suggested workarounds will not > > work now as it depends on the DefaultApp.nib file to be available. > > > > I think the fix from Bug 522690 will fix the problem. The change is already > > in master and will be available in 4.8M3. Can you please try a recent > > I-build and see if the problem is fixed? - > > http://download.eclipse.org/eclipse/downloads/drops4/I20171019-2000/download. > > php?dropFile=eclipse-SDK-I20171019-2000-macosx-cocoa-x86_64.dmg > > That build works. > > As well, I managed to figure out how to build eclipse.platform.swt from > source and replace that jar in 4.7, and that also works. Can you post that jar file? I haven't set up an environment where I can build eclipse.
(In reply to Kaveh Vaghefi from comment #138) > Can you post that jar file? I haven't set up an environment where I can > build eclipse. tl;dr: Try copying the swt cocoa jar from the 4.8 I-build. Long version.. I wasn't able to find any documentation for setting up the build process (hint hint to the maintainers here) but managed to get something building with quite a bit of difficulty. When I built that jar I built from master which I think is for 4.8. Despite not showing any immediate issues with 4.7, it might have breaking changes making it incompatible with 4.7. I don't honestly know. I went back to the 4.7 branch and tried to apply the change there and rebuild but I ran into issues and gave up as it was getting late and I was not confident in my hacked-up build process. I only tested the very basics but so far so good with the 4.8 swt cocoa jar in 4.7.
Hmm...I'm using 4.6 (the basis for TI's code composer, which I need for microcontroller debugging). Do you think this will work there? Another workaround I found: Disable SIP (System Integrity Protection) and you can restore the Default.nib to that folder (from Time Machine). I managed to get my menus back that way, though I don't like that I had to disable SIP to do it. I also filed a bug with Apple.
(In reply to Kaveh Vaghefi from comment #140) > though I don't like that I had to disable SIP to do it. I started to do the same thing but decided against disabling SIP. You might also be able to make a copy of the java runtime (and modify) and run eclipse with that one instead of modifying the one in /System/...
The code in Display.java also checks for the DefaultApp.nib in ${java.home}/../Resources/English.lproj/DefaultApp.nib Looking at my "About Eclipse" > "Installation Details" > "Configuration" java.home looks like: java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre SIP does not apply to that directory, so you should be able to copy it there (making the necessary subfolders), i.e. as: /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/Resources/English.lproj/DefaultApp.nib
(In reply to Till Brychcy from comment #142) > The code in Display.java also checks for the DefaultApp.nib in > ${java.home}/../Resources/English.lproj/DefaultApp.nib > > Looking at my "About Eclipse" > "Installation Details" > "Configuration" > java.home looks like: > java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/ > jre > > SIP does not apply to that directory, so you should be able to copy it there > (making the necessary subfolders), i.e. as: > > /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/Resources/ > English.lproj/DefaultApp.nib Of course you may be using a different java version, then you'd have to adapt it.
The latest M Build (http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops4/M20171025-0400/eclipse-SDK-M20171025-0400-macosx-cocoa-x86_64.dmg) does not work for me on 10.13.1 Beta 4. This bug should be re-opened as it appears to be rather critical and needs back porting to 4.7.2
For those that need a quick fix for their 4.7.1: I downloaded the I build and extracted the latest SWT files to a ZIP: http://karsten-becker.de/swt-fixed-3.106.1.v20170926-0519.zip Extract those to your ~/.p2/pool/plugins directory and overwrite the existing files. Or name them to whatever version is shown in your plugin dependencies when searching for SWT.
(In reply to Karsten Becker from comment #144) > The latest M Build > (http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/ > drops4/M20171025-0400/eclipse-SDK-M20171025-0400-macosx-cocoa-x86_64.dmg) > does not work for me on 10.13.1 Beta 4. > This bug should be re-opened as it appears to be rather critical and needs > back porting to 4.7.2 Note Bug 522690 contains the fix which allows eclipse to run without any DefaultApp.nib at all, and it is already reopened for back porting to 4.7.2
*** Bug 525420 has been marked as a duplicate of this bug. ***
*** Bug 525429 has been marked as a duplicate of this bug. ***
Still can see same happening even after trying, options mentioned here, https://www.eclipse.org/org/press-release/20170925criticalbug.php. Also tried, manually upgrading to eclipse 4.7.1a, changing the workspace directory, But NO LUCK. Posted the issue here, https://stackoverflow.com/questions/47009559/menu-options-in-eclipse-are-disable/47009659#47009659
Still does not work on latest beta: 10.13.1 Beta (17B46a) Version: Oxygen.1a Release (4.7.1a) Build id: 20171005-1200 tried starting w -nl en, editing PList, etc. Menu remains disabled.
(In reply to Nagarjuna Reddy from comment #149) > Still can see same happening even after trying, options mentioned here, > https://www.eclipse.org/org/press-release/20170925criticalbug.php. > As noted in comment#135, the workarounds mentioned in the above article worked on 10.13 but doesn't work on 10.13.1 as all the DefaultApp.nib files are gone now. The bug has been fixed in Eclipse and is already available in Eclipse 4.8M3 build. It will be available in Eclipse 4.7.2, please see Bug 522690. For existing Eclipse users moving to 10.13.1, the workaround suggested by Till in comment#142 works well. It doesn't involve disabling SIP and the change needs to be done only once on the machine and not for every Eclipse build.
Workaround from comment#142 in detail: 1. Find java.home used by your Eclipse (look for java.home in "About Eclipse" > "Installation Details" > "Configuration") 2. If your java.home is, for example, /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre , go to /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home and create the subfolders Resources/English.lproj 3. Copy the DefaultApp.nib file from a 10.13 or older Mac to /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/Resources/English.lproj (DefaultApp.nib can be found under /System/Library/Frameworks/JavaVM.framework/Resources/en.lproj or /System/Library/Frameworks/JavaVM.framework/Resources/English.lproj on Mac OS version < 10.13.1) Please comment if the workaround doesn't work for you.
(In reply to Lakshmi Shanmugam from comment #152) > Workaround from comment#142 in detail: > > 1. Find java.home used by your Eclipse (look for java.home in "About > Eclipse" > "Installation Details" > "Configuration") > > 2. If your java.home is, for example, > /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre , go to > /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home and create > the subfolders Resources/English.lproj > > 3. Copy the DefaultApp.nib file from a 10.13 or older Mac to > /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/Resources/ > English.lproj (DefaultApp.nib can be found under > /System/Library/Frameworks/JavaVM.framework/Resources/en.lproj or > /System/Library/Frameworks/JavaVM.framework/Resources/English.lproj on Mac > OS version < 10.13.1) > > Please comment if the workaround doesn't work for you. The workaround works for Java 8, but not for Java 9... There is no "jre" folder under my /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home. The folders are: bin, conf, include, jmods, legal, lib, Resources (created by me)
(In reply to Lakshmi Shanmugam from comment #121) > (In reply to Martin Lippert from comment #120) > > I don't see this change: > > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=e12b6881d244e3ac214c67decf01c36012b7c678 > > > > > > applied to the 4.7 maintenance branch. Any plans to do that? > > I know that there is the fix in Display that already made it into the 4.7 > > maintenance branch, just wondering about the other change. > > The changes in Display fixes the problem. The equinox changes were not > pushed to keep the changes minimal for 4.7.1a. Will push the equinox changes > to maintenance branch for 4.7.2. Bug 526687 tracks the back-port of the equinox change to 4.7.2.
(In reply to Jay mustangxugmail.com from comment #153) > > The workaround works for Java 8, but not for Java 9... There is no "jre" > folder under my > /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home. The folders > are: bin, conf, include, jmods, legal, lib, Resources (created by me) Sorry, I didn't try with Java 9. When using Java 9, what does java.home point to? "jre" folder is not required. SWT looks for {java.home}/../Resources/English.lproj/DefaultApp.nib, we just need to make sure that the nib file exists in this path.
(In reply to Lakshmi Shanmugam from comment #152) > Workaround from comment#142 in detail: > > 1. Find java.home used by your Eclipse (look for java.home in "About > Eclipse" > "Installation Details" > "Configuration") > > 2. If your java.home is, for example, > /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre , go to > /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home and create > the subfolders Resources/English.lproj > > 3. Copy the DefaultApp.nib file from a 10.13 or older Mac to > /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/Resources/ > English.lproj (DefaultApp.nib can be found under > /System/Library/Frameworks/JavaVM.framework/Resources/en.lproj or > /System/Library/Frameworks/JavaVM.framework/Resources/English.lproj on Mac > OS version < 10.13.1) > > Please comment if the workaround doesn't work for you. Oh Finally, This workaround works for 10.13.1 Beta. Thanks Team
Created attachment 271264 [details] English.lproj For any one who need the "English.lproj" from older version of mac, they can download this.
And after all of this.. guess what's back with the latest High Sierra beta? DefaultApp.nib has returned and in all of the languages. $ cd /System/Library/Frameworks/JavaVM.framework/Versions/Current/Resources $ ls */DefaultApp.nib ar.lproj/DefaultApp.nib es.lproj/DefaultApp.nib hu.lproj/DefaultApp.nib no.lproj/DefaultApp.nib sv.lproj/DefaultApp.nib ca.lproj/DefaultApp.nib es_419.lproj/DefaultApp.nib id.lproj/DefaultApp.nib pl.lproj/DefaultApp.nib th.lproj/DefaultApp.nib cs.lproj/DefaultApp.nib fi.lproj/DefaultApp.nib it.lproj/DefaultApp.nib pt.lproj/DefaultApp.nib tr.lproj/DefaultApp.nib da.lproj/DefaultApp.nib fr.lproj/DefaultApp.nib ja.lproj/DefaultApp.nib pt_PT.lproj/DefaultApp.nib uk.lproj/DefaultApp.nib de.lproj/DefaultApp.nib he.lproj/DefaultApp.nib ko.lproj/DefaultApp.nib ro.lproj/DefaultApp.nib vi.lproj/DefaultApp.nib el.lproj/DefaultApp.nib hi.lproj/DefaultApp.nib ms.lproj/DefaultApp.nib ru.lproj/DefaultApp.nib zh_CN.lproj/DefaultApp.nib en.lproj/DefaultApp.nib hr.lproj/DefaultApp.nib nl.lproj/DefaultApp.nib sk.lproj/DefaultApp.nib zh_TW.lproj/DefaultApp.nib
(In reply to Lakshmi Shanmugam from comment #155) > (In reply to Jay mustangxugmail.com from comment #153) > > > > The workaround works for Java 8, but not for Java 9... There is no "jre" > > folder under my > > /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home. The folders > > are: bin, conf, include, jmods, legal, lib, Resources (created by me) > Sorry, I didn't try with Java 9. When using Java 9, what does java.home > point to? > "jre" folder is not required. SWT looks for > {java.home}/../Resources/English.lproj/DefaultApp.nib, we just need to make > sure that the nib file exists in this path. java.home of Java 9 is /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home, I moved the Resources folder to /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents and the workaround works~
(In reply to Lakshmi Shanmugam from comment #152) > Workaround from comment#142 in detail: > > Please comment if the workaround doesn't work for you. thanks, this works on latest (#5) beta.
I can confirm the in the released 10.13.1 (17B48), the DefaultApp.nib are back in all languages. The menus work again even in eclipse 4.4.2.
Since I'm experiencing this same problem with my RCP application, where can you tell the packager that it should only include in the Info.plist only the languages that I have defined (my application does support localized menus, but only for two languages and it fails as of now) Cheers!
New Gerrit change created: https://git.eclipse.org/r/111190
Gerrit change https://git.eclipse.org/r/111190 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=efe3545c44d8d6e3729d6f086c27083b4170ddb6
