AnyJavaObject doesn't have any conformance to JavaValue

[lokesh-tr]

As per https://github.com/swiftlang/swift-java/blob/80b68a595ca533ffb4d63d04ee53785a8549f8af/Sources/JavaKit/JavaValue.swift#L23C69-L26C70 , AnyJavaObject protocol should inherit the JavaValue protocol. And this would allow us to utilise the java types such as java.lang.String and java.lang.Array by code gen using Java2Swift.

For some unknown reasons, the code documentation seems to be outdated and the implementation of all the primitive types including types such as the above mentioned ones have been updated to conform to JavaValue directly as we can see in the JavaKit/BridgedValues folder.

This now puts us in an interesting situation where non-primitive java classes, java.lang.Class, java.lang.Object all conform to AnyJavaObject which doesn't conform to JavaValue while the primitive types, java.lang.String, java.lang.Array all conform to JavaValue but does not conform to AnyJavaObject. Thus, creating completely disjoint sets of types.

This also becomes a problem when we mark a method with @JavaMethod to let Swift access the Java methods, because this macro internally needs to make a dynamicJavaMethodCall whose parameters and return type are all JavaValue, therefore we can't have function signatures that involves java.lang.Class, java.lang.Object, or anyother non-primitive java type since the Macro Expansion would fail due to type mismatch.

Its possible that I might have overlooked some details and maybe there's a way to convert AnyJavaObject to JavaValue and vice versa. Please feel free to let me know if I missed something. And also update the code documentation if time permits.

[DougGregor]

This decision was deliberate, but is up for debate. Currently, only an optional of an AnyJavaObject-conforming type conforms to JavaValue, through this conditional conformance. This is because Java doesn't fully embrace nullability, so it felt safer to say that Java objects provided to/from Swift should always account for nil by being optional.

String and Array account can account for nullability by using the empty string/array as a stand-in for nil. Other types don't necessarily have that option, and even there it's a little sketchy.

The approach we should take to nil with Java interoperability would a good topic for the forums.