Trying to extend Lombok with my own transformations, got stuck

[Suseika]

I want to write an extension for Lombok, but there are a couple of issues.

I looked at the existing Handlers and they use classes from packages org.mangosdk.spi and com.sun.tools.javac.code. I am using maven, and I haven't found any artifact with those libraries. Moreover, the org.projectlombok:lombok artifact itself doesn't seem to have that code, and it doesn't declare any dependencies, so I can't understand where am I supposed to get that code. Am I supposed to download a copy of it and put it in something like the old-fashioned lib folder and not get it as a managed dependency from Maven?

Another thing is that maven artifacts org.projectlombok:lombok for versions 1.14.* and 1.16.* have different types of content: 1.14.* has class files in its lombok/javac directory, but 1.16.* has those *.SCL.lombok files instead. Why are these named differently? How am I supposed to write a custom extension for 1.16.* then, if I can't use those class files?

[Suseika]

Ok, I figured out how custom Lombok transformations work and how you should make them. I thought Lombok follows a kind of a modular approach when if you wan't to extend Lombok, you depend on it in your maven build and write your custom transformation. But instead, apparently, you have to fork Lombok if you want anything added to it. 

The dependencies org.mangosdk.spi.ProviderFor and com.sun.tools.javac.* are retrieved upon an Ant build (by the way, the Ant build process for Lombok looks really smooth — I haven't had a single issue and that's fantastic, because I got used to Ant builds driving me crazy).

I still don't know why the extensions for classes in 1.16.0+ artifacts are *.SCL.lombok , but that is not a concern any more since I managed to write and test the custom AST transformation I wanted.

And is there any hope for Lombok to become more modular in future so it is easier to write custom transformations?

[DaveTheDane]

From the short experience I have (about half an hour) I would say there is room for modularisation:
- some bits seem to be just for eclipse
- other bits seem to be just for lombok internals
- then there are the Annotations themselves

While its convenient to ship everything in 1 jar & just 1 project,
this makes it massively more difficult to understand & contribute to.
(particularly as there's almost no documentation, help, tutorials, how-to's etc...)

Some of the classes have restrictions on what Java Source Level may be used.
These could maybe be in an own project with, say, a J2SE-1.4 Execution environment)

Couldn't the classes hidden by the ShadowClassLoader be packaged in a suitably named jar?
(that is I believe not the same as the previously-used jarjar concept: ShadowClassLoader would still be needed)

All this might make it much easier to contribute to lombok.

All the best,
Dave

[binkley]

I discovered the same problem moving from lombok 1.14 to 1.16.  My example extension no longer compiles as there are no longer class files for lombok internals.  A solution here would be welcome.

https://github.com/binkley/binkley/tree/master/lombok/src

[Necrontyr]

I am more surprised this idea of shifting to an internal model where you must extend Lombok rather than just use it as a maven dependency hasn't been published anywhere. 

Can we get confirmation @Roel Spilker about this change ?

I've been using and depending on Lombok for two custom annotations since version 0.10.8 ; With this change in direction not only do i need to re-write my annotation for Java 8 ( which i was more than prepared to do ) , I also need to fork Lombok, seems a tad extreme. 

Daniel 

[Reinier Zwitserloot]

On Monday, January 30, 2017 at 4:48:49 PM UTC+1, Necrontyr wrote:

I am more surprised this idea of shifting to an internal model where you must extend Lombok rather than just use it as a maven dependency hasn't been published anywhere. 

Well, we always had class loading shenanigans where things living in the lombok.* package get special treatment, and we never quite fully supported 'bolt-on' lombok additions outside of just making your own custom lombok.jar.

The shadow loader stuff makes life even harder for extending lombok in a way that does not involve making your own custom lombok.jar, but it solves problems for others by no longer polluting your namespaces with our stuff and making it even clearer which parts of lombok are 'public' and which ones are not. We made the decision to continue down this path.

One day we'll make a fancy extension mechanism.