[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Supporting Nullability in JDT core
|
> *If* we'd call out null annotations as a top
> priority for the next milestones,
Given that we haven't done so yet, I'm looking for a solution that lets me benefit from nullability testing without impacting the workflow of anyone else.
Hi Stefan,
Thanks for your detailed thoughts. Yes, I want to see
null annotations used in Eclipse source code!
However, my gut feeling tells me that comprehensive use
of null annotations in JDT/Core is a task much larger than
what we can chew with the given man power and specifically
in times when Java 9 has absolute priority.
In particular, the compiler is written in a style that is not
well suited for complete null checking: too many arrays, too
many public fields that are uninitialized at object creation
but assumed to be non-null in later phases, etc. "Type state"
would be a good approach for this section of the code, but
that's a different animal.
As an alternative, I spoke to Noopur to use her new JUnit5
plugin as a first guinea peg in JDT land. A first plugin
for dog-fooding null annotations.
Will you be at ECE in Ludwigsburg? I'm looking forward to
Mike Vorburger's talk, and I was thinking of having a BoF
on spreading the use of null annotations. Also Manoj and Till
will be in Ludwigsburg, and we should set aside some time
to discuss this and other issues among the team.
Some preliminary technical answers:
Location: The tricky part here is to check which build
technology is ready to find external annotations and properly
feed them into compilation. Maven/Tycho doesn't yet have
the smooth support that I am aiming at. They'd probably
require to put the external annotations on the classpath
and use CLASSPATH as the annotation location to search.
In Object Teams I have one plugin configured with external
annotations within the project and that's pretty straight-
forward to set up, but then in Object Teams I'm still using
PDE/Build, not Maven/Tycho, but that should be feasible.
I don't think we can use a setup that depends on a specific
workspace layout.
One package at a time: the idea of "unchecked" warnings is
to have those problems that are due to incomplete migration
appear as warnings, not errors. *If* we'd call out null
annotations as a top priority for the next milestones,
we'd have to live with lots of warnings for a while,
reminding us to complete that work. For those of your
proposals that call for changing the compiler, let's
throw them into the discussion with other adopters.
If your proposals mend a sore spot that's also observed
by others this should be worth it, but at this point
I'd refrain from adding new features that are driven *only*
by our own needs.
As for interfacing with yet-unannotated Eclipse plugins:
I'd definitely opt for: use external annotations for now
and at the same time submit patches to the upstream project.
But beware, that annotations that make perfect sense at
their API may require more work in method bodies to be
accepted by the analysis.
Short term suggestion: I see that null annotations could
directly help you to harden the new index implementation.
For that purpose, couldn't you
- annotate *new* classes / packages as desired
- add folders for external annotations locally in JDT/Core --
I suggest "annotations/jre" and "annotations/plugins" for now.
- but DON'T commit any changes to compiler settings
So, locally, you'd have two sets of settings, one just for
your local null-annotation-aware workspace build, and one
that's used in official builds, without null annotations.
Does this sound feasible as a starting point?
Stephan
_______________________________________________
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
