java: Unable to synth Java CDK projects

[victorlevasseur]

Describe the bug

We are unable to synth and deploy CDK projects written in Java since today.
Yesterday, the same projects with the same commit were building correctly.

Expected Behavior

Our CDK project synths properly.

Current Behavior

It throws errors like that (the resource class name vary depending on the project and which resource comes first) :

Exception in thread "main" java.lang.ClassCastException: class software.amazon.awscdk.Resource$Jsii$Proxy cannot be cast to class software.amazon.awscdk.services.apigateway.DomainName (software.amazon.awscdk.Resource$Jsii$Proxy and software.amazon.awscdk.services.apigateway.DomainName are in unnamed module of loader 'app')

Reproduction Steps

Any Java project on our stack seems impacted, I think the standard CDK example should have the same issue.

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.89 (but various 2.x versions of the CDK lib used)

Framework Version

Java 11/17

Node.js Version

16.20.1

OS

Mac OS X (M1)

Language

Java

Language Version

11/17

Other information

No response

[vnhim]

same issue here

[victorlevasseur]

Seems related to the release of AWS JSII 1.86 as it looks a lot like this issue : aws/jsii#4202.

Wouldn't it possible to enforce a JSII version to each AWS CDK version to avoid any issues when we enforce the CDK versions on our sides?

[RomainMuller]

Wouldn't it possible to enforce a JSII version to each AWS CDK version to avoid any issues when we enforce the CDK versions on our sides?

If that was done, you suddenly would be required to ensure ALL packages in your dependency closure were built by the EXACT SAME version of jsii-pacmak, which you would soon find is EXTREMELY inconvenient 🫣

[RomainMuller]

As a workaround until I get around to publish a fix, you should be able to pin the version of software.amazon.jsii:jsii-runtime on your project to [1.85.0].

[ielkhalloufi]

I fixed it by adding the explicit jsii-runtime version of your dependency. For example, in my project I had:

    <dependency>
      <groupId>software.amazon.awscdk</groupId>
      <artifactId>aws-cdk-lib</artifactId>
      <version>2.83.1</version>
    </dependency>

When checking which jsii-runtime version is included (see compile dependency): https://mvnrepository.com/artifact/software.amazon.awscdk/aws-cdk-lib/2.83.1
you see that version 1.82.0 is used.

Exclude the jsii-runtime, and add the jsii-runtime explicitly in your pom file:

    <dependency>
      <groupId>software.amazon.awscdk</groupId>
      <artifactId>aws-cdk-lib</artifactId>
      <version>${cdk.version}</version>
      <exclusions>
        <exclusion>
          <groupId>software.amazon.jsii</groupId>
          <artifactId>jsii-runtime</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
      <groupId>software.amazon.jsii</groupId>
      <artifactId>jsii-runtime</artifactId>
      <version>1.82.0</version>
    </dependency>

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[gefloh]

@RomainMuller I wonder why you guys are not using fixed versions for all dependencies in CDK. This issue broke our prod release which deployed just fine on the upstream environments a couple of hours earlier. That's not nice.

[victorlevasseur]

@RomainMuller But currently the jsii-runtime version already changes as AWS publishes new versions of it. So how fixing the version would cause problems with the jsii pacmak as changing versions would not?
The whole concept of a CI is to have reproductive builds, that's not the case currently. I don't say it should be changed as soon as possible but it probably has to be explored for the future.

Gradle or Maven will be able to see different versions of jsii required by all modules but would then use the best one automatically so one version is used across a project.