alternative to FindBugs DefaultAnnotation for javax.annotation for fields and methods

Question

I currently use

@DefaultAnnotation(NonNull.class)
package jobs;

import edu.umd.cs.findbugs.annotations.DefaultAnnotation;
import edu.umd.cs.findbugs.annotations.NonNull;

however the annotation @edu.umd.cs.findbugs.annotations.DefaultAnnotation is deprecated: http://findbugs.sourceforge.net/api/edu/umd/cs/findbugs/annotations/DefaultAnnotation.html

They propose to use javax.annotation.ParametersAreNonnullByDefault However, DefaultAnnotation not only targets parameters, but also fields and methods.

So, what is the javax.annotation alternative for setting fields and methods to Nonnull by default?

Answer 1

As far as I know there is none. Wanting the same thing, I copied the source for ParametersAreNonnullByDefault into my own FieldsAreNonnullByDefault and MethodsAreNonnullByDefault and changed the @TypeQualifierDefault values to match (FIELD and METHOD respective). FindBugs picks up these new annotations perfectly.

Here's a sample for FieldsAreNonnullByDefault:

package com.sample;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

import javax.annotation.meta.TypeQualifierDefault;

/**
 * This annotation can be applied to a package or class to indicate that the 
 * classes' fields in that element are nonnull by default unless there is
 * <ul>
 *   <li>an explicit nullness annotation
 *   <li>a default field annotation applied to a more tightly nested element.
 * </ul>
 */
@Documented
@Nonnull
@TypeQualifierDefault(ElementType.FIELD)  // <-- METHOD for return values
@Retention(RetentionPolicy.RUNTIME)
public @interface FieldsAreNonnullByDefault {
}

Answer 2

So from the pure code point of view, there is not really any major difference.

The difference occurs once you start distributing your code afterwards.

As long as you do not ship your code with the annotations jar and a JRE, you should be OK.

If you are distributing a JRE then as you already know you need to comply with the Oracle Java Binary License.

You may want to refresh yourself with the terms of that license, specifically:

F. JAVA TECHNOLOGY RESTRICTIONS. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun", “oracle” or similar convention as specified by Oracle in any naming convention designation.

So if you are distributing a JRE and the same distribution includes a jar file that defines classes in a javax subpackage, unless the classes comply with a specification released and published by a JSR, you are not complying with the terms of the Oracle Java Binary License.

It is at this point that you then should take a look at the JSR 305 official page.

At this point in time that JSR has not published anything:

So you will need to ensure that you do not distribute the "jsr305.jar" file beside a JRE in your Windows installer, OS-X installer, Docker image, etc.