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>
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>
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 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, 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>
CL 24800 changed the error representation from strings to objects.
However, since native errors types are not immediately compatible
across languages, wrapper types were introduced to bridge the gap.
This CL remove those wrappers and instead special case the error
proxy types to conform to their language error protocol.
Specifically:
- The ObjC proxy for Go errors now extends NSError and calls
initWithDomain to store the error message.
- The Go proxy for ObjC NSError return the localizedDescription
property for calls to Error.
- The Java proxy for Go errors ow extends Exception and
overrides getMessage() to return the error message.
- The Go proxy for Java Exceptions returns getMessage whenever
Error is called.
The end result is that error values behave more like normal objects
across the language boundary. In particular, instance identity is
now preserved: an error passed across the boundary and back will
result in the same instance.
There are two semantic changes that followed this change:
- The domain for wrapped Go errors is now always "go".
The domain wasn't useful before this CL: the domains were set to
the package name of function or method where the error happened
to cross the language boundary.
- If a Go method that returns an error is implemented in ObjC, the
implementation must now both return NO _and_ set the error result
for the calling Go code to receive a non-nil error.
Before this CL, because errors were always wrapped, a nil ObjC
could be represented with a non-nil wrapper.
Change-Id: Idb415b6b13ecf79ccceb60f675059942bfc48fec
Reviewed-on: https://go-review.googlesource.com/29298
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Accept Java API interface types as arguments and return values from
bound Go package functions and methods. Also, allow Go structs
to extend Java classes and implement Java interfaces as well as override
and implement methods.
This is the third and final part of the implementation of the golang/go#16876
proposal.
Fixesgolang/go#16876
Change-Id: I6951dd87235553ce09abe5117a39a503466163c0
Reviewed-on: https://go-review.googlesource.com/28597
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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