[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] Using annotation processors within JDT code
|
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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev
