[Java.Base, generator] Bind all of package java.lang

[jonpryor]

Context: bc5bcf4

Bind all classes and interfaces in the java.lang package.

Alter Java array binding, so that instead of IList<T>, we get
"direct" Java arrays, e.g.

namespace Java.Lang {
partial class Character {
// Previous/Xamarin.Android-like
public static int CodePointAt (IList<char>? a, int index);
// New/Desktop
public static int CodePointAt (JavaCharArray? a, int index);
}
}

Rationale: it allows for more efficient JVM :: .NET array copying,
by making copies explicit (to the dev), not implicit. We can
add an implicit conversion from e.g. IEnumerable<char> to
JavaCharArray in the future, if deemed useful.

This also impacts method return types, properties, and fields.

Bind the java.lang.module package in the namespace
Java.Lang.Modules. This is to avoid a type/namespace conflict
with java.lang.Module, bound as Java.Lang.Module.

Continue updating generator to remove "Android-isms".

Update Java.Base.csproj to ignore warning CS0108:

Java.Lang.Reflect.IAnnotatedArrayType.cs(15,45):
warning CS0108: 'IAnnotatedArrayType.AnnotatedOwnerType' hides inherited member
'IAnnotatedType.AnnotatedOwnerType'. Use the new keyword if hiding was intended.

The problem here is that we have:

public partial interface IAnnotatedType {
// Contains default interface method
virtual unsafe IAnnotatedType? AnnotatedOwnerType => …;
}
public partial interface IAnnotatedArrayType : IAnnotatedType {
// Contains *no* method body; re-abstracted
IAnnotatedType? AnnotatedOwnerType {get;}
}

TODO: figure out how to properly fix this. managedOverride
metadata (5a0e37e) doesn't seem useful to "re-abstract" a default
interface member.

Update Java.Base.targets to use generator --global. This is so
that java.lang.System can be bound as Java.Lang.System without
causing various C# compilation errors due to type lookup.
(Compare to Xamarin.Android's Java.Lang.JavaSystem, which got a
Java* prefix to avoid these compilation errors.)

Update JavaInteropCodeGeneratorTests.CreateOptions() so that C#
features such as default interface methods and nested interface types
are enabled within the unit tests.

TODO:

• When generator --codegen-target=JavaInterop1 is used, all the
  language features should also be enabled by default.

• Certain Java Annotation-related types aren't bound in
  JavaInterop1, vs. XAJavaInterop1. Revisit this.

• "Revisit" use of JNIEnv.ToLocalJniHandle() in Xamarin.Android
  bindings, and it's outright removal in JavaInterop1 bindings.
  @jonpryorthinks the JNIENv.ToLocalJniHandle(v) was introduced
  "in case" v would be collected by the GC "during" a JNI call.
  Use of GC.KeepAlive() (1f21f38, da73d6a), would be a better
  solution, but also requires auditing generator output.

• Bind the rest of java.base.jmod (bc5bcf4).

[jonpryor]

So… strings: how should we bind them? There's no backward compatibility requirement with Java.Base.dll, so we don't need to be consistent with Xamarin.Android (which binds java.lang.String as System.String). This PR alters things so that java.lang.String is bound as Java.Lang.String.

Consider java.lang.String.compareTo(java.lang.String):

classString {
publicintcompareTo​(StringanotherString);
}

In Xamarin.Android, this is bound as:

partialclassString{publicintCompareTo(stringanotherString);}

In this PR, it is bound as:

partialclassString{publicintCompareTo(Java.Lang.String?anotherString);}

This PR also adds an implicit conversion from string to Java.Lang.String, so "normal" usage works:

vars=newJava.Lang.String("value");s.CompareTo("another value");

but this implicit conversion means extra GC String instances will be created.

Pros of binding java.lang.String as Java.Lang.String

Object identity is preserved. If there is a Java API which requires that you use exact string instances and not string equality, then we need to bind java.lang.String as Java.Lang.String.

• Note: we've never encountered a bug related to this in Xamarin.Android. This is thus only theoretical.

Cons of binding java.lang.String as Java.Lang.String

The "simple" case of s.CompareTo("constant") either (1) isn't possible (unless you have an implicit conversion, as done in this PR), or (2) results in extra String instances that contribute to GC times.

In a "java.lang.String is bound as Java.Lang.String world order", s.CompareTo("constant") can be improved by providing method overloads which accept string. Xamarin.Android already does this for ICharSequence parameter types; extending this to also handle Java.Lang.String shouldn't be too complicated (famous last words), but is still a generator complication.

Part of the complication eluded to above is around virtual methods: the string overload shouldn't be virtual, which means it would need to create a temporary Java.Lang.String instance anyway; we'll be able to dispose it, but it'll still need to be created. Consider java.util.ResourceBundle.containsKey():

partialclassResourceBundle{// Xamarin.AndroidpublicvirtualboolContainsKey(string?key);// Java.Base?publicvirtualboolContainsKey(Java.Lang.String?key);publicboolContainsKey(string?key){usingvarjkey=key==null?null:newJava.Lang.String(key);returnContainsKey(jkey);}}

If we don't have a virtual method in play, we can instead overload by hitting JNI directly:

partialclassString{publicintCompareTo(Java.Lang.String?anotherString);publicintCompareTo(string?anotherString){conststring__id="…";return_members.InstanceMethods.InvokeAbstractInt32Method(__id,this, …);}}

This would avoid a Java.Lang.String temporary, but at the cost of generator complexity.

Consistency: commit bc5bcf4 had suggested a possible binding strategy change of:

TODO: Other Binding Changes?

We should eventually "unify" java.lang.Object and System.Object.
Consider java.lang.Class:

 /* partial */ class Class<T> {
public boolean isInstance(java.lang.Object);
public java.lang.Object[] getSigners();
}

If we unify java.lang.Object and System.Object, we'd have a
binding of:

 partial class Class {
public bool IsInstance (object value);
public JavaObjectArray<object> GetSigners();
}

"Removing" java.lang.Object in lieu of System.Object has been a 12+ year old request. For consistency, if we bind java.lang.Object as System.Object, then we should bind java.lang.String as System.String.

Likewise, if we bind java.lang.String as Java.Lang.String, we should not bind java.lang.Object as System.Object.

We could likely get much of the desired benefit of "unifying" Java.Lang.Object with System.Object by providing an implicit conversion from System.Object to Java.Lang.Object:

namespaceJava.Lang{partialclassObject{publicstaticimplicitoperatorObject?(object?value)=> …
}}

I'm not sure if either/any of these are good ideas.

The "nice" thing about binding java.lang.String as Java.Lang.String is that it makes some bits of generator more consistent: we can consistently emit v?.PeerReference ?? default or new JniObjectReference(v) for all reference type parameters. Internal consistency is nice!

This in turn suggests that "unifying" java.lang.Object with System.Object might not be a good idea either.

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jpobst]

A downside of binding as Java.Lang.String is that the implicit cast is not discoverable. When using IntelliSense, there is no way to know that you can use a string here:

Additionally, for return values, you are not going to see methods available on string, only methods available for Java.Lang.String:

Calling, for example, Java.Lang.String.ToUpperCase () instead of string.ToUpper () is probably not desired, as it incurs a Java roundtrip.

[jonpryor]

@jpobstreminded me that I'm not personally very good with how things look like with IDE-colored glasses. Those are two separate scenarios -- parameters vs. return types -- but the underlying issue is the same: how the IDE presents options is not necessarily ideal.

generator-emitted auto string overloads can help with parameters. It can't help with return types.

[jonpryor]

I previously pondered:

We could likely get much of the desired benefit of "unifying" Java.Lang.Object with System.Object by providing an implicit conversion from System.Object to Java.Lang.Object…

After additional thought, that wouldn't be good, as it wouldn't be bidirectional. Consider:

varlist=newJava.Util.ArrayList();list.Add(newList<int>{1,2,3,4});

This can be "made to work" by updating Java.Lang.Object to have an implicit conversion from System.Object. However, what would one want to do with list?

varitems=(List<int>)list.Get(0);// boom

If ArrayList.Get(int) returns Java.Lang.Object, then the cast to (List<int>) will fail with an InvalidCastException, which is entirely unexpected. This can't be fixed without altering C# to support generic conversion operators, or possibly by inserting an "intermediate" cast (with appropriate "glue"):

varitems=(List<int>)(object)list.Get(0);// *maybe* works as expected?

Thus, updating Java.Lang.Object to have an implicit conversion from object is a Bad Idea™.

The original idea of "unifying" Java.Lang.Object with System.Objectcan be "made to work", a'la:

partialclassArrayList{publicobject?Get(intindex){conststring__id="get.(I)Ljava/lang/Object;";try{JniArgumentValue*__args=stackallocJniArgumentValue[1];__args[0]=newJniArgumentValue(index);var__rm=_members.InstanceMethods.InvokeVirtualObjectMethod(__id,this,__args);returnglobal::Java.Interop.JniEnvironment.Runtime.ValueManager.GetValue<object>(ref__rm,JniObjectReferenceOptions.CopyAndDispose);;}finally{}}}

…because Runtime.ValueManager.GetValue<object>(…) will "unbox" any "boxed" values.

Which taken together suggests two things to me:

1. We should bind java.lang.String as System.String, a'la Xamarin.Android, and
2. We should "unify" java.lang.Object and System.Object. Such unification must be part of the actual bindings, and not "higher level" in e.g. Java.Lang.Object bindings.

[jpobst]

We should "unify" java.lang.Object and System.Object.

I think one of the biggest sticking points for users is the need to inherit JLO to implement a bound Java interface, a la:

publicclassMyListener:Java.Lang.Object,IOnChangeListener{ ...}

Would we be able to get around this requirement?

[jonpryor]

@jpobstasked:

Would we be able to get around this requirement?

Yes and no.

See also: https://github.com/xamarin/java.interop/issues/17 (which is closed for some reason?!)

The "problem" is that all interfaces now implement IJavaPeerable, which has 12 required members. The easiest way to do this is to subclass Java.Lang.Object. We also need Java Callable Wrapper support, which currently excludes Java.Interop.JavaObject, but that can be fixed.

That said, it should be possible to (eventually) make IJavaPeerable implementable by "mere mortals", in part by documenting how to do so, and by extending jcw-gen so that we don't constrain to just Java.Lang.Object subclasses.

"Unifying" java.lang.Object with System.Object is not directly related to your "can IJavaPeerable be implemented?" question, though; IIRC the primary motivation for such "unification" was the above ArrayList example, so that you wouldn't need to create a class Holder : Java.LangObject {} class to stuff "arbitrary" types which are referenced only by Java code. We can support that. We can also "allow" people to implement IJavaPeerablethemselves, so long as they do it "correctly" (which is quite the constraint!).