I am maintaining a Java 7 web project that uses multiline annotation to store certain constants.
I could configure Eclipse fine when I was using Mars, so I could launch Tomcat with that application deployed and it worked like a charm...
Until I upgraded!
Now no annotation processing is done despite the configuration.
I have found that this problem is due to a feature of Eclipse 4.6, as documented here
Java 6 annotation processors are supported in the batch compiler and in the IDE. By design, Java 6 processors are only executed during a build, not while editing. (bug 188558)
The linked bug says, in brief, that annotation processing has been removed from Eclipse's incremental compilation (perhaps the Build automatically???) for legitimate reasons. And in fact when I compile my project in CI server using Ant, annotations get processed as usual.
But I can't run my project anymore in Eclipse. It fully depends on the correct processing of the Multiline annotation.
So far, I have tried to disable the Build Automatically flag and manually build the project. No result.
I also tried to go to Java Compiler -> Annotation processing -> Factory Path, select the multiline-string jar, go to Advanced properties and uncheck Run this container's processors in batch mode, despite the checkbox is counterintuitive (I mean, it should be named "Run in incremental mode" and unchecked by default, according to the above mentioned bug)
The application is a web application, so on every attempt I try to deploy it to local Tomcat.
What do you think I can do about it?
A couple of suggestions:
The multiline annotation you are using only supports up to Java version 1.6. (For instance, MultilineProcessor specifies #SupportedSourceVersion(SourceVersion.RELEASE_6), and the recommended pom settings specify source and target values of 1.6.) If your package is building with a JDK Compliance Level greater than 1.6, this is probably why the annotations are being ignored.
Instead of using that annotation, you could just hard-code the multiline strings to your string variables. It would make your code less readable, but builds will be faster.
Related
I'm currently following this tutorial: https://openjfx.io/openjfx-docs/ (JavaFX and IntelliJ IDEA). I use Intellij 2021.3.2.
I have created a project (1. Create a JavaFX project), which worked out great and didn't need to 2. Set JDK 16 because it was already set to 17 (which I guess is fine).
But here begin the weird stuff (and I'm very new to programming so I'm sorry if it sounds silly). "You can also set the language level to 11 or greater." I don't have this option. Because it's "can" I felt like it wasn't a big deal but if someone can explain what this is all about? Just out of curiosity, because I'm at the very beginning of the tutorial and I kinda only understand half of it.
Then 3. Create a library, and I don't have what they have, and my stuff is red:
So when they said "add the JavaFX 17 SDK as a library to the project" I didn't know what to do. I also didn't know what to do to fix the red stuff.
And finally, they say "Warning: If you run now the project it will compile but you will get this error: ..." but if I click on this button
everything works! which you know i'm not complaining about but I would like to understand a bit more what is happening.
And then they suggest I should 4. Add VM options to fix the problem that I don't have. So I figured maybe my computer set the VM options correctly without me knowing it but there is currently no VM option (and it works). Should I add them nonetheless?
Thank you for your help, I'm very lost and feel like I don't really understand anything.
The current documentation in the openjfx tutorial for getting started with JavaFX using Idea is incorrect, at least for recent Idea releases (2021.3 +).
The tutorial is written as though a new Java project was created, rather than a new JavaFX project. Once a new JavaFX project has been created, most of the rest of the steps in the tutorial are either redundant or wrong.
Step 1, “Create a JavaFX project", does a lot more than just “Create a Java project”, which is why everything else is different from the tutorial.
A better tutorial for getting started with JavaFX with Idea, is the official Idea documentation:
Create a new JavaFX project.
Differences between creating a new Java project and creating a new JavaFX project
The new JavaFX project:
Provides a build script for Maven (pom.xml) or Gradle (build.gradle).
Adds the appropriate dependencies for JavaFX base, graphics, controls and fxml.
Provides an example application and controller code that you can run immediately.
The example project is modular and provides a module-info.java
Because the program is modular and dependencies are downloaded via maven and recognized by the IDE, you don’t need to manually configure VM runtime options for the module path and adding modules.
Idea will recognize the Maven or Gradle projects and automatically synchronize the initial transitive dependent libraries with the Idea project.
There are options in the Idea Maven tool window which will allow you to synchronize further changes to dependent libraries or javadoc and source code in libraries.
Selects a JDK and attaches it to the project, automatically downloading the selected JDK version if not already present.
Sets an appropriate language level for the project.
When you just use the create new Java Project option, it doesn’t do any of those things, so you need to do things manually instead, which is what the rest of that tutorial is about:
Manually download the JDK and configure it in the SDK.
Manually download the JavaFX SDK and add the libraries from it to your project.
Manually configure VM modular arguments.
Manually maintain any other dependencies.
Manually associate javadoc and source code.
Manually write the code for a basic application.
Manually set the project language level.
Doing all this stuff manually is more work and more error prone. The manual work usually leads to a worse outcome and a project that is more difficult to maintain for many people getting started with JavaFX, so I do not recommend it.
Versions
In terms of the versions to use, I recommend using the most recent stable (non-beta) releases of both JDK and JavaFX, regardless of what versions may be referenced in any tutorials you may be using.
You can set JavaFX versions in the Maven file generated by the new JavaFX project wizard, then press the button in the Maven Tool window to synchronize the Maven project with the Idea project.
Language level settings
These are important later on, but pretty irrelevant when just getting started.
The language level settings:
Tell the compiler what version of the java byte code to compile the application to.
Tell the IDE what language syntax rules to enforce and provide help with.
If you use Java 17 only features, the app won’t run on a Java 11 VM.
You can define the settings in Idea manually:
language setting level.
But it is better to set them in the compiler section of the maven project and synchronize the project with Idea, which will also configure the settings in the IDE.
IMO, set it to the most recent stable version and have a requirement that your application be run with that Java version as a minimum (you can enforce that by using jlink or jpackage to bundle the JRE version you choose with your packaged app).
Some java warnings (e.g. for code order) might apply for one project, but not for the other. How can I reflect this fact in NetBeans where the only setting seems to be the Hint tab in the editor configuration on application level? I could setup the checkstyle maven plugin, but that'd be far from "IDE support" (facing the fact that I'd have to evaluate the output in the browser and then find the referenced line(s) of code in the IDE).
I'm using NetBeans 8.0.2, maven 3.2.5 and and OpenJDK 8.
There's a Hints option to configure warnings per project (overwriting the IDE-wide settings in the Editor section)
I just encountered a strange error when switching the JDK version of a new Project of mine from 7u45 to 8u20. A harmless LogManager declaration at the beginning of my class is being refused with the following error:
The type java.lang.reflect.AnnotatedElement cannot be resolved. It is indirectly referenced from required .class files
This is the code:
public class Class1 {
private static Logger log = LogManager.getLogger(Class1.class);
...
Eclipse proposes me to configure the build path, but I have no Idea what to configure because I don't know the underlying problem of that error.
Using the JDK with version 7, everything works fine.
When using JDK 8 and an IDE (or any other code processing tool/framework) with its own compiler, like Eclipse, you have to update the tool to a version with Java 8 support, even if you are not using the newer Java 8 features.
The reason is that the compiler must be able to load the newer class files of the JRE in order to compile your software which references these classes.
Sometimes you can get away with an older compiler when it ignores the newer version number of the class files. But some types will confuse older class file parsers as they use new features, notably AnnotatedElement, which now has default methods, and Map.Entry, an interface which now has static methods.
It seems that Eclipse does not make a difference between references for which no class file could be found and class files it failed to read when saying “«classname» cannot be resolved”.
The same applies to all tools and frameworks using ECJ as embedded compiler.
If this happens to you in Tomcat running from within Eclipse (question was closed as duplicate and redirects here), go to Preferences → Server → Runtime Environments → Tomcat version → Edit… and make sure the selected JRE matches the Tomcat version. (Maybe you need to install one.)
Solution 1:
Try changing the source level.
Go to Project > Preferences > Java Compiler.
Enable Project specific settings
Set compiler compliance level to 1.4 or below.
Restart
Solution 2:
Create a new workspace.
Copy project files into the new workspace.
Import project into eclipse and rebuild.
I change from JRE 8 to JRE 7 and restart Eclipse then it works fine.
I was using Eclipse Helios with JRE 8 and updating the software solve the problem.
Now I'm using Eclipse Mars and works just fine -> https://eclipse.org/downloads/
How come Eclipse compiles my project (automatically) without errors, but when I run Ant build.xml -> compile target, the build fails with compile error:
<MyClass> is not abstract and does not override abstract method <someMethod>
I understand this error message, but it seems not to be true, because 1) Eclipse shows no errors 2) Deploying this project to server succeeds and the class works as it should work.
So how is this problem even possible?
Are you using some special extensions to Eclipse, like Lombok (could be the extension generate something for you)?
Are you using some special framework (could be the framework generate some class for you)?
What you also need to understand is Eclipse and Ant using different compiler. Eclipse has its own compiler which behave differently with the Sun JDK, or with certain version of Sun JDK. One example of such behavior can be read here. But before I jump to that conclusion, I will inspect all configurations I have on my Eclipse.
It's also possible that your Ant build is just not set up the same as your Eclipse build. Different source folders, different JARs, etc. For example, perhaps your Eclipse build references an old version of a third-party JAR, and your Ant build references a new version where a new abstract method was added to a class you're inheriting from.
Because there are minor differences in the Eclipse compiler. I found a bug once, too, where the Javac threw an (IMHO stupid) error, while the Eclipse compiler was able to compile it like expected.
FYI: Eclipse uses a different compiler (its own) because it needs one optimized for incremental builds while you type.
Create a test case that shows that the differences are real, and send it to the eclipse team. They will adjust the behaviour of their compiler. However, I can't believe that such a major bug like an unimplemented method is really in the Eclipse compiler. I therefore assume you find the bug in your setup while creating a testcase for that.
Thank you all for your quick answers. It has been very helpful to understand that Eclipse uses different compiler, that explained a lot.
As for my problem - I assumed that Java compiler is right and that the build actually had errors. On closer examination, it occured to be the incompatibility of an older version of Apache Commons DBCP with Java 1.6. I was sure I was using the latest one and consulted wrong documentation version, which stated that the required methods were implemented.
Now as for Eclipse. The bug is actually tricky. I managed to write a test case showing this bug. I use Java 1.6 and Eclipse Helios for Java EE. I created a Java project in Eclipse and added
com.springsource.org.apache.commons.pool-1.5.3.jar
com.springsource.org.apache.commons.dbcp-1.2.2.osgi.jar
to the classpath (downloaded these JARs from SpringSource repository). As you see, Apache Commons DBCP is an old one. Java 1.6 requres version 1.4+.
In my test project I extend org.apache.commons.dbcp.BasicDataSource and additionally said it should implement javax.sql.DataSource. Like this:
import org.apache.commons.dbcp.BasicDataSource;
import javax.sql.DataSource;
public class MyDataSource extends BasicDataSource implements DataSource {
}
The tricky part here is that BasicDataSource implements DataSource interface. But in version 1.6 this interface got extended it, so the new methods are not implemented. Adding "implements DataSource" again explicitly should cause and error, which Java compiler successfully reports. But Eclipse compiles this code without any warning and it even runs.
So that was the problem. Seems like a bug in Eclipse to me.
We have an internal Java library, that for legacy reasons, needs to be compiled using Java 1.4. However, this lib has gone through several versions, the latter of which have had certain methods and objects deprecated. For client support reasons, the code needs to use some of these deprecated methods/objects. As such, we always keep the latest lib on the build path of our projects (in Eclipse).
I would like to
#SuppressWarnings("deprecation");
Though, do to the aforementioned 1.4 dependency, this is not possible.
Is there a way for me to remove the warnings, if only from my Eclipse Problems view, and somewhat cleanup my development environment?
Is there a way for me to remove the warnings, if only from my Eclipse Problems view, and somewhat cleanup my development environment?
You can configure the Java Compiler to ignore the Deprecated Warnings. I'd suggest to configure this setting for the specific project, not globally. To do so, right-click on your project and go to Properties > Java Compiler > Errors/Warnings. Click Enable project specific settings and then unfold Deprecated and restricted API and select Ignore for Deprecated API.
This will disable all deprecated warnings though.
If you're not concerned about deprecation anywhere in that project, you could always give it custom project compilation settings and set it to ignore deprecation. It's not ideal, but it may well be better for you in this case than living with the deprecation warnings - it means you'll be able to spot ones in your other projects more easily.
You could treat it as a standalone project. If its legacy you won't need to update often. In your main project use the JAR created with a link to the source so you still see that. That way it won't be compiled so it won't create warnings all the time.