On 2/20/2019 10:52 AM, Sean Mullan wrote:
On 2/20/19 1:41 PM, Xuelei Fan wrote:
ping ...
I took a quick look, but not enough time to understand the full context.
The exception in the UnparseableExtension can be useful to get a stack
trace later of why it could not be parsed. Did you think of any other
way you can fix this?
In the UnparseableExtension implementation, the private 'why' variable
can be used to dump the stack trace later. But as it is used to get it
exception message only, I updated to store the exception message only.
The update does not impact the fix. It is a kind of DiD fix in case it
is used in a static field in other places. We can leave it unchanged if
you like.
Thanks,
Xuelei
--Sean
On 2/8/2019 12:26 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8168069/webrev.00/
In the lazy initialization holder in SSLContextImpl, an exception is
reserved as static in order to check if the holder is initialized
properly. If the exception had a strong referent to some object, the
object will be out of the cycle of garbage collection.
With this update, the original exception is debug logged, and a new
exception with the same exception message as the original one.
Code cleanup, no new regression test.
Thanks & Regards,
Xuelei
