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.
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).
Valid IMHO.
I think Milos was wanting something like this too - the current template for a TopComponent involves too much weird and fragile code.
+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.
Given that there is an API template for this, can this be closed?
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.
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...
Handled decently with @TopComponent.Registration, I think; there is much less boilerplate in the new templates. *** This bug has been marked as a duplicate of bug 191407 ***