commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: [flyweight] WAS [proxy] 2.0 WAS Re: a bit of commons-style code in search of a home
Date Wed, 21 Jul 2010 12:10:07 GMT
The one problem with creating an instance is that the flyweight needs
to be able to get back to his "home" to reconstitute the object.  If
it's some instance floating around, that's harder.

On Tue, Jul 20, 2010 at 2:43 PM, James Carman
<> wrote:
> On Tue, Jul 20, 2010 at 2:36 PM, Matt Benson <> wrote:
>> I know what you mean; it's potentially not that much code.  Maybe start in the sandbox
and, once everything's working satisfactorily, decide what to do with it?  As for memory,
what if you actually put the map of flyweight id:instance onto a Flyweights class and managed
*its* id mappings statically/weakly?  Then a given Flyweight would just become expired whenever
its owning Flyweights instance () was no longer accessible, and its getObject could reflect
that somehow.  Typically it would be a sign of a programming error if a Flyweight associated
with a given container were used after its container had been reclaimed, so a simple exception
might be enough.  Just ruminating...
> Interesting thought.  I'll have to churn on that one a while.
> Basically what I'm trying to do is come up with a nice re-usable way
> to solve the writeReplace()/readResolve() problem so that most folks
> can understand it.  I can see having a superclass that automatically
> registers a Flyweight for itself and spits that out in its
> writeReplace() method.  Then, when anyone wanted that functionality,
> they could extend that superclass.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message