• Type: Enhancement
• Component: javafx
• Sub-Component: window-toolkit
• Affected Version: 7u6

• Priority: P4
• Status: Open
• Resolution: Unresolved

• Submitted: 2012-06-27
• Updated: 2018-09-05

Other
tbdUnresolved

Morris, your opinion, if you agree, lets re-target to 9u20 17-11-2015 I think we should postpone this RFE and address it in conjunction with adding support for java.desktop features, possibly in a 9 update release. See JDK-8091107 and JDK-8048731. 16-11-2015 This bug is "In Progress" status now, so re-targeting back to Fix Version 9. If you are not working on this bug fix anymore, please update the bug from "In Progress" to just "Open" 13-11-2015 Quick feedback: 1. The changes to the launcher will need to be reviewed more carefully than I have time for tonight. I don't quite understand why you changed the setApplicationName to setApplicationClass and then added a new setApplicationName, but it doesn't look quite right. For one thing it looks like you haven't covered all cases in LauncherImpl. There are two primary entry points: one called by the java launcher and one called by Application.launch() if the java launcher is not used. More importantly, the changes are causing unit test failures in the threading because you are now calling the glass Application.setName method before the FX application thread is created. This needs to change (possibly be adding a new method specifically for this purpose). 2. In MacApplication.java the following: Class cl = Class.forName(name); I'm not sure this will work in all cases, since the class loader in effect at that time (which is the class loader that loaded the MacApplication class) might not be able to load the application class. Has this been tested? 3. I see that you changed the following methods: Toolkit.startup Application.run Since this is targeted for 9 this is fine (and will catch places that you missed like StubToolkit so that's a good thing). I will note that it is possible that there are some SQE tests that use these internal methods, so I wouldn't want to do that if it were going into 8u-dev, but as there are other reasons to not push this to 8u I am fine with these changes going into 9. SQE tests won't be able to use any internal classes without making changes anyway (and really shouldn't be using these). 29-05-2015 A couple of overall questions / comments: * This is only for 9, so we might consider new API if it makes sense. I think the problem might be (Morris can chime in here) that this needs to be set very early on. The current patch sets it before any application code is run. * If we do add API (that is, if it both feasible and desirable to do so), one question is whether the proposed mechanism is useful in its own right even if we have public API. If so, then any new API could be considered in a follow-on JIRA with the default being the application name as implemented in this patch. * Related to the above, is this something that a Mac application might want to set at packaging time? If so, then we need to make sure that the packager can specify the name and have that override the default. My feedback on the patch itself will follow, although I will note that there is at least one bug in the patch -- StubToolkit was not updated so "gradle test" will fail with a compilation error. 29-05-2015 If we wait until 9 should we add a public API to set that value? I'm not sure if there is code to programmatically change the task bar icon/name separate from the frame titles/icons but if so this seems like the easiest API. 28-05-2015 I reviewed the changes and nothing popped out at me. I would agree with Kevin that we should probably target this at 9 so we have more testing time. 22-05-2015 I see that you sent the review out for 8u60, whereas this JIRA is targeted for 9. I think that 9 seems like a better place for it to go, as this seems too intrusive for 8u60 given that this is a very old request. So this is not approved to go into 8u-dev, at least not without further discussion as to the compatibility / testing implications. In any case, I'd like to hear Danno's opinion on this, since it seems to go hand-in-hand with packager work. I'll review it more thoroughly later (probably Monday). There are a couple of changes that I want to look at in more details such as the changes to mac.gradle (to make sure we will have no build problems), although if targeted for 9 that will be less of an issue. This will need to be well-tested on all platforms since it touches shared code and not just Mac-specific code. 06-03-2015 Please review: http://cr.openjdk.java.net/~morris/RT-22988.01/ 06-03-2015 Not quite sure this would be the right way to do that. In AWT we set the application name using Java Runtime Support. At some point I've implemented the fix using that approach, but something didn't work well. Please see NSApplictionAWT registerWithProcessManager in AWT sources for reference. The same could be done in FX. 18-10-2013 The problem is that the file http://hg.openjdk.java.net/openjfx/8/controls/rt/file/eb8fe386f751/deploy/javafx-launcher/src/com/javafx/main/Main.java name is fixed while we want it to be dynamically generated (based on application name). I have no idea how to do that. Where would be the best place to get help, thanks! 18-10-2013 All: please note that OpenJFX is an open-source project. If you wish to help, you could contribute patches to resolve this issue or any other bugs you'd like to see fixed. You don't need to decompile anything - just check out the code from the repo, modify, build, test, and then post a patch at openjfx-dev@openjdk.java.net for review (or attach it to a JIRA entry). Your contribution would be very much appreciated by all of the OpenJFX community. 18-10-2013 I have a solution for you guys...Not very legal but it works... Decompile the code of the javafx.main.Main class and copy it to your own package, give it the name of your application and place it in the Manifest file instead of javafx.main.Main and you're done. 18-10-2013 I can appreciate that it is frustrating to see issues not being fixed in JavaFX 8.0. I can't speak specifically to this bug, but I would like to clarify that Van Ness is not necessarily Java 9 - at present Van Ness is just a code name we use to mean 'a future release'. As JavaFX 8.0 moves closer to completion we'll be more clearly defining the future version numbers / code names, and at that point the higher priority bugs will be targeted at releases based on the importance, requirements and jira feedback. So no, I hope you don't have to wait until 2016 for this feature - it could perhaps appear in a Java 8 update release, of which there are many planned between Java 8.0 and the eventual release of Java 9. 18-10-2013 As Carl noted, this is a show stopper for building Mac apps for JavaFX. And now we're supposed to wait for a fix when Java 9 comes out in 2016? 18-10-2013 Petr is correct. This needs to be fixed in GlassApplication.m where we initialize an FX app. We should use the same SPI that we use in AWT. Note that the Java launcher converts the -Xdock:name command line argument to an environment variable named APP_NAME_<pid> (see NSApplicationAWT.m in JDK sources for details). 18-10-2013 I wish issues such as this, that have accumulated a number of votes, were treated with higher priority and fixed. 17-10-2013 Any update on this. It's a blocker, how are we supposed to build applications using JavaFX 2.2 if the there are basic bugs like a menu? For Swing application using JavaFX native packaging I'm seeing my application name but 'About Main' and 'Quit Main' instead of 'About MyApp' and 'Close MyApp'. 10-04-2013 Swing handles it. In fact before JavaFx 2.2 it was recommened to use Swing to use menus. Now that we have use system menu in menubar this java menu should not exist. 05-04-2013 AFAIK we should support -Xdock:name for FX applications. Here's a few relevant issues: RT-18716, RT-12113, RT-18693, RT-22416. Perhaps some of them (or even this one) might be closed as duplicates of one another. 05-04-2013 This menu name is set by Cocoa and is always equal to the application process name and this can not be changed. AWT supports a property -Xdock:name to specify the application name, however it is implemented using some strange API from the JavaVM.framework: JRSAppKitAWT registerAWTAppWithOptions, where you provide an app name in options. This is an undocumented API I would not vote for using this it in FX. However it looks like it is the only possible way to change the application name at runtime. 05-04-2013 See RT-21743 for adding "About", "Preferences", etc. It's a separate issue. 01-04-2013 "java" should be replaced with a name of the main application class, or otherwise identify the running FX application. 01-04-2013 Please fix, I don't want to be forced to re-write my app in Swing just because of a handful of small, but very 'unprofessional' quirks. 29-03-2013 I would like to see an actual implementation of the Mac menu bar in place of "Java", which would include the "About" menu, "Preferences", "Quit", "Hide", "Services", etc. 20-11-2012 Maybe you should check your code. I'm using b19 here and despite the unwanted java menu (Which is still present), the menu bar is behaving as expected 13-08-2012 Using JavaFX 2.2.0 b19 on Mac OS I have tried setting useSystemMenuBar to true, but what I am seeing is the menu bar simply disappearing from the main stage without reappearing as a typical Mac menu bar next to the OS Apple. 13-08-2012 Still verified in b18 26-07-2012