[icedtea-web] RFC: Fix for PR852: Classloader not being flushed after close

[Deepak Bhole]

* Omair Majid <omajid at redhat.com> [2012-01-27 15:56]:
> On 01/27/2012 03:29 PM, Deepak Bhole wrote:
> >* Omair Majid<omajid at redhat.com>  [2012-01-26 21:55]:
> >>Hi Deepak,
> >>
> >>On 01/26/2012 01:18 PM, Deepak Bhole wrote:
> >>>This patch fixes PR852. I would like to put it in 1.2 in addition to
> >>>HEAD.
> >>
> >>I have a few on the patch comments below.
> >>
> >>>diff -r 41f03d932cdf netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
> >>>--- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java	Mon Jan 09 18:45:31 2012 -0500
> >>>+++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java	Thu Jan 26 13:15:59 2012 -0500
> >>
> >>>+    public static void incrementLoaderCount(JNLPClassLoader loader) {
> >>
> >>>+    public static void decrementLoaderCount(JNLPClassLoader loader) {
> >>
> >>Just a thought, but it might be cleaner to make these instance
> >>methods, since they always operate on a loader object. With that
> >>changes, this becomes:
> >>
> >>public void incrementLoaderCount()
> >>public void decrementLoaderCount()
> >>
> >>In fact, incrementLoaderCount does not even have to be public. If we
> >>do go down that route, perhaps we can also go ahead and rename
> >>decrementLoaderCount to dispose() or release()? (I am also thinking
> >>close() but that would clash with the URLClassLoader's close()
> >>method in OpenJDK7.) I think it makes the purpose clearer in that
> >>this method releases resources associated with the classloader. It
> >>also hides the fact that we are caching something from the users of
> >>the JNLPClassLaoder api.
> >>
> >
> >Sure. I think making it non-static should be perfectly fine.
> >
> 
> What about private? ;)
> 

Oops. New patch attached. I also renamed the methods to make them more
clearer ([increment|decrement]LoaderCount ->
[increment|decrement]LoaderUseCount)

Okay for 1.2 and HEAD?

Cheers,
Deepak