Re: [jdt-dev] Using annotation processors within JDT code

[Jayaprakash Arthanareeswaran <jarthana@xxxxxxxxxx>]

Sorry for coming into the discussion late. Looks like we have already had covered most of the points. Only point I would like to highlight is that:

We are getting bug reports 'now' that seem to have been around for ever [1]. Even couple of the NPE bugs that Stefan talk about in the other thread fall into this category.

This seem to bolster the argument that APT probably has not been tested enough. But it is also a good thing we now get an opportunity to address these problems. I understand these bugs didn't get the attention that you may have wanted. But together we should be able to make things better.

And finally coming to the question at hand, I agree with Stephan and Dani that JDT Core is probably not the right component to do this. But we will be glad to help anyone willing to do that.

Regards,
Jay
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=478427
     https://bugs.eclipse.org/bugs/show_bug.cgi?id=478225

Daniel Megert ---10/19/2015 12:59:57 PM---Hi Stefan I'm all also a big fan of eating our own dog food. Unfortunately, in this

From: Daniel Megert <daniel_megert@xxxxxxxxxx>
To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
Date: 10/19/2015 12:59 PM
Subject: Re: [jdt-dev] Using annotation processors within JDT code
Sent by: jdt-dev-bounces@xxxxxxxxxxx

---

Hi Stefan 

I'm all also a big fan of eating our own dog food. Unfortunately, in this particular case, we have lots of food but not enough dogs. And every dog prefers different food. 

I suggest that those that already use annotation processors and heavily depend on it, start to dig deeper into the APT code and help to contribute with the goal to become committers. As other JDT committers already pointed, we are willing to provide feedback and also help. 

I'm fine if a project like Platform UI wants to start using APT so that we have closer feedback loops. 

Dani 



From:        Stefan Xenos <sxenos@xxxxxxxxxx> 
To:        "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx> 
Date:        18.10.2015 04:27 
Subject:        Re: [jdt-dev] Using annotation processors within JDT code 
Sent by:        jdt-dev-bounces@xxxxxxxxxxx

---

Fair enough.  

If Jay is the man on point, his opinion is critically important on this matter. If my suggestion of dogfooding won't be helpful to him, I agree we should punt it. 

On Sat, Oct 17, 2015 at 6:58 AM Stephan Herrmann <stephan.herrmann@xxxxxxxxx> wrote: 
Eclipse projects have one big advantage over "external" users:
they can consume corrections in JDT per I-Build, not just per release.
And if JDT gets useful feedback at the same rate, this might
actually allow us to cut down our procrastination & hesitation
about proposed patches to some degree :)

But I should really let Jay have his say.

Stephan


On 10/17/2015 03:37 PM, Stefan Xenos wrote:
>  >  From my p.o.v. *any* Eclipse project / component could step up into the important role of using annotation processing and filing
> excellent bug reports which would perhaps allow
>  > us (Jay) to fix those bugs more efficiently, so we wouldn't trade better support for annotation processors with "devastatingly
> bad" support for Java 9 when the time comes.
>
> Actually, I've been considering this, too. We could start using annotation processors in - say - the UI component (I have some ideas
> for using them to enforce the correct use of databinding tracked getters).
>
> My concern is that the teams using the annotation processors would then get blocked on the APT bugs for a long period of time and be
> unable to fix them themselves. Any workflow-breaking bug they encountered would get mixed in with the rest of the bugs and could sit
> unfixed for a long time. Dogfooding within APT would be preferable since anyone blocked by a bug would be more likely to be able to
> do something about fixing it -- and blockers would be immediately sifted out from the rest.
>
> The idea is not without merit, though. If JDT were willing to dogfood annotation processors, I think I could convince platform UI to
> do so as well. More widespread testing is definitely better.
>
>    - Stefan
>
> On Sat, Oct 17, 2015 at 6:19 AM Stefan Xenos <sxenos@xxxxxxxxxx <mailto:sxenos@xxxxxxxxxx>> wrote:
>
>     I'm really sorry, I didn't mean to give offense and shouldn't have used such inflammatory language. I don't want to disparage
>     the efforts of our few overworked JDT committers -- you guys rock and I appreciate all you're doing. By "devastating", I was
>     referring to the impact of the bugs upon affected users, not trying to imply this is the fault of the committers.
>
>      > From my p.o.v. *any* Eclipse project / component could step up into the important role of using annotation processing and
>     filing excellent bug reports which would perhaps
>     > allow us (Jay)to fix those bugs more efficiently
>
>     IMO, all teams should be dogfooding their own features since it's always way easier to fix a bug you discover while working on
>     your own code than it is to try to describe that bug to someone else. Quite often you'll discover such bugs while you have the
>     debugger open anyway. It's also much easier to do bug triage when you're dogfooding -- it's hard to tell the difference between
>     a showstopper and a mild annoyance when you're looking at a stack trace attached to a bug report and the difference is much more
>     obvious when you're experiencing it yourself. We all have way more incoming bugs than we can possibly fix, so good triage is
>     important.
>
>     >few examples of "devastatingly bad" shape might help
>
>     I'm told by teams that do a lot of annotation processing that the compiler crashes on them frequently. A lot of my time at the
>     moment is spent responding to user emails about Eclipse problems, and there seems to be a large cluster of reports around
>     annotation processors. A lot of those crashes are caused by NullPointerExceptions. All of the bugs I'm aware of are in bugzilla
>     (I've either filed them or updated them with any information I could locate).
>
>     I'd also like to try to help out more directly: I suspect my customers would benefit more from me fixing annotation processor
>     bugs than the UI stuff I normally work on since this is what they complain about the most. Unfortunately, I'm still climbing the
>     slope of the JDT core learning curve, so it may be some time before I can contribute decent fixes... but I'm very interested in
>     trying to help Jay out in his difficult task.
>
>     I'm not sure that's enough, though -- dogfooding would go a long way toward making the bugs easier to reproduce.
>
>      > As another factor, I don't think it would be a good idea to use any kind of magic in the compiler source code, because this
>     piece of code is used for bootstrapping in several projects and should be compilable with minimal requirements.
>
>     Would the use of annotation processors really be considered magic for the annotation processing sub-component?
>
>      > I personally don't think dog-fooding in JDT is the silver bullet here.
>
>     Oh, I agree. Dogfooding won't fix all our problems... I just think it will make it easier to fix a lot of them.
>
>        - Stefan
>
>     On Sat, Oct 17, 2015 at 4:50 AM Stephan Herrmann <stephan.herrmann@xxxxxxxxx <mailto:stephan.herrmann@xxxxxxxxx>> wrote:
>
>         Hi Stefan,
>
>         Thanks for caring about the quality of JDT.
>
>         I believe Jay is well aware of open bugs, not sure he would use
>         such drastic words as you. Just in case you disagree in the
>         extent of the problem, a few examples of "devastatingly bad" shape
>         might help.
>
>         So, I don't really think it's a matter of awareness. I think it
>         is as simple as lack of man power / time to fix the known bugs
>         or even just review proposed patches.
>
>         Just 3 full time JDT/Core committers is not a comfortable
>         situation to be in. Situation in other JDT components is
>         similar I believe.
>
>         E.g., I personally still have a number of compiler bugs on my
>         plate, where we still don't correctly handle some corner cases
>         of Java 8 type inference. As long as that back log of compiler
>         errors is filled the most effective use I can make of my spare
>         time is fixing compiler bugs. Awareness of problems in annotation
>         processing just "distracts" me from an essential task.
>
>         Jay as component lead and main driver of the Java 9 efforts
>         has "more important" tasks on his plate, too. As I understand
>         him he just stepped into the role of working on annotation
>         processing *because nobody else could*. So we need two Jays.
>
>         As another factor, I don't think it would be a good idea to
>         use any kind of magic in the compiler source code, because this
>         piece of code is used for bootstrapping in several projects
>         and should be compilable with minimal requirements. This could
>         mean that only non-core plug-ins of JDT might qualify as the
>         dog-food-eaters.
>
>           From my p.o.v. *any* Eclipse project / component could step up
>         into the important role of using annotation processing and
>         filing excellent bug reports which would perhaps allow us (Jay)
>         to fix those bugs more efficiently, so we wouldn't trade better
>         support for annotation processors with "devastatingly bad"
>         support for Java 9 when the time comes.
>
>         Yes, we need to find a way to make both ends meet, but I personally
>         don't think dog-fooding in JDT is the silver bullet here.
>
>         regards,
>         Stephan
>
>         On 10/17/2015 08:17 AM, Stefan Xenos wrote:
>          > Eclipse's support for annotation processors is not in great shape. The compiler crashes a lot... and this sort of bug
>         tends to be
>          > both devastatingly bad and also really hard to reproduce outside the code you found it in. Also, many (most?) Eclipse
>         committers
>          > don't use annotation processors in their own code and aren't familiar enough with them to help with bugfixes, which puts
>         a bigger
>          > burden on the others.
>          >
>          > ...so we end up with some really serious APT bugs that have gone unfixed for a long time.
>          >
>          > I'd like to suggest a solution: we could start using annotation processors within the implementation of JDT. I'd suggest
>         we start by
>          > adopting some open-source processors that do something simple and useful (like https://github.com/google/auto or Dagger ).
>          >
>          > I'm basically suggesting dogfooding APT.
>          >
>          > What will this accomplish?
>          > - JDT developers will be more likely to notice serious APT bugs early.
>          > - When we do encounter bugs, we'll see them in Eclipse code that all committers have access to (rather than in
>         proprietary customer
>          > code).
>          > - More widespread knowledge about using and developing annotation processors will mean more committers who are able to
>         help fixing
>          > these bugs.
>          >
>          > So what do you think? Could we make use of a few annotation processors within JDT? Would auto-value be a good first adoptee?
>          >
>          >    - Stefan
>          >
>          >
>          > _______________________________________________
>          > jdt-dev mailing list
>          > jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
>          > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>          > https://dev.eclipse.org/mailman/listinfo/jdt-dev
>          >
>
>         _______________________________________________
>         jdt-dev mailing list
>         jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
>         To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>         https://dev.eclipse.org/mailman/listinfo/jdt-dev
>
>
>
> _______________________________________________
> jdt-dev mailing list
> jdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jdt-dev
>

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