On Fri, Jul 2, 2010 at 2:34 PM, Richard S. Hall <[email protected]> wrote: > On 7/2/10 9:06, Richard S. Hall wrote: >> >> On 7/2/10 2:20, Atle Prange wrote: >>> >>> Hi, >>> >>> i have a question about static references and how they are treated in >>> OSGi. >>> >>> Will singletons stay in memory after a bundle has been unloaded and >>> leak memory, or can i safely create huge amounts of static references? >>> And what about ThreadLocals? Can I use them safely as well? I see some >>> projecs use the "bundle activator singleton" pattern to access >>> resources throughout the code, but a tiny voice behind my ear tells me >>> that it might not be a good idea, is that voice right or wrong? >> >> As long as a bundle cleans up its threads and other bundles do not hold >> onto stale references (i.e., objects from bundles that have been >> uninstalled), then there shouldn't be any issues. The framework doesn't hold >> onto bundle objects or class loaders after they are uninstalled (and >> refreshed). > > Of course, I should have added, I don't recommend using statics, since they > are just another form of global variables.
Completely agree with Richard, if you can avoid statics do. But think it might be worth mentioning a minor addendum that bundle private statics are "less awful" than bundle exported statics. With private statics (i.e. objects that are referenced in private packages or accessible only by private or package private accessors) you are generally[1] in control and can work to ensure that when your bundle is stopped/uninstalled then there are no more references to those objects. But with statics that are exported outside of the bundle the only way to ensure these get cleared up is to have all code that is grabbing hold of those static references to also listen for bundle lifecycle events to know when to null references - which is a maintenance nightmare waiting to happen... 2 cents anyway... Regards, Dave [1] Generally - be wary of reflection that allows others to access private vars...but definitely that's an edge case problem... > > -> richard > >> >> -> richard >> >>> Thank you >>> >>> -atle >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
