> However, I've got a question: These annotations have
@Retention(Runtime). (See
https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/latest/javax/annotation/Nullable.html
.)
Aren't we enforcing the presence of the respective jar at runtime?
Hi.
Usually, for Annotations, it have 3 ways to choose from, at the Annotations
defined.
If I understand correctly, only RUNTIME annotations will really needed for
runtime.
If you don't need any RUNTIME annotations, you can just make this lib
<scope>provide<scope>
Otherwise, you must treat that lib as a normal dependency.
see java.lang.annotation.RetentionPolicy for details.
/*
* Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 only, as
* published by the Free Software Foundation. Oracle designates this
* particular file as subject to the "Classpath" exception as provided
* by Oracle in the LICENSE file that accompanied this code.
*
* This code is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* version 2 for more details (a copy is included in the LICENSE file that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License version
* 2 along with this work; if not, write to the Free Software Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
* or visit www.oracle.com if you need additional information or have any
* questions.
*/
package java.lang.annotation;
/**
* Annotation retention policy. The constants of this enumerated type
* describe the various policies for retaining annotations. They are used
* in conjunction with the {@link Retention} meta-annotation type to specify
* how long annotations are to be retained.
*
* @author Joshua Bloch
* @since 1.5
*/
public enum RetentionPolicy {
/**
* Annotations are to be discarded by the compiler.
*/
SOURCE,
/**
* Annotations are to be recorded in the class file by the compiler
* but need not be retained by the VM at run time. This is the default
* behavior.
*/
CLASS,
/**
* Annotations are to be recorded in the class file by the compiler and
* retained by the VM at run time, so they may be read reflectively.
*
* @see java.lang.reflect.AnnotatedElement
*/
RUNTIME
}
Well I never use jsr305 so I'm not sure how they implement it.
But I can make sure in jetbrains.annotations, @NotNull and @Nullable are
using CLASS.
Xeno Amess <[email protected]> 于2020年8月26日周三 下午2:42写道：
> > how do we guarantee our meta are right and don't create false positives
> If we cannot even make the meta correct, then means we cannot make sure
> which function can return Null, which can not,
> Then why do you think our customers can do.
> And if people who write these libs are not sure which function can
> receive Null parameters, sounds like adding it will at least make
> developers sure their logics.
>
> Romain Manni-Bucau <[email protected]> 于2020年8月26日周三 下午2:30写道：
>
>> For what it is worth:
>>
>> 1. Generally speaking - and IMHO - these annotations only make sense in a
>> particular tooling setup(s) - like considering values which can be null by
>> code analysis and not by spec (@NotNull) - which I'm not sure we have so
>> it
>> is mainly about making it consumer friendly but how do we guarantee our
>> meta are right and don't create false positives? Until we can guarantee
>> it,
>> it sounds like we can only bring drawbacks by adding it and users can
>> trivially solve it since if he already uses @NotNull he puts it in his
>> code
>> at a higher level anyway.
>> 2. Please don't use javax.annotation.* since, thanks JPMS, it can make the
>> code not compilable on java >= 9 - a package must be owned by a single
>> module. (Not)Nullable static check is generally about the annotation
>> simple name and not the package so you can just duplicate the 1-2
>> annotations you want in [lang], it is a saner compromise in today's
>> ecosystem.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 26 août 2020 à 01:30, Matt Sicker <[email protected]> a écrit :
>>
>> > Runtime retention still doesn’t require the annotations to be present on
>> > the classpath unless you perform reflection on them (I forget the
>> > specifics). It’s a feature specific to annotations.
>> >
>> > On Tue, Aug 25, 2020 at 14:36 Jochen Wiedmann <
>> [email protected]>
>> > wrote:
>> >
>> > > On Tue, Aug 25, 2020 at 9:08 PM sebb <[email protected]> wrote:
>> > >
>> > >
>> > >
>> > > > AFAIK that means Maven won't download the dependency.
>> > >
>> > > > Surely that makes it harder for the developer?
>> > >
>> > >
>> > >
>> > > No, it means that Maven won't add the dependency to a distribution.
>> > >
>> > >
>> > >
>> > > However, I've got a question: These annotations have
>> > >
>> > > @Retention(Runtime). (See
>> > >
>> > >
>> > >
>> >
>> https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/latest/javax/annotation/Nullable.html
>> > > .)
>> > >
>> > > Aren't we enforcing the presence of the respective jar at runtime?
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Jochen
>> > >
>> > >
>> > >
>> > > --
>> > >
>> > >
>> > >
>> > > Look, that's why there's rules, understand? So that you think before
>> > >
>> > > you break 'em.
>> > >
>> > >
>> > >
>> > > -- (Terry Pratchett, Thief of Time)
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > >
>> > > To unsubscribe, e-mail: [email protected]
>> > >
>> > > For additional commands, e-mail: [email protected]
>> > >
>> > >
>> > >
>> > > --
>> > Matt Sicker <[email protected]>
>> >
>>
>
