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.

Does Google App Engine support Java 8?

Trying to get started with Google App Engine - does it work with Java 8?
I've followed the instructions on this page:
https://console.developers.google.com/start/appengine
Selecting 'Java', I successfully completed the Maven build, but when I visit localhost:8080 nothing is running.
The instructions say "make sure you have Java 7 JDK installed" however I have just installed Java 8 JDK.
Do I need to separately install Apache?

Java 8 is now generally available on App Engine Standard Environment, joining the GA runtime on the App Engine Flexible Environment.
Learn about the differences.
The new Java 8 runtime has all the benefits of Java 7 but with upgrades and enhancements:
OpenJDK 8-based Java runtime supports the standard public Java
library (no whitelist)
Doesn't impose a security manager--your code won't be restricted by Java permissions issues.

Not at the time of writing but you can keep track of the status in this issue:
Java 8 support: https://code.google.com/p/googleappengine/issues/detail?id=9537

[The passage of time has changed the 'no' from this accepted answer to 'yes'. Please see others answers below.]
Short answer, no. They will integrate it over time, but for now if you use it, it will cause you a lot of errors. I would recommend against it
Also take note of user7610's answer below :). It is as of now the only way to have Java 8 on the Cloud Platform

Update: it is available in the "standard" (sandboxed) offering since mid 2017, https://cloud.google.com/blog/products/gcp/java-8-on-app-engine-standard-environment-is-now-generally-available
Before then, it was sort-of available, via Managed VMs. The idea is that you provide a Docker container with whatever software you need (like Java 8) and GAE will use that as your app instance VMs. You still get the autoscaling, monitoring and all that.
The disadvantage of Managed VMSs is that you are charged as for the Compute Engine VMs. That means you pay by minute and there is no free quota. There is the $300 credit for new user accounts for 60 days, but after that you'd have to pay.

If your interest is in using lambda expressions on Google App Engine, you could give Retrolambda a try. I haven't tried it yet, but it claims to backport Java 8 lambda expressions to Java 7.

Google App Engine Java 8 support is generally available as of Q3 2017. https://cloud.google.com/appengine/docs/standard/java/runtime-java8

It's not quite the same thing, but you can use Java 8 with the new App Engine "flexible environment". I don't think you can access App Engine APIs (such as the images service or task queues) but you'll be able to use services which live outside of App Engine, such as the Datastore and Pub/Sub.
It's also worth bearing in mind that the service is currently in beta (so not covered by any SLAs). Also, the pricing is different; instead of using the normal App Engine pricing structure, it's based on usage of GCE virtual machines.

yes it does. We just launched this to Beta and soon GA.
https://cloudplatform.googleblog.com/2017/06/Google-App-Engine-standard-now-supports-Java-8.html

App Engine Standard Java now supports Java8.
See the Beta documentation at: Java8 on GAE Standard documentation
Thanks

Add <runtime>java8</runtime> to your appengine-web.xml file.

Yes, using App Engine flexible environment. Here are the official docs:
https://cloud.google.com/appengine/docs/flexible/java/
And here is the github repo for this implementation:
https://github.com/GoogleCloudPlatform/appengine-java-vm-runtime

You can apparently use JDK8 to create JRE7 compatible byte code, and this seems to be what Google recommends: https://cloud.google.com/appengine/docs/standard/java/download
-source 1.7 -target 1.7

Yes, You can use flexible environment. and change setting of your app.yaml
vm: true
for more information study https://cloud.google.com/appengine/docs/flexible/

Convincing customers to upgrade to Java 5

We sell packaged Java web applications to some of our customers. It's basically a collection of servlets, some SOAP web service and some static resources. We don't do EJB nor any other Java Enterprise fancy stuff.
Some of our clients are running IBM WebSphere Application Server v5.1, hence we are limited to Java 1.4 for the run-time and the development. Of course, we would like to do our development using Java 5 (or even better Java 6). Doing SOAP in 1.4 requires an external lib (we use AXIS, but it's aging). We can't use enum, boxing, generics... It's becoming harder to find 1.4 compliant third-party libraries.
The customers are currently satisfied with this old-but-working-well setup. We would like them to upgrade their Java run-time. In this case, it means upgrading to IBM WAS 6.1 or 7.0?
What can we tell them? What's in it for them?
So far I've got:
Better performance as JVM is much more efficient in Java 5 (even better with Java 6). I can't put figures on it, though. Not sure if IBM VM has improved a lot (one of our client is running on AIX).
Support. IBM WAS 5.1 can only be supported through special extended support programs.
They are big corporations, so they plan their solutions more than a year in advance. They select a mature product today and they deploy it years later. The product then has a few months before being end-of-life.
See IBM WebSphere Application Server comparison

Java 1.5 has reached end of life November 3, 2009.
So neither 1.4 nor 1.5 are supported any longer which means no security fixes.
So basically the only supported Java platform currently is Java6 (aka Java 1.6)

You could tell them the costs of their decision.
If they continue to choose Java 1.4 then adding a new feature will cost $yyy. If they upgrade then adding the same feature would cost $xxx. Presumably they also have a cost of upgrading their systems. If you can show them that the savings on the newer version of Java exceed the cost for them of upgrading their system then they can see that they will save money if they upgrade.
Obviously it is difficult to give exact values for the development costs, but if you can estimate that development would go for example roughly 30% faster (and therefore be 30% cheaper) on a newer version of Java then you can get a rough figure at least.

First of all, the only SDK that is supported with a given version of WAS is the SDK that actually ships with the product (in other words, IBM won't support running WAS on another JDK, if this matters).
Secondly, WAS might actually not even start with a more recent version of the SDK (WAS 6.1 won't start with IBM JDK 1.6 for example).
WAS 5.1: J2EE 1.3, JDK 1.4.2
WAS 6.0: J2EE 1.4, JDK 1.4.2
WAS 6.1: J2EE 1.4, JDK 1.5
WAS 7.0: J2EE 1.5, JDK 1.6
So requiring a more recent runtime will probably be synonym of big migration: qualification of the JDK and application server, training of admins, migration of platforms, migration of applications, update of monitoring, deployment tools, regression testing, etc. This is generally a complex and extremely slow process with big conservative companies.
In your case, you could maybe consider branching your software and offer different versions and:
only do maintenance on the old version
and define an EOL date for the old versions (you can't maintain it Ad Vitam Aeternam)
offer new features on the new version only
offer more aggressive pricing on the new version
There must be a good reason for your customers to adopt a newer version and it must out-weight the cost of a migration.

You're in business to satisfy your customers. They have a need (be it real or perceived) to stick with an obsolete platform.
So, say "yes," but let them know you plan to increase your maintenance and upgrade prices for the old platform on a date certain. This is a perfectly justified price increase; you need to maintain expertise and equipment to make sure your code works on an old, unsupported, and conceivably insecure platform. You're delivering real value to them by supporting their current infrastructure.
And be happy you're not in the diesel engine business. If you were, you'd have plenty of customers with world-war-ii era technology.

Been there... Clients can be stubborn.
I have used RetroTranslator(http://retrotranslator.sourceforge.net/) and Retroweaver(http://retroweaver.sourceforge.net/) to have Java 5 features. Nothing can be done on the performance side though.
As for Java 1.5/1.4 EOL there is Java for Business program for Java customers - they are not EOL if you pay for them...

Tell them about security. I'm not sure if sun still deliver patches for older versions (pavanlimo answer).

While I agree with the other answers given, another consideration is have you considered there situation? Have you written the application in such a way that it plays well with others? I've been a system admin for a while now and one of my biggest gripes is the number of development houses that think that we should change our IT environment when they are ready. And of course if there are 2 or more such development houses supplying products to my site then there is conflict.
Have you written your app in such a manner that I could run your choice of Java version and the (pick your number but its likely to be greater than 2) other versions of Java that I require, usually on the same server, to support the other equally important applications? And suggesting backward compatibility is irrelevant - the other vendor will not support me unless I'm on their chosen version.

Perhaps because Java 1.4 has reached EOL on 30th Oct 2008.
And so, their security can be compromised!.
Show a couple of examples, where, security has actually been compromised due to Java 1.4.
They will be sufficiently scared IMO.

Why not go to java 6? Both java 1.4 and java 5 have reached their end of life.

Dropping support for JRE 1.3

We provide a popular open source Java FTP library called edtFTPj.
We would like to drop support for JRE 1.3 - this would clean up the code base and also allow us to more easily use JRE 1.4 features (without resorting to reflection etc). The JRE 1.3 is over 7 years old now!
Is anyone still using JRE 1.3 out there? Is anyone aware of any surveys that give an idea of what percentage of users are still using 1.3?

Sun allows you to buy support packages for depreciated software such as JRE 1.4. For banks and some other organizations, paying $100,000 per year for support of an outdated product is cheaper than upgrading. I would suggest only offering paid support for JRE 1.3. If anyone needs support for this, they can pay for a hefty support package. You would then shelve your current 1.3 code base, and if a customer with a support contract requires a bug fix, then you could fix the 1.3 version for them, which would likely just mean selectively applying a patch from a more recent version.

Even JDK 1.4 reached the end of its support life in Oct 2008. I think you're safe.
But don't take it from me. The people that you really need to ask are your customers. Maybe putting a survey up on your download page and soliciting feedback will help. If no one asks in three months, drop it.

Why not have your program report back what version of Java it is being run with. This will give you an idea of your user base.
I highly recommend dropping support for Java 1.3, and instead of doing a minor upgrade to Java 1.4, why not use Java 1.6? There have been massive improvements since 1.3. You really are missing out.

End-of-life is normal part of software's life cycle.
The real question you should ask/answer is whether you have a compelling business need to add features to the "old" versions. If not, you can continue to offer it for customers who need it -- but encourage everyone else to take the latest & greatest which requires 1.4 (or 1.5/1.6).

It's difficult to give figures for what companies use internally. There do exist figures for browser plugin installation, but Sun's figures are confidential.
1.3 support stopped some time ago (Solaris 8 vintage support dragged on for a bit). 1.4 has completed its End of Service Life, but is likely to be supported under Java for Business for yonks. IIRC, if you try to download 1.4 from the archives at sun.com then you are asked for some information such as an e-mail address. 1.5 is more than half way through its service life (but its still quite common on Macs).
It's not that difficult to use 1.4 features optionally. You just need to load one class via reflection (or just package it differently) and then have a 1.4 and 1.3 implementation of a light abstraction over the new features.

Why not only do critical patches for 1.3 & 1.4 if anyone actually requests them and do all new releases on 1.5 - the current oldest version supported by Sun?

I was developing with jdk 1.4 for a long time while jdk 6.0 was out. We couldn't upgrade(clients this, servers blablabah). At some point, we just upgraded without talking too much about it. Clients upgraded without being annoying, "this upgrade will fix lots of security holes, many bug fixes, improved performance :-)".
Right now, I try to keep my code compatible with jdk 1.5, I have no concern at all for people running 1.4 and below. At some point, they'll understand that it is in their best interest to "try" upgrading.

Can I do Java 6 development in OS X?

I know when Leopard came out everybody (well, everybody that was a Java developer and cared enough to do development on a Mac) was pissed that there was no Java 6 SDK support. I know somebody provided some kind of hack way a few months after Leopard was released, but I could have sworn that I read sometime later that Apple and/or Sun finally put out an official version of the Java 6 SDK.
So now a year and a half later I am finally interested in doing some Java dev on the Mac (thank Google App Kit for that). But when I go to Apple's Java site... all I see is stuff about Java 5.
So, can I do Java 6 on a Mac?
See also: Installing Java 6 on Mac OS

Yes, JDK6 is available, and it is quite nice, for example it supports DTrace, which otherwise you only get on Solaris.
The main drawback is that Apple is very aggressive in deprecating older hardware (and OS versions). Java6 will never be released for Mac versions before 10.5, and only works on 64bit Intel. That also kills native 32 bit libraries, such as SWT/Carbon, which is what Eclipse uses (they need to move to Cocoa now).
Update: Snow Leopard apparently has Java6 for 32bit Intel, too (in addition to 64bit).

http://developer.apple.com/java/ (which is only for 64-bit Macs)
http://landonf.bikemonkey.org/static/soylatte/ (SoyLatte, a separate Java 6 port).

Yes, JDK6 is available.
However, some versions of Eclipse do not support it. There is a new one (based on Cocoa) that should but it is not officially available.

You can but you have to be very wary of Apple on this one. Sun released JDK 6 in December 2006. Apple released Java 6 for MacOS X a year later.
Why the delay? It seems that integrating the new Look and Feel was the answer but we don't have an official reason.
Now if Java 6 was important to you at the time this would've been (and was) a big deal.
As other answers mention, support for certain hardware and libraries can also be problematic.
windows and Linux are (imho) still the preferred Java development platforms. If it ever becomes critical you can always do Java development on a Mac in a VM however.

Partly. Apple released its version of Java SDK 6 a few months back. But there are still some functions which are not available on Apple's SDK 6 which exist in Sun's Java SDK 6. I don't know why this is so.
For e.g., after Unisys's patent on GIF format expired, Java included the capability to write image files in GIF format in SDK6. Yet, you still can't write GIF files on Apple's SDK.

http://developer.apple.com/java/
Looks like you can.