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>
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>
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>
Since the Go package name is already prefixed to generated ObjC
names, the empty extra prefix is useful. Support that by not reverting
to the default extra prefix, "Go", if -prefix "" is specified.
To avoid file name clashes with the Go header files, add ".objc" to
the ObjC-facing header names.
Change-Id: I559fe60d7474521617f23894af247c6019ff2a21
Reviewed-on: https://go-review.googlesource.com/33954
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Output every Java class, including the support classes, from gobind
-lang=java. In addition, replace Go package export data parsing with
converting from go/ast to go/types. That way, gobind can tolerate
unknown imports as long as the exported Go API doesn't use them.
In a follow-up CL, the gobind gradle plugin will use gobind for a first
pass to expose the generated Java classes to the android plugin.
Change-Id: I8134899ec818c7fee79e4d9df8afcae9dd679add
Reviewed-on: https://go-review.googlesource.com/30093
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>
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>
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>
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.
This has the advantage of relying entirely on the go tool for correctly
resolving and parsing dependencies of the package being bound. (For
example, a bound package can now depend on cgo.) It also removes a class
of bugs where the version of the loader we depend on can get out of sync
with the go tool. (For example, gobind now correctly handles vendor
dependencies.)
As a bonus, for packages with significant dependencies this approach
should also be noticeably faster as we do not need to parse and
typecheck all of the dependencies.
Change-Id: If9a431c137eae2071c1d89be88a4a6a61d6812fa
Reviewed-on: https://go-review.googlesource.com/16911
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Introduce options -javapkg and -prefix for gobind command.
The following generates java class Testpkg with package name com.example.
gobind -lang=java -javapkg=com.example testpkg
The following generates objective-c files where function and type names
are prefixed with ExampleTestpkg.
gobind -lang=objc -prefix=Example testpkg
As discussed in golang/go#9660 and golang/go#12245.
Gomobile support is not yet implemented.
Change-Id: Ib9e39997ce915580a5a2e25643c0c28373f27ee1
Reviewed-on: https://go-review.googlesource.com/13969
Reviewed-by: David Crawshaw <crawshaw@golang.org>
For some target languages, gobind will need to output multiple files.
(e.g. objective-c) -output flag is not compatible with such cases.
Change-Id: I6da6109ae75c3aaa7d7379d411df2bb14c88bbc2
Reviewed-on: https://go-review.googlesource.com/4120
Reviewed-by: David Crawshaw <crawshaw@golang.org>
