On 2/20/19 2:28 PM, Xuelei Fan wrote:
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.
Actually I took another closer look at the code and I am ok with your
change since you can always get the stack trace if you reparse the cert
and enable debugging.
--Sean
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
