Is WSO2 API Manager certified against Suse EE SP3 and Oracle Java JDK7 ?
http://docs.wso2.org/display/AM160/Installation+Prerequisites
Whatdoes de * means with JDK7
In a technical point of view, the WSO2 products should be able to run on Oracle JDK 7. I do not think anyone has especially tested on Suse EE SP3.
As long as it runs on Oracle JDK, the products should work fine.
The 1.7.* means that any Java 7 update should work. For example: 1.7.51 -> Java 7 Update 51
However we have faced issues specific to a Java update. For example, there is an issue with Java 7 update 45. You will encounter JAXP00010001 error after a certain number of requests to API Manager.
I would recommend you to use the latest JDK from Oracle. AFAIK, we haven't encountered any issue with latest JDK.
I hope this helps.
Related
So I'm trying to understand which JDK versions are compatible with Jakarta EE 9.1 (using glassfish 6.1.0). Apparently it supports up to JDK 11 but in NetBeans in able to perfectly run GlassFish with JDK 16 installed. Also it shows that the installed Jakarta API libraries are of version 9.0.0 but somehow I'm still able to download, install and run GlassFish 6.1.0..
To put it simply, I'm just really confused with all the version compatibility and how can stuff work on my end without matching versions (under the assumption that what I wrote above is correct).
Any product compliant with Jakarta EE 9.0 is guaranteed to work with Java 8.
Any product compliant with Jakarta EE 9.1 is guaranteed to work with Java 11.
Some products work well with later versions of Java as well.
Java 8, 11, and 17 are the official Long-Term Support (LTS) versions. So these are the versions expected to be used in production for serious deployments.
The main point of Jakarta EE 9.1 is the support of Java 11. Some specs have other changes, but mostly minor.
Jakarta 10, under development now, is where you can expect to see innovations and improvements. You can find many video presentations and blog posts discussing possible changes and current plans. The various teams are asking for input from those with an interest in their particular spec.
You said:
able to perfectly run GlassFish with JDK 16 installed
Java 16 is now at end-of-life, no longer supported. I suggest you move on to Java 17, the current version, and also a LTS version.
Yes, many products will run well with later versions of Java. This is especially true of products compliant with Jakarta EE 9.1, aimed at supporting Java 11. Java had some issues with breaking or limiting backward compatibility between Java 8 and 11. So some older products may run into a problem when moving past Java 8. In contrast, compatibility from Java 11 through 17 has been very smooth with very few issues.
But that is the point of the six-month cadence of official Java releases. You can, and likely should, do some of your dev and testing work using each Java release. If you encounter any issues, you can provide feedback to the developers of the problematic product sooner rather than later.
Regarding Eclipse GlassFish specifically, their home page describes various releases.
Version 6.2.2 is the current release compliant with Jakarta EE 9.1.
Compiles with JDK 11 to JDK 17
Runs on JDK 11 to JDK 17.
Briefly tested with JDK 18 early-access releases.
The prior version, GlassFish 6.2.1, brought much improved support for JDK 17.
We currently use Glassfish 4.1 and I really want to use Java 8. Will Glassfish 4.1 work with Java 8 or will I have to upgrade my application container?
Simple answer,
Yes.
GlassFish 4.1 will work with Java 1.8.
In general: updating the jvm version alone rarely leads to issues.
Keep in mind that a lot of work goes into making sure that new Java versions are backwards compatible. And most importantly: a new jvm can always run byte code compiled for an older version of Java. The other way round (upgrading your application server for example) is much more likely to cause significant problems.
So, the (unspecific) answer here is: just try it. And for the record: Java 9 (or newer) with the new module system is a completely different story. But at least for now, the corresponding checking can be disabled on the command line.
Of course, there can be subtle issues for large applications. A new jvm may use different defaults for say, garbage collection settings (or use a different gc in the first place). That can of course change the runtime characteristics of large applications running in a large stack.
The best (and easiest) approach for determining whether Java version 'x' will work Glassfish version 'y' is to refer to the Release Note for that specific Glassfish release.
The Release Note will have a section titled Hardware and Software Requirements, and within that a sub-section titled Required JDK Versions.
For Release 4.1 the answer is:
GlassFish Server Open Source Edition Release 4.1 requires Oracle JDK 7
Update 65 or later, or Oracle JDK 8 Update 20 or later.
Notes:
The word "later" in the part stating "Oracle JDK 8 Update 20 or later" is ambiguous, but it is referring only to the update level for the specified JDK version. Do not interpret "later" as implying that Glassfish 4.1 might work with Java 9 or higher. It would be much clearer if the wording was:
GlassFish Server Open Source Edition Release 4.1 requires Oracle JDK 7
using Update 65 or later, or Oracle JDK 8 using Update 20 or later.
It is incorrect to state that "Glassfish 4.1 will work with Java 7 or Java 8", because in both cases a minimum update level is also required.
You can also get the minimum JDK requirements from Glassfish itself. Under the root of the unzipped download in a file named README.TXT there is a section titled 0. Prerequisite. For Glassfish 4.1 it is worth noting that the information given conflicts with that in the Release Note!...
GlassFish 4.1 requires Oracle JDK 7 Update 65+ or Oracle JDK 8 Update
5+.
In the odd cases where the requirements in the documentation conflict I'd always be inclined to choose the higher update level, and most of the time this is unlikely to be an issue.
we are using a very old version of java installed previously in our server (version 1.4) and according to this case we used a very old version of iText2.1
Our main vendors planned to upgrade the server and they will upgrade the java version to 8.
Question: should i upgrade my application which uses the iText2.1, or it will work fine with the new Java ver.? and what version should i use then?
Note:i've tried to raise this question in the itext blog but they put the stackoverflow link for any technical question. , so please be kind and help me.
The above comment is really an answer:
I know that in recent versions of iText (I think 5.5.7 or 5.5.8) we made some small changes for Java 7 and Java 8. The minimum for iText 5.x.x is Java 5. Anything older than 5.0.0 is totally unsupported, sorry. iText 2.1.0 is from March 2008, that's 8 years ago.
Using Eclipse
I am Using 1.8_45 with iText5.7
No Exception and warning with it .
So Upgrade
and if you are not upgrade your iText2.1 with java 1.8_45
so it's give you Exception
yes you can easily upgrade your versions
1.8_45 to 66 jdk
with
iText5.7
Could you please help in finding out if JRE 8 would be compatible with weblogic 10.3?
We have a swing based application deployed on weblogic 10.3 server. We want to upgrade our JRE so wanted to check if JRE 8 would be able to run apps deployed on weblogic 10.3
Java 8 is supported on WebLogic Server 12.1.3. It is not supported on 10.3.6, 12.1.1, or 12.1.2.
See https://blogs.oracle.com/WebLogicServer/entry/weblogic_server_12_1_3
Java 8 is not yet supported in Weblogic server (till Weblogic 12.1.2).
It would be supported in future release.
https://community.oracle.com/thread/3539686
Bit old topic, but just came across this issue myself and have a bit more to add to it. As with the existing answers, it can't be used to install directly- the oracle installer will complain.
However, it is possible to install using an earlier JDK (6 or 7 are supported in 10.3.6), and then swap to JDK8 under the covers. I expect you could also use a custom install to bypass the installer entirely.
This obviously isn't supported - but it does run. If you try to use certain JDK8 features though, they tend not to work (such as newer jdbc drivers - 4.2 simply won't run), so there isn't much benefit to this in normal use cases.
As per the latest update Weblogic 12C is compatible with JDK 8.
https://docs.oracle.com/en/middleware/fusion-middleware/weblogic-server/12.2.1.4/notes/whatsnew.html#GUID-960100E8-DFC1-49E5-8CED-1EC1D883A42F
I am developing software on a machine with the latest JDK update (e.g. jdk1.6.0_24). Do the machines where the software is running also need the corresponding JRE update version? Or would it suffice to have an older version (e.g. jre1.6.0_10) installed?
Just the major version (1.6.0) needs to match for Java. It's fine if the update version (10 and 24) is different, the spec is still the same. Although ideally the place where the software will run has the latest update for bug fixes, security fixes and performance improvements.
You do not need to worry, if both are the same major version, which is your case, both are Java 6.
However, if you are releasing your software to a client machine, I would suggest you to read the incompatibilities between Java 6 and other Java versions. And, if there is an incompatibility, mention it in your product document.
Please read this document: Java 6 Compatibility