Community
Participate
Working Groups
The prototype implementation for bug 186342 and friends makes good progress. If we release the required API for 3.7M6 we will have a fair chance of releasing the actual implementation for 3.7M7. Since most of the implementation is internal within JDT/Core only a few constants in JavaCore and IProblem are required for implementing the UI side. The essential constants (incl. their semantics) don't seem to be controversial, so even if the implementation is not considered done by M7 no harm is done by releasing the API. We may/may not consider actual annotation types to be part of that API, too. Note, however, that users can use their own annotation types (or those of another tool provider). The prototype is documented in http://wiki.eclipse.org/JDT_Core/Null_Analysis#Actual_Strategy_in_the_JDT which by now is stable enough to serve as a basis for further discussions.
Created attachment 189894 [details] provided annotation types This zip contains the proposed annotations which are used if no different annotation names are configured. Draft doc comments are included.
The constants in question can be summarized as follows: new option configuration keys (legal option values in parens): COMPILER_ANNOTATION_BASED_NULL_ANALYSIS (enabled/disabled) COMPILER_NULLABLE_ANNOTATION_NAME (fully qualified name) COMPILER_NONNULL_ANNOTATION_NAME (fully qualified name) COMPILER_NULLABLEBYDEFAULT_ANNOTATION_NAME (fully qualified name) COMPILER_NONNULLBYDEFAULT_ANNOTATION_NAME (fully qualified name) COMPILER_NULLNESS_DEFAULT (unspec./nonnull/nullable) new problem reporting options: COMPILER_PB_NULL_CONTRACT_VIOLATION COMPILER_PB_POTENTIAL_NULL_CONTRACT_VIOLATION COMPILER_PB_NULL_CONTRACT_INSUFFICIENT_INFO IProblems: direct contract violations: DefiniteNullFromNonNullMethod PotentialNullFromNonNullMethod NonNullReturnInsufficientInfo DefiniteNullToNonNullParameter PotentialNullToNonNullParameter NonNullParameterInsufficientInfo DefiniteNullToNonNullLocal PotentialNullToNonNullLocal NonNullLocalInsufficientInfo conflicts with inherited contracts: IllegalRedefinitionToNullableReturn IllegalRedefinitionToNonNullParameter IllegalDefinitionToNonNullParameter new warnings/errors on usage of annotated elements: PotentialNullMessageSendReference RedundantNullCheckOnNonNullMessageSend The first two groups of option keys are needed for new entries in the preference pages. Constants in IProblem are needed for quickfixes. Some of these constants are unchanged from my patch in bug 186342 comment 75. At this point I'm omitting those constants that were subject to dispute in bug 186342 (emulation and default import of annotation types). Among the option keys only the constants for default nullness are new over the previous patch. I will attach a draft patch incl. doc comments upon initial thumbs-up.
I'm concluding this request with an personally biased assessment of where we currently are: CONCEPTS: ========= We have a consensus about the core understanding of @Nullable and @NonNull - slight dissent about a possible distinction between @Nullable and no annotation at all. + I hold that original Java semantics are different from @Nullable, because dereferencing a normal Java value is a normal thing, whereas dereferencing a @Nullable value is an error (at least warning). + By supporting the un-annotated state we are still open to dis-allowing it by *requiring* a top-level default if null annotations are enabled. If we equate non-annotated with @Nullable from the beginning, there's no way we can restore the distinction later. Regarding defaults we have a superset of what others provide: + per workspace/project default + per package default + per type default (ev. possible for nested types) The rules are what everybody expects for nested scopes. Regarding inheritance we have + agreement about conformance rules + a majority (I believe) for "automatic" inheritance (vs. needing to explicitly repeat annotations from an overridden method) Concerns about visibility: + It may happen that a declaration is governed by annotations somewhere else (default or by inheritance). Within the IDE we have plenty of means to visualize the "effective null contract" without the need to bloat the code with fully explicit annotations at every possible location. IMPLEMENTATION: =============== Two mechanisms which work well during full build currently cause some grief in other compilation scenarios (incr. build, AST creation ...): Annotations applied from defaults at enclosing scopes and inherited annotations my not be processed in time. + There is a possible fallback: if "automatic" inheritance is omitted for now the remaining dependencies can be easily computed during completing type bindings. I would regret this but it would be a compatible workaround.. + Annotation inheritance also needs to be addressed for APT scenarii, so we should actually investigate possible real solutions here. (I do have an idea and a half). Implementing the prototype unveiled a few existing bugs / inconsistencies in JDT/Core, which are being addressed. NON-CORE ISSUES: ================ We already have a number of quickfixes, which seem to work well modulo two technical issues (cross-cu fixes in bulk-mode / availability of inherited annotations on secondary AST types). (I only have medium knowledge in this field, so the code will need some cleanup by an expert). Implementing the additions to preference pages shouldn't be an issue, right? NICE-TO-HAVE: ============= I may even have the time to implement within the M7 time frame: + null annotations for fields (maybe restricted to fields with initializers) + nullity profiles for 3rd party code (several ideas exist) FEEDBACK: ========= I have seen no critique regarding the prototype I uploaded 4 weeks ago (I just updated it to version 0.7.1 today). Nor did anyone complain about the content of the wiki page (except for comments on the old brain-storming which I've moved to a sub-page). So, what should prevent us from trying to get this done for 3.7?
>FEEDBACK: >========= >I have seen no critique regarding the prototype I uploaded 4 weeks ago >(I just updated it to version 0.7.1 today). >Nor did anyone complain about the content of the wiki page (except for >comments on the old brain-storming which I've moved to a sub-page). > > >So, what should prevent us from trying to get this done for 3.7? Sorry about the missing feedback. We are currently very busy as we had to close down on 3.6.2 and had to work on other fixes besides the Java 7 work which is our highest priority as I already mentioned in our phone call. We don't want to try and/or ship an unpolished item with 3.7 and there are just no cycles left in the team to do this.
I hope you didn't get the impression that I wanted to publish an unpolished feature. From my own POV there would be good chances to have it polished within the 3.7 time frame, but if indeed no cycles are free for reviews then this won't work. In this light a separate request to release the API makes no sense, and we can continue on the existing bugs. I still hope this "status report" was maybe helpful in some way, given that the master bug is already too long for anybody to read all the comments.
> I still hope this "status report" was maybe helpful in some way, given that > the master bug is already too long for anybody to read all the comments. Yes, definitely Stephan. Thanks for staying tuned with us. We'll make sure this is put on the 3.8 plan so that we can plan ahead for the needed resources.
(In reply to comment #6) > > I still hope this "status report" was maybe helpful in some way, given that > > the master bug is already too long for anybody to read all the comments. > Yes, definitely Stephan. Thanks for staying tuned with us. We'll make sure this > is put on the 3.8 plan so that we can plan ahead for the needed resources. OK, I'll keeping posting my status. Looking forward to the times of Juno, or will it be Jasmine? :)
Verified for 3.7M6
