On 03/03/2009 12:13 PM, Bob Lee wrote:
On Mon, Mar 2, 2009 at 10:37 PM, David M. Lloyd david.ll...@redhat.com
mailto:david.ll...@redhat.com wrote:
If not, then there is no automatic solution possible, even with
special VM ephemeron support (this basically IS an ephemeron
On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd david.ll...@redhat.comwrote:
No, actually what I've implemented *exactly* matches this definition: a
mapping where the value is held strongly until the key is known to be
garbage collected (even when the value has a reference back to the key).
On 03/03/2009 02:17 PM, Bob Lee wrote:
On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd david.ll...@redhat.com
mailto:david.ll...@redhat.com wrote:
No, actually what I've implemented *exactly* matches this
definition: a mapping where the value is held strongly until the key
is known
On 03/02/2009 10:45 PM, Bob Lee wrote:
David,
Here's the problem I'd like to see solved: enable a library to hold an
indirect reference to a Class without preventing that Class's loader
from being reclaimed. The reclamation should happen automatically when
the loader is not otherwise
I have a simpler and more secure solution. I just need one method on
ClassLoader:
public class ClassLoader {
public void keepReferenceTo(Object o) { ... }
...
}
The ClassLoader would keep a strong reference to the passed reference
indefinitely (using some sort of minimal memory
On 02/27/2009 12:10 PM, Bob Lee wrote:
I have a simpler and more secure solution. I just need one method on
ClassLoader:
public class ClassLoader {
public void keepReferenceTo(Object o) { ... }
...
}
The ClassLoader would keep a strong reference to the passed reference
indefinitely
On Fri, Feb 27, 2009 at 10:40 AM, David M. Lloyd david.ll...@redhat.com wrote:
Seems like a reasonable alternate approach, *however* I think there ought to
be a way to clear the reference as well,
Do you have a use case?
*If* we wanted to support removals (I don't think we should), I would
do
On Fri, Feb 27, 2009 at 11:04 AM, David M. Lloyd david.ll...@redhat.com wrote:
A couple use cases, off the top of my head:
1) I've got a set of FooBars that associate with Classes; now for whatever
reason, I want to change the FooBar that is associated with the Class. The
old FooBar is now
On 02/27/2009 01:15 PM, Bob Lee wrote:
On Fri, Feb 27, 2009 at 11:04 AM, David M. Lloyd david.ll...@redhat.com wrote:
A couple use cases, off the top of my head:
1) I've got a set of FooBars that associate with Classes; now for whatever
reason, I want to change the FooBar that is associated
On Fri, Feb 27, 2009 at 11:44 AM, David M. Lloyd david.ll...@redhat.com wrote:
WeakHashMapClass?, Externalizer()
*fails* because Externalizer instances are usually customized to the class
they externalize (which, by the way, could well be a system class). This
means that Externalizer keeps a
On Fri, Feb 27, 2009 at 12:48 PM, David M. Lloyd david.ll...@redhat.com wrote:
I don't think you understood what I wrote
I understood. I just think you're trying to solve a problem that no
one really has. 99% of the time, the problem is with a class from a
parent class loader keeping a strong
There's no need for insults, David. Have some perspective. I've been nothing
but civil and respectful (even after you presumed to know what I do and
don't understand).
On Fri, Feb 27, 2009 at 1:12 PM, David M. Lloyd david.ll...@redhat.com
wrote:
I'm not talking about a parent/child relationship
On 02/27/2009 03:51 PM, Bob Lee wrote:
There's no need for insults, David. Have some perspective. I've been
nothing but civil and respectful (even after you presumed to know what I
do and don't understand).
I haven't insulted you that I am aware of, only stated the facts as I see
them.
This thread needs a third perspective (which I can't provide for lack of
expertise).
On Fri, Feb 27, 2009 at 2:32 PM, David M. Lloyd david.ll...@redhat.comwrote:
On 02/27/2009 03:51 PM, Bob Lee wrote:
There's no need for insults, David. Have some perspective. I've been
nothing but civil
After running into the problem described in this bug for the umpteenth
time, I decided to get off my duff and do something about it.
Following are two patches. The first one adds the notion of class-local
storage, and the second adds class loader-local storage; both mechanisms
work basically
15 matches
Mail list logo
