| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This covers
- integration of all changes from OpenJDK 9+181 into
java.util.{AbstractList,List,Map,Objects,Set}.
- Map, List, Set gain static of() / ofEntries() factory methods.
- Objects gains misc static checker methods.
- When implementing RandomAccess, AbstractList.spliterator() as
well as subList.spliterator() is now built on top of random-access
List.get(int) rather than List.iterator().
- addition of various new files that are needed by those.
- addition of Nullablity annotations for the new APIs.
Changes to reference upstream versions
--------------------------------------
While the other files were previously derived from OpenJDK 8u121-b13,
Map.java was previously derived from OpenJDK 9b113+. After this CL,
all of the touched files derive from OpenJDK 9+181 with no further
changes waiting to be integrated; Android-changed and similar markers
note where Android carries local patches.
Notes on test coverage
----------------------
This CL adds test coverage for the new APIs/behavior.
The test coverage for Set.of() duplicates a bunch of logic from
the List.of() coverage. I experimented with ways to reuse code
but that reduced clarity and I didn't want to spend a lot of effort
on a major rearchitecture of the tests.
AbstractListTest asserts that iterator() is not called
while exercising basic existing Android spliterator, and checks
the fail-fast behavior guaranteed by the documentation.
Bug: 147483640
Test: atest CtsLibcoreTestCases:libcore.java.util.{Map,List,Set}OfTest
Test: atest CtsLibcoreTestCases:libcore.java.util.{AbstractList,Objects}Test
Test: atest CtsLibcoreTestCases
Test: Checked how the added @implSpec appear in generated docs: they
appear under headings "Implementation Requirements:".
Change-Id: I362ec405b270ba00fe3176dc19f08943b7d350d5
|
|
|
This change annotates Arrays, Collections, and Objects.
The most interesting decision here is probably annotating the Object
argument of the various Objects.requireNonNull overloads. Under the
normal rules, this would be @NonNull, because the method throws NPE if
it's null. This change annotates them as @Nullable because throwing
NPE on null is the whole point of the method, and calling it with an
argument which is provably non-null is pointless; or, to put it
another way, the method exists to convert possibly-@Nullable T to
definitely-@NonNull T with an exception thrown in a controlled
fashion.
Note that the methods involving natural sort ordering of arrays or
collections require the elements to be non-null, because they end up
calling e1.compareTo(e2) for arbitrary pairs of elements. For the
methods that take Comparators, the nullability of the elements match
the parameter of the Comparator's type parameter.
Test: make core-current-stubs-nullability-validation-check-nullability-warnings
Bug: 64930165
Change-Id: I52744d72da857751274fe44f58cff38e6d6b8a2f
|
