Why are there separate handlers for Javac and Eclipse?

[Volodymyr Bolshutkin]

I recently started using Lombok and I'm excited. Then I found some limitations and thought about extending it, so I downloaded the sources. I was able to make some of the changes I wanted, however it turned out that we must maintain two separate handlers for Eclipse and Javac. Also, this forces the developers of the Lombok plugin for Intellij IDEA to implement their own handlers set.

I'm surprized with this design as I thought about some abstract AST manipulation API and two of its implementations. In my forked Lombok repo I've deleted everything except of @Setter and @Getter and reimplemented them using this approach alowing to develop new annotations easier and not having to support multiple handlers with similar code.

Sure those were the easiest annotations and I might be missing some significant limitations that forced Lombok to use the current approach. So, can anyone explain me what were the arguments in its favour?

Regards Volodymyr.

[Michael Ernst]

If you create an abstract AST manipulation API, that could be useful both for Lombok and for other tools.

Rather than rolling your own, I suggest that you build upon JSR 198, which is a Java standard.

I'm not aware of any existing implementation of JSR 198.  That suggests that implementing JSR 198 might not be trivial, though I don't recall the reasons.

Mike

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/db863bac-2240-4dd8-89dd-a2ec76ae7aa5n%40googlegroups.com.

[Arnaud Nauwynck]

Hi Volodymyr,

I am interrested in reading your generic implementation of Lombok AST transformation, not bounded to Javac/Eclipse/IntelliJ specificities.
Where is your code / branch?

Does it means you choosed one "X" as a pivot, and plug in specific implementation of "Y"
like "1/ convert Y->X, 2/ transform X->X, 3/ convert X->Y" ?
Did you choose "X" amoung one of the available Javac|Eclipse|IntelliJ, or introduced yet another one amoung JavaPoet|Spoon|.. ?

Does your intention is to allow pluggable user-defined implementations of AST transformation?
and you choosed Getter+Setter to test your new ideas?

Personnally, I am searching a tool that would allow users to define their own meta-programming transformation rules,
but it need to be valid java syntax, and easily integrated in Lombok (-> in maven + Eclipse + IntelliJ)

Regards,
Arnaud

[jhma...@gmail.com]

For a code generation I see

• Use custom annotations and custom javac plugins for generating _additional_ stuff derived from annotated java classes.
• Enhance your compiler (lombok) for making more AST transformations _inside_ (and additional) the class.
• Use a text based dsl and tools like Xtext for generating your stuff – you have to specify your „enhanced java syntax“ by yourself (maybe there is existing stuff).
• Use an integrated DSL workbench like Jetbrains MPS and define your „enhanced java syntax“ there …

 

Jan

To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/b9797939-5151-4ef8-af0d-33c05106e8ebn%40googlegroups.com.

[Reinier Zwitserloot]

10 year history, mostly. We're considering doing something like what you say and even made one aborted approach (the lombok.ast project). We did learn from some mistakes we made with lombok.ast, but we just haven't gotten around to it.

In other words, no particularly _good_ reason. There is 1 pragmatic upside to our current approach:

It's simpler, in that often "weird things" happen, such as cleanup-on-save actions misunderstanding what lombok generated and having to dance around the problems this causes by getting funky with the positions of the generated nodes. This is a lot more complicated to both investigate and work around if there's an abstraction layer in the middle. You need to then punch holes in your abstraction layer and have an API on the abstraction to override positions on a per-IDE basis, some sort of `node.setPositionOverride(AstType.ECJ, alternateNodeToUseAsSource, +5)`, where the 5 is an offset of sorts.