Before this CL, generated Java classes or interfaces were inner
classes to the top package class. That is both unnecessary and creates
ugly class names. Instead, move every generated class and interface to its
own package level class.
NOTE: This is a backwards incompatible change and requires every client
of gomobile APIs to be updated to leave out the package class in the
type names. For example, the Go type
package pkg
type S struct {
}
now generates (with the default java package name go) a Java class named
go.pkg.S. The name before this CL was go.pkg.Pkg.S.
Also, change the custom java package to specify the package prefix and
not the full package as before. This is an unfortunate change needed
to avoid name clashes between two bound packages. On the plus side,
the change brings the custom package case closer to the default behaviour,
which is a commen prefix, "go.", and a distinct java package for every
Go package bound.
Change-Id: Iadfaad56e101d1caf7e2a05006f4d384859a20fe
Reviewed-on: https://go-review.googlesource.com/27436
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The change from using strings to objects for passing errors across
the language barrier broke the custom java package mode of gombile
bind. Fix it and add a runtime test to make sure it won't happen
again.
Fixesgolang/go#16262
Change-Id: Ia7f8afb79556798056f0755758052190081a2dbb
Reviewed-on: https://go-review.googlesource.com/24800
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Add a missing #include to declare the exported Go function
setContext, and replace old GNU-style struct initializers.
Change-Id: Id1660559236c39505a47368a700c8e0ad834cf6c
Reviewed-on: https://go-review.googlesource.com/24491
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
Proxies are an implementation detail, so make them private to hide
them from the public API.
Also, move the proxy classes out of its interface scope; classes
declared inside Java interfaces are always public and cannot be
declared otherwise. Use the lowercase "proxy" class prefix to
avoid name clashes with exported Go interfaces and structs.
Change-Id: Iae6a53ed4885b7899f2fa770b73c135f54ffb263
Reviewed-on: https://go-review.googlesource.com/21370
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Requiring user code to extend Go interface Stubs to be able to pass
Java objects to Go is clumsy and use up the single extend slot.
Instead, support (and enforce) java classes to implement translated
Go interface directly. This is similar to how ObjC works.
The stub classes are now gone, and users of gobind Java APIs need
to update their code to implement interfaces directly.
Change-Id: I880bb7c8e89d3c21210b2ab2c85ced8d7859ff48
Reviewed-on: https://go-review.googlesource.com/21313
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Each side of the language barrier maintains a map of reference numbers
to objects. Each entry has a reference count that exactly matches
the number of active proxy objects on the other side. When a reference
crosses the barrier, the count is incremented and when a proxy finalizer
is run, the count is decremented. If the count reaches 0, the reference
number and its object are removed from the map.
There is a possibility that a reference number is passed to the other
side, and the last proxy is then immediately garbage collected and
finalized. The reference counter then reaches 0 before the other side has
converted the reference number to its object, crashing the program.
This is possible in both Go/Java/ObjC but is most likely to happen in
ObjC because its own automatic reference count runtime frees objects
as soon as they are statically never referenced again.
Fix the race by always incrementing the reference count before sending
a reference across the barrier. When converting the reference back into
an object on the other side, decrement the counter again.
Only the new ObjC test fails without this fix, but I left the Java
counterpart in for good measure.
Change-Id: I92743aabec275b4a5b82b952052e7e284872ce02
Reviewed-on: https://go-review.googlesource.com/21311
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Java classes must explicitly declare implemented interfaces. Bind
already declares all such interfaces within each package. Expand
the set of interfaces to include all bound packages.
In addition, let Java interfaces extend all possible interfaces in
the same way as Java classes. To avoid circular references, only
let interfaces extend compatible interfaces with fewer methods.
Before, each package was imported in its own importer, breaking the
assumption of types.AssignableTo that identical packages have
identical *types.Package. Fix that by using one importer for all
bound packages, replacing package path equality checks with direct
equality checks.
While we're here, add missing arguments to a few error messages.
Change-Id: I5eb58972a3abe918862ca99d5a203809699a3433
Reviewed-on: https://go-review.googlesource.com/20987
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Warnings used to be invisible when running SeqTest.m through
go test. Treat warnings as errors and fix a bug that surfaced.
Change-Id: I81e7291635824cdb4a898c91db740f7aa10f3611
Reviewed-on: https://go-review.googlesource.com/21133
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The objc reference handling has bug on assigning different refnum
to the same ios object. The reason for this is that the
RefTracker _refs is not properly initialized thus incorrect
reference check in assignRefnumAndIncRefcount.
Change-Id: Id86423dcf378d11e9056bf7c7ecb646333a94a04
Reviewed-on: https://go-review.googlesource.com/21120
Reviewed-by: Elias Naur <elias.naur@gmail.com>
An extra struct initializer was left over from an earlier version
of the direct call conversion. Remove it.
Change-Id: I19c3eb3be7bf78378af47ea182931b0c24cdd34d
Reviewed-on: https://go-review.googlesource.com/21104
Reviewed-by: David Crawshaw <crawshaw@golang.org>
If a method or function refers to a type from an unbound package,
ignore it instead of reporting an error.
Change-Id: I689da63c1a0d1a3aa09220311d871c1f6f66208f
Reviewed-on: https://go-review.googlesource.com/20985
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Rename the refnum field, Num, to something much less likely to clash
with an interface method set.
Change-Id: If334966b2430f38118baded44461bd39298bafb0
Reviewed-on: https://go-review.googlesource.com/20983
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Bind attempts to generate bindings for everything a package exports,
generating an error for what it cannot handle.
For multiple bound packages, unexporting what should not be bound
is sometimes awkward or outright impossible.
Lacking the equivalent of Cgo's //export directory, this CL change
the behaviour of bind to simply ignore everything it can't generate
bindings for, even if otherwise exported. For every declaration it
ignores, a comment is generated instead, to help any confusion as
to why a particular export was not included.
Change-Id: I2c7a5bee0f19a58009293b4e5ac2c95687e62e80
Reviewed-on: https://go-review.googlesource.com/20651
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
ToRefNum only handles Go objects, but it can be passed foreign object
proxies as well. Add a check whether the object is a proxy, and if so,
simply return its refnum and don't track it.
Change-Id: Ib17bd11b48e472c3bec0e5fb06661b201c3dfa97
Reviewed-on: https://go-review.googlesource.com/20681
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
It was generated once per bound package before, but since it is
constant it belongs in seq.h.
Change-Id: I7d920e8e87ce11cc9ae5e5e410dd935bc6e53480
Reviewed-on: https://go-review.googlesource.com/20657
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Bind generates a default toString for Go structs. If the struct has
a String() string method, use that instead.
Change-Id: If83a6f5c9ad03abbd0b939b9120ff8dd2135f713
Reviewed-on: https://go-review.googlesource.com/20656
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Make sure that a bound package's imported and also bound packages
are initialized before referencing methods and constructors in the
imported packages.
Change-Id: If158aac83c245a33695d3b1648d0dfc37a7313ac
Reviewed-on: https://go-review.googlesource.com/20652
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Before, bind always used the currently bound package for all JNI type
descriptors. Now, the type's package is used, which is important
when referencing other bound packages.
Change-Id: If36a45785f7333072803f1e7a8ff28b39fa57d0f
Reviewed-on: https://go-review.googlesource.com/20650
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Fix the tests that CL 20575 broke.
Change-Id: Id4059547c289c693ed4cfda6f748209d3e7f8658
Reviewed-on: https://go-review.googlesource.com/20620
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>
Also, upgrade the android plugin version used for java/seq_test
from 1.2.3 to 1.5.0
For golang/go#9603
Change-Id: I7b465ff0e607319a08150c4405675832d91edc1e
Reviewed-on: https://go-review.googlesource.com/20411
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
cgoType panics on types not yet supported by bind. Replace the panics
with more appropriate error messages.
Change-Id: I0b8609b50de07ca93db13c50654f62ffbd9f25c2
Reviewed-on: https://go-review.googlesource.com/20472
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Currently there is a Go test package for each platform, iOS and
Android. This CL merges them into a single, shared package. Apart
from the reduced code duplication, the merger stops the tests
diverging further. Most importantly, one shared package clarifies
that the intent of gobind is that the same Go package can be
reused across platforms.
This CL only merges the obvious test duplicates. The rest have been
copied from the ObjC package into the Android test under different
names.
While we're here, demote the long string test to the basictypes
bind test; the test never had a runtime part.
Change-Id: I7838b16999968fae7b012016a5b5f6bb80f94023
Reviewed-on: https://go-review.googlesource.com/20300
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Add a XCTestCase based ObjC driver, SeqTest.m, to run the benchmarks
package on iOS.
While we're here, replace "Java" with "Foreign" in test names to
reflect that benchmarks run on both platforms now.
Change-Id: I38a38f3093b4b97961107b5ea66f03cff8e395c3
Reviewed-on: https://go-review.googlesource.com/20259
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Replace test.bash with go test that builds and run the bind tests
through the XCode testing framework.
Running on the iOS emulator unmasked a bug where autorelease pools
were not in place for Go calls into ObjC, leaking autoreleased
objects. Fix that by adding autoreleasepool blocks to the tracker
finalizer callback and to every generated ObjC proxy.
Will not run on the emulator without CL 19206.
Change-Id: I6a775f9995f3b8ea50272982069d033e41ddcb7b
Reviewed-on: https://go-review.googlesource.com/20255
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
LOG_FATAL already throws an exception on iOS. Make it abort() on
Android, so that any fatal error will hopefully end up with a useful
log instead of an easily missed message in logcat.
Also, remove return statements after LOG_FATAL on both platforms.
They're unnecessary and confusing and they weren't used consistently
anyway.
Change-Id: I2a8e2e0ac064e95f52ca130de17265c9741cefe4
Reviewed-on: https://go-review.googlesource.com/20257
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Converting a Go string to a string suitable use a specialized function,
UTF16Encode, that can encode the string directly to a malloc'ed buffer. That
way, only two copies are made when strings are passed from Go to Java; once
for UTF-8 to UTF-16 encoding and once for the creation of the Java String.
This CL implements the same optimization in the other direction, with a
UTF-16 to UTF-8 decoder implemented in C. Unfortunately, while calling into a
Go decoder also saves the extra copy, the Cgo overhead makes the calls much
slower for short strings.
To alleviate the risk of introducing decoding bugs, I've added the tests from
the encoding/utf16 package to SeqTest.
As a sideeffect, both Java and ObjC now always copy strings, regardless of
the argument mode. The cpy argument can therefore be removed from the string
conversion functions. Furthermore, the modeRetained and modeReturned modes
can be collapsed into just one.
While we're here, delete a leftover function from seq/strings.go that
wasn't removed when the old seq buffers went away.
Benchmarks, as compared with benchstat over 5 runs:
name old time/op new time/op delta
JavaStringShort 11.4µs ±13% 11.6µs ± 4% ~ (p=0.859 n=10+5)
JavaStringShortDirect 19.5µs ± 9% 20.3µs ± 2% +3.68% (p=0.019 n=9+5)
JavaStringLong 103µs ± 8% 24µs ± 4% -77.13% (p=0.001 n=9+5)
JavaStringLongDirect 113µs ± 9% 32µs ± 7% -71.63% (p=0.001 n=9+5)
JavaStringShortUnicode 11.1µs ±16% 10.7µs ± 5% ~ (p=0.190 n=9+5)
JavaStringShortUnicodeDirect 19.6µs ± 7% 20.2µs ± 1% +2.78% (p=0.029 n=9+5)
JavaStringLongUnicode 97.1µs ± 9% 28.0µs ± 5% -71.17% (p=0.001 n=9+5)
JavaStringLongUnicodeDirect 105µs ±10% 34µs ± 5% -67.23% (p=0.002 n=8+5)
JavaStringRetShort 14.2µs ± 2% 13.9µs ± 1% -2.15% (p=0.006 n=8+5)
JavaStringRetShortDirect 20.8µs ± 2% 20.4µs ± 2% ~ (p=0.065 n=8+5)
JavaStringRetLong 42.2µs ± 9% 42.4µs ± 3% ~ (p=0.190 n=9+5)
JavaStringRetLongDirect 51.2µs ±21% 50.8µs ± 8% ~ (p=0.518 n=9+5)
GoStringShort 23.4µs ± 7% 22.5µs ± 3% -3.55% (p=0.019 n=9+5)
GoStringLong 51.9µs ± 9% 53.1µs ± 3% ~ (p=0.240 n=9+5)
GoStringShortUnicode 24.2µs ± 6% 22.8µs ± 1% -5.54% (p=0.002 n=9+5)
GoStringLongUnicode 58.6µs ± 8% 57.6µs ± 3% ~ (p=0.518 n=9+5)
GoStringRetShort 27.6µs ± 1% 23.2µs ± 2% -15.87% (p=0.003 n=7+5)
GoStringRetLong 129µs ±12% 33µs ± 2% -74.03% (p=0.001 n=10+5)
Change-Id: Icb9481981493ffca8defed9fb80a9433d6048937
Reviewed-on: https://go-review.googlesource.com/20250
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>
Address comment from CL/20095.
Change-Id: I2b3b3230106ad27128440609472003c69bd97825
Reviewed-on: https://go-review.googlesource.com/20173
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Since the normal Go benchmark machinery cannot readily be used for
Android apps, a new test, TestJavaSeqBench, is added that builds and
runs the new benchmarkpkg package along with its support Java class
SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it
produces benchcmp compatible output.
Excerpts of the output from a Nexus 5:
BenchmarkJavaEmpty 65536000 26 ns/op
BenchmarkJavaNoargs 256000 7685 ns/op
BenchmarkJavaNoargsDirect 64000 17405 ns/op
BenchmarkJavaOnearg 64000 26887 ns/op
BenchmarkJavaOneret 32000 38325 ns/op
BenchmarkJavaManyargs 32000 41720 ns/op
BenchmarkJavaRefjava 32000 38139 ns/op
BenchmarkJavaRefgo 32000 34403 ns/op
BenchmarkJavaStringShort 32000 32366 ns/op
BenchmarkJavaStringLong 8000 127879 ns/op
BenchmarkJavaSliceShort 32000 42462 ns/op
BenchmarkJavaSliceLong 8000 138391 ns/op
BenchmarkGoEmpty 524288000 3 ns/op
BenchmarkGoNoarg 32000 40342 ns/op
BenchmarkGoOnearg 32000 43529 ns/op
BenchmarkGoOneret 32000 45456 ns/op
BenchmarkGoRefjava 32000 55111 ns/op
BenchmarkGoRefgo 32000 57038 ns/op
BenchmarkGoManyargs 16000 67967 ns/op
BenchmarkGoStringShort 32000 57538 ns/op
BenchmarkGoStringLong 8000 128485 ns/op
BenchmarkGoSliceShort 32000 59279 ns/op
BenchmarkGoSliceLong 4000 411225 ns/op
Benchmarks prefixed with "BenchmarkJava" are for calls from Java into
Go. Benchmarks prefixed with "BenchmarksGo" are the other way around.
Note that all Go benchmarks run against a Java interface implementation
while the Java benchmarks calls Go functions directly. In other words,
every Go call serializes an implicit Java reference, explaining the
higher call times. The JavaRefgo and JavaRefjava tests attempt to
quantify the overhead equivalent for Java.
The "Direct" suffix are for variants that runs the benchmarks from a
new thread or goroutine. For Go it makes little difference, but there
is a noticable speedup when calling Go from Java when there is already
a JNI call context earlier in the stack.
The benchmarks are for Android only for now, but the benchmarkpkg
has been added to the common golang.org/x/mobile/bind package in
anticipation of future iOS support.
Change-Id: I3c948dc710b65bc348e7635416324095060a5beb
Reviewed-on: https://go-review.googlesource.com/20095
Reviewed-by: David Crawshaw <crawshaw@golang.org>
RefMap tracks its number of live Ref instances in the 'live' member.
However, when a reference was removed and later added, 'live' wasn't
updated accordingly. Fix and add a test.
Change-Id: I806e17ea0319d76db4d07b5f8d9107b146ee80db
Reviewed-on: https://go-review.googlesource.com/19975
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
On some Android devices (my HTC One S running Android 4.1.1),
SeqTest failed the testAssets test because the LoadJNI hack to
locate a valid context fails.
Instead, make testAssets set up a valid context acquired from
InstrumentTestCase.
Change-Id: If6e11173dbacff45eb6cb0f409f56cbd88186e30
Reviewed-on: https://go-review.googlesource.com/19896
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Avoid taking a good name (seq) away from users.
Fixesgolang/go#14168
Change-Id: I88e90cb74b479e348c642a1caa27096ed4a6d68e
Reviewed-on: https://go-review.googlesource.com/19601
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The existing implementation has memory leaks on two local variables
that are not deleted after use. Android app will crash after this issue.
add UnitTest for this issue.
Fixesgolang/go#14346
Change-Id: Ic233d15556ac97b35e00e13279a572c48a03049f
Reviewed-on: https://go-review.googlesource.com/19532
Reviewed-by: Elias Naur <elias.naur@gmail.com>
The Seq Java class has a special case for null references. Expand
the special case to Go so that null references from Java are properly
translated to nil.
Fixesgolang/go#14228
Change-Id: I915d1f843c9db299d6910480f6d10dae0121a3b4
Reviewed-on: https://go-review.googlesource.com/19460
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Java methods from Go are run on a thread pool managed on the Java side,
to avoid the complexities of getting Go threads to play along with the
Android JVM. However, for call stacks that contain a Java->Go->Java
chain, this behaviour confuses Java code sensitive to specific threads
if the Go->Java call is executed on an arbitrary thread from the pool.
For example, most Android UI changes must happen on the single UI
thread.
Replace the thread pool with direct calls to mimic ObjC<->Go and
Java->Go calls. Threads not already attached to the JVM are attached.
Introduce a thread local variable to detach such threads at thread exit.
Change-Id: I8cb65803c9278666ae77a0c7a65dc2d9c7e739e1
Reviewed-on: https://go-review.googlesource.com/19334
Reviewed-by: David Crawshaw <crawshaw@golang.org>
To implement an interface in Java the interface type must be listed
in the class declaration. Emulate the implicit Go interface
implementations in Java by listing all possible (non-empty) interfaces.
For example, given
type (
S struct{}
I interface {
M()
}
)
func (s *S) M() {
}
in Go, the Java class S will be declared to implement the Java
interface I.
Fixes a TODO.
Change-Id: I5b0d2dd65938004ab29029f481cace4b8fb4b26f
Reviewed-on: https://go-review.googlesource.com/19417
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
An inspection of the RefTracker inc and dec methods suggests
that a particular Java Stub instance is included in the javaObjs
map if and only if its reference count, refcnt, is larger than zero.
A newly created reference created by RefTracker.createRef has zero
refcnt but was also inserted in the javaObjs map, violating the invariant.
Fix that by not inserting new references in javaObjs. Without the fix
a Stub instance that were never passed to Go would leak, along with
any other instances it referenced, transitively.
This fixes a Java reference tracking problem, I have not verified if
the same problem applies to the Go and ObjC sides of the Seq machinery.
Change-Id: I3ede90d5258630bc837fe61bba850df222d09a26
Reviewed-on: https://go-review.googlesource.com/19261
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This allows reuse of the code in custom gomobile bind tools.
Change-Id: I4e013ca871d0fa64983e7efb5e1e9dad8ac723c0
Reviewed-on: https://go-review.googlesource.com/18581
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Fixes the bug in 64bit platforms.
Change-Id: I499995d69db03d136dcb2ca7f930ba1e309c8b6d
Reviewed-on: https://go-review.googlesource.com/19070
Reviewed-by: David Crawshaw <crawshaw@golang.org>
not harmful, but this consistency may simplify cgo handling
in some custom build systems
Change-Id: Id4692986725b3737c23cdeb9ce1a1fa2bc9f7dad
Reviewed-on: https://go-review.googlesource.com/18615
Reviewed-by: David Crawshaw <crawshaw@golang.org>
