RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278

Xueming Shen xueming.shen at oracle.com
Thu Feb 15 07:49:29 UTC 2018


Hi,

Please help review the change for  JDK-819798

issue: https://bugs.openjdk.java.net/browse/JDK-8197988
webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev

The change for JDK-8164278 caused a decoding regression. A Tier2
test case,  javax/net/ssl/interop/ClientHelloChromeInterOp.java,  that
uses mime-base64-decoder failed.

The "condition" that triggers the decoding to go the fast path is 
incorrect in
the code pushed for JDK-819798.

The intent here is to only start/try the fast path when we are at the 
beginning
of a 4-byte legal base64 unit. The correct/appropriate check is to see if
shiftto == 18, which means the decoder is still at the beginning of 4-byte
unit. ( bits == 0 is a false indicator, as bits might include decoded 
byte value of
0). The fix is a relatively easy/one line change.

Thanks,
Sherman


More information about the core-libs-dev mailing list