Java software allows you to run applications called

Java Runtime Environment for Mac

Java JRE 8 Update 481

  -  46.72 MB  -  Freeware
  • Latest Version

    Java JRE 8 Update 491

  • Operating System

    Mac OS X 10.7 or later

  • User Rating

    Click to vote
  • Author / Product

    Oracle / External Link

  • Filename

    jre-8u481-macosx-x64.dmg

  • MD5 Checksum

    d8c31c4dde4dbf45ff72d1061e0b6c26

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 481.


For those interested in downloading the most recent release of Java Runtime Environment for Mac 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 481 Screenshots

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

    Java JRE 8 Update 481 Screenshot 1
  • Java JRE 8 Update 481 Screenshot 2
  • Java JRE 8 Update 481 Screenshot 3

What's new in this version:

New Features:
- core-libs/java.rmi
- ➜ Endpoint Identification Enabled By Default for RMI Connections Over TLS (JDK-8341496 (not public))
- RMI will use TLS connections if the [javax.rmi.ssl.SslRMIClientSocketFactory] class is used. These connections now have TLS endpoint identification enabled by default. This may cause some previously-working TLS connections to fail. If this occurs, ensure that the certificate presented by the server has a Subject Alternative Name that matches the server's hostname. Alternatively, endpoint identification for RMI TLS connections can be disabled on the client side by setting the jdk.rmi.ssl.client.enableEndpointIdentification system property to false.

Other Notes:
security-libs/javax.net.ssl➜ Disabled SHA-1 in TLS 1.2 and DTLS 1.2 Handshake Signatures (JDK-8340321):
- The SHA-1 algorithm has been disabled by default in TLS 1.2 and DTLS 1.2 handshake signatures, by adding "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" to the jdk.tls.disabledAlgorithms security property in the java.security config file. RFC 9155 deprecates the use of SHA-1 in TLS 1.2 and DTLS 1.2 digital signatures. Users can, at their own risk, re-enable the SHA-1 algorithm in TLS 1.2 and DTLS 1.2 handshake signatures by removing "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" from the jdk.tls.disabledAlgorithms security property.

install/install➜ Windows Installers to Return to Full Version Directory and Use of Junction (JDK-8310932 (not public)):
- For the JDK11+ LTS families, the JDK will install into a version-specific installation directory by default. The installation directory of 11+ will have a - before the version-specific string to keep consistency with the past 11+ conventions per family. A junction, also known as a symlink for Windows, will also be created in a "latest" directory. It will point to the latest version of that family. Here is a breakdown example of installation and junction locations 11+ families
- Each junction will always point to the latest JDK of the matching LTS family. The junction for each family will be removed when the last JDK of the matching LTS family is uninstalled.
- install/install➜ Make jcmd Command Available in the Headless JDK RPM (JDK-8359443 (not public)):
- jcmd command will be available in the headless JDK RPM instead of the headful JDK RPM.
- It will be added to the java alternatives group instead of the javac alternatives group.
- security-libs/javax.net.ssl➜ Disabled TLS_RSA Cipher Suites (JDK-8245545):

The TLS_RSA cipher suites have been disabled by default, by adding "TLS_RSA_" to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. The TLS_RSA cipher suites do not preserve forward-secrecy and are not commonly used. Some TLS_RSA cipher suites are already disabled because they use DES, 3DES, RC4, or NULL, which are disabled. This action disables all remaining TLS_RSA cipher suites. Any attempts to use cipher suites starting with "TLS_RSA_" will fail with an SSLHandshakeException. Users can, at their own risk, re-enable these cipher suites by removing "TLS_RSA_" from the jdk.tls.disabledAlgorithms security property. The following previously enabled cipher suites are now disabled:
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- core-libs/java.util:i18n➜ Changes to the Default Time Zone Detection on Debian-based Linux (JDK-8345213):
- On Debian-based Linux distributions such as Ubuntu, the /etc/timezone file was previously used to determine the JDK's default time zone (TimeZone.getDefault()). According to Debian's Wiki, /etc/localtime is now the primary source for the system's default time zone, making /etc/timezone redundant. As a result, the JDK's default time zone detection logic has been updated to use /etc/localtime instead of /etc/timezone. If /etc/localtime and /etc/timezone are inconsistent for any reason, the JDK's default time zone is now determined solely based on /etc/localtime file.
- core-svc/tools➜ jcmd -l and jps Commands Do Not List Java Processes Running in Docker Containers (JDK-8193710):
- The HotSpot runtime code has been updated to allow the jcmd -l and jps commands discover JVMs running in a container.

security-libs/java.security➜ Filter Rules for URIs in the Authority Info Access Extension for Certificates (JDK-8368032 (not public)):
- A new system and security property, com.sun.security.allowedAIALocations, has been introduced. This property allows users the ability to define one or more filtering rules to be applied to URIs obtained from the authority info access extension on X.509 certificates. These filter rules are applied specifically to the CA issuers access method. Any CA issuers URIs in X.509 certificates are only followed when the com.sun.security.enableAIAcaIssuers system property is enabled and the filter allows the URI.
- In order to set the rules, the user must set either the com.sun.security.allowedAIALocations security property or the system property by the same name. If the system property has a value, it will override the security property. By default the property is blank, which enacts a deny-all ruleset.
- For either property, the value consists of a set of space-separated rules that take the form of a URI, with the following constraints:
- The URI must be absolute and hierarchical.
- The URI must only use one of the following schemes: http, https, ldap, or ftp (case-insensitive).
- A hostname or address must be specified and must match (case-insensitive). No name resolution is performed on hostnames to match URIs with IP addresses.
- The port number must match. Where a port number is omitted, the well-known port will be used in the comparison.

For hierarchical schemes (http[s], ftp):
- A rule's normalized path portion of the URI is matched in a case-sensitive manner. If the final component does not end in a slash (/), it is considered to be a file path and must match the CA issuer URI path component. If the rule's path component ends in a slash, then it must match or be a prefix of the CA issuer URI path component. (for example, a filter path of /ab/cd/ will match a CA issuer path of /ab/cd/, /ab/cd/ef and /ab/cd/ef/ghi.).
- Query strings and fragments will be ignored when matching CA issuer URIs.

For ldap URIs:
- The base DN must be an exact match (case-insensitive)
- Any query string in the rule, if specified, will be ignored

Fixed:
- Memory leak in getAllConfigs of awt_GraphicsEnv.c:386
- Enforce limits on the size of an XBM image
- Crashes in getConfigColormap, getConfigVisualId, XVisualIDFromVisual on Linux
- Device.getDisplayMode() doesn't report refresh rate on Linux in case of dual screen
- Cannot list all the available display modes on Ubuntu linux in case of two screen devices
- Memory leak in getAllConfigs of awt_GraphicsEnv.c:585
- java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text
- java/awt/Frame/FrameLocationTest/FrameLocationTest.java fails
- Cannot resize CheckBoxItemMenu in Synth L&F with setHorizontalTextPosition
- JFileChooser renders file names as HTML document
- JFileChooser in GTK L&F still displays HTML filename
- JPasswordField identifies spaces in password via delete shortcuts
- Right to Left Orientation Issues with MenuItem Component
- Move SimpleSSLContext to jdk/testlibrary
- sun/net/www/protocol/http/RedirectOnPost.java failing
- vmTestbase/gc/lock/malloc/malloclock04/TestDescription.java crashes intermittently
- Solaris: deprecated <pwd.h> and <gid.h> interfaces should be replaced
- Safepoint sync time did not increase
- ClassVerifier::ends_in_athrow() should be removed
- @ignore CheckEBCDICLocaleTest
- NullPointerException in sun.launcher.LauncherHelper.checkJavaFXRemoval