summaryrefslogtreecommitdiff
path: root/ojluni/annotations/sdk/nullability/java
Commit message (Collapse)AuthorAgeFilesLines
* Add nullability annotations to InetAddress APIspaulhu2021-04-211-0/+89
| | | | | | Bug: 183938110 Test: make update-api Change-Id: I64e0ffbcf6892be59936b2e4dd08e51c7d5f31c4
* Merge "Add nullability annotations for Map's and Set's copyOf method"Treehugger Robot2021-03-052-0/+4
|\
| * Add nullability annotations for Map's and Set's copyOf methodNikita Iashchenko2021-03-032-0/+4
| | | | | | | | | | Test: m update-api Change-Id: I5139d8c8063976e7e2e35a970e21c90b8bb96567
* | Update java.util.List to 11+28Nikita Iashchenko2021-03-021-1/+3
|/ | | | | | Bug: 160356973 Test: treehugger Change-Id: I5ed9ec74ed8a84a9eb7636c308e2fa6c4e77957b
* Make Class.getPackageName public.Nicolas Geoffray2020-12-111-0/+2
| | | | | | | Import from 11+28. Test: PackageTest, OldClassTest. Change-Id: I1d65c1e1b49a24fd67eb4f5f8378213ba9304aba
* Update misc java.util classes to OpenJDK 9+181 and immediately expose APITobias Thierer2020-01-174-4/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove metalava-manual from droidstubs generationPaul Duffin2019-11-113-6/+5
| | | | | | | | | | | | | | | | | | | | | | The metalava-manual droiddoc_exported_dir provides some annotations (in tools/metalava/manual/master.txt) that are merged into libcore stubs. They were provided in the API signature file because metalava does not support TYPE_USE annotations correctly when specified on Java code and so adding the libcore.util.Nullable/NonNull TYPE_USE annotations to the appropriate file in the ojluni/annotations/sdk/nullability directory did not work because they were discarded. This change works around that issue by allowing libcore.util.Nullable/NonNull to be specified on other element types like methods and fields. That allows them to be used in places where TYPE_USE annotations are not allowed and metalava merges them in correctly. Bug: 111116803 Test: m checkbuild tested that this does not change offline-sdk-docs Change-Id: I6fb0cfcfe158a61537b6706ef97f4f2c4359fe7a
* Add missing StringBuilder nullability annotationsPaul Duffin2019-11-011-3/+3
| | | | | | | | | | | StringBuilder implements some methods of CharSequence that have nullability annotations but was missing its own annotations on those methods which resulted in the nullability validator reporting them was incompatible. Bug: 143700871 Test: m dist Change-Id: I226810d40c19917aacb0a350bf6691951f0f10ad
* Fix more issues in ojluni annotations.Aurimas Liutikas2019-08-062-2/+2
| | | | | | | | Test: make -j core-current-stubs-nullability-validation -> is gettng closer to passing Bug: 138981090 Change-Id: Id0b3ef3e349c5114ba679fc01dfda397fade477f
* Fix syntax issues in HashMap.annotated.java.Aurimas Liutikas2019-08-021-2/+2
| | | | | | Bug: 138863051 Test: run metalava with syntax check enabled Change-Id: Ie118ea1658e8739333a002908b197ff8c0829e3c
* Add *Buffer covariant method overloads.Tobias Thierer2019-01-241-0/+14
| | | | | | | | | | | | | | | The java.nio.Buffer methods {position,limit,mark,reset,clear,flip,rewind} return "this". In OpenJDK 8, those methods were final and their return type was Buffer. In OpenJDK 9, the methods changed to nonfinal and the subclasses {Byte,Char,Double,Float,Int,Long,Short}Buffer gained overrides whose compile-time return type was that of the subclass. This CL makes the same change to java.nio.Buffer and adds synthetic covariant overloads to the subtypes. Fixes: 71597787 Test: atest CtsLibcoreApiEvolutionTestCases Change-Id: Ib6f63b6e3dce0212ff7dd60341145ede17a1b454
* Add nullability annotations for ConcurrentHashMap.Pete Gillin2018-11-191-0/+238
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Add nullability annotations for static utils in java.util."Treehugger Robot2018-11-143-0/+594
|\
| * Add nullability annotations for static utils in java.util.Pete Gillin2018-11-133-0/+594
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Add nullability annotations for some Map types."Treehugger Robot2018-11-135-0/+433
|\ \
| * | Add nullability annotations for some Map types.Pete Gillin2018-11-135-0/+433
| |/ | | | | | | | | | | | | | | | | | | 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
* / Add nullability annotations to several Collection types.Pete Gillin2018-11-0712-0/+998
|/ | | | | | | | | | | 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
* Merge "Add nullability annotations for j.u.regex.Matcher and Pattern."Treehugger Robot2018-11-062-0/+180
|\
| * Add nullability annotations for j.u.regex.Matcher and Pattern.Pete Gillin2018-11-022-0/+180
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Add nullability annotations to some j.u.Locale and Calendar."Treehugger Robot2018-11-062-0/+592
|\ \
| * | Add nullability annotations to some j.u.Locale and Calendar.Pete Gillin2018-11-012-0/+592
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Add nullability annotations for java.logging.Level and Logger."Treehugger Robot2018-11-052-0/+247
|\ \
| * | Add nullability annotations for java.logging.Level and Logger.Pete Gillin2018-11-022-0/+247
| |/ | | | | | | | | | | | | | | | | | | | | 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
* / Add nullability annotations to java.security.MessageDigest.Pete Gillin2018-11-021-0/+72
|/ | | | | | | | | | | | | | | Points of note: - It is theoretically possible to construct an instance where the algorithm is null, but it seems clear that doing this is not intended, so this change treats it as @NonNull everywhere. (Forcing users to null-check the return of getAlgorithm(), for example, would not be helpful.) - This class itself does not prevent digest() returning a null array, but the jvadoc implies that it won't, so again this change treats it as @NonNull. Bug: 64930165 Test: make core-current-stubs-nullability-validation-check-nullability-warnings
* Merge "Add missing nullability annotations to java.lang."Treehugger Robot2018-10-257-43/+39
|\
| * Add missing nullability annotations to java.lang.Pete Gillin2018-10-237-43/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | This fills in all the missing annotations from partially-annotated classes in this package found during validation. Note that most of these are in the method/parameter annotation form which metalava currently expects. The exception is on arrays, where they are in strict type annotation form for forwards compatibility. Bug: 64930165 Test: treehugger Change-Id: I20e296ec6ce87dba89602958bee7e69f2e67f42e
* | Merge "Add nullability annotations to some java.io and nio classes."Pete Gillin2018-10-253-0/+368
|\ \
| * | Add nullability annotations to some java.io and nio classes.Pete Gillin2018-10-243-0/+368
| |/ | | | | | | | | | | Bug: 64930165 Test: treehugger Change-Id: Id0c7ed1c514d93c71e0474e2bcf21a34954215c8
* | Merge "Add nullability annotations to j.t.DateFormat and NumberFormat."Pete Gillin2018-10-252-0/+400
|\ \
| * | Add nullability annotations to j.t.DateFormat and NumberFormat.Pete Gillin2018-10-242-0/+400
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is one non-obvious choice here. DateFormat.setCalendar(null) does not fail, but it puts the object into a useless state (unless, I suppose, this is a subclass which overrides all the methods that read the field). DateFormat.getCalendar() does return null if it follows setCalendar(null). The best choice seems to be to annotate the parameter of setCalendar(Calendar) as @NonNull, since it is helpful to warn the user if they try to set to null; and to annotate the return type of getCalendar() as @NonNull also, since it would be unhelpful to tell users to check the value for null just because of this edge case. Bug: 64930165 Test: treehugger Change-Id: I35b390c9e120ac3c507fbe9bbd63891175525b95
* | Merge "Add nullability annotations for j.l.Throwable."Treehugger Robot2018-10-241-0/+71
|\ \
| * | Add nullability annotations for j.l.Throwable.Pete Gillin2018-10-241-0/+71
| |/ | | | | | | | | | | Bug: 64930165 Test: treehugger Change-Id: I1c77438fa4bd98f18e54a90450793a96d357dcd0
* | Merge "Add missing nullability annotations to java.lang.reflect."Pete Gillin2018-10-2410-81/+77
|\ \
| * | Add missing nullability annotations to java.lang.reflect.Pete Gillin2018-10-2410-81/+77
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | This fills in all the missing annotations from partially-annotated classes in this package found during validation. Note that most of these are in the method/parameter annotation form which metalava currently expects. The exception is on arrays, where they are in strict type annotation form for forwards compatibility. Bug: 64930165 Test: treehugger Test: re-run validation (in pending CL) Change-Id: I1686750f7a7d4b1a93345486da36b432458b9a75
* / Fix some nullability annotations on Map.Entry.Pete Gillin2018-10-231-4/+4
|/ | | | | | | | | 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
* Move .annotated.java files into an 'sdk' subdirectory.Pete Gillin2018-09-1842-0/+4540
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 03:24:19 +0000