> 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
