We Keep Coding

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();}}

ElasticSearch Client vs Base JVM version

I have an existing project that I want to use ElasticSearch in.
The core ElasticSearch requires Java 8, which isn't a problem since it will run in a different JBoss than the existing project we want to integrate with.
However, the ElasticSearch client will be integrated in the existing JBoss, which runs Java 7. Does anyone know the Java version requirement for the client? We are unable to upgrade this Java version due to other circumstances.

According to documentation you can use 8 or 7, however 8 is preferred.

what version of OpenNTF Domino API can I use?

I would like to use the OpenNTF Domino API but to me it is not clear which version I can use?
The version of the extension library on the Domino server is 9.0.1.v00_00_20151122-0905 (upgrade pack 1).

If you're using Domino 9.0.1 Feature Pack 8, then 4.0.0 is the way to go. Otherwise, 3.2.1 is the right one.
The plan is for 3.2.x to get critical fixes (which is what 3.2.1 itself was over 3.2.0) but otherwise remain as-is, while future development will happen on the 4.x+ Java 8 path.

The version of ODA will depend primarily on the Domino server version. It sounds like you're running Domino 8.5.3 and we've not specifically developed against that version. There was a lot of new functionality added in 9.0, specifically around NoteCollections, which is spread throughout the API. I did compile a version some years ago for 8.5.3, but it was never heavily tested or officially released. The server in question was upgraded to 9.0 before the project went live, so I'm not sure if I even have that version any more.
Version 4.0.0 is the first specifically compiled for 9.0.1 FP8 and will not work on previous versions. That's because it includes the new core Domino APIs (encryption, ID Vault etc) added with FP8. It's not currently compiled for Java 8, but work on that has already begun in the develop branch.
Version 3.2.1 is the recommended version for 9.0.1 up to FP7. It will still work on FP8, but only if there is no intention of using the new Domino APIs added with FP8. It will work with the base Extension Library as long as the Graph API REST functionality isn't required (not a regular requirement at this time), for which ExtLib 9.0.1_v00_17 is required. That's because additional hooks were added to the core Domino REST service functionality in ExtLib.
For any general discussion about ODA, there is an OpenNTF Domino API channel in the OpenNTF Slack. The OpenNTF Slack team can be joined from the main OpenNTF website home page.

Java Version Compatibility Issue

I have a client jar made-up using java 1.6 and used enum and other new features of java, my application is built on java 1.4.
I want to use that client jar in my application.
Is it feasible to do ?

Normally: no, you can't.
You could use a library/byte-code rewriter like Retroweaver to rewrite the library to be 1.4 compatible. There's also Retrotranslator which does the same thing and other tools. The last time I used Retroweaver was just after Java 5 was released, so I can't talk about it's current state.
But that will be a hack at best. Using an ancient Java version is a liability at best and you should upgrade to at the very least Java 5 as soon as possible.

Can't you upgrade to JDK1.6?
else you need to add rt.jar of JDK1.6 to your class path but that will cause conflicts for classes common to JDK1.4 and JDK1.6

Your client jar will need JRE 1.6. As for your application, ideally you should be able to run it on JRE 1.6 as Java is backward compatible.
So you need to port your application to JRE 6, recompile and then you should be able to use client jar.
However, upgrading and porting has it own complexity and consequences.

you could try making the jar available via a web service interface and run it as 1.6; should work, but I won't tell you it 'll be easy.

You obviously need JRE 1.6 or higher to run your library code. Due to backward compatibility the 1.4 part of your application should run on a that JRE as well. How you interact between your 1.6 lib and your 1.4 application is another question though.
Your application cannot use enums or other 1.5 features directly. If everything you directly access in your library is 1.4 compatible it should work, I think. E.g. if your application defines an interface and the library provides an implementation of that. (I.e. typical plugin pattern.) If your library's interface needs the application to use 1.5 features, e.g. pass an enum value as method parameter, that obviously won't work with your existing byte code.

Is Apache Commons projects tied with Java edition?

I have a question about Apache Commons projects. We know there are many nice classes and methods are available in Apache Commons Projects. But it is related to particular Java edition, I think. If I start use Apache Commons projects now, when Java updates itself to 1.8, I have to make sure Apache Commons projects has the similar update before I update to Java version 1.8? Having some 3rdparty libs is a good thing but I always worry about the compatibility between them and the main programming language I am using.

In general Java is fully backwards compatible, so if you start using e.g. commons-io in JSE1.6 it's going to work in JSE1.8 as well. Working with Java since 1999 I've never seen any issues regarding backwards compatibility.
EDIT: As long as Oracle does not change its compatibility policy, you should not run into trouble. If you later run into trouble anyway, you still have the source to fix it on your own (but may have to give back to the community depending on the license).

The Apache Commons projects update a lot more often than the JDK does. I would strongly advise to keep you libraries current. Even if only to get the newest fixes. That will also take care of any possible problems with JDK versions (which are backwards-compatible and have changed very little over the years and could be considered rather stable).

But it is related to particular Java edition, I think.
The only case where I have ever seen this be true with Apache Commons, Jakarta Anything or Spring was when one version used new JVM and/or compiler features. For example, Spring 2.5 had several jars which were for 1.5 and newer which means that in theory they would work on Java 5 through Java 8 without any bugs caused by the platform. You just couldn't use them on a Java 3 or 4 VM.
This is pretty much the norm throughout the Java community, for SE anyway. JavaEE compatibility may break because it's a matter of library compatibility and development methodology.