We Keep Coding

Can I run a java program built using Java 8 (.192) using JRE 17, or does everything (JRE, JVM, JDK) have to be on the correct Java 8 version first?

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.

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

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
}

Security issues of compiling against older JDKs

Are there any known security issues with compiling against an older JDK? For instance lets say Oracle decides to change something in one of their implementations that was to close a security vulnerability. If we compile against the older JDK would we still be vulnerable?
EDIT
We are running against JDK 6 and we compile against Java 5, which is the crux of the issue I was attempting to get at for any one else whom sees this question. For the sake of completeness lets say that in the ant build we target 1.5
EDIT 2
Additionally there is the issue of calls in the application that potentially have private APIs/implementations that are not directly accessed.

Aside from some very hypothetical niche situation that hasn't ever happened yet, the only thing that matters is the version with which the application is executed.
I don't think there are any known security issues that have been "fixed" with #deprecated, because that wouldn't really be appropriate.
There are two issues at play here:
1) You can have your Java compiler produce binaries that are binary compatible with older versions. That affects the language features available to you.
2) You can compile against the Java system libraries of an older version, and that will affect what methods/classes are available, as they are always adding new ones.
But neither of these affects the security of your application. What matters is the runtime version with which the application is executed.
Observe that security problems are fixed between updates, not the major versions, which introduce changes in the language itself. For example, Java 6 is currently at update 21. Java 6 update 19 fixed stuff that was vulnerable in Java 6 update 18.
When Java 6 update 19 was released, updates were released for Java 1.5 and Java 1.4, to fix the same issues in Java 1.5 (update 24) and Java 1.4 (update 26). See the security baseline table here: http://www.oracle.com/technetwork/java/javase/6u19-141078.html

If you compile against JDK 1.5:
Users that are using JRE 1.5 will be vulnerable
Users that are using JRE 1.6 will not be vulnerable
The application will run using the libraries of the users's runtime. Since the vulnerabilities are fixed in Oracle's library, which is now being called by your application, the security vulnerability will be alleviated.
However, since you compile against 1.5, your users will be able to use 1.5. Do anything you can to avoid the vulnerability; if you can't avoid it, detect the JRE version at startup and issue an alert if apporpriate.

If Oracle changes an API (not an implementation) to promote security, they will probably add an #Deprecated annotation but preserve backward compatibility for some time. The annotation will trigger a warning in a newer compiler, but not in yours, and not in the compiled program. (Unless Oracle decides to throw an exception or log a message from the deprecated method.)

I would say that those unfixed vulnerabilities are still there, and you and your app are still at risk.
It'd be the same issue as running with an old, unpatched OS or browser.
It's a good incentive to migrate up to newer JVMs.