feat: supports custom toBuilder method name

[bengbengbalabalabeng]

Summary

Related: #4056 (Scope: @Builder)

Adds a new toBuilderMethodName attribute to @Builder, allowing users to customize the name of the method generated when toBuilder = true.

• Default: "toBuilder" (backward compatible — existing code is unaffected).
• Only takes effect when toBuilder = true; otherwise the attribute is ignored.
• Implemented in both the javac and eclipse/ECJ handlers.

Adds the config key lombok.builder.toBuilderMethodName, which sets the global default whenever @Builder(toBuilder = true) is used without an explicit toBuilderMethodName parameter.

• Resolution order: explicit annotation attribute → lombok.builder.toBuilderMethodName config key → "toBuilder" (Default).

[nealeu]

Nice. Really simple and the example of e.g. .mutate() as an alternative to .toBuilder() could be nice for visual ergonomics.

[Rawi01]

My initial thought about it was that this should probably be a config flag instead of an individual attribute. This keeps all builders in sync and leads to a better codebase. Different names for different builders doesn't feel right.

[bengbengbalabalabeng]

My initial thought about it was that this should probably be a config flag instead of an individual attribute. This keeps all builders in sync and leads to a better codebase. Different names for different builders doesn't feel right.

The configuration file approach is indeed a more unified way to keep the behavior of all builders consistent (e.g. lombok.builder.toBuilderMethodName). However, I think offering both annotation parameters and configuration options gives users more flexibility to choose in different scenarios.

Regarding the priority between the two, my thoughts are:

• If the lombok.builder.toBuilderMethodName setting exists in the configuration file and the annotation still uses the default value toBuilder, then the configuration file value should be used;
• If the lombok.builder.toBuilderMethodName property is set in the configuration file and the toBuilderMethodName annotation parameter is not explicitly specified, then the configuration file value should be used.
• If toBuilderMethodName is explicitly specified in the annotation, the annotation takes precedence.

This way, we maintain global consistency while still allowing overrides on individual builders, striking a balance between flexibility and controllability.

[nealeu]

Have you tried this out in different IDEs?

I am aware of the Jetbrains IDEA Lombok plugin being part of the main IDE git tree now, so they'd need to update that given they maintain an internal autocomplete index. I suspect they'd be willing given it's been active with work on @ExtensionMethod in recent releases.

[bengbengbalabalabeng]

Have you tried this out in different IDEs?

I am aware of the Jetbrains IDEA Lombok plugin being part of the main IDE git tree now, so they'd need to update that given they maintain an internal autocomplete index. I suspect they'd be willing given it's been active with work on @ExtensionMethod in recent releases.

I’ve only tried this in IntelliJ IDEA so far.

Regarding the JetBrains Lombok plugin: I’m not fully sure about the coordination process between Lombok and JetBrains. Would it be appropriate to wait for further progress on this PR before opening a corresponding update request on their side, or would parallel tracking be acceptable?

I’m happy to follow whichever workflow is preferred.

[nealeu]

If using your changes in IntelliJ doesn't cause any issues then that's great. I'll defer to the Lombok team on collaboration with Jetbrains. I personally see no reason it should get in the way.

[bengbengbalabalabeng]

If using your changes in IntelliJ doesn't cause any issues then that's great. I'll defer to the Lombok team on collaboration with Jetbrains. I personally see no reason it should get in the way.

Sorry for the confusion earlier — what I meant is that using IntelliJ IDEA as the development environment does not cause any issues for compiling or testing the newly added functionality.