JBoss AS 7 is also compatible with JavaEE5 ? or I must use JavaEE 6?
I cann't find the document about the compatibiliy.
Yes, for most practical reasons it is compatible. It does not mean that JBoss especially built support for older version, but Java EE 6 itself is more like superset of Java EE 5. As result you can deploy application that uses only features that were available in Java EE 5 to the application server that supports Java EE 6 features.
Related
I am trying to find out what is the latest JDK level supported by TomEE 8 or 9. Specifically if JDK 15 will work. The install documentation says only Java 6 or 7 are supported. That seems a bit too old.
The JDK compatibility and support of TomEE is not well documented. The "java compatibility" note in the official documentation is outdated. The Java versions mentioned in the install documentation are an obsolete minimum requirement - propably a copy & paste thingy.
Here is what is known:
TomEE 8.0.9 definitely supports JDK 8, JDK 11, JDK 17
From a short stackoverflow research, for some users JDK 14 or JDK 15 also worked
TomEE 9.x does only support the Jakarta namespace (Jakarta EE 8, Jakarta EE 9.x)
Watch the Release Notes for updates.
According to this documentation page only JDK 8 is supported by TomEE 8.
I am currently involved in a project, that requires migration of 3.5 to 4.x, 4.14 is working fine. I am raising this question because, mule 2 is supporting Java 11, while mule recommended approach is to work on adoptopenjdk 8.0
https://docs.mulesoft.com/release-notes/mule-runtime/mule-4.2.0-release-notes
It is not clear exactly what is the question, however migrating from Mule 4.1.x to 4.2.x doesn't require usually changes to applications. You are free to use Java 8 or 11, though 8 is recommended.
You can upgrade from 4.1 to 4.2 without changing the code or the java version.
So the best approach to migrate would be to use the same configuration as in 4.1
Furthermore, it's a good practice to upgrade the connectors versions of your app.
My understanding is that Java EE 7 runs on Glassfish 4. What version of Java must I use to run Glassfish?
GlassFish 4.x requires Java 7 or Java 8. Java 7 is no longer supported, so Java 8 is recommended.
Page 1-3 of the GlassFish 4 release notes specifies the following:
GlassFish Server Open Source Edition Release 4.1 requires Oracle JDK 7
Update 65 or later, or Oracle JDK 8 Update 20 or later.
https://javaee.github.io/glassfish/doc/4.0/release-notes.pdf
Would I encounter any problems running Java programs and associated libraries compiled in Java version 1.6 and 1.7 (I'm compiling using 1.7 whereas some libraries are compiled using 1.6) and running the entire program in a 1.7 JRE?
As answered already you are mostly safe and most products and 3rd party libraries will simply work. However there do exist very rare cases where binary incompatibilities (ones where the class file compiled using older JDK will fail to run in the newer JVM) were introduced between JDK versions.
Official list of Oracle Java incompatibilities between versions:
in Java SE 9 since Java SE 8
in Java SE 8 since Java SE 7
in Java SE 7 since Java SE 6
in Java SE 6 since Java SE 5.0
in Java SE 5.0 since Java SE 1.4.2
Compatibility tool
Packaged with JDK 9, there is a tool called jdeprscan which will verify the compatibility, list no longer used APIs within your code and suggest alternatives(!). You can specify the target JDK version (works for JDK 9, 8, 7 and 6) and it will list incompatibilities specific to your target version.
Additional comment in case of libraries:
A reasonable rule of thumb is to use latest stable release version of library for the JRE version your software targets. Obviously you will find many exceptions from this rule, but in general stability of publicly available libraries usually increases with time.
Naturally API compatibility and versioning have to be considered when changing versions of dependencies.
Again most popular dependencies will have web pages where such information should be available.
If however you are using something a bit more obscure, you can discern which JRE were the classes within your dependency compiled for.
Here is a great answer on how to find out class version. You might need to unzip the JAR file first.
You would not encounter any problems - that's the magic of Java -it's backwards compatible.You can run almost all code from Java 1 on Java 8. There's no reason why Java 6 code won't run on a Java 8 Runtime.
What is interesting, is that for applications written in, let's say, Java 1.4, you even have speed increases when running them on later runtimes. This is because Java is constantly evolving, not just the language known as "Java", but also the JVM (Java virtual machine). I still have source code from more than 10 years ago that still work, as expected in the latest JVM.
If you want to target, let's say, a Java 5 VM, then you can do that with the Java 8 SDK tools. You can ultimately specify which target VM you wish to support, as long as you bear in mind that a version 5 VM might not support all the features a version 8 VM will.
I've just tested code I wrote in Java 5 against the new Java 8 runtime and everything works as expected, so, even though we have a more powerful language and runtime now, we can continue to use our investments of the past. Just that alone makes Java a great development choice for companies.
I heard that JBoss 7 is not certified for FreeBSD - is that correct?
Where can I find a list of supported platforms? (I spent some time googling, but was not successful)
Strictly speaking there is no certified OS for JBoss 7 as only JBoss EAP 6 is supported by Red Hat.
The supported configuration for JBoss EAP 6 (the supported version of community JBoss 7) can be found here: https://access.redhat.com/knowledge/articles/111663
As JBoss is pure java application, a compliant JDK is enough to have a supported system. So if you have the Oracle or IBM JDK running on FreeBSD is will be supported by Red Hat. But they haven't test them with JBoss.
Any way if you want Red Hat support for the EAP you better check with there representative to discus the extends of the support (if the FreeBSD JDK have some compliance bug, they will probably send you back to the JDK supplier. If you chose RHEL with OpenJDK you will have one supplier to blame for any software stack issue, no redirect to another suplier.)
For community JBoss as for other platform, you will be responsible to make it work with your stack. An good first test can be performed by running the standard compliance tests included in the JBoss sources, if it runs on your target platform and JDK it is a good sign that JBoss is working on it.
Certified Support as per Redhat only goes up to 6:
https://access.redhat.com/knowledge/articles/111663
However if you look back at the release docs they have not changed. OS's are the same.