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

I believe recent Oracle JVMs can garbage collect loaded classes, at least this appears to work inside m2e. Beware of JVM bug [1], which results in JVM crash in some cases. Our workaround was to disable URLConnection cache for entire Eclipse JVM (see bug 442524 [2]).

[1] https://bugs.openjdk.java.net/browse/JDK-8031691
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=442524

--
Regards,
Igor


On Thu, Sep 29, 2016, at 11:56 PM, Walter Harley 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
------------
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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

_______________________________________________
jdt-core-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

_______________________________________________
jdt-core-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________
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