Iris Clark wrote:
Hi, Alan.
Before I consider initiating the CFV, I have one question. Is JDBC really considered part of
Core Libraries? We want to make sure that Core Libraries does not become
the catch-all for APIs that don't belong anywhere else.
You are right and that is the real
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
Alan Bateman wrote:
Iris Clark wrote:
Hi, Alan.
Before I consider initiating the CFV, I have one question. Is JDBC
really considered part of Core Libraries? We want to make sure
that Core Libraries does not become the catch-all for APIs that
don't belong anywhere else.
You are right
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
Changeset: de1d02ad2d1d
Author:mchung
Date: 2009-02-27 13:43 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de1d02ad2d1d
6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized
lazily
Summary: Lazily initialize the hexFloatPattern static field
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
Changeset: 0da45c759116
Author:mchung
Date: 2009-02-27 16:34 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0da45c759116
6809504: Remove enctype=text/xml from the offline registration page
Summary: Remove enctype=text/xml from register.html and other localized
versions
14 matches
Mail list logo
