Unable to use Role.import_ in Java CDK

[RomainMuller]

I'm attempting to call Role.import_(...) in my Java CDK application, but I'm getting a ClassCastException from the CDK library. Apparently the result that's being returned from the Jsii runtime is a Construct which cannot be cast to an IRole:

Exception in thread "main" java.lang.ClassCastException: software.amazon.awscdk.Construct cannot be cast to software.amazon.awscdk.services.iam.IRole
	at software.amazon.awscdk.services.iam.Role.import_(Role.java:24)
	at MyCallingCode

The underlying TypeScript (github) declares that it returns IRole and explicitly returns an ImportedRole, which implements IRole, but also extends Construct (github). While walking through the Java code in the debugger I see that the result from Jsii's toString() shows "ImportedRole", but it's type is Construct.

[RomainMuller]

The issue appears to be that ImportedRole (what Role.import) returns is not an exported class, which results in the JSII runtime interpreting it as it's exported base class (Construct) when returning the instance over. This causes the Java runtime to then incorrectly type it as Construct instead of IRole. Basically, the interface types are lost at the boundary.

A minimal repro is:

package software.amazon;

import software.amazon.awscdk.App;
import software.amazon.awscdk.Stack;
import software.amazon.awscdk.services.iam.ImportedRoleProps;
import software.amazon.awscdk.services.iam.Role;

public final class Jsii320
{
    public static void main(final String[] args)
    {
        final App app = new App();
        final Stack stack = new Stack(app, "TestStack");
        Role.import_(
            stack,
            "ImportedRole",
            ImportedRoleProps.builder()
                             .withRoleArn("arn:aws:iam:::role/ImportedRole")
                             .build()
        );
        app.run();
    }
}

[rix0rrr]

The Java jsii runtime should be constructing an interace proxy for IRole instead of guessing at a concrete class. Same as what the .NET runtime is doing. Do we have a tracking issue for this yet?

[rix0rrr]

And it should be a compliance test for jsii.

[RomainMuller]

I reckon this is the tracking issue for that...

The issue here is really that the jsii-kernel returns an FQN on the concrete class instead of returning that of the declared type of the property.

This could be solved either by having the kernel return an ObjID with the correct type name, or by having the Java runtime ignore the type fragment of the FQN (merely treating it as a hint) and just generating an object proxy if the declared type is an interface.

[rix0rrr]

Fine, but the codegen has the declared type so it could use that as well.

[RomainMuller]

Agreed. I'm leaning towards a fix that makes the Java runtime not trust the type part of the ObjID so much, because that's a much easier fix, and also because that'd possibly make some use-cases quite convoluted (same object returned under various different interfaces it implements... ouch).

[rix0rrr]

If we go and trust the declared type completely, there are some edge cases that we can no longer downcast the object even if that would be legal (if jsii would return an exported subtype, or if we passed a subtype from java -> jsii -> java).

We should either:

• Combine static and runtime types, and so something the likes of:

if (exported(concrete_type))
  return concrete_type;
else
  return declared_type_proxy;

• Use the reflection API to create a class for the unexported type at runtime.
• Not care about downcasting.

[RomainMuller]

Adding a compliance test around this issue revealed that .NET/C# is also affected by this problem.

[RomainMuller]

PR #321 fixes this issue, 🎉