BASELINE: Update Chromium to 70.0.3538.78

Change-Id: Ie634710bf039e26c1957f4ae45e101bd4c434ae7
Reviewed-by: Michael Brüning <michael.bruning@qt.io>

1 files changed, 118 insertions, 60 deletions

diff --git a/chromium/styleguide/java/java.md b/chromium/styleguide/java/java.md
index 24f98a3b3c1..62647ecbcad 100644
--- a/chromium/styleguide/java/java.md
+++ b/chromium/styleguide/java/java.md
@@ -7,24 +7,128 @@ Chromium follows the [Android Open Source style
 guide](http://source.android.com/source/code-style.html) unless an exception
 is listed below.
 
-A checkout should give you clang-format to automatically format Java code.
-It is suggested that Clang's formatting of code should be accepted in code
-reviews.
-
 You can propose changes to this style guide by sending an email to
 `java@chromium.org`. Ideally, the list will arrive at some consensus and you can
 request review for a change to this file. If there's no consensus,
 [`//styleguide/java/OWNERS`](https://chromium.googlesource.com/chromium/src/+/master/styleguide/java/OWNERS)
 get to decide.
 
+[TOC]
+
+## Java 8 Language Features
+[Desugar](https://github.com/bazelbuild/bazel/blob/master/src/tools/android/java/com/google/devtools/build/android/desugar/Desugar.java)
+is used to rewrite some Java 7 & 8 language constructs in a way that is
+compatible with Java 6 (and thus all Android versions). Use of
+[these features](https://developer.android.com/studio/write/java8-support)
+is encouraged, but there are some gotchas:
+
+### Default Interface Methods
+ * Desugar makes default interface methods work by copy & pasting the default
+   implementations into all implementing classes.
+ * This technique is fine for infrequently-used interfaces, but should be
+   avoided (e.g. via a base class) if it noticeably increases method count.
+
+### Lambdas and Method References
+ * These are syntactic sugar for creating anonymous inner classes.
+ * Use them only where the cost of an extra class & method definition is
+   justified.
+
+### try-with-resources
+ * Some library classes do not implement Closeable on older platform APIs.
+   Runtime exceptions are thrown if you use them with a try-with-resources.
+   Do not use the following classes in a try-with-resources:
+   * java.util.zip.ZipFile (implemented in API 19)
+   * java.net.Socket (implemented in API 19)
+
+## Other Language Features & APIs
+
+### Exceptions
+* As with the Android style guide, we discourage overly broad catches via
+`Exception` / `Throwable` / `RuntimeException`.
+  * If you need to have a broad catch expression, use a comment to explain why.
+* Catching multiple exceptions in one line is fine.
+
+It is OK to do:
+```java
+try {
+  somethingThatThrowsIOException(filePath);
+  somethingThatThrowsParseException(filePath);
+} catch (IOException | ParseException e) {
+  Log.w(TAG, "Failed to read: %s", filePath, e);
+}
+```
+
+* Avoid adding messages to exceptions that do not aid in debugging.
+
+For example:
+```java
+try {
+  somethingThatThrowsIOException();
+} catch (IOException e) {
+  // Bad - message does not tell you more than the stack trace does:
+  throw new RuntimeException("Failed to parse a file.", e);
+  // Good - conveys that this block failed along with the "caused by" exception.
+  throw new RuntimeException(e);
+  // Good - adds useful information.
+  throw new RuntimeException(String.format("Failed to parse %s", fileName), e);
+}
+```
+
+### Logging
+* Use `org.chromium.base.Log` instead of `android.util.Log`.
+  * It provides `%s` support, and ensures log stripping works correctly.
+* Minimize the use of `Log.w()` and `Log.e()`.
+  * Debug and Info log levels are stripped by ProGuard in release builds, and
+    so have no performance impact for shipping builds. However, Warning and
+    Error log levels are not stripped.
+* Function calls in log parameters are *not* stripped by ProGuard.
+
+```java
+Log.d(TAG, "There are %d cats", countCats());  // countCats() not stripped.
+```
+
+### Asserts
+The Chromium build system strips asserts in release builds (via ProGuard) and
+enables them in debug builds (or when `dcheck_always_on=true`) (via a [build
+step](https://codereview.chromium.org/2517203002)). You should use asserts in
+the [same
+scenarios](https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md#CHECK_DCHECK_and-NOTREACHED)
+where C++ DCHECK()s make sense. For multi-statement asserts, use
+`org.chromium.base.BuildConfig.DCHECK_IS_ON` to guard your code.
+
+Example assert:
+
+```java
+assert someCallWithoutSideEffects() : "assert description";
+```
+
+Example use of `DCHECK_IS_ON`:
+
+```java
+if (org.chromium.base.BuildConfig.DCHECK_IS_ON) {
+  // Any code here will be stripped in Release by ProGuard.
+  ...
+}
+```
+
+### Other Android Support Library Annotations
+* Use them! They are [documented here](https://developer.android.com/studio/write/annotations).
+  * They generally improve readability.
+  * Some make lint more useful.
+* `javax.annotation.Nullable` vs `android.support.annotation.Nullable`
+  * Always prefer `android.support.annotation.Nullable`.
+  * It uses `@Retention(SOURCE)` rather than `@Retention(RUNTIME)`.
+
 ## Tools
 
 ### Automatically formatting edited files
+A checkout should give you clang-format to automatically format Java code.
+It is suggested that Clang's formatting of code should be accepted in code
+reviews.
 
 You can run `git cl format` to apply the automatic formatting.
 
-### IDE setup
-
+### IDE Setup
 For automatically using the correct style, follow the guide to set up your
 favorite IDE:
 
@@ -32,31 +136,29 @@ favorite IDE:
 * [Eclipse](https://chromium.googlesource.com/chromium/src/+/master/docs/eclipse.md)
 
 ### Checkstyle
-
 Checkstyle is automatically run by the build bots, and to ensure you do not have
 any surprises, you can also set up checkstyle locally using [this
 guide](https://sites.google.com/a/chromium.org/dev/developers/checkstyle).
 
 ### Lint
-
 Lint is run as part of the build. For more information, see
 [here](https://chromium.googlesource.com/chromium/src/+/master/build/android/docs/lint.md).
 
-## File Headers
-
-Use the same format as in the [C++ style guide](https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md#File-headers).
+## Style / Formatting
 
-## TODOs
+### File Headers
+* Use the same format as in the [C++ style guide](https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md#File-headers).
 
-TODO should follow chromium convention i.e. `TODO(username)`.
-
-## Code formatting
+### TODOs
+* TODO should follow chromium convention. Examples:
+  * `TODO(username): Some sentence here.`
+  * `TODO(crbug.com/123456): Even better to use a bug for context.`
 
+### Code formatting
 * Fields should not be explicitly initialized to default values (see
   [here](https://groups.google.com/a/chromium.org/d/topic/chromium-dev/ylbLOvLs0bs/discussion)).
 
 ### Curly braces
-
 Conditional braces should be used, but are optional if the conditional and the
 statement can be on a single line.
 
@@ -82,49 +184,7 @@ if (someConditional)
   return false;
 ```
 
-### Exceptions
-
-Similarly to the Android style guide, we discourage the use of
-`catch Exception`. It is also allowed to catch multiple exceptions in one line.
-
-It is OK to do:
-
-```java
-try {
-  somethingThatThrowsIOException();
-  somethingThatThrowsParseException();
-} catch (IOException | ParseException e) {
-  Log.e(TAG, "Failed to do something with exception: ", e);
-}
-```
-
-### Asserts
-
-The Chromium build system strips asserts in release builds (via ProGuard) and
-enables them in debug builds (or when `dcheck_always_on=true`) (via a [build
-step](https://codereview.chromium.org/2517203002)). You should use asserts in
-the [same
-scenarios](https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md#CHECK_DCHECK_and-NOTREACHED)
-where C++ DCHECK()s make sense. For multi-statement asserts, use
-`org.chromium.base.BuildConfig.DCHECK_IS_ON` to guard your code.
-
-Example assert:
-
-```java
-assert someCallWithoutSideEffects() : "assert description";
-```
-
-Example use of `DCHECK_IS_ON`:
-
-```java
-if (org.chromium.base.BuildConfig.DCHECK_IS_ON) {
-  // Any code here will be stripped in Release by ProGuard.
-  ...
-}
-```
-
 ### Import Order
-
 * Static imports go before other imports.
 * Each import group must be separated by an empty line.
 
@@ -145,7 +205,6 @@ This is enforced by the
 under the ImportOrder module.
 
 ## Location
-
 "Top level directories" are defined as directories with a GN file, such as
 [//base](https://chromium.googlesource.com/chromium/src/+/master/base/)
 and
@@ -170,5 +229,4 @@ much like
 [//base/android/OWNERS](https://chromium.googlesource.com/chromium/src/+/master/base/android/OWNERS).
 
 ## Miscellany
-
 * Use UTF-8 file encodings and LF line endings.