RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup

Jim Gish jim.gish at oracle.com
Thu May 16 15:20:59 UTC 2013


Thanks.

Daniel -- could you please push 
http://cr.openjdk.java.net/~jgish/TestRB.7.2/ 
<http://cr.openjdk.java.net/%7Ejgish/TestRB.7.2/> ?

Jim

On 05/16/2013 08:13 AM, Alan Bateman wrote:
> On 16/05/2013 03:46, Mandy Chung wrote:
>> On 5/15/2013 2:19 PM, Jim Gish wrote:
>>> Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/
>>
>> Looks fine.  This fix gets the Glassfish to run on jdk8 as an interim 
>> fix while allowing us to investigate a proper solution for jdk8.
>>
>> Daniel mentioned the performance overhead of 
>> Reflection.getCallerClass() offline that does incur some overhead. 
>> Applications that create logger with no resource bundle likely call 
>> Logger.getLogger(String name) instead of Logger.getLogger(String 
>> name, String rbname).  In other words, when Logger.getLogger(name, 
>> rbname) is called, it's likely that rbname is non-null.   It might 
>> incur some performance overhead to applications who resource bundle 
>> is visible to TCCL or system class loader as Logger.getLogger(String, 
>> String) always obtains the immediate caller but not used.  In 
>> Glassfish and OSGi environment, there is no performance issue since 
>> it has been doing the stack walk in the past.  I think it's fine as 
>> it is.
>>
>> Nits: L1639, 1712 - better to align with the line above.
>>
>> Thanks for extending the test to cover various cases.
>>
> This looks okay to me too and I agree with Mandy's comment about 
> thinking of this as a fix for the short-term. More work will be 
> required to figure out what the right thing to do is and maybe the 
> methods that take a resource bundle name needed to be deprecated in 
> favor of new methods.
>
> -Alan
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com




More information about the core-libs-dev mailing list