tree 5320f5ee467d645da902bc557709ba1ad1d17285
parent 0692a133e3895e44eb828ca1298e057bed7ed731
author Tobias Thierer <tobiast@google.com> 1518126309 +0000
committer Tobias Thierer <tobiast@google.com> 1518524413 +0000

Update java.net.URL to OpenJDK 8u121-b13.

This CL integrates upstream commit (a behavior change)
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/1837db2935fd
and completes the update to OpenJDK 8u121-b13.

Notes:

 - Android's URL.hashCode is not part of the serialization.
   The Android change for this used to be at the place where
   the field was declared, but is now in the logic associated
   with readObject(); UrlDeserializedState's hashCode field
   is kept, but its value is always -1; the existing test
   URLTest.testUrlSerializationWithHashCode() checks that the
   hashCode is recomputed during deserialization.
 - The upstream commit introduces a behavior change around
   deserialization of URLs which inconsistent state (eg.
   host and port disagreeing with authority); this CL applies
   the same behavior change to Android and adds test coverage
   for the new behavior.
 - The behavior change differs between URLs handled by built-in
   vs. custom (application) URLStreamHandler implementation.
   Android makes the same distinction, although the method
   isBuiltinStreamHandler() that distinguishes built-in handler
   implementations was adjusted to Android's needs.
 - For built-in Handlers, readResolve() produces a new URL
   object via its String representation. This means that,
   for example, host and port are recomputed from the authority;
   similarly, the split between host and file parts is recomputed.
   This guards against inconsistencies of those field values in
   the serialized form.
 - For custom Handler implementations, a more conservative approach
   is taken; a null authority is recomputed from port and nonempty
   host, but host/port consistency with authority is not otherwise
   checked. Android is adopting this behavior in this CL and adding
   test coverage, but the rationale behind the exact behavior choices
   was not analyzed in detail.
 - This CL factors the Android-added createBuiltinHandler() out into
   a helper method in order to put it adjacent to
   createBuiltinHandlerClassNames(), which must remain consistent
   (tested by testCommonProtocolsAreHandledByBuiltinHandlers()).

Bug: 71861693
Bug: 35910877
Test: CtsLibcoreTestCases

Change-Id: Ieffa8df1818b8b31601214e74da617a3e2e78c2c