RFR: 8002070 Remove the stack search for a resource bundle for Logger to use

[Mandy Chung]

On 3/6/2013 11:42 AM, Jim Gish wrote:
>>> http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/ 
>>
>>
>> L122-125: you may want to replace <code>....</code> with {@code .... }
> I think we'll save that for a later day - and then update all the 
> occurrences of <code> to {@code}

Fine with me.

>> L129-130: you can use @linkplain instead:
>>      {@linkplain ClassLoader#getSystemClassLoader()system ClassLoader}
> All other existing links are using @link.  Why should we use 
> @linkplain here?

The javadoc generated in your current change will show:
     system ClassLoader, <a 
href="....">ClassLoader.getSystemClassLoader()</a>,

If you use @linkplain, the javadoc will show:
<a href="....">system ClassLoader</a>

>>
>> LoggerResourceBundleRace.java: I think what you really want is to add 
>> a new test that sets a context class loader to a class loader that 
>> finds the resource bundle for a logger that a system class loader 
>> can't find.   I suggest to leave this test as it is and then add a 
>> new test to exercise the context class loader search of a resource 
>> bundle as a separate RFE that will improve the test coverage.
> Leaving the existing test as is not an option unless we change the 
> test to run in othervm as I had on my first webrev.  The bundles are 
> not found otherwise.  Hence the change to set the context classloader.

I'm confused.  Is the resource bundle 
"LoggerResourceBundleRace$MyResources" in the classpath as this test 
class is located?  Should the system class loader be able to find them? 
This test shouldn't depend on the stack search.  Shouldn't  the thread 
context classloader be null and then use the system class loader?  Is 
another test set the thread context classloader in the jtreg run? Does 
the test pass if you run it directly (not via jtreg)?

Mandy