Consider I have a constructor of more that 10 or more args, and I am using it in criteria select query to fetch data.
Now the problem is that I want to remove my constructor as it gives me sonar issues.
So I tried to Lombok dependency, #AllArgsConstructor it is working in my IDE,
but when I create the jar file it is not being used by JPA query.
I need help either to make lombok work in my project.jar file,
OR
change in select query which does not use constructor,
OR
Any other better way
Lombok is a compile-time affair. Once your code is compiled (you have class files), lombok shouldn't be there / wouldn't be doing anything. Lombok is not a library in that sense. You don't ship 'javac' with your app either.
If lombok is part of the compilation, then lombok will do its thing. If it's not, then your compiler would generate an error; after all, it wouldn't know what #AllArgsConstructor is about. So, if you're not observing any compilation errors, lombok did its thing*.
Secondly, sonar is a linting tool. It's there to help you out. If it is 'telling you off' for writing code where you think it is the best way to do it, then tell sonar to stop complaining about it. It's a tool for you to use; not a prison.
You can use javap to check if the all-args constructor is there. If it is (it should be), then your question is actually: How do I make my JPA tooling use that constructor?
*) It is possible, but takes some work, to tell javac to have lombok's classes available, but NOT to run it as an annotation processor. But if you do manage that, then lombok wouldn't have transformed any of your classes. I assume that's not the case, as you need to go out of your way with lots of command line switches to make this happen.
Related
I have a Java class which uses a .jar file.
Every time that I want to compile this class, I have to do something like javac -cp ".:myJar.jar" myClass.java and every time that I want to execute it, I have to do the similar thing but with java instead of javac.
Is there a way to avoid doing this?
I know that I could put this jar file into my class path but I don't want to do that. I don't neither want to do a maven projet.
There is nothing preventing you from using an IDE, taking advantage of all its super useful features when developing the program, and then submit just the source code and associated jars to the professor.
Advantages of using IDE that your professor don't need:
Syntax color-coded editors with auto-complete.
Built-in display of javadoc, so you know what all the built-in Java methods do, and how they work.
Instant high-lighting of syntax errors.
Never having to compile the code, since IDE always keeps the code compiled.
Easy single-button execution of the program when you want to run it.
Debugger. Very important feature when your code is not working as you intended.
... more ...
Looking at trying to use the GWT-Jackson-Apt library for doing certain RPC, but when looking at examples and trying to run some demos there are always interfaces with a bizarre undefined constructor call.
#JSONMapper
public interface SampleMapper extends ObjectMapper<SimpleBean> {
SampleMapper INSTANCE = new App_SampleMapperImpl();
}
source: https://github.com/DominoKit/gwt-jackson-apt/blob/f60d0358b90bcbf78d066796f680aeae1d7156bb/samples/basic/basic-client/src/main/java/org/dominokit/jacksonapt/samples/basic/App.java
I've been digging around, but there is no definition of App_SampleMapperImpl() anywhere in the source code. And it doesn't compile, saying that there is an undefined symbol
The exact same thing is done in the readme file's exmaples which can be found on this page: https://github.com/DominoKit/gwt-jackson-apt/tree/f60d0358b90bcbf78d066796f680aeae1d7156bb
can anyone explain what is going on here? How is this constructor being defined, or implied? And what do I need to do to make the example compile?
Assuming you are making a Maven project, the important thing is to include the annotation processor which generates the mappers. Then, once the project knows how to generate them, you'll be able to use them in your code.
Annotation Processors run while the compiler is running, which means you technically get to write code which doesn't appear it will compile. Then, as the compiler is running, it asks all registered annotation processors to please generate code based on the annotations and existing types (not the missing references like App_Sample_MapperImpl as you might think). The processor then runs, generates the missing class, and then the compile continues.
Usually what happens is that you build while writing code (eclipse, for example, does this every time a file is saved, intellij does it when you ask for a build, etc), and then the class exists and can be referenced going forward. Even when the project is cleaned and rebuilt, while the reference seems like it should not work, it will work as soon as the compiler runs.
In this case, we'll need to follow the example to make sure the processor is present. in https://github.com/DominoKit/gwt-jackson-apt/blob/f60d0358b90bcbf78d066796f680aeae1d7156bb/samples/shared-mappers/shared-mappers-shared/pom.xml, we see this in the dependencies:
<dependency>
<groupId>org.dominokit.jackson</groupId>
<artifactId>jackson-apt-processor</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
This is marked scope=provided since it is only needed to compile, then shouldn't be included in later dependency graphs. For each specific IDE, you may need to specify additional options to get it to re-run automatically (a checkbox in Eclipse, nothing in IntelliJ I believe, and I haven't used other IDEs in too long to say).
One final note for maven: you must use a relatively recent maven-compiler-plugin so that generated code is handled correctly: latest is 3.8.0, published July 2018, but I think anything after 3.5.1 will be sufficient if you must use an older one.
Just follow the example on the main page of the project: https://github.com/DominoKit/gwt-jackson-apt/
Does that work ?
Is there a way to configure a ClassLoader or a JVM to load annotations with CLASS retention policy, so I can access them using reflection?
This is useful for compile-time post-processing, as mentioned here.
I annotate some of my classes in order to generate an antlib.xml file automatically. I would prefer if my annotation could have CLASS retention policy, so that it does not create runtime dependencies.
javac can process source and class level annotations, with the -processor option. See javax.annotation.processing.AbstractProcessor. (Since java 1.6).
I started using it while compiling .java files. Apparently it can also be used to process CLASS annotations with .class input files. I haven't tried this because I'm using ant to compile, and ant does not seem to pass .class files to the compiler.
I have to do a full compile when I want to process all the annotations in my project.
I think you might want to have a look at this tutorial.
It explains how to create your own annotation processor and how to use it to generate code. It doesn't handle bytecode manipulation though.
He also gave a presentation available on YouTube. In case you're too lazy to read... ;-)
I'm digging into the source code of the deeplearning for java recently. There is such a class NeuralNetConfiguration in which there are tons of fields that all requires getters and setters. The NeuralNetConfiguration.java source code does not provide any, however.
When I open this project in IntelliJ, ctrl click on the usage of this class, which are methods mostly like, NeuralNetConfiguration.getNInput() or NeuralNetConfiguration.getKernelSize(), the IDE direct me to the compiled class file in which all the getters are defined for each of the field in this class.
Just wonder how this is done since I'm a new bee to java. Posts I found about java reflect suggest that reflect can not add method to a method to a class unless you wrote your own classloader. I check the deep learning for java project and I don't think they have done that.
What bothers me too from time to time is, IntelliJ starts to report errors that those getFields methods could not be resolved since they are not in the source file at all, especially after my building the project using IntelliJ instead of using mvn command line.
The magic happens with the #Data annotation on the class. This annotation is from Project Lombok. There is probably an annotation processor somewhere that hooks into the compiling process and generates these methods.
I am using a 3rd party annotation processor for generating meta-data code (.java files) from the annotated classes in my project.
I have successfully configured the processor through Eclipse (Properties -> Java Compiler -> Annotation Processing) and the code generation works fine (code is automatically created and generated). Also, Eclipse successfully auto-completes the generated classes and their fields, without any errors. Let's say that I have a class "some.package.Foo" and that the generated meta-data class is "some.package.Foo_". By the help of auto-completion, I can get the following code in the Eclipse editor, without any errors:
import some.package.Foo_;
...
public class Test {
void test() {
Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
However, as soon as I actually build the project (or just save the file since Build automatically is enabled), I get the error which tells that "some.package.Foo_" cannot be resolved.
It seems like Eclipse is generating and compiling the some.package.Foo_ at the same time, or more likely.
I found two temporary solutions (which are practically hindering the use of the annotation processor in the first place):
Before each build of that generated classes, right click on every generated file go to Properties and uncheck the "Derived" tick. After that, I do the cleanup of the project and the imports are fine - there are no more errors. However, if I do the cleanup one more time, the errors again show up, because the generation of the files causes the "Derived" tick to be checked again (automatically). So this is really annoying and time-consuming.
I also uncheck the "Derived" tick
from all those files, and this time
I uncheck the "Derived" tick from
the source folder and packages which
contain those files. Then I disable
the annotation processor, and then
do the cleanup. There are no more
import errors, even if I do another
cleanup, but there is no benefit of
using the annotation processor,
because if I was to change something
which would update the model, I need
to turn the annotation processor
back on, and repeat this tedious
procedure to turn it off, after it
has generated the new version of
those files.
Is this a bug in Eclipse? If yes, is there a better workaround or quick-fix than the two I have stated above? If not, what should I try to solve the problem?
I also tried rearranging the order of the libraries on the build path and it doesn't help.
I assume that you are generating sources in the last processor round. This is not recommended way and leads exactly to the problem that you had.
Explanation is here: http://code.google.com/p/acris/wiki/CodeGenerationPlatform_Pitfall_Rounds
So the my advise is to generate sources in regular processing rounds and final round should be used just for notification that processing is over or something like that.
Hopefully this helps you.
I have a similar problem, and the only thing I've found is that it's the imports specifically that don't work, but the references in the class itself do work. The workaround I've used is to use the FQCN in all cases where the generated class is needed (except when the generated class is in the same package, since then the import is obviously not needed).
So to use your example, I'd do:
public class Test {
void test() {
some.package.Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
My only guess then is that the eclipse compiler is processing the imports before doing the annotation processing, which imho must be a bug in eclipse.
I know this question is over a year old, so I'd be interested to know if you've found any other way to fix it.
We were experiencing a similar problem and apparently just solved it, so thought of sharing it at SO, in case it helps someone.
We are using:
Eclipse Indigo (Build id: 20120216-1857)
m2e Connector for maven
openJPA for static metamodel class generation
Our problem:
Say, we have a package named com.abc.xyz and an entity class in there named OurEntity. When we build the projects (JPA, EJB, EAR etc. all together with an mvn clean at the beginning) the metamodel classes get generated. And also get appropriately packaged within the PU jar. But when we try to import the generated metamodel class com.abc.xyz.OurEntity_, Eclipse cannot resolve it. OP apparently got past this point:-). Maven build failed, saying it could not resolve that class. Not much help from google except for a few bug reports such as this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=350378
That bug report said importing the whole package as opposed to the single class helped. So, tried that, but with no benefit. It also said (and so did David Heitzman) that using the fully qualified class name worked for them. That did not work either.
The solution:
Added the PU jar to Eclipse build path for the project that needed to use the metamodel classes. All of a sudden all the red underlines went away (not a surprise). But the fear was there might be two PUs in the same ear. But maven automagically took care of that.
As this rather old question got some attention without pointing to the very probable eclipse bug the OP was specifically asking for, I'd like to complement the above answers with a pointer to the eclipse bug tracker:
Cannot resolve import for generated class IF processing annotations with parameters referencing constants
The workarounds include
doing a wildcard import of the package defining the generated classes (i.e. import some.package.*;)
using the fully qualified name of your generated class, i.e. referring to some.package.Foo in your code and not using an import
switch to a newer Eclipse. This specific eclipse bug is resolved with Eclipse version 4.4 (aka Luna).