2016-09-16 19:19:01 +02:00
|
|
|
// Copyright 2014 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
package java
|
|
|
|
|
|
|
|
import (
|
2017-01-01 22:43:46 +01:00
|
|
|
gopkg "Java/java"
|
2016-09-16 19:19:01 +02:00
|
|
|
"Java/java/io"
|
|
|
|
"Java/java/lang"
|
2017-01-01 19:55:42 +01:00
|
|
|
"Java/java/lang/System"
|
2016-12-26 20:47:09 +01:00
|
|
|
"Java/java/util/Spliterators"
|
2016-09-16 19:19:01 +02:00
|
|
|
"Java/java/util/concurrent"
|
|
|
|
)
|
|
|
|
|
|
|
|
type Runnable struct {
|
|
|
|
lang.Runnable
|
|
|
|
}
|
|
|
|
|
bind,cmd,internal: generate reverse bindings for exported Go structs
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>
2016-12-31 16:41:36 +01:00
|
|
|
func (r *Runnable) Run(this gopkg.Runnable) {
|
2016-09-16 19:19:01 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
type InputStream struct {
|
|
|
|
io.InputStream
|
|
|
|
}
|
|
|
|
|
|
|
|
func (_ *InputStream) Read() (int32, error) {
|
|
|
|
return 0, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewInputStream() *InputStream {
|
|
|
|
return new(InputStream)
|
|
|
|
}
|
|
|
|
|
|
|
|
type Future struct {
|
|
|
|
concurrent.Future
|
|
|
|
}
|
|
|
|
|
internal,bind: resolve overloaded methods at runtime
Before this CL, calling overloaded methods on reverse bound Java
classes and interfaces involved confusing and ugly name mangling.
If a set of methods with the same name differed only in argument count,
the mangling was simply adding the argument count to the name:
func F()
func F1(int32)
But if two or more methods had the same number of arguments, the type
had to be appended:
func (...) F() int32
func (...) F1(int32) (int32, error)
func (...) F__I(int32, int32)
func (...) F__JLjava_util_concurrent_TimeUnit_2(int64, concurrent.TimeUnit)
This CL sacrifices a bit of type safety and performance to regain the
convenience and simplicity of Go by resolving overloaded method dispatch
at runtime.
Overloaded Java methods are combined to one Go method that, when invoked,
determines the correct Java method variant at runtime.
The signature of the Go method is compatible with every Java method with
that name. For the example above, the single Go method becomes the most
general
func (...) F(...interface{}) (interface{}, error)
The method is variadic to cover function with a varying number of
arguments, and it returns interface{} to cover int32, int64 and no
argument. Finally, it returns an error to cover the variant that returns
an error. The generator tries to be specific; for example
func G1(int32) int32
func G2(int32, int32) int32
becomes
func G(int32, ...int32) int32
Overriding Java methods in Go is changed to use the Go parameter types to
determine to correct Java method. To avoid name clashes when overriding
multiple overloaded methods, trailing underscores in the method name are
ignored when matching Java methods. See the Get methods of GoFuture in
bind/testpkg/javapkg for an example.
Change-Id: I6ac3e024141daa8fc2c35187865c5d7a63368094
Reviewed-on: https://go-review.googlesource.com/35186
Reviewed-by: David Crawshaw <crawshaw@golang.org>
2017-01-16 14:08:12 +01:00
|
|
|
func (_ *Future) Get() (lang.Object, error) {
|
|
|
|
return nil, nil
|
2016-09-16 19:19:01 +02:00
|
|
|
}
|
|
|
|
|
internal,bind: resolve overloaded methods at runtime
Before this CL, calling overloaded methods on reverse bound Java
classes and interfaces involved confusing and ugly name mangling.
If a set of methods with the same name differed only in argument count,
the mangling was simply adding the argument count to the name:
func F()
func F1(int32)
But if two or more methods had the same number of arguments, the type
had to be appended:
func (...) F() int32
func (...) F1(int32) (int32, error)
func (...) F__I(int32, int32)
func (...) F__JLjava_util_concurrent_TimeUnit_2(int64, concurrent.TimeUnit)
This CL sacrifices a bit of type safety and performance to regain the
convenience and simplicity of Go by resolving overloaded method dispatch
at runtime.
Overloaded Java methods are combined to one Go method that, when invoked,
determines the correct Java method variant at runtime.
The signature of the Go method is compatible with every Java method with
that name. For the example above, the single Go method becomes the most
general
func (...) F(...interface{}) (interface{}, error)
The method is variadic to cover function with a varying number of
arguments, and it returns interface{} to cover int32, int64 and no
argument. Finally, it returns an error to cover the variant that returns
an error. The generator tries to be specific; for example
func G1(int32) int32
func G2(int32, int32) int32
becomes
func G(int32, ...int32) int32
Overriding Java methods in Go is changed to use the Go parameter types to
determine to correct Java method. To avoid name clashes when overriding
multiple overloaded methods, trailing underscores in the method name are
ignored when matching Java methods. See the Get methods of GoFuture in
bind/testpkg/javapkg for an example.
Change-Id: I6ac3e024141daa8fc2c35187865c5d7a63368094
Reviewed-on: https://go-review.googlesource.com/35186
Reviewed-by: David Crawshaw <crawshaw@golang.org>
2017-01-16 14:08:12 +01:00
|
|
|
// Use a trailing underscore to override multiple overloaded methods.
|
|
|
|
func (_ *Future) Get_(_ int64, _ concurrent.TimeUnit) (lang.Object, error) {
|
|
|
|
return nil, nil
|
2016-09-16 19:19:01 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
type Object struct {
|
|
|
|
lang.Object
|
|
|
|
}
|
2016-12-26 20:47:09 +01:00
|
|
|
|
|
|
|
func innerClassTypes() {
|
|
|
|
// java.util.Spliterators.iterator use inner class types
|
|
|
|
// for the return value as well as parameters.
|
internal,bind: resolve overloaded methods at runtime
Before this CL, calling overloaded methods on reverse bound Java
classes and interfaces involved confusing and ugly name mangling.
If a set of methods with the same name differed only in argument count,
the mangling was simply adding the argument count to the name:
func F()
func F1(int32)
But if two or more methods had the same number of arguments, the type
had to be appended:
func (...) F() int32
func (...) F1(int32) (int32, error)
func (...) F__I(int32, int32)
func (...) F__JLjava_util_concurrent_TimeUnit_2(int64, concurrent.TimeUnit)
This CL sacrifices a bit of type safety and performance to regain the
convenience and simplicity of Go by resolving overloaded method dispatch
at runtime.
Overloaded Java methods are combined to one Go method that, when invoked,
determines the correct Java method variant at runtime.
The signature of the Go method is compatible with every Java method with
that name. For the example above, the single Go method becomes the most
general
func (...) F(...interface{}) (interface{}, error)
The method is variadic to cover function with a varying number of
arguments, and it returns interface{} to cover int32, int64 and no
argument. Finally, it returns an error to cover the variant that returns
an error. The generator tries to be specific; for example
func G1(int32) int32
func G2(int32, int32) int32
becomes
func G(int32, ...int32) int32
Overriding Java methods in Go is changed to use the Go parameter types to
determine to correct Java method. To avoid name clashes when overriding
multiple overloaded methods, trailing underscores in the method name are
ignored when matching Java methods. See the Get methods of GoFuture in
bind/testpkg/javapkg for an example.
Change-Id: I6ac3e024141daa8fc2c35187865c5d7a63368094
Reviewed-on: https://go-review.googlesource.com/35186
Reviewed-by: David Crawshaw <crawshaw@golang.org>
2017-01-16 14:08:12 +01:00
|
|
|
Spliterators.Iterator(nil)
|
2016-12-26 20:47:09 +01:00
|
|
|
}
|
2017-01-01 19:55:42 +01:00
|
|
|
|
|
|
|
func returnType() {
|
|
|
|
// Implicit types (java.io.Console) should be wrapped.
|
|
|
|
cons := System.Console()
|
|
|
|
cons.Flush()
|
|
|
|
}
|