I've been checking ContextWrapper.java in android sdk and noticed that there are some methods which are annotated in javadoc by #remove. I assume, it is an indicator to give lint warnings in IDE but that'd be great to know exactly what it is and why they needed such as thing in the first place instead of removing completely.
/** #removed */
#Override
public SharedPreferences getSharedPreferences(File file, int mode) {
return mBase.getSharedPreferences(file, mode);
}
Like #hide, it causes Doclava (a Javadoc doclet Android uses to generate SDK documentation and API signature text files) to omit the annotated member from generated documentation and, if the -api flag is passed, from the generated API signature text file. If the -removedApi flag is also used, members annotated #remove will be included in the removed.txt signature file.
Related
Can anyone enlighten me about the difference of getRealOneOfs and getOneOfs?
https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/Descriptors.Descriptor.html#getOneofs--
Every proto3 optional field is placed into a one-field oneof, called a "synthetic" oneof, as it was not present in the source .proto file. The getOneOfs method will return all oneofs, including synthetic ones, whereas getRealOneOfs will exclude the synthetic oneofs.
More info here (in the Background section):
https://github.com/protocolbuffers/protobuf/blob/main/docs/implementing_proto3_presence.md
In my company, we're starting to mix Kotlin with Java and found a curious scenario. When I place a Java annotation on a property parameter of a constructor in a Kotlin class, and use a non-existent reference as one of the annotation's parameters, IntelliJ visually indicates an error, but both its build (Ctrl+F9) and maven's build compile normally, without errors.
We're using Java 8 and Kotlin 1.4.20.
Here's the annotation, declared as a Java file:
#Retention(RetentionPolicy.RUNTIME)
#Target({ElementType.FIELD, ElementType.METHOD})
public #interface Required {
String scope() default "ABC";
}
And here's the Kotlin class using the annotation (class Abc does not exist):
data class Test(
// Compiles normally
#Required(scope = Abc.X)
val text: String
) {
// Compilation error
#Required(scope = Abc.X)
fun x() {
}
}
As mentioned in the code comments, the same annotation placed in a Kotlin function behaves as expected (that is, the code does not compile). An equivalent annotation declared as a Kotlin file also behaves as expected.
When the code is run, the scope variable assumes its default value, so there are no runtime errors.
I've already tried to:
Invalidate IntelliJ cache and restart.
Switch the annotation declaration from #Required(scope = Abc.X) to #field:Required(scope = Abc.X)
I also tried to replicate the behaviour in a brand new project without inheriting from the company's base maven project, but to no avail.
Honestly, I think there's a huge possibility that it is something related to the company's project. I know I haven't specified what my company uses and all the configuration (in fact, the question would get way too big if I did that), but I hope that even with just the basic problem someone may be able to help.
This is a Kotlin compiler bug: argument list is not analyzed for usage of Java annotation with #Target(FIELD) on Kotlin property.
For updates on this please follow the issue https://youtrack.jetbrains.com/issue/KT-33822.
I'm trying to add a hook after all the files are created by the Go client generator and I'm wondering where I can add this.
Right now, files are generated in this order (a) models (b) API paths (c) supporting files.
If I hook into AbstractGoCodegen's postProcessSupportingFileData function like so, myfunc() will get called before the supporting files like README.md and client.go are created, but I want the function be called afterwards.
#Override
public Map<String, Object> postProcessSupportingFileData(Map<String, Object> objs) {
generateYAMLSpecFile(objs);
objs = super.postProcessSupportingFileData(objs);
myfunc();
return objs;
}
I've also tried a few other other postProcessing* functions as shown in DefaultCodegen but they didn't work as desired.
How can I do this?
If you do not get the desired functionality from overriding the configuration methods, I suggest that you extend the DefaultGenerator class. These contain the actual generation methods such as generateSupportingFiles. You should be able to easily add your hook after this method has generated the supporting files.
Keep in mind that you might have to change a few modifiers from private to protected.
I am writing a java annotation processor for java 7 source code.
And surely, I can use javax.annotation.processing.filer to help me generate the file under project directory automatically.
ex: annotation is #becare
public interface test {
#becare
int compare(int a, int b);
}
my annotation processor's job is when it detects the given annotation #becare, it will generate the file for me.
My Question is that if I remove the annotation from the previous code snippet, can I let annotation processor to be aware that and delete the file it just created?
Or is there any workaround to help me achieve this ?
Thanks in advance.
When you create the generated file you declare that it's linked to your 'test' interface like this:
Elements eltUtils = processingEnv.getElementUtils();
filer.createSourceFile("testGenerated", eltUtils.getTypeElement("test"));
When the source is deleted, the processor will remove generated file like javadoc says:
If there are no originating elements, none need to be passed. This information may be used in an incremental environment to determine the need to rerun processors or remove generated files. Non-incremental environments may ignore the originating element information.
Consider such code
public void m1(String text) {
if(text == null)
text = "<empty>";
System.out.println(text.toLowerCase());
}
And this is a buggy version:
public void m1(String text) {
System.out.println(text.toLowerCase());
}
If null value passed, the NullPointerException may be thrown. I would like the static-analysis tool (e.g. FindBugs) to report this issue. Unsuccessfully the FindBugs (at least by default) requires me to specify #Nullable annotation explicitly.
public void m1(#Nullable String text) {
System.out.println(text.toLowerCase()); // FindBugs: text must be nonnull but is marked as nullable
}
The problem is that if I forget to annotate it, the bug will be missed!!!
How can I make the FindBugs (or any other free tool) to assume #Nullable by default?
According to Javadoc:
#DefaultAnnotationForParameters indicates that all members of the class or package should be annotated with the default value of the supplied annotation class.
(BTW Javadocs for #DefaultAnnotation, #DefaultAnnotationForFields and #DefaultAnnotationForMethods contain exactly the same text).
But according to chapter 10 of FindBugs Manual:
This is same as the DefaultAnnotation except it only applys to method parameters.
While theroretically either
#DefaultAnnotationForParameters(value = Nullable.class)
or
#DefaultAnnotationForParameters({Nullable.class})
should work, both don't.
I don't know if FindBugs supports this but with JSR 305 you can also use #ParametersAreNullableByDefault annotation applied to a package, class or method. Unfortunately FindBugs 1.3.9 ignores #ParametersAreNonnullByDefault and similar annotations (used on packages or on types).
You can write your own detector in FindBugs that looks for any use of parameters that are not null checked. Would be relatively simple to do.
What you're looking for is #ParametersAreNullableByDefault (http://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/ParametersAreNullableByDefault.java) but I would urge you to use #ParametersAreNonnullByDefault instead. It would also have detected your buggy code. Preferably, you put them in your package-info.java file as an annotation on the package.