Support for @NotNullByDefault

[enexusde]

I have a maven modul that contains DTOs only to encapsule the Single-Version-Of-Truth.

Since there is no LLOC Spotbugs thinks they are unused.

In order to not get an spotbugs-error I use @NonNull on all fields (org.codehaus.commons.nullanalysis.NotNull). This works great.

Since I need to annotate every single field with this annotation I tried to use org.codehaus.commons.nullanalysis.NotNullByDefault on the class in order to affect all fields in the class.

Unfortunately @NotNullByDefault does not cascade @NonNull to the class's fields.

But the javadoc points out:

By default, types in method signatures that lack a null annotation are regarded as nullable. This annotation (with it default value true) indicates that types in method signatures that lack a null annotation are regarded as non-null. It is generally good practice to add @NotNullByDefault to all your package declarations (i.e. 'package-into.java' files), because in well-designed code (especially API methods), @nonnull is significantly more frequent than @nullable.

Please:

1. Support @NotNullByDefault on class-level
2. Support @NotNullByDefault on package-info level

[enexusde]

Hm, maybe I made a mistake. I use @nonnull on fields but the javadoc said on method-parameters.
Maybe close?

[gtoison]

This is possibly related to #805

[gtoison]

Have you tried org.eclipse.jdt.annotation.NonNullByDefault? There are references to it, so it seems to be supported

[enexusde]

If I use the annotation I need to publish the sourcecode according to https://www.eclipse.org/legal/epl-2.0/

I can not do that!

[iloveeclipse]

If I use the annotation I need to publish the sourcecode according to https://www.eclipse.org/legal/epl-2.0/

This is wrong. EPL 2.0 only requires to publisch modified EPL 2.0 code, so if you only use an EPL library, nothing needed to be published.

[enexusde]

Please read again. At last if someone subclass the annotation we need to publish the subclass including the package, license and other organisational decisions. It forces company details to offer to the public clients are not willing to admit.

[enexusde]

Support org.eclipse.jdt.annotation.NonNullByDefault but not support org.codehaus.commons.nullanalysis.NotNullByDefault, is up for debate in this ticket IMO.

[iloveeclipse]

Sorry, you are still wrong, and don’t understand EPL.
The main purpose of EPL is to allow commercial use of applications built on top of EPL 2.0 software. The applications can use EPL based libraries without publishing its own code, and they only need to publish modified EPL code. This is done to make sure any improvements of the EPL code can fo back to the community without opening proprietery code. So you can extend classes or implement EPL interfaces as much as you can - the whole Eclipse story is based on that, and all of the major software companies do that without publishing their code! However, if you change EPL code, e.g. changes the annotation class for whatever reason, then you must make the changed code publicly available. However, even in this case you can separate changed code into a dedicated bundle and only publish that bundle, not your entire application.

[enexusde]

Legal department said no EPL. Im no lawyer. Back to the debate?

[gtoison]

I'm not sure what you want to debate, sure it would be nice if SpotBugs could support more ways to declare nullability, but at the end of the day this takes valuable time to contributors, on their free time.
The J2EE API is published under the EPL, it would be quite problematic if using the API required to publish your code. Your Legal is misunderstanding the EPL

[enexusde]

Well, I think this ticket can be closed. You guys decide.

[gtoison]

I don't think we're closing the door to supporting org.codehaus.commons.nullanalysis.NotNullByDefault, just trying to say that a reasonable alternative seems to exist already.
The project is a bit short on manpower and this type of improvement usually takes time. You can help by submitting a code sample illustrating your query.