You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
jpobst opened this issue
Feb 13, 2023
· 0 comments
Labels
generatorIssues binding a Java library (generator, class-parse, etc.)proposalIssue raised for discussion, we do not even know if the change would be desirable yet
One of the key tenets of "slim bindings" is that you only bind the type(s)/method(s) that you need to use. Unfortunately this does not work for a normal binding project because your desired types likely derive from other unbound types or take unbound types as method parameters or return types.
Trying to bind just MapView would fail because it also needs the types: MapViewBase, MappableComponent, MapViewOptions, PinResult, and PinCoordinates. Binding each of those types may require further types, and you essentially end up needing to bind the entire library.
Slim Bindings
The way slim bindings fixes this is that you write a Java wrapper around the API you need that does not expose these custom types to C#. This may look something like:
In effect, it performs "type erasure" of custom types in order to bind the class.
One potential downside to this is that users must write a Java wrapper in order to expose the correct API, and many users may not know Java or would prefer to remain in C#.
Flutter's New jingen Bindings
Either as a conscious choice or because it is very early in development, jnigen does not expose any custom types in their bindings. Every non-primitive type is exposed as jni.JObject. (Their ~equivalent of Java.Lang.Object.)
So their binding of the above class would look like this (in a C#-looking language rather than dart):
Basically, they are performing the same "type erasure" that our slim bindings require.
Vaguely Typed Slim Bindings
Applying the automatic type erasure that jnigen does to our generator process would provide a nice "hybrid" approach:
Bindings could be generated automatically without the user needing to write and maintain a Java wrapper.
Binding everything as JLO would eliminate nearly all errors that prevent typed bindings from automatically working today:
Missing implementations of abstract base type methods
Missing implementations of interface methods
Covariant return type issues
Generics
Mismatched override signatures
The downside is that you lose all C#/compile time type checking and type checks are performed at runtime by Java. For this reason, it feels better to keep these as "slim bindings" that are used sparingly on a few types rather than binding an entire library without types.
Example:
// Works correctly:varactivity= my_activity;varmap_view=new MapView (activity,null);// Compiles, but throws a Java exception like IncompatibleClassException or something at runtimevarcontext= my_activity.Context;varmap_view=new MapView (context,null);
We would need a way to specify which types to bind, perhaps in MSBuild?
Inevitably you will need to work with some additional "real" types from a library. Consider the AddPin method, which requires a PinCoordinates parameter and returns a PinResult type.
Assuming they do not come from a typed binding of a dependency, we would need to additionally bind them:
The text was updated successfully, but these errors were encountered:
jpobst
added
generator
Issues binding a Java library (generator, class-parse, etc.)
proposal
Issue raised for discussion, we do not even know if the change would be desirable yet
labels
Feb 13, 2023
generatorIssues binding a Java library (generator, class-parse, etc.)proposalIssue raised for discussion, we do not even know if the change would be desirable yet
Background
One of the key tenets of "slim bindings" is that you only bind the type(s)/method(s) that you need to use. Unfortunately this does not work for a normal binding project because your desired types likely derive from other unbound types or take unbound types as method parameters or return types.
Example:
Trying to bind just
MapView
would fail because it also needs the types:MapViewBase
,MappableComponent
,MapViewOptions
,PinResult
, andPinCoordinates
. Binding each of those types may require further types, and you essentially end up needing to bind the entire library.Slim Bindings
The way slim bindings fixes this is that you write a Java wrapper around the API you need that does not expose these custom types to C#. This may look something like:
In effect, it performs "type erasure" of custom types in order to bind the class.
One potential downside to this is that users must write a Java wrapper in order to expose the correct API, and many users may not know Java or would prefer to remain in C#.
Flutter's New
jingen
BindingsEither as a conscious choice or because it is very early in development,
jnigen
does not expose any custom types in their bindings. Every non-primitive type is exposed asjni.JObject
. (Their ~equivalent ofJava.Lang.Object
.)So their binding of the above class would look like this (in a C#-looking language rather than dart):
Basically, they are performing the same "type erasure" that our slim bindings require.
Vaguely Typed Slim Bindings
Applying the automatic type erasure that
jnigen
does to ourgenerator
process would provide a nice "hybrid" approach:JLO
would eliminate nearly all errors that prevent typed bindings from automatically working today:override
signaturesThe downside is that you lose all C#/compile time type checking and type checks are performed at runtime by Java. For this reason, it feels better to keep these as "slim bindings" that are used sparingly on a few types rather than binding an entire library without types.
Example:
We would need a way to specify which types to bind, perhaps in MSBuild?
Theoretically this is all that should be required to create a vaguely typed binding for the
MyMapView
class.Flutter also includes the ability to exclude problematic members if needed, which could be something like:
Or it could use XPath.
Working With Vaguely Typed Slim Bindings
Inevitably you will need to work with some additional "real" types from a library. Consider the
AddPin
method, which requires aPinCoordinates
parameter and returns aPinResult
type.Assuming they do not come from a typed binding of a dependency, we would need to additionally bind them:
We can now create instances of these types, or use
JavaCast<T>
to convertJLO
to a type:The text was updated successfully, but these errors were encountered: