| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| | |
Test: m update-api
Change-Id: I5139d8c8063976e7e2e35a970e21c90b8bb96567
|
| |/
|
|
|
|
| |
Bug: 160356973
Test: treehugger
Change-Id: I5ed9ec74ed8a84a9eb7636c308e2fa6c4e77957b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Test: make -j core-current-stubs-nullability-validation -> is gettng
closer to passing
Bug: 138981090
Change-Id: Id0b3ef3e349c5114ba679fc01dfda397fade477f
|
| |
|
|
|
|
| |
Bug: 138863051
Test: run metalava with syntax check enabled
Change-Id: Ie118ea1658e8739333a002908b197ff8c0829e3c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an unusual case. Normally, even if a Map does not accept null
keys, calling containsKey(null) is legitimate, and returns false, so
Map.containsKey() takes @Nullable Object. On a CHM, calling
containsKey(null) throws NPE. (This behaviour is allowed by the
contract of Map, which says "Attempting to query the presence of an
ineligible key or value may throw an exception, or it may simply
return false; some implementations will exhibit the former behavior
and some will exhibit the latter.") This change therefore declares the
argument to CHM.containsKey as @NonNull Object. This relationship
breaks the normal 'rules' that an implementation can't narrow the type
of an argument to an interface method it's implementing, but it is the
best representation of reality. The practical consequence is that a
warning or error will be generated on chm.containsKey(null) if chm is
statically typed as CHM, but not if it is a CHM instance that is
statically types as Map. This gap in null-safety checking is an
inevitable consequence of the optionality in the contract of Map.
There are some rather non-obvious nullability contracts on the
functional programming methods on CHM. For example, consider the
forEach overload which takes a BiFunction<? super K, ? super V, ?
extends U> and a Consumer<? super U>: the BiFunction is allowed to
return null, so its third parameter is @Nullable, but the Consumer is
not applied in that case, so its parameter is @NonNull. See the
class-level and method-level javadoc.
Test: make core-current-stubs-nullability-validation-check-nullability-warnings
Bug: 64930165
Change-Id: Ia36ef9f841df1dae4ce06b24acd34290d25e415b
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Map itself is already annotated (see Map.annotated.java), and many of
the annotations here are copied onto its implementations. There are
new methods added in the Sorted and Navigable interfaces.
Test: make core-current-stubs-nullability-validation-check-nullability-warnings
Bug: 64930165
Change-Id: Ia976a37deef9ce9f20190dd84dbbfd598337b9af
|
| |/
|
|
|
|
|
|
|
|
|
| |
N.B. List has already been annotated (see List.annotated.java) and
most of these annotations are just copies of those. There are
additional methods on Queue and Deque, where the only interesting
thing is the distinction between peek vs element, poll vs remove, etc.
Test: make core-current-stubs-nullability-validation-check-nullability-warnings
Bug: 64930165
Change-Id: I579af8696e6a57f009d239cfbf74f9e07d37d654
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The only noteworthy thing here is that, although Matcher.group(int)
can return null for arguments >= 1, but Matcher.group() which
delegates to group(0) cannot return null. This is because the methods
throw unless there was a successful match, and group() returns the
whole matching substring (which may be empty, but won't be null).
Bug: 64930165
Test: make core-current-stubs-nullability-validation-check-nullability-warnings
Change-Id: I7e58d5f6f0f0139c3a24b5216bd1c82ad05758a3
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Notes:
- The Calendar constructor does actually accept a null Locale
argument. But there's a TODO saying that it's for backwards
compatibility only and should be changed to check and throw in
future. This change annotates it as @NonNull because otherwise
that future change would be impossible.
- It may not be entirely guaranteed that the keys and values of
the Map returned by Calendar.getDisplayNames are not null, but
it seems to be the intention, based on the javadoc and all the
known code paths.
- Locale.Builder.setLanguageTag's javadoc claims that it accepts
a null argument, but the implementation does not. (There is an
open bug about this.) This change annotates it as @NonNull to
reflect the real behaviour.
- Locale.parse and Locale.mapEquivalents don't actually throw if
their Map arguements contain nulls in all cases, but it seems
to be the intention that they shouldn't, based on javadoc, so
this change annotates them all as @NonNull.
Bug: 64930165
Test: treehugger
Change-Id: I61bd750f0df57774e68ce124e739136119a76a86
|
| |/
|
|
|
|
|
|
|
|
|
| |
The Logger annotations reflect the fact that the various log* methods
are fairly tolerant of null arguments. Although this tolerance isn't
always documented in Logger itself, it is documented in the
equalivalent setters and getters in LogRecord.
Bug: 64930165
Test: make core-current-stubs-nullability-validation-check-nullability-warnings
Change-Id: I80209a3749918cf0a3afe8de51700e1cf31e75f2
|
| |
|
|
|
|
|
|
|
| |
While these were technically correct as type annotations, metalava was unable to understand them because it doesn't support type annotations. Moving them means they can be processed by metalava as method annotations.
Bug: 64930165
Test: treehugger
Test: re-ran validation (in pending CL) and verified that warnings about missing annotations on return types of these methods disappear
Change-Id: I28cf66629867c775372a501e410fced017a82f76
|
|
|
All of the current annotations are intended for use in the SDK build,
and live at ojluni/annotations. In order to make room for annotated
stubs for other purposes, this change moves them. There is a README
that describes the intended directory structure. (N.B. Validation of
the nullability stubs is not landed yet but is described here in
anticipation.)
Bug: 115746226
Test: `make api-stubs-docs`
Change-Id: I7cfbdb5dc9888f796eb1f384155fce33125a7d9e
|
