This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Product:||platform||Reporter:||Rich Unger <richunger>|
|Component:||Window System||Assignee:||issues@platform <issues>|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
Description Rich Unger 2005-01-11 18:05:36 UTC
Creating a singleton TopComponent is a pretty common thing to want to do (explorer window, form palette, debugger stuff, etc). The code necessary to ensure that the singleton whose id is declared in Windows2/Components is the same as any instance that might be returned from in-code invocation is rather complicated and hard for a newbie to grok. It requires understanding a lot about how the window system works. I'd like a subclass of TopComponent that overrides preferredID() and instead delcares abstract String getID(), and which will guarantee that only one instance of that class can exist (and has that ID).
Comment 1 David Simonek 2005-05-09 12:42:48 UTC
Comment 2 Jesse Glick 2005-11-04 18:23:16 UTC
I think Milos was wanting something like this too - the current template for a TopComponent involves too much weird and fragile code.
Comment 3 _ tboudreau 2006-05-10 09:54:25 UTC
+1 > I'd like a subclass of TopComponent that overrides > preferredID() and instead delcares abstract String > getID() Almost guaranteed that someday, somewhere, someone will decide not to always return the same value from getID(); some way of making it immutable would be nice. May not be worth worrying about though. I'm not sure that really solves the problem, though - there's a bit of a chicken and egg thing here: You need to have the ID to try to look up the existing singleton component (if any), but if getID() is an instance method, you need to create one to find out the ID. Or did I not understand the suggestion? It would definitely be nice to see less generated boilerplate code in new TC's from a template, however we do it. A little reflection could do the trick - have a SingletonTopComponent subclass which tries getClass().getDeclaredField (null, "PREFERRED_ID") in its preferredID() method. The findInstance() method in the template would not be significantly more clunky if moved to WindowManager.findSingleton (Class singletonTCSubclass) (if the PREFERRED_ID field is required, no ID argument is needed to this method - it can look it up). The getDefault() method in the template is simply calling a default constructor - and in fact, it's a defacto memory leak - we could and probably should allow "singleton" TopComponents to be gc'd: Move ResolvableHelper into the SingletonTopComponent class, have and it take a class object. When a TC becomes only weakly reachable, see if writeReplace() returns an instance of SingletonTopComponent.ResolvableHelper. If it does, then we know we can dispose the instance, if not we can hold the return value of writeReplace() and still dispose the TC. That should have at least some value for memory usage, though we should measure how often people have closed singleton TC's lying around and how many of them there typically are.
Comment 4 Jesse Glick 2008-04-08 17:59:24 UTC
Given that there is an API template for this, can this be closed?
Comment 5 David Simonek 2008-10-20 14:51:51 UTC
Still I think it would be usable - there is not enough API differentiation between TCs that should act as singletons (view type of window typically) and others (document type of window typically). I remember some VOC about this. richunger, what is your opinion on current state? Do we still need such an API for Netbeans 7.0 or something similar in this area? Thank you.
Comment 6 Rich Unger 2008-10-21 03:47:48 UTC
I think some differentiation between the two main TC use cases would still be helpful. Relying on template-generated code is pretty weak. Is there a way to utilize Bloch's advice for using enums for serializable singletons in this case? Say, using an enum for a map of singleton TCs, and having the winsys api go there to load and retrieve them? I'm just thinking off the cuff here, so feel free to disregard...