JRE 8 compatibility with weblogic 10.3.6 (11g - java

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

Related

Will it be possible to use Java 8 on Glassfish 4.1?

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.

CA-sv will supported in Java 8?

CA service virtualization can be configured by Java 8
As I checked with CA sv document I had seen its supports only limited Java versions.
Kindly help me to get info.
As far as running DevTest Server and DevTest Workstation are concerned, the Windows installer automatically includes a compatible JDK. As of the latest GA release (10.1.0), that would be Java 8. Most recent releases have been Java 8.
On Unix, you must provide your own JVM, and there are different settings for Oracle and IBM JVMs.
https://docops.ca.com/devtest-solutions/10-1/en/installing/preinstallation/system-requirements#SystemRequirements-SupplyingYourOwnJVM
That link is specific to 10.1.0 which requires Java 8. If you have an older version, please check the version specific documentation.
Note that OpenJRE is not supported at any version.
The JDK that DevTest runs on is only important if you're writing custom extensions. You don't want to build an extension with a Java version newer than what the server uses.
Scripts within a VSM, however, are another matter. The deprecated JavaScript step, I believe, only understands JDK 1.4. I'm not certain about the JSR-223 step but, if you select Beanshell, you're probably still limited to 1.4.
You're also limited to JDK 1.4 in Beanshell expressions like:
{{=new java.util.Date();}}

Which Java EE server?

I'm moving in to developing Web Apps using Java EE and the first problem I have is not knowing which Server to use! There seems to be so many to chose from!
Glassfish server seems to stand out foremost (and it's top of the list) but when I try to start Glassfish 4.1.2, I get the error GlassFish requires Java SE version 6. and I can't download Java SE 6 for MacOSX without joining the "Oracle Club".
So which Server should I use??
You're running JDK 8, as you should. You should not be downloading JDK 6. It's long past the end of its support life.
Looks like the latest is version 5. You can download it here.
It should be said that you don't need Java EE to write Java web apps. Another alternative is Spring Boot. You won't need an app server, just an executable JAR to be run on a JDK.
Are you on OSX? You can get a JDK1.6 download here: https://support.apple.com/kb/DL1572?locale=en_US
I would be very careful with JDK1.6, it's about as safe as seatbelts made from toilet paper.

JNLP. Cause client to use JDK < 7 version

After some JDK 7 updates my applet won't work (security exceptions). How I can specify JRE version range to use by client in JNLP file? I want cause him to use only JRE 6, not 7.
What you are trying to do is a Really Bad Idea.
Java 6 has been EOL'ed and that means no more free security updates. So what you are doing is encouraging people to downgrade the version of Java used by their web browsers to an out of date version of Java that is likely to have unpatched security bugs that could soon be being actively exploited to do all sorts of nasty things to the user.
The correct approach is to fix your applet so that it works with the latest JDK update (as well as older ones).
The only way out is ,detect the version of java using in browser and giving him a proper message that ,use java 6 jre.
You might heard about deployJava.js
and check the version like
if(deployJava.versionCheck("1.7")){
//message him
}

Which JRE when developing with latest JDK update

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

Categories