A previous CL switched gobind to use the "source" importer so go
files using cgo can be type checked. However, CGO_ENABLED=1 also
have to be passed in for such files not be ignored.
Also add -tags ios to the gomobile test output missing from CL
99777.
Fixesgolang/go#24941
Change-Id: I868469af3061b82ab592899e365a8a90a0333e58
Reviewed-on: https://go-review.googlesource.com/108336
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When passing a refnum across the language barrier there is a small
window where a proxy object itself can be garbage collected, its
reference count go to 0 and the object be gone when the refnum
is dereferenced on the other side.
In Go the proxy object is pinned with runtime.KeepAlive. This CL
implements the same mechanism in Java by passing the proxy object to
native code, ensuring the Java GC can't reclaim it during the call.
Change-Id: I23824439012eb00f90d729f59d4846999f24f01f
Reviewed-on: https://go-review.googlesource.com/107095
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Android runs a finalizer watchdog that tracks the running time of
finalizers and throws an exception if any runs too long. Our
finalizers do very little work and as such are not affected by the
timeout. However, there has been reports, for example:
https://stackoverflow.com/questions/24021609/how-to-handle-java-util-concurrent-timeoutexception-android-os-binderproxy-fin
that the watchdog does not take into account periods where the device
goes to sleep in the middle of a finalizer run. So if a given app runs
in the background, the Java GC starts a finalizer and the device goes
to sleep before it returns, an exception will crash the app if the sleep
period extends the watchdog timeout.
The problem might be fixed on some newer version of Android, but the
problem is reported for as late as Android 6.
The suggested workaround is to use PhantomReferences and run a
background thread that take dead references off a ReferenceQueue and
perform cleanup.
This CL builds on the previous CL and splits up the Ref class so Refs
only reference counts Java objects, while a new class GoRef tracks Go
references. The Go references are wrapped in PhantomReferences that in
turn appear on a GoRefQueue to be cleaned up by a background (daemon)
Thread.
Change-Id: I04e3296b851999c612d3baf6a593cc044c2c5bdd
Reviewed-on: https://go-review.googlesource.com/106876
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Today, the Seq.Ref class has two purposes. For Java references,
Ref contains the refnum, a reference to the Java object and a
reference count. For Go references, Ref contains the refnum and
its finalizer makes sure to decrement the reference count on the Go
side.
The next CL will replace the use of finalizers with an explicit
ReferenceQueue of Go references, and the Ref class will no longer
be used for Go refences. To prepare for that, this CL pulls up the
construction of Go referencing Ref instances into the Seq.trackGoRef
function.
Change-Id: I9eefe238cd3fd1b661b2af11d331a2f61e31303b
Reviewed-on: https://go-review.googlesource.com/106875
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Before this change, binding unsupported basic types such as
uint failed with an error. Instead, add them to the list of
ignored types so that no error is generated and a comment is
generated explaining why the offending function, constant or
variable was skipped.
Unsigned integers are probably easy to support in ObjC, but
leave them unsupported for now.
While here, improve the printing of the ignored types in the
explaining comments.
Fixesgolang/go#24762
Change-Id: I0d9ab471b2245728270f6ee588f554d4a105d500
Reviewed-on: https://go-review.googlesource.com/105377
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Issue golang/go#24058 demonstrates a Go package that fails to build with
gomobile but builds successfully with a manually using the standalone NDK
toolchain. I haven't been able to figure out a set of CPPFLAGS/LDFLAGS
that fixes the build for 24058 so instead rework gomobile to use
standalone NDK toolchains.
Standalone toolchains fixes the 24058 build and is the official way
to build Android programs. So gomobile should be less affected by
future changes in the NDK toolchain internals.
Create the standalone toolchains with gomobile init.
With the new Go 1.10 build cache, the prebuild work by the gomobile
init command is useless. Use the opportunity to simplify init to
only creating NDK toolchains and, optionally, building OpenAL for
Android. With that, it is no longer necessary to use gomobile init
to build iOS apps and frameworks.
Fixesgolang/go#24058
Change-Id: I4692fcaa927e7076a6387d080ebc1726905afd72
Reviewed-on: https://go-review.googlesource.com/99875
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Move the benchmark support package to the testdata directory, just
like the other test packages.
Change-Id: Idc35ca973a7da78e8c8bb640ba60cfb947fbed5b
Reviewed-on: https://go-review.googlesource.com/101896
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
If ever the gobind tool switches to a source importer (see CL
99777), make sure import paths are without trailing slashes are
handled correctly.
Change-Id: Ib3ce15f8dcd53dce09a5bb183e4013a5deba39b4
Reviewed-on: https://go-review.googlesource.com/99776
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>
The gobind command is about to get more powerful and able to generate
complete and standalone bindings. Platform specific build tags based
on GOOS or GOARCH are now meaningless to generate bindings from, so
remove them from the test packages.
The tags mattered to the reverse bound packages, since the go tool can't
build them without the Go wrappers for the imported Java packages.
Before this CL, the `android` tag was used to fool the go tool since
the host GOOS is unlikely to be android.
A fix is to check in the generated Go wrappers, but since the
packages are for testing we don't want that. Instead, move the test
packages to the testdata directory so the go tool ignores them.
Change-Id: I57178e930a400f690ebd7a65758bed894eeb10b0
Reviewed-on: https://go-review.googlesource.com/99315
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Remove the android support library dependency.
The Android build system assumes at least one resource, so
add a dummy string.
Change-Id: I7223b75709f1aa5907e6d04bc656eea5503bb640
Reviewed-on: https://go-review.googlesource.com/94195
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The test in CL 87656 exposed the problem that an ObjC class C in
header C.h can't implement an interface I in I.h if I.h itself includes
C.h, resulting in an include cycle. Avoid the problem for now by
restricting the set of declared interfaces to the current package and
its imports. This is too strict, but simple and avoids any include
cycles.
Fixes the bind/objc SeqTest on iOS.
Change-Id: I2ff964593cb9e56994c42b68cc49eebe2f549217
Reviewed-on: https://go-review.googlesource.com/88818
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
If a Go struct or interface has the same name as its package class,
append an underscore to the generated Java class name.
Fixesgolang/go#23327.
Change-Id: Ib680af35c956801073a0effb510a3ed9bbb8b9d1
Reviewed-on: https://go-review.googlesource.com/87656
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Xcode 9 now enables CLANG_WARN_STRICT_PROTOTYPES by default.
This update ObjC function prototypes with no params from
FOUNDATION_EXPORT Something* DoSomething();
to
FOUNDATION_EXPORT Something* DoSomething(void);
Change-Id: I23b1d3e70a2ede2d2d77951ffe8a1a9598a1b7a0
Reviewed-on: https://go-review.googlesource.com/68970
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Convert Go documentation to JavaDoc tags (/** ... */).
Since the .aar file format doesn't support source files, gomobile
will create a package-sources.jar along with the main package.aar.
For Objective-C, JavaDoc-style comments seems to work as well,
judging by manual inspection of Xcode quick help.
Change-Id: I47fe5b6804681d459a873be37a44610d392166ef
Reviewed-on: https://go-review.googlesource.com/52330
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Declare all implemented interfaces in the protocol list of a bound
struct. This is the ObjC equivalent of similar functionality for
Java.
Change-Id: Ibaea881f57fecf8a0716d25ec925de43974fe0fe
Reviewed-on: https://go-review.googlesource.com/52010
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
For functions on the form
New<T>... (...) *T
or
New<T>... (...) (*T, error)
generate corresponding initializers. The name of an initializer is
the function name where "New<T>" is replaced by "init".
If no functions match for a type *T, generate a default (empty)
initializer that returns new(T). The default initializer mirrors
the default constructor in Java.
Fixesgolang/go#20254.
Change-Id: I3c317418fa517d3f2de3f67f400867285b11ea4f
Reviewed-on: https://go-review.googlesource.com/52012
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The name replacement is done in asMethod.
Change-Id: I9aedf1231c0563f53e3a34f29197e106c090ee6e
Reviewed-on: https://go-review.googlesource.com/51871
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Currently the generated bindings assume that any object
passed to Go as a method argument is actually a valid one
originating from Go. The `null` object is however a corner
case to this assumption, which should be accepted for Go
pointer types, since they can cleanly convert into `nil`.
This CL modifies the generated wrapper code so any `nil`
reference is permitted for Go pointer types, which until
now produced a nil pointer dereference error.
Fixesgolang/go#20330
Change-Id: If1ab9cf9df7ac3808486d23ccf2db8d32fb89426
Reviewed-on: https://go-review.googlesource.com/43253
Reviewed-by: Elias Naur <elias.naur@gmail.com>
The generator recently changed the default ObjC prefix to the empty
string but the benchmark wasn't changed accordingly (the benchmark
doesn't run in -short mode).
Fixesgolang/go#19048
Change-Id: Id8f63da787f399410ea86c13ee77eb3005d31f38
Reviewed-on: https://go-review.googlesource.com/37314
Reviewed-by: Andris Valums <eighttt@fastmail.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
If a wrapped Java class is missing at runtime, for example because
the app is running on an older Android version, the resulting class
not found exception would cause the app to crash. Fix it by ignoring
missing classes, allowing the app to avoid using them according to a
runtime version check.
Change-Id: I9138c4e2a905b180959306ecbb997695236ab273
Reviewed-on: https://go-review.googlesource.com/35853
Reviewed-by: David Crawshaw <crawshaw@golang.org>
With Go 1.8 to be released, runtime.KeepAlive is now necessary to
make sure a reference to a foreign object is not garbage collected
and finalized before we get a chance to increment its reference
count.
runtime.KeepAlive was introduced in Go 1.7 which is the minimum
version required by gomobile.
Change-Id: I32215f96e4f415ff9be7b979dd3677e067b8d201
Reviewed-on: https://go-review.googlesource.com/35954
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Bump the minimum required version of Go to 1.7.
This removes version specific code and makes sure users have the
latest mobile related fixes to Go applied. Also, this change is
necessary when runtime.KeepAlive is introduced in a later CL.
Change-Id: I8441a28aef7f645379fbd8f00edabe3c3fb219de
Reviewed-on: https://go-review.googlesource.com/35953
Reviewed-by: David Crawshaw <crawshaw@golang.org>
For Java classes implemented in Go, it is useful to take a Java instance
and extract its wrapped Go instance. For example, consider the
java.lang.Runnable implementation wrapping a Go function:
package somepkg
type GoRunnable struct {
lang.Runnable
f func()
}
Java methods that take a java.lang.Runnable cannot directly take a
*GoRunnable, so this CL adds a Unwrap method:
import gorun "Java/somepkg/GoRunnable"
...
r := gorun.New()
r.Unwrap().(*GoRunnable).f = func() { ... }
javapkg.Run(r)
The extra interface conversion is unfortunately needed to avoid
import cycles.
Change-Id: Ib775a5712cd25aa75a19d364a55d76b1e11dce77
Reviewed-on: https://go-review.googlesource.com/35295
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
Running go get golang.org/x/mobile/... results in errors because the
go tool fails to find the reverse generated Java ("Java/...") and
Objective-C ("ObjC/...") packages. Work around the errors by adding
the android and ios tags, respectively, to files importing those
packages.
The gobind gradle plugin is updated to pass along GOOS=android to
ensure the gobind tool continues to build Android reverse packages.
Fixesgolang/go#17750
Change-Id: Id66a3c6cdfe249c6ed494192eb12195d6509332f
Reviewed-on: https://go-review.googlesource.com/34956
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>
Before this CL, calling overloaded methods on reverse bound Java
classes and interfaces involved confusing and ugly name mangling.
If a set of methods with the same name differed only in argument count,
the mangling was simply adding the argument count to the name:
func F()
func F1(int32)
But if two or more methods had the same number of arguments, the type
had to be appended:
func (...) F() int32
func (...) F1(int32) (int32, error)
func (...) F__I(int32, int32)
func (...) F__JLjava_util_concurrent_TimeUnit_2(int64, concurrent.TimeUnit)
This CL sacrifices a bit of type safety and performance to regain the
convenience and simplicity of Go by resolving overloaded method dispatch
at runtime.
Overloaded Java methods are combined to one Go method that, when invoked,
determines the correct Java method variant at runtime.
The signature of the Go method is compatible with every Java method with
that name. For the example above, the single Go method becomes the most
general
func (...) F(...interface{}) (interface{}, error)
The method is variadic to cover function with a varying number of
arguments, and it returns interface{} to cover int32, int64 and no
argument. Finally, it returns an error to cover the variant that returns
an error. The generator tries to be specific; for example
func G1(int32) int32
func G2(int32, int32) int32
becomes
func G(int32, ...int32) int32
Overriding Java methods in Go is changed to use the Go parameter types to
determine to correct Java method. To avoid name clashes when overriding
multiple overloaded methods, trailing underscores in the method name are
ignored when matching Java methods. See the Get methods of GoFuture in
bind/testpkg/javapkg for an example.
Change-Id: I6ac3e024141daa8fc2c35187865c5d7a63368094
Reviewed-on: https://go-review.googlesource.com/35186
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL restructures function generation to match the way methods
are generated, to avoid two different code paths for a coming CL.
Change-Id: I5a4f15e51ea5df101f9aa419ed4170ab36506418
Reviewed-on: https://go-review.googlesource.com/35185
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The filepath package works on native paths, not package paths. Replace
it with the path package. Do it for Objective-C as well, for correctness.
No new tests; the existing reverse tests fails on Windows without
this CL.
Change-Id: I8963db992d4bed30e8828579fb83ecaf8c9d9ade
Reviewed-on: https://go-review.googlesource.com/35176
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Make the golang.org/x/mobile/bind/java buildable without CGO, and
replace the which tool with exec.LookPath. Both helps on Windows that
often don't have a C compiler available and no which command.
Found while testing external NDK use on Windows.
Change-Id: I6d3311aae3fa97acb61b5ab9bed334e4a608c386
Reviewed-on: https://go-review.googlesource.com/35174
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
This is the Objective-C version of a similar change to the Java
generaters, CL 34777.
This CL makes sure the types only implicitly referenced through method
parameters or return values are also reverse generated. In doing so,
the anonymous interface{} is never used by the reverse generator,
gaining type safety, removing a special case and making sure passing
values of implicit types can be passed across the language barrier.
To support implicit types, the Objective-C importer is changed to
extract the module of a type from the clang AST dump instead of
relying on the module implied by the Go reference (e.g.
ObjC/Foundation.NSString).
Change-Id: Ie9305f4cd9a9802decbd93f81cec84dd05af11ab
Reviewed-on: https://go-review.googlesource.com/34991
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The gomobile tool mishandled build tags in two ways, first by
ignoring tags for iOS, second by passing multiple tags along to
the go tool incorrectly. This CL fixes both.
Fixesgolang/go#18523Fixesgolang/go#18515
Change-Id: I28a49c1e23670adb085617d9f5fb5cd5e22a4b65
Reviewed-on: https://go-review.googlesource.com/34955
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is the Objective-C equivalent of CL 34776, generating reverse
wrappers for generated ObjC types. The implementation follows the same
strategy as the Java implementation: use the Go ast package to find
exported structs with embedded Objective-C types and synthesize their
types as if they were imported through clang.
In turn, the handling of the implicit "self" parameter changes in the
same way as well: the type of self parameters must be the wrapped type
for the generated type. For example:
func (d *GoNSDate) Description(self Foundation.NSDate) string
becomes
import gopkg "ObjC/Objcpkg"
func (d *GoNSDate) Description(self gopkg.GoNSDate) string
Change-Id: I26f838b06a622864be463f81dbb4dcae76f70f20
Reviewed-on: https://go-review.googlesource.com/34780
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The Objective-C bindings was recently changed to support the empty
name prefix and to use that as the default. This CLs changed the Java
generators in the same way, supporting the empty Java package and using
it as the default.
Change-Id: I857affce686c67638a2b6c4e1da5d6a88d7ba560
Reviewed-on: https://go-review.googlesource.com/34778
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, Java types that were only implicitly referenced
were represented as interface{}. However, if a value of such an
implicit type were passed to Java, a runtime crash would occur
because there would be no wrapper class to unwrap.
Fix this by generating implicit types, fixing the crashes,
gaining type safety, and removing the interface{} special case in
the generator.
While we're here, remove a redundant insert to the clsMap map in
java.go.
Change-Id: Ic50125da3d7cd6075899bf628d419b084c630490
Reviewed-on: https://go-review.googlesource.com/34777
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>
Before this CL, using the reverse bindings to access two Java packages
with the same last component would fail with a duplicate package import
error. This CL renames generated import statements to use unique
aliases.
Change-Id: I94696281e58f011f45811445cf81aea02af69c4f
Reviewed-on: https://go-review.googlesource.com/34774
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The return value of a JNI call is undefined when an exception was
raised during the call. To make sure comparisons with NULL works,
clear the value when an exception is raised.
No new tests; some devices, like the Samsung S2, crashes with the
existing tests without this CL.
Change-Id: I85eb983e9444fff1f05e0f83a0640d106280e54d
Reviewed-on: https://go-review.googlesource.com/34631
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Since generated names now have their package names prefixed, the
extra prefix, "Go", is both confusing and counter-productive to
making the generated ObjC code look like any other native code.
Change the default to the empty prefix, while preserving support
for an explicit prefix if needed.
This is a backwards incompatible change; to keep the old behaviour,
specify "-prefix Go" to the gobind or gomobile command.
While we're here, fix the Ivy example for the recent change in
error returns.
Change-Id: I7fef4a92a18ddadee972ccf359652e3b31624f33
Reviewed-on: https://go-review.googlesource.com/34643
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
