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
Related
My RCP application makes calls to SOAP web services and has been using the built-in JAXB/JEE components in Java 1.8. I have set up the build process to force the use of Java 1.8 and this had been working well.
Recently, the build stopped working because the builder (Tycho) now has a component which only works with later Java versions. If I compile with the later version I get 100's of JEE-related errors such as JaxbElement not found or #WebMethod not found.
At some point we will have to move away from Java 1.8 and use a Java version which does not provide those JEE components, so forcing the use of 1.8 can only be a short-term solution.
Is there an eclipse plugin which already provides those missing components? (I have searched but not found anything) Or do I need to create my own helper plugin which contains the necessary libraries? Is there perhaps a JAXB alternative which I could use for the SOAP calls?
The JAXB plugins/bundles are available on Eclipse Orbit: the plugins/bundles starting with javax..
In the plugins/bundles where they are needed, add the dependency in the MANIFEST.MF file via Import-Package (using Require-Bundle would require that these plugins/bundles are available even when using Java 8).
See also this answer.
Recently I was assigned to a task wherein I have to upgrade the existing standalone java application from Java 1.6 to Java 1.8.
I'm yet to go through the code and I have no idea about this project.
They were using
ANT 1.6.1,
AXIS 1.5.1,
ABINITIO 2.15,
ORACLE 11.1.0.7,
AUTOSYS R11,
Java 1.6.
I got to know that first I need to identify whether the above mentioned Tools/Frameworks are compatible with Java 1.8.
Please suggest what are the other challenges I might encounter while compiling and building the application?
Although Java is supposed to be backward compatible between versions, it's also known that backward compatibility in any language isn't aways as straight forward as the name suggests. Some (most) projects release it's libs versions compiled specifically targeting one or another development kit, to take advantage of new features and enhancements added to the language.
That being said, I believe the smarter way to go would be: first, update the project's JDK and rebuild it targeting the new bytecode's version. There's a chance you'll have to upgrade both Ant and (if that's your IDE of choice) Eclipse (see here why).
Second, you'll have to check for compilation errors, which will most likely lead you to update libraries conditionally to get them fixed. With those solved, you MUST run your app and see if it's running as intended; remember that compilation problems are just the top of the iceberg when the subject are dependencies.
Carefully check the app's logs looking for exceptions of any kind but mainly the ones related to class loading exceptions such as ClassCastException, ClassNotFoundException, NoClassDefFoundException, UnsatisfiedLinkError and others. If any apear, you'll have to pinpoint one by one and search for the specific solution of the specific troublemaker library.
With all that covered, you should have your app running healthily again.
One last hint, if this project of yours is still being developed, it would be a very good practice to keep the tools you use updated to their very last release. Keep also the development tools updated, like build (such as Ant, Maven, Gradle and others), JDK's and IDE's. It way easier to upgrade the pieces as they are release than to handle a mass scale upgrade :)
As far as I understand, it is better to use Spring versionless xsd.
However, when using Intellij the validation is done based on a random xsd file.
When adding the version to the xsd file everything works as expected.
As you can see I use Spring 4.2.1 but Intellij chooses 3.1 version.
Is it a bug (or not yet implemented feature) in Intellij?
Is there a workaround?
If there is no place with version specification, then
yes, it is random, you can try the following test: add space in front of line (make some simple change) with xsd specification), after each change it jumps to another random xsd version
If you want to lock it on the latest lib version and don't specify it, you can use gradle build.
//use latest version of library with gradle:
compile 'org.springframework:spring-orm:+'
after that idea always points to latest version of xsd for schemaLocation
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.
Here is a small explanation of my problem.
I have an application which was compiled with java 1.5. This application is installed on 2000 pc (blockboxes) installed at customer premisses.
The jar of my application is often updated to add new feature and fixes, but for technical reasons, it is not very easy to update the java version, so I must keep using Java 1.5 on those existing machines.
Few months ago, I got a request for a new requirement for this application. To fulfil this task I have added the usage of Hazelcast in this application.
My problem if the following:
- Hazelacast jar file needs Java 1.6 or above, so I must compile my application with 1.6
- The new functionality using hazelcast will only be activated on demand by settings a new parameter. This means that it will not be used in the 2000 already installed blackboxes.
- All new blackboxes will be installed with Jave 1.6 or above to be able to use the Hazealcast functionality.
My problem is that I want to have a unique source code and unique version of my application for old blackboses using Java 1.5 and new blackboxes using 1.6 or above.
In the beginning, my idea was to always compile with version 1.5 and make sure that the new functionality would only be activated in blockboses using java 1.6 or above. This option is not working, because when I compile with 1.5, the compiler complains that Hazelcast jar file needs 1.6 :(
The second option would be to compile with 1.6, but then I cannot be sure that my application will still work properly on all blackboxes using 1.5. :(
I'm would like to know if someone here would know how to solve this kind of problem?
Just let me know if my explanation is not clear ;)
Thanks in advance for your help.
JVM is Backward compatible.You can run almost all code from Java 1 on Java 8.
So the best way is to use the option two. Compile it with 1.6 on some testing machines. And if it works( which most probably will) you don't have to make much change to the application .
You can compile your code to Java 1.5 bytecode using JDK 1.6, just take care of the following:
-source=1.5 and -target=1.5 compiler options
bootclasspath should point to rt.jar from JRE 1.5
See this post for more info: http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html
The post also recommends simply building your application with older JDK if possible. You need to figure out a different build process and exclude incompatible libraries from the classpath. If you use Maven, consider having two pom.xml files, with an optional parent file.