Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] Using annotation processors within JDT code

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




Back to the top