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.

Bug 53252 - Request SingletonTopComponent
Summary: Request SingletonTopComponent
Status: RESOLVED DUPLICATE of bug 191407
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 4.x
Hardware: PC All
: P3 blocker (vote)
Assignee: issues@platform
URL:
Keywords: API
Depends on:
Blocks:
 
Reported: 2005-01-11 18:05 UTC by Rich Unger
Modified: 2011-07-28 19:59 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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
Valid IMHO.
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...
Comment 7 Jesse Glick 2011-07-28 19:59:53 UTC
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 ***