POLL: @Nullable etc.
Recent discussion here convinced us to implement @nullable and @nonnull annotations
in 'constant conditions & runtime exceptions' aka 'data flow analysis' inspection.
The final question is quite simple: how those annotations should be named
and in what package they should reside?
The variants so far are as follows:
@nullable, @Nullable
@nonnull, @notnull, @NotNull, @NonNull
as to package, org.jetbrains comes to my mind.
Suggestions?
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
Please sign in to leave a comment.
Too bad we can't have @null, damn reserved words :P
Anyways, I'm bending towards @nullable and @notnull, for pragmatism. Other options would be @notnullable (for consistence) or @nonnull (for correctness). And org.jetbrains sound good enough till we have a standard on this.
@Nullable and @NotNull (the capitals may be ugly, but standard is better than better) in package com.jetbrains (unless you guys have become not-for-profit recently).
--Dave Griffith
Those annotations are non-profit for sure. I mean people would like to distribute
annotations.jar with their code.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
@Nullable
@NotNull
Then should it be org.jetbrains or org.jetbrains.analysis?
(Yes, I am thinking in terms of other analysis annotations.)
--Dave Griffith
Or better org.jetbrains.annotations? Like java.lang.annotations.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
Maxim Shafirov (JetBrains) wrote:
I was about to throw that one in as well.
@notnull and @nullable because lowercase looks like a keyword and
notnull instead of nonnull because the latter looks kinda ugly in
all lowercase letters.
Sascha
Works for me
--Dave Griffith
@nullable and @nonnull seem best to me.
I like package org.jetbrains.annotations.
Regardless of the word used, if the standard is to use CamelCase words,
then that's what Jetbrains should use. It provides just that little less
resistance to making it a proper Sun Java standard.
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001
This one is real argument, no doubt.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
Agree. While I like the lower-case version better from a stylistic point
of view, I have to agree that JetBrains should probably stick to the standards.
Tobin
I would vote for this.
Tobin
I would probalby have to go with @Nullable and @NotNull.
Tobin
Summarizing those are:
@org.jetbrains.annotations.Nullable and
@org.jetbrains.annotations.NotNull
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
@Nullable
@NonNull
One vote here. I think the camel case in the annotations is ugly, but if it's the convention I can get used to it. The important part is the functionality, which I can't wait to get my hands on.
Bas
I feel very strongly about nonnull (or NonNull) instead of notnull (NotNull).
"notnull" simply contradicts the style of every other java modifier (public,
static, final - these are all adjectives).
I don't have a strong opinion for NonNull vs. nonnull. I think @nonnull looks
nicer and fits better with Java language, but all standard annotations (SuppressWarnings,
Override) start with capital letters like class names so maybe we should
go with this.
I don't mind the package.
I don't see yet the purpose of having @nullable and @notnull. Aren't
they orthogonal? If a variable is not @nullable, what is it then? I
assume, @notnull. But existing code always is nullable, so declaring one
@nullable is IMHO redundant, so only @notnull is useful.
Otherwise I always try to keep my variables not null (and have a lot of
assertions to enforce this for method parameters), so writing @nullable
in our code, most likely would be less work and less clutter.
Tom
You may have noticed that IDEA will not mark this code:
String s = someMethod();
s.toString();
However, IDEA will mark this with a warning:
String s = someMethod();
if (s == null) System.out.println("s is null");
s.toString();
Specifically, I believe it will mark the s.toString() call, saying "s may
be null" or something.
Anyway, this is about usability and heuristics. We all know that every reference
in Java could be null, but I think almost no one would want every single
reference to be highlighted, because 80% of references or so would be highlighted,
and many of them would be for values which are documented as not null in
Javadoc, or we know from experience that they are not ever null. So, if it
highlighted every possible null, IDEA would be cluttering your editor with
distractions. Instead, it only chooses the values which you have explicitly
checked for nullness already, because you must care about those values' nullness.
So, @nullable is a means for an API developer to say "I've thought about
this method, it may or may not return null." And tools which understand @nonnull
and @nullable can be stricter when they see @nullable than when they see
no annotation at all.
And please, stand back and think about it, @notnull violates the naming convention
for Java declaration modifiers. I think if we all think about it maybe we
will all realize this, and decide on @nonnull. :)
Hi Keith,
Yes, I know this. I just don't understand why adding both annotations.
Could you (or somebody else) please show a sample, where both
annotations and un-annotated references are used?
BTW, I've read a programming language (forgot the name) lately, which
used a preceding '!' to mark nullable references. All other references
were non-null out of the box.
You know, I'm no native speaker, but for me speaking "notnull" sounds
easier than "nonnull", which sounds like "no null".
Tom
class Test {
@Nullable nullable() { return null; }
@NotNull Object notnull(@NotNull Object p) { return p; }
Object unannotated(Object p) { return p; }
void foo() {
notnull(nullable()); // Flagged error
notnull(unannotated(null)); // No error flagged, though there's actually.
Object o = notnull(new Object()); // OK
if (o != null) { // Condition always true.
//something
}
}
}
Something like that. Generally saying, those annotations allows a static
analysis tool to make certain assumption on whether null reference can happen.
If there's no annotations then no additional assumptions can be made.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
Vote for CamelCase - don't have a strong feeling about NonNull versus
NonNull.
R
If there's no annotations, the tool should behave according to some user-specified (project-wide) preference. Otherwise, one would have to mark all methods with one annotation or the other.
When you're working with existing code, it's ok to have both annotations: you will add them on new methods, or on the methods where the null/non null semantic seems less obvious. However, when you're working with a fresh new codebase, it's much easier to assume that all methods can take or return null, unless specified otherwise -- or the other way around.
I strongly disagree with this. At least your code will always be using some
3rd party libraries (JDK for instance) which wouldn't be necessarily annotated.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
@org.jetbrains.annotations.Nullable seems perfectly reasonable.
I wish I'd thrown this objection in yesterday, but I don't love negating apositive assertion. That's what all the not/n null(able) options do. They tend to not illuminate and be non-intuitive, and I'm not likely to use them.
The problem is lack of a conventional affirmative meaning "guaranteed to have value". Surfing the dictionaries online culled the probably too obscure, but rather apt @Extant. Formally, it is the opposite of extinct. "Extant manuscripts" is cited as usage by Houghton Mifflin via http://www.answers.com/extant
As a native English speaker, it feels too high-brow and even a little obscure. A fancy-pants version of "existing", perhaps.
On the positive side, it has no tech history that I know of, is of clean latin origin, and is easy/obvious to spell. I think it would lodge itself into my crowded little head without a problem.
The biggest objection is that it would be creating jargon. (confession: I'm the kinda geek who names his machines after pre-cambrian species) I should probably just hit the "Cancel" button for that reason, but I'm posting on the off chance this catches on or prompts a less obscure thought from someone.
Max, Bill Pugh of UMD's FindBugs is interested in a similar set of standard
annotations. I told him to contact you so that both of you can benefit from
some agreed upon standard.
Also, you said JB might be interested in supporting or leading a JSR about
such annotations. My father Doug Lea told me that you should feel free to
contact him for help about the mechanics of starting and leading a JSR. His
e-mail is dl@cs.oswego.edu.
Max, do you suppose the names you guys have decided on (org.jetbrains.annotations,
NotNull, Nullable) are final? I would like to support some standard naming
convention for my Nully project, but I feel funny about supporting those:
1. I think NotNull is very bad style and I don't want to associate my project
with it
2. I think Nullable may be confusing because the name implies the value may
be null, but null cannot be assigned to it
And while I could support both your annotations and mine, IDEA will probably
only support the org.jetbrains.*. So I have a dilemma, your names conflict
with my idea of naming and style, but using my own custom annotations has
interoperability problems.
What do you think I should do? Will the names change?
Thanks,
-Keith
I do not have any preferences for the names myself so those names were choosen
mostly upon polling eapers. The names could probably change if necessary
but I feel this should happen as soon as possible if ever since people will
start annotating their code and rename will break it.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
It's the EAP. If we worried about things breaking, we wouldn't be here. Getting this functionality out was a great thing, and if you change the name out from under me a dozen times, it's still a net win.
--Dave Griffith