Update sun.util to upstream OpenJDK8u121-b13.
Before this CL, the package was still based on OpenJDK7u40. All of the
upstream changes integrated here were already present in OpenJDK8u60;
the only upstream changes between 8u60 and 8u121-13 related to timezone
data resource files, which are not used on Android (Android uses ICU).
Below,
[U] means that a change was integrated from upstream.
[L] means a local edit was made, e.g. to improve documentation of
existing Android changes.
[identical] means the file is identical to the upstream version,
after this CL.
The affected files were:
In sun.util.calendar:
BaseCalendar [identical]:
[U] drop unneeded import
CalendarDate [identical]:
[U]: pass cause to InternalError ctor during clone()
CalendarSystem
[L] improved formatting of Android-changed sections
[U] throw InternalError rather than RuntimeException
in case of Exception during calendarClass.newInstance()
(Shouldn't happen).
LocalGregorianCalendar:
[U] Add missing @Override annotations
[U] Drop unused imports
[U] Drop redundant generic type argument.
[LU] Adopt upstream implementation of getLocalGregorianCalendar().
Previously, the implementation was substantially different from
OpenJDK7u40, but the implementation in 8u121-b13 nearly exactly
matched what Android had.
The differences to previous Android versions are:
- Catch IllegalArgumentException, not just IOException,
when calling CalendarSystem.getCalendarProperties(), and
- throw InternalError rather than RuntimeException when
that fails.
This implementation in 8u121 was practically identical with what
Android had, allowing us to drop an Android change.
[L] Tweak an Android-changed comment.
In sun.util.locale:
BaseLocale [identical]:
[U] Adopt use of SoftReferences in Key.
See further below why this change is safe, but not obviously so.
InternalLocaleBuilder:
[L] Document the sole Android change from libcore commit
51b1b6997fd3f980076b8081f7f1165ccc2a4008 ("Initial import of
OpenJdk files") from Feb 2015 which first added this file.
The change is unexplained.
There were no upstream changes to this file between
OpenJDK7u40 and 8u121-b13.
LanguageTag [identical]:
[U]: Correct RFC number.
LocaleMatcher:
[L] document the places where the backport of JDK-8166994
(OpenJDK 9) has been applied. This change resulted
from a patch that was previously upstreamed to
OpenJDK. This documentation can be removed if/when
Android updates to OpenJDK 9, since that includes
this change.
LocaleObjectCache [identical]:
[U] fix createObject() to be called before rather than
after normalizeKey().
LocaleUtils [identical]:
[U] copyright year
LoggingProxy [identical]:
[U] copyright year
LoggingSupport [identical]
[U] copyright year
PlatformLogger:
[U] Remove (previously @Deprecated) isLoggable()/getLevel()/setLevel()
methods based on int values to identify the level.
[U] Make the int constants, representing log levels, private.
[L] Use /* .. */ rather than // to comment out a removed block;
This results in a small diff vs. upstream.
[U] Update the aforementioned block to the latest upstream version.
[L] document Android change in getCallerInfo where we have to
use throwable.getStackTrace() rather than
SharedSecrets.getJavaLangAccess().getStackTraceElement()
In sun.util.resources:
OpenListResourceBundle [identical]:
[U] narrow the scope of the synchronized block in loadLookup()
[U] add missing @Override annotations
[U] override keySet()
[U] Various API changes (public -> protected handleGetObject(),
handleGetKeys(); drop of getParent() override, addition
of createSet(), generic type arguments for createMap()).
Comments follow on why the adoption on SoftReference<String>s in
BaseLocale (and the change to LocaleObjectCache) appears correct but
not obviously so. This change was introduced by upstream commit
http://hg.openjdk.java.net/jdk9/client/jdk/rev/0fcff3336fee
Because investigation of whether this change is correct/safe and
its benefits took some time, these comments are fairly verbose:
- The only apparent benefit of these SoftReferences is that it avoids
holding on to (potentially large) String objects for "stale" Cache
entries. Cache entries are stale between the time the cached
(BaseLocale) value has been garbage collected and when the entire
entry is removed by LocaleObjectCache.cleanStaleEntries(), which
happens during Cache.get().
The Strings, e.g. from the Locale(String, String, String, String) ctor,
are typically short (this is the case for all Strings passed in in
the platform) so the four SoftReference objects appear to only be
an improvement if unusually large Strings are passed in by a misbehaved
application.
- The fact that normalizeKey() and createObject() do not need check
for whether the SoftReference<String>s have been cleared appears
correct but not obviously so:
- normalizeKey() and createObject() are only called from
LocaleObjectCache.get().
- Code in BaseLocale holds strong references to the String values
whenever it constructs Key objects to call LocaleObjectCache
with (guaranteeing that the String won't be garbage collected
during construction / interaction with the Cache).
- Specifically, BaseLocale.getInstance(String, String, String, String)
holds strong references while calling CACHE.get(), and
BaseLocale.createInstance(String, String) holds strong references
while calling CACHE.put() for a newly constructed Key object.
- normalizeKey() and createObject() could throw NPE if they were
called on a stale entry's Key, but the only way outside code
could get access to such a Key is through (unsafe) reflection.
- Likewise, the behavior of stale Cache entries is nontrivial:
- BaseLocale.Cache indirectly extends SoftReference<BaseLocale>.
The cache entry becomes stale when that SoftReference is cleared.
- BaseLocale has strong references to the same Strings as the Key,
so the earliest time the Key's SoftReference<String>s could be
cleared is when the entry becomes stale.
- While stale entries are never returned by the cache,
key.equals(obj) can still be called for them because other
(non-stale) keys in the LocaleObjectCache.map may have the
same hashCode.
- this is why, unlike normalizeKey() and createObject(),
Key.equals() *does* need to check whether the
SoftReference<String>s have been cleared.
- For keys whose SoftReference<String> has been cleared,
key.equals(obj) returns false for any obj other than themselves.
Such keys are deadweight, but will be removed from the cache during
cleanStaleEntries().
Bug: 37749191
Test: CtsLibcoreTestCases
Change-Id: Idfc63e0ee9bbc0a238ea1c124347f726b74058bc
15 files changed