Gobind uses strings for passing errors across the language barrier.
However, since Gobind doesn't have a concept of a nil string, it
can't separate an empty native string from a nil string.
In turn, that means that empty errors, exceptions or NSError * with
an empty description are treated as no error. With ObjC, empty errors
are replaced with a default string to workaround the issue, while
with Java empty errors are silently ignored.
Fix this by replacing strings with actual error objects, wrapping
the Go error, Java Throwable or ObjC NSError *, and letting the
existing bind machinery take care of passing the references across.
It's a large change for a small corner case, but I believe objects
are a better fit for exception that strings. Error objects also
naturally leads to future additions, for example accessing the
exception class name or chained exception.
Change-Id: Ie03b47cafcb231ad1e12a80195693fa7459c6265
Reviewed-on: https://go-review.googlesource.com/24100
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Multiple packages are already supported, but only as if each packages
were bound in isolation. This CL lets a bound package refer to other
bound packages in its exported functions, types and fields.
In Java, the JNI class jclass and constructor jmethodID are exported
so other packages can construct proxies of other packages' interfaces.
In ObjC, the class @interface declarations are moved from the package
.m file to its .h file to allow other packages to constructs its
interface proxies.
Add a supporting test package, secondpkg, and add Java and ObjC tests
for the new cross package functionality. Also add simplepkg for
testing corner cases where the generated Go file must not include its
bound package.
While we're here, stop generating Go proxy types for struct types;
only Go interfaces can be implemented in the foreign language.
Change-Id: Icbfa739c893703867d38a9100ed0928fbd7a660d
Reviewed-on: https://go-review.googlesource.com/20575
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The seq serialization machinery is a historic artifact from when Go
mobile code had to run in a separate process. Now that Go code is running
in-process, replace the explicit serialization with direct calls and pass
arguments on the stack.
The benefits are a much smaller bind runtime, much less garbage (and, in
Java, fewer objects with finalizers), less argument copying, and faster
cross-language calls.
The cost is a more complex generator, because some of the work from the
bind runtime is moved to generated code. Generated code now handles
conversion between Go and Java/ObjC types, multiple return values and memory
management of byte slice and string arguments.
To overcome the lack of calling C code between Go packages, all bound
packages now end up in the same (fake) package, "gomobile_bind", instead of
separate packages (go_<pkgname>). To avoid name clashes, the package name is
added as a prefix to generated functions and types.
Also, don't copy byte arrays passed to Go, saving call time and
allowing read([]byte)-style interfaces to foreign callers (#12113).
Finally, add support for nil interfaces and struct pointers to objc.
This is a large CL, but most of the changes stem from changing testdata.
The full benchcmp output on the CL/20095 benchmarks on my Nexus 5 is
reproduced below. Note that the savings for the JavaSlice* benchmarks are
skewed because byte slices are no longer copied before passing them to Go.
benchmark old ns/op new ns/op delta
BenchmarkJavaEmpty 26.0 19.0 -26.92%
BenchmarkJavaEmptyDirect 23.0 22.0 -4.35%
BenchmarkJavaNoargs 7685 2339 -69.56%
BenchmarkJavaNoargsDirect 17405 8041 -53.80%
BenchmarkJavaOnearg 26887 2366 -91.20%
BenchmarkJavaOneargDirect 34266 7910 -76.92%
BenchmarkJavaOneret 38325 2245 -94.14%
BenchmarkJavaOneretDirect 46265 7708 -83.34%
BenchmarkJavaManyargs 41720 2535 -93.92%
BenchmarkJavaManyargsDirect 51026 8373 -83.59%
BenchmarkJavaRefjava 38139 21260 -44.26%
BenchmarkJavaRefjavaDirect 42706 28150 -34.08%
BenchmarkJavaRefgo 34403 6843 -80.11%
BenchmarkJavaRefgoDirect 40193 16582 -58.74%
BenchmarkJavaStringShort 32366 9323 -71.20%
BenchmarkJavaStringShortDirect 41973 19118 -54.45%
BenchmarkJavaStringLong 127879 94420 -26.16%
BenchmarkJavaStringLongDirect 133776 114760 -14.21%
BenchmarkJavaStringShortUnicode 32562 9221 -71.68%
BenchmarkJavaStringShortUnicodeDirect 41464 19094 -53.95%
BenchmarkJavaStringLongUnicode 131015 89401 -31.76%
BenchmarkJavaStringLongUnicodeDirect 134130 90786 -32.31%
BenchmarkJavaSliceShort 42462 7538 -82.25%
BenchmarkJavaSliceShortDirect 52940 17017 -67.86%
BenchmarkJavaSliceLong 138391 8466 -93.88%
BenchmarkJavaSliceLongDirect 205804 15666 -92.39%
BenchmarkGoEmpty 3.00 3.00 +0.00%
BenchmarkGoEmptyDirect 3.00 3.00 +0.00%
BenchmarkGoNoarg 40342 13716 -66.00%
BenchmarkGoNoargDirect 46691 13569 -70.94%
BenchmarkGoOnearg 43529 13757 -68.40%
BenchmarkGoOneargDirect 44867 14078 -68.62%
BenchmarkGoOneret 45456 13559 -70.17%
BenchmarkGoOneretDirect 44694 13442 -69.92%
BenchmarkGoRefjava 55111 28071 -49.06%
BenchmarkGoRefjavaDirect 60883 26872 -55.86%
BenchmarkGoRefgo 57038 29223 -48.77%
BenchmarkGoRefgoDirect 56153 27812 -50.47%
BenchmarkGoManyargs 67967 17398 -74.40%
BenchmarkGoManyargsDirect 60617 16998 -71.96%
BenchmarkGoStringShort 57538 22600 -60.72%
BenchmarkGoStringShortDirect 52627 22704 -56.86%
BenchmarkGoStringLong 128485 52530 -59.12%
BenchmarkGoStringLongDirect 138377 52079 -62.36%
BenchmarkGoStringShortUnicode 57062 22994 -59.70%
BenchmarkGoStringShortUnicodeDirect 62563 22938 -63.34%
BenchmarkGoStringLongUnicode 139913 55553 -60.29%
BenchmarkGoStringLongUnicodeDirect 150863 57791 -61.69%
BenchmarkGoSliceShort 59279 20215 -65.90%
BenchmarkGoSliceShortDirect 60160 21136 -64.87%
BenchmarkGoSliceLong 411225 301870 -26.59%
BenchmarkGoSliceLongDirect 399029 298915 -25.09%
Fixesgolang/go#12619Fixesgolang/go#12113Fixesgolang/go#13033
Change-Id: I2b45e9e98a1248e3c23a5137f775f7364908bec7
Reviewed-on: https://go-review.googlesource.com/19821
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
As discussed in golang/go#12245
Usage: gomobile bind [options] a.b.c x.y.z
For ObjC, gomobile bind will generate GoC.{h,m} and GoZ.{h,m}. If
-prefix=App is specified it will generate AppC.{h,m} and AppZ.{h,m}.
Tested on Darwin.
Change-Id: I6af8539a0fb7ed6256f3773efc514eff436014b4
Reviewed-on: https://go-review.googlesource.com/17475
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
As discussed in golang/go#12245
Usage: gomobile bind [options] a.b.c x.y.z
For java gobind and gomobile will generate go.c.C.java and go.z.Z.java.
If -javapkg=com.example is specified they will generate
com.example.C.java and com.example.Z.java.
Tested on Darwin.
Change-Id: Ia8e57c8fec7967131d55de71cc705d9e736ccca0
Reviewed-on: https://go-review.googlesource.com/17023
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Replace the vendored version of x/tools/go/loader with the standard
library's go/importer package. This reads the export data from
$GOPATH/pkg/pkgname.a instead of parsing and type checking the source
code. The "go install" subcommand is invoked just prior to reading
the export data to make sure the export data is up to date.
Not yet tested on darwin, but working for android builds.
Change-Id: I24aa60aa46b843d30bc5833e3035699900bf3df4
Reviewed-on: https://go-review.googlesource.com/16913
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Traditionally, framework bundles have title case names such as
CoreFoundation.framework and UIKIt.framework.
gomobile bind should generate framework bundles named similarly,
following this convention.
Change-Id: Ia6082ed351ddc6fc97e0435e24e5f79c5afbaea4
Reviewed-on: https://go-review.googlesource.com/15330
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Modulemaps allow users to use the import directives without
providing the specific header file but by using a module name
in Objective-C and Swift.
gomobile bind -target=ios golang.org/x/mobile/example/bind/hello
Add the generated framework to an Xcode project. You will be able
to import the library header and use the library by importing hello
in Swift.
import hello
// ...
hello.GoHelloGreetings("burcu");
In Objective-C, you will be able to import with the module name
similarly by using the import directive below.
#import hello
This CL also enables Go bindings to be used from Swift without an
Objective-C bridging header.
Fixesgolang/go#12422
Change-Id: I7c60349caad100861d0b642ddfa873d7ada47598
Reviewed-on: https://go-review.googlesource.com/15044
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Gobind -lang=objc generates code that assume use of ARC.
Set -fobjc-arc to explicitly enable ARC.
Change-Id: Ib0ec7b19773c112c01ed23cb00f1ec9d64946e6b
Reviewed-on: https://go-review.googlesource.com/14544
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Drops the time for `gomobile init` on my machine from 46s to 30s.
Change-Id: Iab89f2e1d1cee4b414dc2fb1c735b4167aef9036
Reviewed-on: https://go-review.googlesource.com/12641
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Tested manually, I can bind github.com/hyangah/ivy and include it
in an Xcode project.
Change-Id: I7dfa7828da7288841bc930d3e506ee97bf2ca520
Reviewed-on: https://go-review.googlesource.com/12388
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Tested:
go test golang.org/x/mobile/bind/java
gomobile bind -target={ios,android} github.com/hyangah/ivy
gobuild build -target={ios,android} golang.org/x/mobile/example/basic
(With various takes on -x and -v.)
Change-Id: I15c8f605490381feb6fefb482110f2a1c210529d
Reviewed-on: https://go-review.googlesource.com/12411
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The go command now has a -pkgdir flag, which specifies a directory
for all install output, including the standard library. Use it to
build the mobile compilers under $GOMOBILE, so that targets like
the iOS simulator (darwin/386) do not conflict with system targets.
The result is we no longer need GOROOT to be writable.
The iOS simulator now works with gomobile bind.
Fixesgolang/go#11342.
Change-Id: I0bc6378e0cb82e3175b2a1efe355e3ce39533649
Reviewed-on: https://go-review.googlesource.com/12303
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
First pass at bind support, simply produces .a/.h files.
In future CLs:
- Take the type defintion from seq.h and place it directly in the
generated header, breaking the user's dependency on seq.h.
Open question for future CLs:
- Should we create a framework directory?
If we bundle assets in the directory, can the asset package
find them automatically?
In 1.6: support multiple archives.
Change-Id: I7c3f655e7653018333e3ce3c89807edfcf62906d
Reviewed-on: https://go-review.googlesource.com/12199
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
