Android apt updating from 1.4 to 1.7 version - java

Hi I wanted to upgrade android-apt in my project from version 1.4 to 1.7
Currently I'm using Google auto-service 1.0-rc2, so all what I had to do is putting #AutoService(Processor.class) annotation in my annotation processor class.
After updating android-apt to 1.7 version my annotation processor stopped working. It seem it is not called during build.
I thought that auto-service may be the issue. So I made resources/META-INF/services/javax.annotation.processing.Processor file with content
pl.edu.radomski.navigator.NavigatorAnnotationProcessor
Sadly it didn't helped at all.
If you want to see the code with android-apt 1.4 and auto-service 1.0-rc2 it is available here
Is there any simple way to upgrade android-apt and keep the processor working?
Is this auto-service 1.0-rc2 fault or something is wrong with android-apt?

In 1.7 a change was made to not automatically build a dependent project that is set as apt, due to unwanted side effects affecting build order.
In 1.8 I'll probably have a better way to support it, but in the mean time you can configure the apt block to specify that your processor should be run like this:
apt {
processor "pl.edu.radomski.navigator.NavigatorAnnotationProcessor"
}
Note that is only needed in the case your processor is in the same project as your app or library. The reason is that the file in META-INF/services is not read by javac in this setup because the project isn't packaged at that point. Explicitly adding a processor statement will add the processor that javac otherwise would not discover.

Related

Update IntelliJ default Gradle version

When starting a new project I get the message unsupported JDK. Using Gradle 7.1. I want to update that default Gradle to 7.3-rc-1.
However, I just can't seem to find where to do this outside of a specific project. I am not sure where IntelliJ obtains it's Gradle version, and it has auto-updated in the past.
Sure I could update it afterwards, but as IntelliJ seems to break on trying to create folders and doesn't go back to do it once Gradle is updated. It would save a lot of headache for IntelliJ and myself to update or force it to use the version I want before the project creation.
https://i.stack.imgur.com/TLyxF.png
IntelliJ bundles version of Gradle much like it bundles a version of the JDK. In order to upgrade the bundled version of Gradle, you must update Intellij. However, there is no guarantee that an updated version of IntelliJ will come with an updated version of Gradle.

How to change an UnsupportedClassVersionError in a user friendly message?

If the Java version is to old then Java produce such very cryptic error message: UnsupportedClassVersionError... . Although we have the necessary Java version in the release notes, many customers contact the support with this error message.
Is there a simple solution to show the users a better error message?
We use Gradle for the building. How can I compile a small set of files with a lower class file version? In this files we can do a version check to display the error message.
Of course we can't change the class file version of the completely project.
How can I compile a small set of files with a lower class file version?
Use the -source and -target options of the javac command (see the reference documentation), or since you're using Gradle, use the appropriate corresponding settings in the Gradle build file for the part that you need to be able to run on an older Java version.
For Gradle you can use the sourceCompatibility and targetCompatibility properties, see Table 47.8 in the Gradle documentation.
I've created a small library called use-newer-java which you can use to perform the version check:
Include use-newer-java as a dependency in your project
Set the Main-Class: field in the manifest of your built jar to
use.newer.java.Version8 or use.newer.java.Version9, etc as appropriate.
Set the Main-Class-After-UseNewerJava-Check: in your jar manifest to the normal main class of your app - Use Newer Java will follow this setting, and invoke this code after making it's check.
https://github.com/rtyley/use-newer-java
Distribute your application via JWS. It ha provisions for ensuring that the required JRE version is installed.

Update Legacy Project from JVM 1.6 to 1.8

I have to update my legacy project from JVM 1.6 to 1.8. Obviously, I'll need to make some changes like install JVM 1.8 on the server that the code will run.
My project is Java based.
What tasks do I need to do to accomplish this?
What risks or complications should I be aware of and plan for?
I'm using Maven. Do I have to make changes to my pom files?
do I have to make changes to my startup bash scripts?
what do I need to do to ensure that the code is compiled under 1.8?
links:
Upgrading existing Java Project from Java 1.6 to 1.8
Just compile using jdk 1.8 and check for any warnings about
deprecated methods.
Java 8 introduces lots of features like lambda streams..etc, try to enhance your code wherever required. (its not mandatory though)
Always good to use latest dependencies
No changes are required to start bash scripts
Since youare migrating from java 6 to java , you could use try with resource feature which is introduced in java 7.
Try to enhance your code wherever it is applicable. Good luck

Eclipse Luna not keeping code generated by Annotation Processing

I am running Eclipse Luna (4.4.1) under Ubuntu 14.10 (Utopic Unicorn) and have a project that uses annotation processing to validate certain forms in the code and generate utility code. In eclipse the code is not being generated.
First, the processors work perfectly with javac. Second the processors DO run in Eclipse. If I alter them to throw exceptions Eclipse reports that. Also if I provide the processors with malformed code (such as a getter/setter pair with different types) it reports the error properly (red squiggles, proper error message, whole nine yards).
No code appears in .apt_generated nor are class files generated.
I've tried disabling them and re-enabling them, starting a new project, tried it on a fresh install of Eclipse, changing the project version from 1.7 to 1.8 and back again, tried batch mode and not batch mode, changing the .apt_generated directory, double checked the permissions on .apt_generated, probably a few other things that I can't recall.
At this point I'm just running javac separately and thinking about making this our first Apache Ant or Maven project if that would help but I'd rather not quite at this juncture.
Anyone have any luck with code generation within Eclipse? Anything else to do or check?
Verify your project is set to actually use APT, as shown in https://www.eclipse.org/jdt/apt/introToAPT.php. Be aware those are project settings, not workspace preferences.
Make sure your potentially generated code is not deleted by some other part of your workflow. E.g. a second processor cleaning the directory that a first processor generated into.
Check that you are using a JDT and not a JRE both for running Eclipse as well as building your project.
Verify that org.eclipse.jdt.apt.core is part of your Eclipse installation, as that is the actual annotation processor integration for the JDT.
Verify your processor has a correctly filled file META-INF/services/javax.annotation.processing.Processor, pointing to the right class implementing the processor. Eclipse may ignore it otherwise.
That being said, I have used different annotation processors (like butterknife for Android) in Eclipse over the years and didn't run into such problems.
I had a similar problem with the AutoValue annotations not being processed with Eclipse 2019-3 with OpenJDK 11 as target runtime. In the Eclipse "Error Log" panel I saw this error:
java.lang.Exception: java.lang.UnsupportedClassVersionError:
javax/lang/model/element/ModuleElement has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Eclipse was running on an old Java 8 installation as indicated by Help -> About Eclipse IDE -> Installation Details -> Configuration. In my case, Eclipse found the JRE to run on on the PATH environment variable, see here. I forced Eclipse to use the OpenJDK 11 installation by adding the -vm argument to the Eclipse.ini:
-vm
"C:\path\to\OpenJDK\bin\server\jvm.dll"

JAXB backward compatibility

Years ago I wrote an application that used JAXB to generate Java bindings for an XML schema. The application code and the schema have been updated quite a lot over the years, but the JAXB jars remained the same since 2008, which was when I started using JAXB for this application. I've been using Ant to build the application, including generating and compiling bindings, and everything worked fine on at least two XP Pro development machines. I made some changes to the schema and never had to think about JAXB.
Recently I tried to rebuild the application from scratch on a new laptop, and the build keeps failing. The new 64-bit laptop is running windows 7 Pro, it had a newer JDK (1.7.0_45) and a new version of Ant (1.9.3). I was able to get around some weird problems by switching to a yet newer version of ant (1.9.4) and switching to latest JAXB jars. At this point, I don't even remember what those issues were (but I can recreate them by reverting to older JAXB jars in SVN).
After upgrading JAXB, I ran into new problems. First of all, the xjc task in ant seems to be interpreting the target attribute differently; it threw some error and apparently the destdir has the semantic meaning that target used to have.
Second, this task no longer generates the impl package with the implementation classes whose names were supposed to end with Type, so the rest of my code fails with a bunch of compilation problems.
Is there a way to make the new JAXB version backward-compatible? My other options are try updating the code to work with the new bindings, which seems like a lot of unnecessary work, or reverting to old JDK and Ant.
This is a late reply to the original post. But should be good as a reference for other folks. I met the same problem. Here is what worked for me after going through much of the same struggles trying to rebuild JAXB 1.0 scheme/binding using later JDKs (8 and 7).
My goal is to build with latest JDKs without the hassle of upgrading JAXB, if possible.
JDK 7&8 failed building with JAXB 1.0 due to ClassCastException thrown from <xjc> possibly due to incompatible language features. JDK 5&6 work, however.
I went through several attempts trying to upgrade to the latest JAXB 2.11.12,
Update ant build file <xjc> task to replace target attribute with deskdir
Change binding files syntax - bindingStyle attribute was removed in <jxb:globalBindings> in the latest JAXB - we use modelGroupBinding
Adjust binding class files suffix to avoid name conflicts. Update sources for the new type names generated.
There were still remaining name conflicts and source upgrades required.
I decided to stop going further down the rabbit hole making all these changes and focus on finding just one version of JAXB that generates JDK 7&8 compatible sources but still support JAXB 1.0 schema and binding.
Newer <xjc> task supports version specification by source attribute. However, as the original poster found out, support of "1.0" was removed in later JAXB distributions
The "Illgal version 1.0" error message when using <xjc> is due to support for version 1.0 was removed in since JAXB 2.2.7 (https://jaxb.java.net/nonav/2.2.11/docs/ch02.html#a-2-2-7)
However, JAXB 2.2.6 doesn't work either. There seems to be a bug in that "jaxb-xjc.jar" version not generating sources correctly based on the attribute, resulting in the certain ClassNotFoundException during build.
I read reports on JAXB 2.1.18 failing to respect "1.0" source as well
Eventually I found JAXB 2.0.5 is to be one version that can generate JDK 7&8 compatible sources using JAXB 1.0 source schema and binding.
Drop in the JAXB-RI 2.0.5 libs and remove old jaxb-libs.jar
Add source="1.0" attribute the <xjc> task
No need to convert <xjc> "target" attribute to "deskdir" in this version
I have not tested more versions beyond 2.0.5 but it's possible there are higher versions that does the same
Your old project seems to use JAXB 1 whereas all the tools now have JAXB 2.x by default.
Try the following in the XJC task:
source="1.0"
target="1.0"
See these documents:
https://jaxb.java.net/2.2.4/docs/xjcTask.html
https://jaxb.java.net/2.2.4/docs/jaxb-1_0.html

Categories