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

So assuming we use the workaround from bug 442524, which component should the workaround go in? Given that it's global, it would be good to put it in only one place so that we don't end up with different workarounds fighting one another if we ever decide we don't want the workaround anymore.

Possible locations for the workaround:
- JDT core (since it loads annotation processors and needs the workaround most urgently).
- P2 (since it's lower-level and Sergey alluded to the fact that it has the same problem)
- The IDE's initializer (since this is a product-level policy)

  - Stefan

On Fri, Sep 30, 2016 at 6:34 PM Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:
Running in a separate VM is not going to happen overnight, but we can have a workaround for the crashes much sooner. It has chances to fix a P2 file caching issue too.

-sergey



On Fri, Sep 30, 2016 at 6:28 PM, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
I filed a bug about this last year:


We could continue the discussion there.

My proposal was for Eclipse to use the same approach as intellij and launch the compiler in a separate JVM.

On Thu, Sep 29, 2016 at 8:56 PM Walter Harley <eclipse@xxxxxxxxxxxxxx> wrote:
As an aside - probably this discussion should be happening in a bug, so that it is discoverable in the future.

The problem with classloading is that, at least historically (JDK 6 and before), the JVM put classes into old gen, so they effectively would never get gc'ed, so the classloaders would never get freed.  We experimented with workarounds for that, unsuccessfully.  If you want to explore it, feel free to give it a go.  Basically the pass criteria would be that you should be able to modify a processor (that uses all the interesting bits of the APT API, such as creating output streams) and re-run, without exiting Eclipse.  Bonus points for not leaking memory with each compile.

On Thu, Sep 29, 2016 at 3:05 PM, Gilles Duboscq <gilles.m.duboscq@xxxxxxxxx> wrote:
On Thu, Sep 29, 2016 at 10:31 PM Walter Harley <eclipse@xxxxxxxxxxxxxx> wrote:
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.
What is the problem exactly?
In particular which problem would not be solved by using a specific class loader for each "annotation context"?

 Gilles

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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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