With Java (JRE) you can run Java applications on your Windows PC!

Java Runtime Environment (64-bit)

Java JRE 8 Update 451 (64-bit)

  -  38.41 MB  -  Freeware
  • Latest Version

    Java JRE 8 Update 461 (64-bit)

  • Operating System

    Windows 7 64 / Windows 8 64 / Windows 10 64 / Windows 11

  • User Rating

    Click to vote
  • Author / Product

    Oracle / External Link

  • Filename

    jre-8u451-windows-x64.exe

  • MD5 Checksum

    78ddb017979adc0d53292ac5073eeb67

Sometimes latest versions of the software can cause issues when installed on older devices or devices running an older version of the operating system.

Software makers usually fix these issues but it can take them some time. What you can do in the meantime is to download and install an older version of Java JRE 8 Update 451 (64-bit).


For those interested in downloading the most recent release of Java Runtime Environment (64-bit) or reading our review, simply click here.


All old versions distributed on our website are completely virus-free and available for download at no cost.


We would love to hear from you

If you have any questions or ideas that you want to share with us - head over to our Contact page and let us know. We value your feedback!

Why is this app published on FileHorse? (More info)
  • Java JRE 8 Update 451 (64-bit) Screenshots

    The images below have been resized. Click on them to view the screenshots in full size.

    Java JRE 8 Update 451 (64-bit) Screenshot 1
  • Java JRE 8 Update 451 (64-bit) Screenshot 2
  • Java JRE 8 Update 451 (64-bit) Screenshot 3
  • Java JRE 8 Update 451 (64-bit) Screenshot 4
  • Java JRE 8 Update 451 (64-bit) Screenshot 5

What's new in this version:

- JDK 8u451 contains IANA time zone data 2025a which contains the following changes since the previous update
- Paraguay adopts permanent -03 starting spring 2024
- Improve pre-1991 data for the Philippines
- Etc/Unknown is now reserved

New Features:
security-libs/javax.crypto:pkcs11➜ Legacy Mechanism Check in SunPKCS11 Provider Is Enhanced with Service Type (JDK-8293345):
- Native PKCS11 mechanisms which support decryption but not encryption, or signature verification but not signing, are considered legacy and are disabled by default. The legacy mechanism check in SunPKCS11 provider is enhanced with the service type. For example, prior to this fix, a mechanism supporting encryption, decryption, and verification but not signing, is considered legacy and can't be used at all. After this fix, the corresponding Cipher service using this mechanism is available since both encryption and decryption are supported. However, the corresponding Signature service is not since only verification is supported. To bypass the legacy mechanism check, set the PKCS11 provider configuration attribute "allowLegacy" to true. The default value is false. Note that it is the caller's responsibility to make sure the legacy mechanism is not used for the unsupported functionality.
- Other Notes
- javafx/other
- ➜ Removal of JavaFX from Oracle JDK 8 (JDK-8341994 (not public))
- As announced in 2020, support for JavaFX on JDK 8, the last commercially supported version of JavaFX from Oracle, ended in March 2025. JDK 8 update 451 is the first upgrade of JDK/JRE 8 without JavaFX. Oracle continues to develop and release JavaFX as stand-alone modules via the OpenJFX project for the latest versions of Java only. For more details see the Java SE Spring 2024 Roadmap Update. Please contact Oracle Sales if you have any additional needs.

security-libs/javax.net.ssl➜ Distrust TLS Server Certificates Anchored by Camerfirma Root Certificates and Issued After April 15, 2025 (JDK-8346587):
- The JDK will stop trusting TLS server certificates issued after April 15, 2025 and anchored by Camerfirma root certificates, in line with similar plans announced by Google, Mozilla, Apple, and Microsoft.
- TLS server certificates issued on or before April 15, 2025 will continue to be trusted until they expire. Certificates issued after that date, and anchored by any of the Certificate Authorities in the table below, will be rejected.
- The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below and the certificate has been issued after April 15, 2025.

An application will receive an exception with a message indicating the trust anchor is not trusted, for example:
- "TLS Server certificate issued after 2025-04-15 and anchored by a distrusted legacy
- Camerfirma root CA: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A.,
- SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU"
- The JDK can be configured to trust these certificates again by removing "CAMERFIRMA_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Camerfirma Root certificates included in the JDK:
- CN=Chambers of Commerce Root, OU
- CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid
- CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:
- keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>
- If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server.

core-svc/tools➜ JarInputStream Treats Signed JARs with Multiple Manifests As Unsigned (JDK-8337494 (not public)):
- The JarInputStream class now treats a signed JAR as unsigned if it detects a second manifest within the first two entries in the JAR file. A warning message "WARNING: Multiple MANIFEST.MF found. Treat JAR file as unsigned." is logged if the system property, -Djava.security.debug=jar, is set.

security-libs/javax.crypto:pkcs11➜ Disable CKM_TLS_KEY_AND_MAC_DERIVE Mechanism in Solaris PKCS11 Configuration File (JDK-8245618):
- On Solaris, the CKM_TLS_KEY_AND_MAC_DERIVE mechanism offered by the SunPKCS11-Solaris provider and specific to TLSv1.0, can derive incorrect key data causing TLSv1.0 communication failure. That mechanism has been disabled via the $JAVA_HOME/jre/lib/security/sunpkcs11-solaris.cfg configuration file. The JCE provider now manages these cryptographic requests.

Fixed:
- The printing result is different from the case instruction.
- [macosx] Accelerators does not spelled for JMenuItems by Voice Over
- [macos13] setFullScreenWindow() shows black screen on macOS 13 & above
- [macOS, Accessibility] VoiceOver: Incorrect announcements of JRadioButton
- [macOS, Accessibility] VoiceOver: No announcements on JRadioButtonMenuItem and JCheckBoxMenuItem
- [macos] Screen magnifier does not show the magnified text for JComboBox
- [macos] a11y : Screen magnifier does not show selected Tab
- [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class
- Crash in ImageIO JPEG decoding when MEM_STATS in enabled
- Java MIDI fails with a dereferenced memory error when asked to send a raw 0xF7
- new javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE
- (process) java/lang/ProcessBuilder/Basic.java uses "cp -p" which is inefficient
- ExecutorService/Invoke.java fails intermittently
- C2: Unexpected dead nodes after matching
- Add additional comments for "8062370: Various minor code improvements"
- Various minor code improvements
- Failures during class definition can lead to memory leaks in metaspace
- Make AbortVMOnException available in product builds
- Update PKCS#11 Cryptographic Token Interface to v3.1
- Update PC/SC Lite for Suse Linux to 2.3.0
- Tables in javadoc documentation missing row headers