bind_test.go compares the generated Go files against golden files
checked in the repository. The bind package formats some of the
generated Go files, so any changes in the go formatter can break
the tests.
This change makes the test more robust by applying formatting based
on the currently used go version. Since a golden file often
includes multiple go files generated by the bind, the `gofmt`
function splits the golden file using the gobindPreamble marker
and then run format.Source for each chunk. In order to ease the
golden file splitting, this CL also moves the gobindPreamble
to the beginning of each generated file consistently.
It turned out bind omits formatting for some go files (generated
for reverse binding). That needs to be fixed but it is a much
bigger fix. Thus, in this CL, we apply the formatting on the
bind's output as well.
This CL also updates the gobindPreamble to follow the style guide
for generated code. https://golang.org/s/generatedcodeFixesgolang/go#34619
Change-Id: Ia2957693154face2848e051ebbb2373e95d79593
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/198322
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The Character.Subset Java class changed between JDK 8 and JDK 11
which is the default JDK on my system. To avoid the golden tests
depend on the JDK version, drop the reference to the Character.Subset
class.
The inner class case is covered by the bind/java runtime tests.
For the upcoming Android container builders.
Change-Id: I05897ff7de7970633176207305099153de2f208c
Reviewed-on: https://go-review.googlesource.com/c/163377
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The go tool requires either HOME or GOCACHE set, but tests invoking
go install only passed GOPATH. Pass the inherited environment as well.
While here, update the reverse generated java.go.golden file with
additions from the latest Android SDK.
Change-Id: I3567dcc30e588b20266e9ba01d17a0ee547919bc
Reviewed-on: https://go-review.googlesource.com/c/159677
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Go 1.10 was supposed to change the jclass JNI type to map to Go
uintptr, but failed to map the Android NDK definition until
recently.
There was a single instance in the reverse binding generator that
compared jclass values to nil. Change it to use 0 and cast the
jclass value to uintptr to ensure compatibility with older Go
releases.
Change-Id: Ifa22ed2db556220b7dfd0076b004bd8930219e08
Reviewed-on: https://go-review.googlesource.com/124915
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The gobind and gomobile bind tools have historically overlapped:
gobind outputs generated bindings, and gomobile bind will generate
bindings before building them. However, the gobind bindings were
never used for building and thus allowed to not be complete.
To simplify version control, debugging, instrumentation and build
system flexibility, this CL upgrades the gobind tool to be the
canonical binding generator and change gomobile bind to use gobind
instead of its own generator code.
This greatly simplifies gomobile bind, but also paves the way to skip
gomobile bind entirely. For example:
$ gobind -outdir=$GOPATH golang.org/x/mobile/example/bind/hello
$ GOOS=android GOARCH=arm64 CC=<ndk-toolchain>/bin/clang go build -buildmode=c-shared -o libgobind.so gobind
$ ls libgobind.*
libgobind.h libgobind.so
The same applies to iOS, although the go build command line is more
involved.
By skipping gomobile it is possible to freely customize the Android
or iOS SDK level or any other flags not supported by gomobile bind.
By checking in the generated source code, the cost of supporting
gomobile in a custom build system is also decreased.
Change-Id: I59c14a77d625ac1377c23b3213672e0d83a48c85
Reviewed-on: https://go-review.googlesource.com/99316
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Before this CL, with code such as
import "Java/some/pkg/Class"
...
Class.StaticFunc().DoSomething()
the reverse generator wouldn't find the the Java/some/pkg.Class
reference.
Change-Id: I1def4b54589fd1c123767ff59438c647cbced0cd
Reviewed-on: https://go-review.googlesource.com/35331
Reviewed-by: David Crawshaw <crawshaw@golang.org>
When wrapping Java exceptions, their toString() methods are called from
the wrapper's Error() method to satisfy the Go error interface. Make
sure toString() is always included, even if it never directly referenced
from bound packages.
Change-Id: I5653f6ad82afbe4b061e02a69d60453000288a83
Reviewed-on: https://go-review.googlesource.com/35189
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The tests was missing the generated code for the universe package
and some parts of the reverse generated code. Include it.
Change-Id: Id5e2f215c8f6f717c30377965255c4b64f31e923
Reviewed-on: https://go-review.googlesource.com/34992
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, the type of the implicit "this" parameter to Java methods
implemented in Go could only be a super class of the generated Java
class. For example, the following GoRunnable type is an implementation of
the Java interface java.lang.Runnable with a toString method:
package somepkg
import "Java/java/lang"
type GoRunnable struct {
lang.Runnable
}
func (r *GoRunnable) ToString(this lang.Runnable) string {
...
}
The "this" parameter is implicit in the sense that the reverse generator
automatically fills it with a reference to the Java instance of
GoRunnable.
Note that "this" has the type Java/java/lang.Runnable, not
Java/go/somepkg.GoRunnable, which renders it impossible to call Java
methods and functions that expect GoRunnable. The most practical example
of this is the Android databinding libraries.
This CL changes the implicit this parameter to always match the exact
type. In the example, the toString implementation becomes:
import gopkg "Java/go/somepkg"
func (r *GoRunnable) ToString(this gopkg.GoRunnable) string {
...
}
One strategy would be to simply treat the generated Java classes
(GoRunnable in our example) as any other Java class and import it
through javap. However, since the Java classes are generated after
importing, this present a chicken-and-egg problem.
Instead, use the newly added support for structs with embedded prefixed types
and synthesize class descriptors for every exported Go struct type.
Change-Id: Ic5ce4a151312bd89f91798ed4088c9959225b448
Reviewed-on: https://go-review.googlesource.com/34776
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Generate Cast functions that take a proxy for a Java class or interface,
and return a new proxy with the same reference. The Cast functions
panic if the underlying Java object is not an instance of the expected
type.
Change-Id: I08a5bf9a79139f0fac5dd102c7b028c8c989fc6d
Reviewed-on: https://go-review.googlesource.com/30095
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The ClassGen.genGo function always uses unsafe, contrary to what
the check in GenGo says. With this CL, generated code always
imports unsafe if there are any classes to be generated.
Change-Id: Ic807111a26e494b4941790830b1950bb8b1f73d5
Reviewed-on: https://go-review.googlesource.com/29873
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Using the new Java class analyzer API, scan the bound packages
for references to Java classes and interfaces and generate Go
wrappers for them.
This is the second part of the implementation of proposal golang/go#16876.
For golang/go#16876
Change-Id: I59ec0ebdae0081a615dc34d450f344c20c03f871
Reviewed-on: https://go-review.googlesource.com/28596
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Hana Kim
Elias Naur
Elias Naur