Can we use lombok framework in embedded Java? Like midlets or implementations where we need only core java.
Yes, I expect that you can use lombok in embedded Java.
Lombok is a compile time dependency, and not related to any deployment platform.
You might want to modify lombok.config and instruct lombok to not generate #ConstructorProperties using lombok.anyConstructor.suppressConstructorProperties=true (in the upcoming release, this will be the default behavior and deprecated), since I expect that that is not available at runtime.
Also, the generated code is optimized for hotspot, so you might also want to configure lombok.equalsAndHashCode.doNotUseGetters=true and lombok.toString.doNotUseGetters=true to use direct field access instead of getters.
Disclosure: I am a lombok developer.
Related
I am using the openapi-generator-maven-plugin to generate model sources.
Is there a way to generate them only with fields and without any access methods?
I want the access methods to be generated via lombok with the additionalModelTypeAnnotations configOption in the maven configuration of the openapi-generator-maven-plugin
You can implement those customizations by changing the Mustache templates
Fetch the templates of the Java framework (ie spring-boot) you want to use (ie openapi-generator-cli author template -g spring --additional-properties=library=spring-boot -o tmp/mytemplates
Modify the local model.mustache file to import the packages you want (lombok) and pojo.mustache to remove the getters/setters. There might other customisations necessary (each framework templates are different) but this the recommended approach.
As #beppe suggested in their answer, this can easily be done by modifying the mustache template. However, I highly advice against it. In doing so, you discard many of the the features included with the model objects created by the generator. Some of the features you lose are:
Bean Validation
Jackson Serialization Library Support
Support for vendor extensions
By adding the Lombok annotation to the generated files, you are basically ignoring the main point of the generator, which is to generate files that support each other. You are instead using a generator to call a generator.
Finally, the amount of customization necessary to make the lombok library work with the mustache files is much more than is really worth it. Sure, you can add #Data or #Jacksonized to your model, but what about #JsonIgnore? Do you want to use parameters in your Lombok calls? Because you can't set the builder classname via #Builder(builderClassName = "EmployeeBuilder"). That would be hardcoded. Instead, you'd have to use mustache parameters, such as #Builder(builderClassName = {{$builderClassName}}), which you'd then have to define elsewhere. What about #Builder vs #SuperBuilder? Which one do you use in which situation? How do you define and template it?
At this point, you might as well rewrite the entire pojo.mustache to be able to use the lombok annotations. But, what if you need the old pojo.mustache functionality elsewhere? Now you need to write a custom generator to determine which mustache to use in which situations.
It is best to just build the domain models as the openapi-generator intends and use them as they are. You can add annotations if you need to via vendor extensions such as x-field-extra-annotation and x-class-extra-annotation if you really feel the need to.
As per my understanding, these annotations used for methods with an access modifier that allows method invocation from another class for unit testing
#VisibleForTesting - com.google.common.annotations.VisibleForTesting
#TestOnly - org.jetbrains.annotations.TestOnly
The first big difference is obviously that it's provided by different projects.
#VisibleForTesting is part of the Google Guava libraries and #TestOnly is part of JetBrains annotations which are associated with JetBrains, the makers of IntelliJ IDEA, among others.
Comparing the JavaDoc of the two shows that they serve basically identical goals: #TestOnly and #VisibleForTesting.
Note that the documentation of both annotations contain a note effectively warning you that the annotation itself does not prevent production code from calling the annotated method. JetBrains suggests the use of static checking tools that support that annotation (one of which is presumably built into IntelliJ IDEA) and Guava suggests the use of external checker tools with an explicit list of forbidden APIs.
tl;dr They indicate effectively the same thing. The decision which one to use depends mostly on which tools you are using to act on them and which one they support. Already using other annotations or classes from one of those packages is another reason to pick one over the other.
They are not for the same thing.
#VisibleForTesting is used for a methods that could be private/package-visible but has a higher visibility so it can be used by tests. Such a method can still be called in Production.
#TestOnly is used for a method that can only be used by tests, for instance to create a stub or to perform an additional validation only when testing. Such a method should never be called in Production, although the annotation won't prevent that.
By the way, JetBrains provide both annotations, so they can be used in the same project.
I am writing a code generator that generates additional classes for each class annotated with a certain annotation. I have other classes in my project that has to refer these generated classes. If I can somehow integrate my code generator into the automatic build process, then I figure the generated code will always stay up to date.
Is this possible? Can I do this if write a new custom builder?
EDIT (2/7):
I looked at Lombok which is doing something similar. However, it modifies the AST from an annotation processor by using undocumented internal methods in eclipse. I don't want to take that risk. Moreover, I think they never wanted to do source generation - just byte code generation.
Assuming you have annotation processing configured, you can use the annotation processing plugin for m2e.
Here's the marketplace link: https://marketplace.eclipse.org/content/m2e-apt
Can a JSR 305 annotation like javax.annotation.Nonnull be used in code that will run on Android ? It does not look like the Dalvik VM is supporting the package and those annotations have a runtime retention policy. Has anyone got it working using the javax package (or alternatives like using eclipse JDT) ?
Afaik, annotations can be missing at runtime (even with runtime retention), which will result in the annotation being silently dropped. So if your code compiles, then you're OK even if the VM that is later running your code does not know of the annotation.
In your case, you are using javax.annotation.Nonnull, which is used by static analysis tools, but usually has no effect at runtime. So yes, you can use it.
In contrast, a hypothetical other annotation whose presence is relevant to your app at runtime, must be present on the classpath.
The javax.* package is not fully supported by dalvik or ADT. You can use normal annotations however. The full package list in the official docs.
That said, anything that targets .class files will not work. There's a library called dexmaker that helps with this problem.
Why not use androidx.annotation from Android standard sdk plartform
Are Java annotations used for adding functionality to Java code besides just adding documentation about what's going on in the code? What's the most advanced/complex functionality you could add to your code through an annotation?
Annotation are basically not more than a tag (with optional additional data) on a class/method/field. Other code (libraries or tools) can discover these tags and execute functionality dependant on the annotations found. I don't see a real limit on the complexity of the functionality possibly added by annotations. This can for example emulate AOP (adding functionality before or after a method with an annotation).
Annotations as such only add information (metadata) to a class.
One can easily build a system that uses that metadata to provide additional functionality, however.
For example you can use apt to generate classes based on the information provided by the annotation.
An annotation needs a tool to react to it. If such a tool does not exist the annotation is merely a notation. The "tool" can be an APT based agent or some piece of code that uses reflection (for instance, JUnit's #Test).
Several annotations are recognized by the Java compiler and thus have pre-defined semantics: #Override, #Deprecated, #Target.
I would understand Annotations as a way to document your code in a machine readable way.
For example in Hibernate you can specify the whole persistence information for your objects as annotations. This is directly readable for you and not in a distant xml file. But is also readable for the tool to generate configurations, database schemes etc.