android: Convert java_deobfuscate.py to Java

build/android/stacktrace/BUILD.gn

Index: build/android/stacktrace/BUILD.gn
diff --git a/build/android/stacktrace/BUILD.gn b/build/android/stacktrace/BUILD.gn
new file mode 100644
index 0000000000000000000000000000000000000000..307cfa42dcabcbf12aacdf1ca4a5a0c915e35559
--- /dev/null
+++ b/build/android/stacktrace/BUILD.gn
@@ -0,0 +1,19 @@
+# Copyright 2017 The Chromium Authors. All rights reserved.

[Yaron, 2017/06/28 15:55:25]

Move to tools/android

[agrieve, 2017/06/29 01:59:20]

My intention is to have test_runner.py use this tool. We try to keep all
dependencies of build/ within build/ when possible so chrome sub-projects can
DEP in build/ and have it work without also having to track down other
dependencies.

+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+import("//build/config/android/rules.gni")
+
+java_binary("java_deobfuscate") {
+  main_class = "org.chromium.build.FlushingReTrace"
+  java_files = [ "java/org/chromium/build/FlushingReTrace.java" ]
+  deps = [
+    "//third_party/proguard:retrace_java",
+  ]
+  data = [
+    "$root_build_dir/lib.java/build/android/stacktrace/java_deobfuscate.jar",

[Yaron, 2017/06/28 15:55:25]

weird that you have to re-list jars and they aren't picked up by classpath?

[agrieve, 2017/06/29 01:59:20]

This is so that they will be available to swarming. There actually doesn't look
to be any existing precedent for running java_binaries on swarming that I can
see, and it's certainly arguable how it should work.

My thoughts:
- Don't want to have all java_library() declare themselves as data, because the
libraries don't know if they'll be needed at runtime
- Can't add classpath as data at the java_binary level because GN has no way to
express that
- We could use dist_jar() instead to package them all up as one jar, but there's
no existing logic for that, and I figured with just a few files it wasn't worth
it.

+    "$root_build_dir/lib.java/third_party/proguard/proguard.jar",

[jbudorick, 2017/06/28 16:11:38]

Shouldn't these two be handled by //third_party/proguard?

[agrieve, 2017/06/29 01:59:20]

If someone wanted to go the dist_jar() route, then no. Given there's no other
uses currently, and we may want the option of swapping out another proguard
version, probably does make sense to change... so, done!

+    "$root_build_dir/lib.java/third_party/proguard/retrace.jar",
+    "$root_build_dir/bin/java_deobfuscate",
+  ]
+}