Add a new class as an entry-point for Java reflection

android_webview/glue/java/src/com/android/webview/chromium/ReflectionEndPoint.java

Index: android_webview/glue/java/src/com/android/webview/chromium/ReflectionEndPoint.java
diff --git a/android_webview/glue/java/src/com/android/webview/chromium/ReflectionEndPoint.java b/android_webview/glue/java/src/com/android/webview/chromium/ReflectionEndPoint.java
new file mode 100644
index 0000000000000000000000000000000000000000..654389d765f10d45b2fbfd03bd46717916f66f8a
--- /dev/null
+++ b/android_webview/glue/java/src/com/android/webview/chromium/ReflectionEndPoint.java
@@ -0,0 +1,22 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package com.android.webview.chromium;

[Torne, 2017/03/20 13:35:49]

Let's introduce a new package for this since I suspect we'll end up with more
than one class (as soon as we need something non-static). Maybe
com.android.webview.chromium.reflection ?

[Nate Fischer, 2017/03/20 19:57:48]

done

+
+import org.chromium.android_webview.AwContentsStatics;
+import org.chromium.base.annotations.UsedByReflection;
+
+/**
+ * Entry points for reflection into Android WebView internals.
+ *
+ * Methods in this class are not guaranteed to remain, and may be removed when we no longer wish to

[Torne, 2017/03/20 13:35:49]

Might want to be a bit more explicit in the comment here: we will be able to
remove stuff from here, but we shouldn't change things in any other incompatible
way (i.e. behaviour shouldn't become drastically different), because we don't
want anyone doing version-based logic here.

[Nate Fischer, 2017/03/20 19:57:48]

done

+ * expose the functionality.
+ */
+@UsedByReflection("")

[Torne, 2017/03/20 13:35:49]

Since we want to keep everything here, it might be better to just add a wildcard
based on the class/package to the proguard config for webview, rather than using
@UsedByReflection which will get pretty repetitive. We can just keep all public
members here.

[Nate Fischer, 2017/03/20 19:57:48]

While I see the advantages to that, I'd still like to argue in favor of the
explicit @UsedByReflection:

 - Without the annotation, someone may be enticed to add their new static method
(perhaps a new API) to this class, simply to avoid proguard stripping it. The
annotation discourages this behavior, and encourages the programmer to find a
more appropriate class for their method.
 - Without the annotation, someone reading the code may be confused why the
method is never called. Best case, they waste time being needlessly confused;
worse case, they remove the method to "fix" the code.

Reflection should be limited, so I don't think the burden of @UsedByReflection
will be too great. I don't think we can rely on the package name here, as
programmers often overlook package names (I know I often do).

Perhaps I'm underestimating the scale of static reflection methods we'll need.
If you or Toby feel strongly about this, I will make the change.

+public class ReflectionEndPoint {

[Torne, 2017/03/20 13:35:49]

If we introduce a dedicated package for this then probably this class could be
called something more specific; maybe something like WebViewConfig (if we're
just going to have static configuration methods on it)

Not sure what's ideal though.

[Nate Fischer, 2017/03/20 19:57:48]

WebViewConfig SGTM. I'm open to other suggestions from Toby

+    @UsedByReflection("")
+    public static void disableSafeBrowsing() {
+        AwContentsStatics.setSafeBrowsingEnabled(false);
+    }
+}