I just got a bit of context here https://github.com/pulumi/pulumi-java/issues/151#issuecomment-1224188934

A quick idea I had was to make sure that for every methods that accepts an FooArgs to also have a method that accepts FooArgs.Builder instead. So instead of

var storageAccount =
    new StorageAccount(
        "%s%s%s".formatted("sa", APPLICATION_NAME, stackName),
        StorageAccountArgs.builder()
            .resourceGroupName(resourceGroup.name())
            .sku(SkuArgs.builder().name(Standard_LRS).build())
            .kind(StorageV2)
            .build());

you'd have

var storageAccount =
    new StorageAccount(
        "%s%s%s".formatted("sa", APPLICATION_NAME, stackName),
        StorageAccountArgs.builder()
            .resourceGroupName(resourceGroup.name())
            .sku(SkuArgs.builder().name(Standard_LRS))
            .kind(StorageV2));

Also with all the nesting it would be good to investigate the Nested Fluent Builder pattern, for which I'm not sure what the authoritative definition / description is but this article goes into some detail: https://theagilejedi.wordpress.com/2016/10/21/nested-fluent-builders-with-java-8/

Nested Fluent Builder can have the disadvantage though of hiding the nested structures, which you might want to have visible in your code

Only other option for java to make code less verbose is Annotation Processors or compiler plugins 🙂

but event then it would be verbose

//Annotation Processor will throw error if var names in nested classes does not match the schema

@StorageAccount("sa-app-dev") 
@Kind(StorageV2)
class AppNameStorageAccount extends AbsStorageAccount {
  @ResourceGroup class DevResourceGroup {
    var name = "app-dev-group"; 
  }
  @Sku class SkuDev {
    var name = Standard_LRS
  }
}

usage

new AppNameStorageAccount().outputs()

Now of course this pattern has its fans and its haters, but it is quite commonly used and I would say it's idiomatic. I'll give another example.

RestAssured is also kind of a DSL to define http calls, this time with a focus on (integration) testing. You can find some example uses here: https://github.com/rest-assured/rest-assured/blob/master/examples/rest-assured-ite[…]t/java/io/restassured/itest/java/GivenWhenThenExtractITest.java

If we ignore the nested / chained builders for a minute, I mentioned a way to save a bit of boilerplate at the beginning of this Thread. It can be combined with another Pattern where you have aliases for the

builder()

-Methods that are named after the object you want to build. The benefit of this is that you can do a static import of the method without name clashes. My example would then look like:

var storageAccount =
        new StorageAccount(
            "%s%s%s".formatted("sa", APPLICATION_NAME, stackName),
            storageAccountArgs()
                .resourceGroupName(resourceGroup.name())
                .sku(skuArgs().name(Standard_LRS))
                .kind(StorageV2));

It should be possible to implement these two simplifications in an optional, backwards-compatible matter.

Just found this issue, so my first suggestion is already tracked 🙂 https://github.com/pulumi/pulumi-java/issues/244

You mean the java code, right? Not go?

Wow, that's a huge JAR! https://repo1.maven.org/maven2/com/pulumi/azure-native/1.64.0/

On the other hand, the cdktf provider jar is even a bit larger https://repo1.maven.org/maven2/com/hashicorp/cdktf-provider-azurerm/2.0.10/

The way the code is generated right now has a lot of benefits, the parts that users interact with directly are discoverable and simple to read. That's a very good thing. Still, if you are in serious need to reduce the size of the codebase, it looks like the builders and maybe other things could be generated at runtime with dynamic proxies (if you're willing to switch a few classes to interfaces) or using cglib. Annotation processors could also be an option, they would run at compile time, but on the user's machine. This might make their compile times unacceptably slow though. In summary, and I'm sure you have already considered a lot of this, the best bet looks to be to split the larger providers into multiple jars. I saw an issue in azure-native for go, which seems to have a similiar problem with the size.

at the moment the java support does not have many resources for invasive changes, but with enough community participation everything is possible 🙂