| Age | Commit message (Collapse) | Author |
|---|
|
New annotation is tools/platform-compat/annotation/src/java/android/compat/annotation/UnsupportedAppUsage.java.
Existing annotations in libcore/ and frameworks/ will be deleted after the migration:
- libcore/dalvik/src/main/java/dalvik/annotation/compat/UnsupportedAppUsage.java
- frameworks/base/core/java/android/annotation/UnsupportedAppUsage.java
This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Exempt-From-Owner-Approval: +2 by owner, by vote lost on latest patch.
Change-Id: Ib5b7baa399cdc38da1d3ca622ba0ba26936b1b2d
|
|
This adds package-level mappings for libcore.*, sun.*, android.system,
dalvik.system, and org.json.
Test: treehugger
Bug: 130283485
Change-Id: I4f82d1fe316d4d0ac76951c43bdc08c69336a252
|
|
Since names cannot be null, get(null) is guaranteed to throw, so the
parameter to get() is declared @NonNull. Since opt(null) is guaranteed
to return null, the parameter to opt() is declared @Nullable. The
type-specific get* and opt* methods follow that pattern.
The overload of optString which takes a fallback actually does accept
a null fallback, and may return null if the fallback is null but not
otherwise. The most helpful thing seems to be to declare the fallback
parameter and the return type as both @NonNull since that is
presumably the common usage.
The toString() implementation does return null if a JSONException was
thrown during the processing. It seems like this shouldn't be possible
for a validly constituted instance, and forcing users to do null
checks on the returned String seems like it would not be helpful, so
the return value is annotated as @NonNull. (JSONStringer.toString also
returns null if its out field is zero length, but the preceding call
to writeTo(JSONStringer) will ensure that at least the { and } will
have been appended, so that can't happen.)
Test: make core-libart
Bug: 64930165
Change-Id: Ie5a8c6c212b86035a1daeff14b784a5ca9e0f626
|
|
Test: ensured that generated light grey list did not change
Bug: 117818301
Merged-In: Ifcdd4c815a2d8fc438290a5b3b9db669f5035145
Change-Id: I6bd92384b4c81d425961d0f9ef4b681271e36125
|
|
There's at least one test user that isn't trivial to
switch over so we can try to remove it from the API
later.
Bug: 113148576
Test: build only
Change-Id: If583e498f6c13caaca9e79db756a1c8e6a7bf387
|
|
The integration of OpenJDK 9 javac into the Android build system
requires non-libcore code to live in non-libcore packages, as
long as that code isn't considered part of the same module as
libcore at javac time.
This CL moves libcore test related classes out of such
packages; since libcore tests could already only test
public (as opposed to package private APIs), no change
other than the package name and imports is necessary.
Because many libcore tests already live below a top-level
package "libcore" (eg., the tests for java.util are in
libcore.java.util), this CL likewise prepends "libcore."
to the package names of affected classes. For classes
relating to libcore.* packages, this results in a package
name of the form "libcore.libcore.*".
Alternative considered but not pursued:
To compile the test classes without moving the out of a libcore
package, javac would need to consider them to be in the same
module as libcore. This would likely be possible via
javac --patch-module, but this has not been explored in detail
because:
- Most luni tests are already in a toplevel package libcore.*,
so this CL makes the test structure more consistent.
- Use of --patch-module would likely cause problems when running
tests under a runtime that implements the OpenJDK 9 module
system; for example, --patch-module cannot add exported
packages to the module, so any new packages added in tests
(such as the libcore.* packages of most existing luni tests)
would not be visible at test runtime.
- Having tests in different packages from code under tests makes
it more obvious (including to IDEs in which the code might be
edited as a single project) that these tests cannot access
package-private identifiers in the code under test.
Test: Treehugger
Test: "make cts" with EXPERIMENTAL_USE_OPENJDK9=true
passes with additional changes present locally
that have not yet been exported as CLs.
Test: CtsLibcoreTestCases
Bug: 68224249
Bug: 68932217 (tracks potential follow-up work)
Change-Id: Ib6b8e6f3bc87093bc219d2108e601163c6e334cd
|
|
Many users org.json have reported errors while trying to use extra
features available from the org.json project with the built in Android
JSON implementation. Updating the JSONException API will help with
integrating classes of the 2 code bases as well as allow better stack
traces from JSONException throws.
Test: Treehugger build succeeds.
Bug: 62898477
Change-Id: Id3f789f577a78b029b5ae4ba0551696f2c76b6d7
|
|
Bug: 28189207
Change-Id: I76b8cc270dbf1b63f43c0dcd6970a703ad040da4
|
|
Change-Id: I8f49c58f39dc5f4268c6b5718cab18ed26ac930a
|
|
There's no guarantee that Selector.open() returns something that's
in the java namespace. It depends on the provider.
Change-Id: I4e4b020ad9ccde4071300f3222c9db87bc27ee73
|
|
Throwing NumberFormatException for bad Unicode escapes was a bug.
The test I added when I fixed that was in a different file, and
apparently I didn't re-run these tests.
Bug: https://code.google.com/p/android/issues/detail?id=103641
Change-Id: I271063ef12eab1369e4ce4cbbb7dd00e15c9ce79
|
|
Only our documentation claims that any of the JSON code throws
NumberFormatException, and throwing JSONException seems much more in keeping
with the rest of the API (and makes it easier for callers to handle errors).
Bug: https://code.google.com/p/android/issues/detail?id=103641
Change-Id: I4f4ebfd983f4ccb2a1f266a0bfa5732174df26f6
|
|
Also, add type arguments to the old Iterator API.
Note that this is source incompatible with wrongly generified
code (example: "Iterator<Object> keys = jsonObject.keys();") but
is compatible with old code that didn't use any type arguments.
Users compiling against the new SDK might see compile breakages.
bug: https://code.google.com/p/android/issues/detail?id=63191
Change-Id: Idf2ef1889dccb4309c843ab073f67af648b09436
|
|
Javadoc referred to a hidden method via a {@link} tag.
Change-Id: I18fc8a05aacd17bdc5fffe4f08870aa3d6d47b93
|
|
It provides better semantics that accumulate. In particular,
the type of the mapping does not depend on the number of calls
to the function.
Change-Id: Ib8f9d229d8de72d57b25ff9d69c69a61215c2fd7
|
|
Changed the map type in JSONObject to a LinkedHashMap so that
its iteration order is well defined.
bug: 12476022
Change-Id: I8f2e40fd6bca5f776396aba4c9fde6e9d58f662e
|
|
Whitespace issues.
Change-Id: I12bf6134c9bdd060ab5362f97d2315471ecd7251
|
|
Bug: https://code.google.com/p/android/issues/detail?id=62539
Change-Id: If41b9afe801832ea796649d27b0af25657653684
|
|
The class documentation makes the difference between the 'get' and 'opt'
methods very clear, but it's less clear to anyone just looking at the
summary of methods.
Bug: https://code.google.com/p/android/issues/detail?id=60998
Change-Id: I17eeaea182a9dbad7be9fbd55086977b512b6fa8
|
|
Bug: https://code.google.com/p/android/issues/detail?id=55114
Change-Id: Ic2e010ac616f24dda7b8abced7eb2fc84dc7d50e
|
|
Bug: https://code.google.com/p/android/issues/detail?id=53461
Change-Id: I2b920fa8d63bcc8f1260669d72e33833bbd81ced
|
|
Bug: https://code.google.com/p/android/issues/detail?id=47878
Change-Id: I0cd05348708a2374a0e301f778bc2ed29cc38f94
|
|
I've left java.util.concurrent alone, since that's upstream code.
Change-Id: I349960aaddb78e55d4c336b58b637009db69ff98
|
|
Bug: http://code.google.com/p/android/issues/detail?id=18508
Change-Id: Ib992a0a4b22e340446abab14e4f32df5efcd0b49
|
|
When we reimplemented this API I broke consistency with
org.json. Bringing it back into line makes the implementation
more strict (my preference) and makes us consistent with
ourselves before this code was redone.
Bug: http://code.google.com/p/android/issues/detail?id=16411
Change-Id: I8c1b52e382ad91932d3cf9a5b346db58df4da7c6
|
|
Change-Id: Ie9dde4971e0a6a8dadd14af43d631158fc488cd8
|
|
Change-Id: I8347bc625480a1c37a1ed9976193ddfedeb00bbc
|
|
files.
I've deleted as many tests as possible that duplicated coverage in Harmony.
We're now running their tests directly against our codebase and having two
copies of every test is quite painful; particularly when the tests need
maintenance.
The AllTests files aren't necessary, our test harness can automatically find
tests and run them without external organization. This strategy is also more
reliable, since often the AllTests files are out of sync.
Change-Id: I3ee052f8839e9b146ba47f945812f5937d878110
|
|
Gentlemen, you may now set your editors to "strip trailing whitespace"...
Change-Id: I85b2f6c80e5fbef1af6cab11789790b078c11b1b
|
|
Neither the JSON RFC nor the documentation of Crockford's
implementation mention these comments, but somehow the
old parser used to support these. And so we shall also.
See bug 2571423.
Change-Id: I77d64c5ec53278d8df5fe1873404f1241320504b
|
|
Our behaviour is consistent with Crockford's.
The test confirms that the behaviour is consistent with the report
of that bug, which the submitter claims is not how it should behave.
http://code.google.com/p/android/issues/detail?id=7257
Change-Id: Ibace4bd995e3cbc8fb6c9dc509f8f4491865a647
|
|
Although this violates my longstanding style preference, it agrees
with almighty JJB's official ArrayList, which is Good Enough For Me.
Change-Id: I7b608c12e04d0b7789bfcabeab4b7347ad22baca
|
|
Change-Id: I3aced2607b48210f76887e0d42b591c098ce5db7
|
|
|
|
Change-Id: I5ec9df6a3a9baac8f4f498890cd35feff774737a
|
|
Change-Id: I9837cfd46684ac6d5b9ec4ac6809da3c3f61d57d
|
|
Change-Id: I277ec3b35a28802dd7b7f82c1f4bbadbd3cc4c65
|
|
Change-Id: I1b67bac70bd25220a619e6ebe61f7f1c6f316faa
|
|
Change-Id: Ife53082824f5916665f198d4b2fb863271841ce0
|
|
This implementation lacks documentation. I intend to write that after checking
it into the master branch. By not waiting we'll have more time to exercise the
code, if only in Google's own applications.
This passes all of my tests. I rewrote some of the tests to make Crockford's
implementation fail. The tests that fail on Crockford's implementation are:
JSONArrayTest
testEqualsAndHashCode equals() not consistent with hashCode()
testTokenerConstructorParseFail StackOverflowError
testStringConstructorParseFail StackOverflowError
JSONObjectTest
testOtherNumbers Object.put() accepted a NaN (via a custom Number class)
testMapConstructorWithBogusEntries JSONObject constructor doesn't validate its input!
JSONTokenerTest
testNextNWithAllRemaining off-by-one error?
testNext0 Returning an empty string should be valid
testNextCleanCommentsTrailingSingleSlash nextClean doesn't consume a trailing slash
assertNotClean The character line tabulation is not whitespace according to the JSON spec.
testNextToDoesntStopOnNull nextTo() shouldn't stop after \0 characters
testNextToConsumesNull nextTo shouldn't consume \0.
testSkipToStopsOnNull skipTo shouldn't stop when it sees '\0'
ParsingTest
testParsingLargeHexValues For input "0x80000000" Hex values are parsed as Strings if their signed value is greater than Integer.MAX_VALUE.
testSyntaxProblemUnterminatedArray Stack overflowed on input "["
Change-Id: I44c4a4a698a66bf043ed339d6bd804951e732cbf
|
|
Alongside development of these tests, I'm working on a new
cleanroom implementation. The self use test was written to
prevent me from self-using in a way that the original
implementation does not.
Change-Id: Ie617aca1978bd39d85b05e5c2c7bd657ed159dd6
|
|
|
|
|
|
|
|
|
|
|
