NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #1835 (closed defect: fixed)

Opened 2013-04-22T14:35:44-05:00

Last modified 2013-04-26T12:34:04-05:00

Application exit relies on hack

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: imagej2-b7-ndim-data
Component: Core Version:
Severity: serious Keywords:
Cc: curtis Blocked By:
Blocking: #1563


There is a hack in the QuitProgram plugin that invokes System.exit(0). This was done because the disposal code was not quite ironed out / fully debugged. Now that we use the LegacyInjector to call context.dispose() directly (when IJ1 app clicked close in legacy mode) we need the disposal code to be more bulletproof. Find what the issues are that keep the app from closing (when the System.exit(0) is commented out in QuitProgram).

Change History

comment:1 Changed 2013-04-22T14:45:03-05:00 by bdezonia

I have gone over this issue a fair amount today and do not yet know the cause. I tried a number of things:

  • check that all implementers of dispose() call super.dispose() if applicable
  • block the 2nd user interface (SwingMDI) from initializing in case it was interfering with disposal elsewhere
  • invoke disposal in separate time delayed thread in case we are having trouble disposing of services when the QUitProgram command is running (because it uses CommandService and ModuleService and indirectly the EventBus).
  • generally making sure things are disposed at least once but only once

I used jprofiler and the eclipse debugger each to see what the threads look like. Can't really get a stack trace in jprofiler of all threads. There are three (a main[?} thread, an awt event queue thread and a timer thread). I'm really running out of ideas. I know ctrueden thought it was related to the DefaultUIService but I messed with it a bit and changed order of operations within it with no effect.

comment:2 Changed 2013-04-22T16:04:54-05:00 by bdezonia

Apparently this is tied to the Mac OSX app menu manipulation. If you set SREEN_MENU to false in the MaxOSXPlatform you can exit the program. We need to make the platforms Disposable.

(Note, I've attempted some simple permutations of setDefaultMenubar(null) and it does not work)

comment:3 Changed 2013-04-24T14:10:00-05:00 by bdezonia

Curtis reorganized the menu bar handling to not use the Apple EAWT extensions as they are buggy and caused issues elsewhere. This code is on the  graceful-quit branch.

It closes correctly if you start app and then close app
It closes correctly if you start app, open image (legacy or not), close image, and then close app
It will not close correctly if you start app, open image (legacy or not), and then close app.

I've tried a good number of things and added a few changes to the branch but can't yet determine what is still expecting events. There are JMenuItems, Menu, and ToggleButtons on the heap. Haven't determined how to release them yet though I've tried a couple of things.

Last edited 2013-04-24T14:15:57-05:00 by curtis

comment:4 Changed 2013-04-25T13:11:09-05:00 by bdezonia

I found the issue. SwingDialogPrompt (and it's MDI cousin) were not disposing their window. Fixed on the graceful-exit branch with commits 63a93a9331636ffdd7af8b3b97e6d7f18887ee8e and cef3869e9cc84ba592aff60d856a5a09d6698e89

comment:5 follow-up: ↓ 6 Changed 2013-04-25T13:12:46-05:00 by bdezonia

  • Status changed from new to closed
  • Resolution set to fixed

Curtis, this code now works but the graceul-exit branch has a menu dispatching bug I will open as a nother ticket and assign to you. I am considering this ticket closed.

comment:6 in reply to: ↑ 5 Changed 2013-04-26T12:34:04-05:00 by bdezonia

Replying to bdezonia:

Curtis, this code now works but the graceul-exit branch has a menu dispatching bug I will open as a nother ticket and assign to you. I am considering this ticket closed.

Note that other ticket is #1840