Jevgeni,
The best long term solution for the VM is
ephemeronshttp://en.wikipedia.org/wiki/Ephemeron.
They're not slated for Java 7 or even 8 yet though.
I implemented class loader locals as a library years ago. Unfortunately, I
don't have the code anymore because I didn't end up using them.
The
On Thu, Sep 16, 2010 at 9:22 AM, Jevgeni Kabanov ekaba...@gmail.com wrote:
Bob, if you check the link to the blog post, it described such an
implementation that I did a while ago.
Doh! Sorry for not reading that.
Unfortunately what I found out is that it doesn't work with some class
On Mon, Oct 12, 2009 at 12:52 PM, Rémi Forax fo...@univ-mlv.fr wrote:
It's not a good idea to have a hashCode() that allocate objects,
at least until escape analysis is implemented in all VMs.
Agree with Joe--these methods don't carry their weight. If the allocation is
too much to bear, it's
On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict pbened...@apache.org wrote:
Understood, but the keyword (pun) here is effectively. Why let a
developer wait until runtime to find out his code will fail? At least
by marking the class as final, anybody who wishes to subclass it will
receive a
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).
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 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 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
11 matches
Mail list logo
