External annotations 关注

Hello Colin,

I just tried to add an @Override annotation using the quickfix, and to
my surprise a "do you want to use external annotations" dialog popped
up. Did I miss this in the release notes? Can we get a quick summary
on how to use it?

It was left out of the release notes because the feature is still not quite
finished. To make use of the external annotations, you'll need to add an
annotations root to your module, library or JDK (using the "Attach Annotations")
button. IDEA will use the directory you've specified as the annotations root
to store the annotations in XML format (one file per package).

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Will you provide default XML files (e.g. JDK, popular libraries) bundled with IDEA? Or could we setup some short of sharing point?

Agreed, my immediate thought was that everyone will be repeating the same work. Even if Jetbrains releases JDK + popular libraries, being able to share for not-so-common libraries will be essential.

Still, I've been waiting for this functionality for ages. Can't wait :)

Hello Yann,

Will you provide default XML files (e.g. JDK, popular libraries)
bundled with IDEA? Or could we setup some short of sharing point?

Definitely not bundled. We do not want to be any kind of authority on the
notnull'ness of JDK methods. :) Also, one man's @NonNls may be something
that definitely needs localization in another project.

But as for a sharing point... I wonder what the best solution would be. Perhaps
just a project on Google Code?

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Dmitry Jemerov wrote:

But as for a sharing point... I wonder what the best solution would be.
Perhaps just a project on Google Code?

Or a Confluence space?

Sascha

Hello Sascha,

>> But as for a sharing point... I wonder what the best solution would
>> be. Perhaps just a project on Google Code?
>>

Or a Confluence space?

It's considerably much clumsier to get new versions from (I think there's
some WebDAV support in Confluence which could make this easier, but that
would take some effort to set up).

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Definitely not bundled. We do not want to be any kind of authority on the
notnull'ness of JDK methods. :) Also, one man's @NonNls may be something
that definitely needs localization in another project.

Hm, I can understand that somehow.
OTOH it's a real pity and diminishes the feature value a lot.
Joe-average-Idea-user probably does not give a hoot about external annotations.
He will be very pleased though if some editor warning about a possible null problem saves him from deploying a buggy release to a customer's site.

Also I don't really see why @NotNull annotations might be subject to different requirements.

Hello Stephen,

>> Definitely not bundled. We do not want to be any kind of authority on
>> the notnull'ness of JDK methods. :) Also, one man's @NonNls may be
>> something that definitely needs localization in another project.
>>

Hm, I can understand that somehow.

OTOH it's a real pity and diminishes the feature value a lot.

Joe-average-Idea-user probably does not give a hoot about external
annotations.

He will be very pleased though if some editor warning about a possible
null problem saves him from deploying a buggy release to a customer's
site.

Also I don't really see why @NotNull annotations might be subject to
different requirements.

No, for @NotNull the requirements are not different, but the difference between
JDK versions is a problem.

I'm thinking that InspectorGeneral's "Infer nullity annotations" could be
very much helpful here. If it could be run on the sources of each JDK release,
automatically, and save its results in our XML format, it would be hardly
less valuable than hand-picked nullable/not-null. And with no authority concerns,
too.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Dmitry Jemerov wrote:

But as for a sharing point... I wonder what the best solution would be.
Perhaps just a project on Google Code?

That's a good idea.

"Save as external annotation file" will be an option on "Infer Nullity Annotations", probably about two days after you all finalize the external annotation spec and api. We will certainly try running it on JDK sources, and seeing what we see.

Sixth and Red River Software
"Code with Grace and Verve"

That would be a killer feature! I have my credit card ready...

Bas

That's what I call a test suite.

Agreed. If I can automatically create external annotations for any open-source library, my credit card won't know what hit it.

Cheers,
Colin

Yup!

One issue to consider though is that it should be possible to have multiple separate "annotation specification xml files" for the same set of classes.
Thus we can have global @NotNull annotations and project-specific @NonNls annotations.

And BTW now that you mentioned the versioning issue: I take it that there is no means to tie a set of external annotations to a specific library version (e.g. by evaluating manifest entries)?

Aw, hell. We've been meaning to send you a license anyway for your bug reports. Apologies. It should be in your mail shortly.

Sixth and Red River Software
"Code with Grace and Verve"

Hello Stephen,

One issue to consider though is that it should be possible to have
multiple separate "annotation specification xml files" for the same
set of classes.

Thus we can have global @NotNull annotations and project-specific
@NonNls annotations.

You can attach multiple annotation roots to the same JDK/library. Not sure
if they are currently merged correctly, and I believe we don't ask you in
which root a particular annotation should be placed, but these are all solvable
problems. :)

And BTW now that you mentioned the versioning issue: I take it that
there is no means to tie a set of external annotations to a specific
library version (e.g. by evaluating manifest entries)?

How do you imagine this would work? You have a single library version attached
to your project, as a JAR file or otherwise, and you attach the annotations
to that specific version.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Just a note, we are also evaluating the possibility of creating a tool for analyzing bytecode of closed-source libraries and generating external nullity annotation files. This might be either a part of InspectorGeneral, or a separate product (possibly even just a command-line tool). There are technical challenges to such a product, but the main issue is one of market value. Given the space of Java today, it seems that use of closed-source libraries is becoming rarer and rarer, making such a tool less necessary than it might seem. Also, if JSR-305 ever comes to fruition, we should be seeing library vendors putting nullity annotations in their jars, obsoleting such a tool completely.

Thoughts? Would you recommend the purchase of such a tool, if it were priced consistent with other Sixth and Red River products, say at $59. If it were bundled with InspectorGeneral, would that help drive a purchasing decision?

Sixth and Red River Software
"Code with Grace and Verve"

Ah, I see. Somehow I had the impression that it would be possible to have an Idea-wide repository of external annotations.
That way each project that gets JDK 1.6 assigned could automatically make use of the annotations for that JDK version.

At the minimum though, you should be able to export and import external annotation definitions from a project.

If it were bundled with InspectorGeneral it would definitely affect a purchasing decision. Like you say, for $60 I'd have to have a concrete use case. As it turns out, I personally have one (we're using a few closed-source products) so I would probably be interested. These are the first closed-source libraries I've ever worked with, though.

Oh, and a product that works with closed-source libraries would have to work with obfuscated ones, as well. I suspect that probably doesn't affect the algorithm, but just a thought.

+That way each project that gets JDK 1.6 assigned could automatically make use of the annotations for that JDK version.
+

It looks like that will be possible, as annotations can be bound to a JDK. If you use global libraries, you can bind annotations there as well. If you use project libraries, you'll need to bind the annotations for each project, just like you have to do now with sources and javadoc.

--Dave Griffith

Thanks much!

Bas

There is also a wide field of sharing configurations. I think many teams
would like to share their live templates, code settings, inspection
settings, code colors etc.

I set up a SVN repository to synchronize my settings at work and at
home. But this only works until merging is necessary...

I think it would be great to have an integrated possibility to
share/synchronize/compare all those settings. Having a nice repository
with comments, previews, ... could be a great thing. Some sort of non
visual "themes".


Regards,

Johannes Schneider

Mike Aizatsky (JetBrains) wrote:

Dmitry Jemerov wrote:

>> But as for a sharing point... I wonder what the best solution would
>> be. Perhaps just a project on Google Code?

That's a good idea.

http://www.jetbrains.net/jira/browse/IDEADEV-12114

Nice!

Can we get some stricter nullity checking now? Please?

This looks great :)

So: What did you see?