[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Apt processor handling
|
Thanks for the intensive discussion and a special thanks to Stefan for
creating the bug report.
Best regards, Lars
On Sat, Oct 1, 2016 at 3:52 AM, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
> I've extracted Lars' original usability email to this bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=502998
>
> Let's move the end-user workflow discussion there. I also added my own
> suggestion, which is to have quite a lot of options but to select defaults
> that behave pretty much like NetBeans.
>
> - Stefan
>
> On Fri, Sep 30, 2016 at 6:49 PM Sergey Prigogin
> <eclipse.sprigogin@xxxxxxxxx> wrote:
>>
>> On Fri, Sep 30, 2016 at 6:40 PM, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
>>>
>>> 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)
>>
>>
>> If it does solve stale P2 cache of local repositories, it should probably
>> go into IDE initializer, otherwise into JDT core.
>>>
>>>
>>> - Stefan
>>
>>
>> -sergey
>>>
>>>
>>> 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:
>>>>>
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=472175
>>>>>
>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
--
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
