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();}}
Related
I have a program for work that I'm told will only use Java version 8 update 192 to run correctly. When I downloaded eclipse, it's suggesting that I use JRE 17.0.2 but I recalled my coworker saying I need Java 8 update 192 otherwise it won't work. Does the JRE version matter? Is it irrelevant?
Perhaps I need to download JRE 8.192? I'm not sure. Any help would be appreciated.
I have a program for work that I'm told will only use Java version 8 update 192 to run correctly.
I would doubt the accuracy of that statement. I would say that someone is making a statement without evidence ... if that is what they actually said.
Maybe a more accurate statement is that the program is only known to run on that particular version ...
Anyway, it will probably run on a later version of Java 8, or Java 11. Java 17 is less certain because of the issue of package sealing / blocking of access to internal packages that occurred in Java 16. (Some of the sealing / blocking started in Java 9 ... but there are easy workarounds ...)
Q: Do you need a JRE?
A: No. A JDK will work just as well. (A JDK distro includes a JRE.) But unless there are strong counter-indications, you need the latest version of Java 8, 11 or 17. Java 8 u192 is years out of date.
The only way to be sure that the application will work on a particular version of Java is to try it. In general, there are no shortcuts.
Java 8 is still available, as the first Long-Term Support (LTS) version. The current release is Update 331. I would suggest starting with the latest update of Java 8.
Be aware that Java 8 is not receiving regular updates for the public except for critical security patches. You may want to consider paying for a support contract from any number of vendors such as Azul Systems or Oracle to get support including possible additional updates releases through the rest of this decade.
Generally Java apps will run on later versions of Java without any modifications needed. The Java team at Oracle and the OpenJDK community place a very high priority on preserving that compatibility.
However, there are exceptions to the compatibility policy. In particular: Java 9 introduced the Java Platform Module System which caused some problems in some apps. And in later versions of Java some libraries that were previously bundled are now removed. Some of those removed libraries were transferred to the Jakarta EE project at the Eclipse Foundation. Some were abandoned for lack of interest such as CORBA.
Some few parts of Java that were for years marked as “deprecated for eventual removal” have now been removed.
If you consider moving beyond Java 8, I suggest your first step be sitting down to read through the Release Notes for every release of Java. They are quite well-written. They should alert you to any issues that may affect your app.
FYI, Java 17 is the latest LTS version. Java 18 is current.
As in the other answers, an application built for Java 8 will probably work fine in Java 17, with some caveats, but if you absolutely need the final product to run under Java 8, go get a real Java 8 runtime and set it up in your IDE. Building a Java application for any specific Java version is best done by having an actual copy of that runtime present, preferably a JDK. By having an exact version of its standard library to compile against, you can avoid accidentally referring to packages, classes, and methods added to, or removed from, later versions. You can get an OpenJDK build of Java 8 from https://adoptium.net/?variant=openjdk8 . Be sure to ask your co-worker why they're mentioning an outdated patch version.
Additionally, keep in mind that Eclipse is itself a large Java application. Running it requires Java, and a growing number of downloads include a Java runtime for that simple reason, even the ones that do not include Java development tools. You don't have to compile your code against that version of Java, though--you probably don't even want to since JDK downloads will include JavaDoc for the standard library, among other useful extras.
I have problems with the following method:
sun.security.x509.AuthorityKeyIdentifierExtension.getEncodedKeyIdentifier()
It exists in openJDK but it does not exist in oracleJDK. I always thought that except for some special cases regarding licensing those JDKs should be the same ...
While I can work around that issue, I fear there are other incompatibilities I might not be aware of.
Classes that are not part of the standard packages and classes that are deprecated can be not part of a jdk.
In your case you can try to solve the problem using the classes of the package javax.security.cert. Searching for it on google you can find some tutorials like this one.
Just to complete the answer is true that "generally" both compiled code comes from the same source code in the open jdk and in the oracle jdk. But oracle jdk and open jdk have different licences so there are also few little differences. Generally the differences are not related to the source of common classes, but to the presence or absence of classes or entire packages. As an example see the font library.
This is not the only difference. As you noted in your code also the security packages are different, because the open jdk added also the old sun version of x509 certificate classes and the oracle jdk not. There is no guarantee on what classes are included or not if they are not part of the standard packages. So if you have problems running your code on different jdk environments use only standard packages or explicitly import libraries as you need.
That class is not part of the public Java API and is therefore not guaranteed (or even likely) to exist in every JRE implementation, nor every release of the same provider's implementation.
If it's not part of the standard APIs, then you can't count on it.
Java Standard Edition 8 - all JDKs should provide these
Java Enterprise Edition 7 - some environments and libraries will provide these
While the OpenJDK and OracleJDK implementations happen to be very similar as they share a common history, they could diverge (or converge) in any private APIs or implementation details at any time, simply because they are separately-run projects.
Instead you should be using the appropriate implementation-agnostic APIs in java.security and javax.security for dealing with certificates.
Oracle JDK was previously called SUN JDK and that was before the takeover by Oracle. Earlier, it was the official proprietary implementation of the Java language. After the takeover it was named as Oracle JDK and Oracle’s team maintains the JDK.
OpenJDK is an open source implementation of the Java Standard Edition platform with contribution from Oracle and open Java community.
Actually, Oracle JDK’s build process builds from OpenJDK source code. So there is no major technical difference between Oracle JDK and OpenJDK.
Apart from the base code, Oracle JDK includes, Oracle’s implementation of Java Plugin and Java WebStart. Also includes third party closed source and open source components like graphics rasterizer and Rhino respectively.
How Oracle JDK and OpenJDK is kept in Sync:
All of the development and bug fixes happens in OpenJDK and then they are propagated to the Oracle JDK. Security fixes happens in private forest without public code reviews unlike general fixes, then they are pushed to Oracle JDK and then to OpenJDK.
more on http://javapapers.com/java/oracle-jdk-vs-openjdk-and-java-jdk-development-process/
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
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
}
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