Repository navigation
Use Java generic type parameters constraints #11912
Copy link
Copy link
Closed
Labels
Area: BindingsIssues in Java Library Binding projects.Issues in Java Library Binding projects.java-interopIssues migrated from dotnet/java-interop / relates to the Java.Interop subtreeIssues migrated from dotnet/java-interop / relates to the Java.Interop subtreeneeds-triageIssues that need to be assigned.Issues that need to be assigned.possibly-staleIssues that are potentially no longer relevant.Issues that are potentially no longer relevant.
Description
generator doesn't "forward" and use generic type constraints in bindings. Consider this Java type:
package com.xamarin.android;
public interface InvokeRunnable<T extends Runnable> {
void invoke (T runnable);
}Here, T is contained to be a type that implements java.lang.Runnable.
However, the binding that generator emits is:
[Register ("com/xamarin/android/InvokeRunnable", "", "Com.Xamarin.Android.IInvokeRunnableInvoker")]
[global::Java.Interop.JavaTypeParameters (new string [] {"T extends java.lang.Runnable"})]
public partial interface IInvokeRunnable : IJavaObject, IJavaPeerable {
// Metadata.xml XPath method reference: path="/api/package[@name='com.xamarin.android']/interface[@name='InvokeRunnable']/method[@name='invoke' and count(parameter)=1 and parameter[1][@type='T']]"
[Register ("invoke", "(Ljava/lang/Runnable;)V", "GetInvoke_Ljava_lang_Runnable_Handler:Com.Xamarin.Android.IInvokeRunnableInvoker, Xamarin.Android.McwGen-Tests")]
void Invoke (global::Java.Lang.Object p0);
}The Java-side parameter, which must be a java.lang.Runnable or type implementing that interface, is bound as Java.Lang.Object.
Feature request: "forward" this constraint information, and use it in the binding, so that we instead emit:
public partial interface IInvokeRunnable : IJavaObject, IJavaPeerable {
[Register ("invoke", "(Ljava/lang/Runnable;)V", "GetInvoke_Ljava_lang_Runnable_Handler:Com.Xamarin.Android.IInvokeRunnableInvoker, Xamarin.Android.McwGen-Tests")]
void Invoke (global::Java.Lang.IRunnable p0);
}Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Area: BindingsIssues in Java Library Binding projects.Issues in Java Library Binding projects.java-interopIssues migrated from dotnet/java-interop / relates to the Java.Interop subtreeIssues migrated from dotnet/java-interop / relates to the Java.Interop subtreeneeds-triageIssues that need to be assigned.Issues that need to be assigned.possibly-staleIssues that are potentially no longer relevant.Issues that are potentially no longer relevant.
Activity
AmrAlSayed0 commentedon Feb 6, 2021
While trying to fix issues in a Java library I'm binding I came upon this issue. Easily fixable with Metadata attr BUT I'm curious as to why the C# interface isn't a real generic interface like
I know there is a reason I'm completely overlooking because I've seen this "issue" in classes too.
jpobst commentedon Feb 8, 2021
Unlike .NET, Java generics do not exist in compiled code or at runtime. They are simply compiler magic that the compiler removes when compiling code.
Since we bind
.jarfiles, the generic information is gone.Assuming that could be fixed, we have another issue at runtime. If Java gives us an arbitrary
ArrayListobject and we want to convert it to aArrayList<T>, we don't know whatTis.For these reasons, our bindings reflect the Java compiled API (without generics) and not the source API.
AmrAlSayed0 commentedon Feb 8, 2021
But generics with constraints is fine cuz you know what T is, got it. I suspected that would be the reason.
I really want to see this implemented (+ covariant returns) because I have seen
Builder<T extends Builder<T>>classes basically become useless when all of the return types of all the methods become Java.Lang.Object when it's clearly more than that.[Java.Base] Begin binding JDK-11 java.base module (#909)
dotnet-policy-service commentedon Jul 1, 2026
We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.
dotnet-policy-service commentedon Jul 15, 2026
This issue will now be closed since it had been marked "possibly-stale" but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.