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.
Summary: | Request SingletonTopComponent | ||
---|---|---|---|
Product: | platform | Reporter: | Rich Unger <richunger> |
Component: | Window System | Assignee: | issues@platform <issues> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | jglick, mkleint |
Priority: | P3 | Keywords: | API |
Version: | 4.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Rich Unger
2005-01-11 18:05:36 UTC
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 *** |