Split lombok.jar into smaller JARs

[victorwss]

I am aware that lombok is a compiler plugin, so it should not be placed as part of the runtime classpath of applications. This means that there are not very much reasons to split it into several JARs. However we have a few:

1. Gradle 5.0 will likely get trouble on that. Currently on gradle 4.6, running a gradle build produces the following warning:

   Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
   See https://docs.gradle.org/4.6/userguide/command_line_interface.html#sec:command_line_warnings

   Running it with gradle --warning-mode=all build will produce:

   Putting annotation processors on the compile classpath has been deprecated and is scheduled to be removed in Gradle 5.0. Please add them to the processor path instead. If these processors were unintentionally leaked on the compile classpath, use the -proc:none compiler option to ignore them..

   However since we have a sole lombok.jar file which contains both the annotations and the annotation processor, there is no simple way to separate those things. A straightforward solution would be to add an hypothetical lombok-annotations.jar to the compile classpath and an hypothetical lombok-processor.jar to the processor path.

2. Other projects uses lombok as a dependency, I am aware at least of bytebuddy, but there could be a few more. Depending in lombok is troublesome because this grabs the annotations, the processor, the launcher, the hacks for javac, the hacks for eclipsec and possibly much more things I'm not aware when just a subset of those matters for them.

3. Due to all that module-craziness that Java 9 added with all those illegal reflective access warnings, managing the dependencies correctly without breaking lombok into smaller parts becames something very hard to do. Breaking lombok into smaller parts simplify that task.

What I suggest could be at least those:

• lombok-annotations.jar
• lombok-processor.jar
• lombok-eclipsec.jar
• lombok-javac.jar
• lombok-launcher.jar

For those who prefer the old way for some reason, a fat everything-inside lombok.jar would continue to be provided. If somebody would need to add something from lombok into the runtime classpath/modulepath for whichever reason, it would also become very clear of what are being added there.

[victorwss]

And oh, just forgot to tell, the delombok tool would also probably land in another jar.

[nsiniakevich]

What is the current status of this issue?

[oehme]

Just to be clear, Gradle 5.0 will keep working, it'll just ignore that jar on your compile classpath going forward. But still, putting a processor on your app's classpath makes no sense, it just unnecessarily increases the size of your application. Most other processors properly separate into api and processor jar.

[rzwitserloot]

No, lombok shall not separate into smaller jars. There's a convenience in being a single jar that we don't just want to throw away for mostly silly reasons. Let's go through them:

1. Gradle

This is opinionated aggressive behaviour from gradle. I disagree with the opinion gradle is espousing here; you should file a bug vs. gradle to warn them they really shouldn't do that in 5.0. Putting jars-containing-annotation-processors on the classpath when compiling is just not an issue. Sure, putting them on the cp at runtime is definitely highly suspect, but lombok does not need to be on the classpath at runtime. The solution is to simply... not do that (the 'provided' status of a dependency is how you specify that lombok should be on the cp when compiling, but not when deploying/shading/running/shipping/etc).

It feels a bit odd to ask us to bend over backwards to accomodate gradle's crazy opinions. I'm tempted to not do it; this is gradle's problem, not ours.

NB: If gradle wants to aggressively ignore/error/warn with scenarios where lombok.jar is on the runtime classpath, more power to em. I share the opinion that this just cannot be right. On the compiler path though - nope. No reason for that.

2. bytebuddy is misconfigured. It should not have lombok on the runtime classpath, it should not shade in lombok, and its dependency def should define lombok such that it is not exported. I suggest filing a bug with bytebuddy for them to correct this.

NB: You can get a jar that is just lombok's annotations and nothing else via java -jar lombok.jar publicApi and we can talk about putting that jar on mavencentral. I would advise against using it (instead, find the projects, such as gradle or bytebuddy, that do weird things or are buggy about this issue, and report bugs to make them fix it), but I can see how its useful as a stopgap at least. There's a reason the 'publicApi' app is built into lombok :) – I see no reason for lombok-processor, lombok-javac, etc. Lombok is a 1.5MB jar file which completely hides virtually every aspect inside it, except the API (the annotations such as lombok.Builder and the launcher entry point of the annotation processor and eclipse agent). Seems utterly pointless to split up the jar to me. Some sense of elegance? We don't share it.

[rzwitserloot]

NB: I filed a bug over at the gradle project: gradle/gradle#5056