[FEATURE] Remove additional compilation rounds

[Rawi01]

Describe the feature
Lombok always initiates multiple rounds of annotation processing, ensuring that all handlers requiring resolution are processed within their dedicated rounds. This was a requirement in the past due to the fact that added methods and fields were not consistently added to type mirrors. However, a significant improvement was introduced in issue #2718, which not only enabled the support of other annotation processors in the same round but also paved the way for accomplishing all tasks within a single round.

Eliminating these rounds has the dual benefit of decreasing compilation time and streamlining the incorporation of other annotation processors that can execute after Lombok and access all the generated content.

Describe the target audience
Everyone

Additional context
I successfully implemented a proof of concept (https://github.com/Rawi01/lombok/tree/remove-additional-rounds) and it resulted in a 15% reduction in compilation time for my sample project.

[rzwitserloot]

The whole 'patch up the type mirrors' trick also feels like a doorway to run all of lombok post-resolution just like ExtensionMethod and company do. Opens up doors such as automatically creating constructors that call the superconstructor and the like.

I wonder how we should go about releasing this; I foresee issues that our tests won't catch. A really long edge-release period? Lombok v1.20 while we also release lombok v1.18 for a year or so (maintain em both) to ensure 1.20 (with this PoC applied) is indeed stable?

Adding it to the next milestone more in the sense of 'we should consider it', not so much "this will definitely be in the next release".

[Rawi01]

I also suspect that there may be certain issues that our tests are not capturing. One particular concern I have in mind is the potential presence of extension methods on a type generated by a different annotation processor. At the moment this works in most cases because we delay the transformation to later rounds.

[rzwitserloot]

@Rawi01 Lombok does not portend to be compatible with other lomboks (i.e. other code-modifying compiler plugins, whether they launch via the AP loader mechanism or any other way). And vanilla APs cannot modify existing code, only add new code. So, we're now down to a really exotic case, where you @ExtensionMethods in a class that doesn't exist at first, but is generated by another AP.

Presumably we can make that work too - just.. ignore the issue of 'oh hey that class doesn't exist at all', and return false (not completed the actions required for this annotation yet), as another round will happen and then it'll be well. So, I'm doubly not worried:

• Other than academic cases it won't come up.
• But if we want to support those, that probably already works right now.

[Rawi01]

I think my example was not explained well enough, I was concerned about classes that get generated by other AP and used in a different place together with a lombok annotation that requires resolution. It was not about a lombok annotation in a generated class, that should work in most cases. I added a small code snippet below to show some interactions between lombok annotations and a GeneratedByApClass.

@ExtensionMethod(StringExtensions.class)
public class Test {
	@Delegate
	private GeneratedByApClass a;
	
	public void test() {
		val b = new GeneratedByApClass();
		
		b.getString().reverse(); //StringExtensions::reverse
	}
}

This is a general problem between lombok and other APs and their might be cases that are unable to solve. At the moment most stuff works because lombok uses multiple rounds and most APs generate code in the first one.

[rzwitserloot]

I'd consider @Delegateing an AP-produced type to be mostly in the same boat: Exotic.

As in, if we can significantly speed up lombok at the cost of breaking that, I think we should break it. (Even better would be that we speed up lombok and continue to support this, of course).