[project lombok] Are you really working on an IntelliJ-plugin for Lombok?

[lazee]

Hi,

Please read this issue: http://youtrack.jetbrains.net/issue/IDEABKL-5667#content-tab=0

Is this a misunderstanding or really true?

/Jakob

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en

[lazee]

I forgot to mention that you should read the comment saying:

"As far as I understand the Lombok guys plan to develop an IDEA plugin
themselves. We don't have any plans to work on that internally at the
moment."

On May 14, 9:51 am, lazee <jakobvadniel...@gmail.com> wrote:
> Hi,
>
> Please read this issue:http://youtrack.jetbrains.net/issue/IDEABKL-5667#content-tab=0
>
> Is this a misunderstanding or really true?
>
> /Jakob
>
> --
> You received this message because you are subscribed to the Google

> Groups group forhttp://projectlombok.org/

[Reinier Zwitserloot]

Hi lazee,

I think Dmitry has misunderstood what we said, and perhaps that's our
mistake for not communicating this clearly.

We are NOT working on an IntelliJ plugin. Since IntelliJ Community
Edition has been open sourced, however, we're fairly sure that, if it
comes to that, we COULD make it. We also WANT to make it, and what
we're working on right now (unified AST) has as one of its many goals
making it easier for us to develop and support an IntelliJ plugin if
it does indeed come to that.

Regardless of our intentions, the current _featureset_ of IntelliJ as
far as source processing is concerned may not be suitable compared to
the other two major IDEs: Since Netbeans 6.9, and for eclipse since a
long long time, all major IDEs that aren't called "IntelliJ" run
annotation processors during the edit process. Even if IntelliJ did
run annotation processors, that doesn't mean lombok will 'just
work' (Lombok uses some private API hacks, which is of course our
fault, but there's no other way to do what lombok does), but it does
mean if we do write that plugin, it'll be (A) far simpler, (B) far
less intrusive into your IntelliJ session, (C) more stable, and (D)
far less likely to break when a new version of IntelliJ is released.
On the flip side of this argument, I hear (but haven't been able to
confirm) that unlike Netbeans and Eclipse, IntelliJ's plugin
architecture actually lets you plug into the parse and compile
process, so IntelliJ may already offer a relatively straightforward
way to write a lombok plugin.

In other words, if IntelliJ wants to officially support lombok, that'd
be _FANTASTIC_, and we'd gladly help the IntelliJ team with whatever
they need to make that happen. Failing that, at least supporting
running annotation processors as-you-edit would help a lot. Even if
the status quo doesn't change at all we'll hopefully get to it at some
point, but we haven't started yet and I can't make any promises when
we start the work, let alone when a first release will be available.

[lazee]

Thanks Reinier for your reply. I have linked your reply to the issue.
Hope you don't mind.

[Reinier Zwitserloot]

No, on the contrary, thanks for doing that!

--Reinier Zwitserloot

[Dmitry Jemerov]

Hello Reinier,

Regarding the specific implementation details: IntelliJ's edit-time
features do not use a Java compiler at all. Instead of running a
compiler (and annotation processors) and then analyzing the
generated .class files, IntelliJ does its own parsing of the code,
building the model (which we call the PSI - Program Source Interface),
and all further features work on top of the model. And there's no way
to add "running annotation processors" to this process, so it's not
really going to happen.

However, our plugin architecture does allow to extend the model which
we build for regular Java classes, and to provide additional
declarations (for example, methods generated by Lombok's annotation
processor) which are not present in the source code. For example, our
AspectJ support is currently being developed as a real honest plugin -
and inter-type declarations also contribute additional members to
regular Java classes.

Because of that, there's no reason for the Lombok plugin to be
intrusive or unstable. It does mean that a certain part of the
annotation processor logic would have to be duplicated inside the
plugin and kept up to date as Lombok evolves, though.

As for our plans, the Lombok support is currently not on the IDEA 10
roadmap, so the only chance for a JetBrains-developed plugin to appear
in 2010 is if someone on the team decides to hack on it as a spare
time project (and such things do happen with our developers from time
to time :) ). However, we'll be happy to help you with working on the
plugin. And if my understanding is correct, it won't require too much
of an effort - you can have something decent up and running in a
couple of weeks, I'd say.

[Reinier Zwitserloot]

Thanks for confirming that's how IntelliJ works. We had our suspicions it worked like this, and it's a perfectly fine model to work on. Though, I think you could technically support running annotation processors (in the plain sense; lombok isn't really an annotation processor, it just masquerades as one so it gets called at the appropriate time in the process) by writing wrappers around the PSI model that fit the interfaces in javax.lang.model. But that's neither here nor there and really wouldn't help lombok much, given that we'd have to write everything against the PSI; lombok currently runs directly on the inner AST representation from both javac and eclipse, and IntelliJ has its own model for it.

The next major lombok release will feature a unified AST and that should help.

--Reinier Zwitserloot