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
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.
There is a way to use annotations to build a java class, based on the properties of multiple java classes?
I want to create a generic log history table for all operations and entities in a spring data jpa project, for this i was thinking if would be possible to get all properties of my entities at compilation time to generate this generic entity log class.
I don't know so much about annotations, but it is used to generate source files so i believe that isn't a impossible ideia.
Could someone give some direction? If it's possible would be nice to point me a good starting point. Or if there is something already done that match my intent.
Annotations themselves do not generate source files -- they signify pointcuts for other classes to enhance/enrich them, or as a marker interface.
However, you can definately use an annotation scanner to scan files and get all the fields.
Then what is left is generating a class from this.
(and then, compile it). Be aweare that this is a multi-step process, and it may seem a bit clunky: you create a file with name GenericEntity, make sure it's in the proper package (so start it with package my.fun.project, write the imports, and write the java class, all as strings which you send tot he file.
From you scan you have an annotated field / class and you can get the type and name (see the reflections library if necessary), and write that to your file as well. Then close the class properly with a }. Now it should a file which should not give compilation errors when loaded in your IDE.
This GenericEntityGenerator then has to be executed (using a maven plugin, probably) on your source code, probably during the generate-sources phase, after which your generated class will be compiled during the compile phase.... and bob's your uncle now.
In all, a fun project
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.
I am generating Java source files for my project using a source generation tool (antlr). However, I am writing most, if not all of my code, in Kotlin.
Kotlin already offers great Java interop, so using the generated sources is not a problem. However, because of how Kotlin brings Java's nullable types into a null-safe system, I lose most of the null-safety that I use Kotlin for. At the very best I have warnings of platform types (make type explicit to avoid subtle bugs); at the worst I have unexpected crashes and subtle bugs.
Kotlin does, however, respect nullability annotations, such as JSR-305, FindBugs, Lombok, Eclipse, and JetBrains's respective forms of #Nullable/#NonNull, bringing those in as the appropriate non-null type or optional.
Because the code is generated and I have access to the source (and understand how it works), I know which functions can/not return null, and want to annotate them as such so they include neatly into my null-safe code. However, I cannot add annotations directly into the code, as it is generated during the build step and would overwrite any manual changes.
Is it possible to / what is the best way to annotate the nullability of generated java sources for the purpose of use in null-safe code?
The best way would be to modify the source code generator so that it includes the annotations that you require.
If you can't modify the generator (e.g. because the generator is proprietary and you don't have its source code) then you can do this using bytecode engineering. For example, this page on the ASM site gives one way to do it:
http://asm.ow2.org/doc/tutorial-annotations.html
Of course, in either case you need some way to tell the tool (the generator, the bytecode rewriter, whatever) which methods should be annotated.
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.