Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-core-dev] Apt processor handling

There's been considerable discussion of this over the years.  It has to do with classloading.  The annotation processor classes need to be loaded into the compiler VM (or alternately, the entire Java model needs to be shipped over a VM boundary).  For Eclipse, that means loading them into the IDE.  Which means that once an annotation processor class is loaded, it effectively cannot be unloaded without restarting Eclipse.

The assumption has been that if an annotation processor is in the *project* path, it may well be something that the customer expects to change and recompile.  That will not work, if we can't unload it after the first time it runs.

IntelliJ uses the javac compiler, launched in a separate process which terminates at the end of compilation.  Thus it reloads every time (but, it does not get the benefit of incremental compilation or annotation processing).

Whether those assumptions are still true or relevant I can't say, but that's the background.

Perhaps more to the point, though, I do not think there is much in the way of active investment in the APT project.  It was driven initially by BEA, who needed to support annotations for their Weblogic product and wanted to use the Eclipse IDE rather than their proprietary IDE.  BEA contributed several developers for several years on this project (I was one of them).  BEA no longer exists; I don't think these days there is anyone with such a strong vested interest in improving annotation processing; and the Java annotation processing API is cumbersome enough that I don't think many annotation processors have become mainstream.

On Thu, Sep 29, 2016 at 4:58 AM, Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
Dear JDT core developers,

A fellow Java champion pointed out to me that the annotation
processing setup in Eclipse is very complex compared to other IDEs.
Here is what we wrote me (slightly reworked for readability):

QUOTE_BEGIN
------------
- NetBeans automatically finds APT JARs in the classpath. You can't
turn it off. You can't tweak any settings.
- IntelliJ  allows to activate APT processing (per project) with a
checkbox; this will find all available APT JARs in the classpath by
default. You can also configure which JARs may be used.
- Eclipse forces you to locate and define every APT JAR by hand, per project.

This means NB is on one side of the spectrum (fully automatic) where
Eclipse is at the opposite side (fully manual), while Intellij sits
somewhere in between.

Example instructions for all IDEs can be found at
http://griffon-framework.org/tutorials/1_getting_started.html#_tutorial_1_4
------------
QUOTE_END

I have not used apt-processors myself in Eclipse but this setup sounds
relatively complex compared to the other alternatives.

Are there plans to improve this? Without knowing the technical details
here, maybe a "Search in project classpath" option could be added?

If I understood him correctly, several customers are selecting NB or
IntelliJ because of that complex Eclipse setup and I promised him to
to ping the JDT developers about this.

Best regards, Lars
--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com

_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev


Back to the top