There was a discussion a year ago about making methods and types
lowercase in ObjC (https://github.com/golang/go/issues/12889),
which was done (https://go-review.googlesource.com/#/c/15780/),
alas the suggested Java lower casing was never addressed.
This CL converts all generated Java methods to lower case.
Change-Id: Ia2f28519bc59362877881636109ddfc651b24960
Reviewed-on: https://go-review.googlesource.com/28494
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
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>
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>
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>
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>
