Java software allows you to run applications called

Java Runtime Environment for Mac

Join our mailing list

Stay up to date with latest software releases, news, software discounts, deals and more.

Subscribe
Download Java JRE 10.0.2

Java JRE 10.0.2

  -  78.49 MB  -  Freeware
  • Latest Version

    Java JRE 8 Update 401

  • Operating System

    Mac OS X

  • User Rating

    Click to vote
  • Author / Product

    Oracle / External Link

  • Filename

    jre-10.0.2_osx-x64_bin.dmg

  • MD5 Checksum

    8b4c4bbe96d507be1ecd1e66e0f1a7aa

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


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!

  • Java JRE 10.0.2 Screenshots

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

What's new in this version:

CHANGES:
core-libs/java.lang.invoke ➜ filterArguments runs multiple filters in the wrong order:
- The specification of the method java.lang.invoke.MethodHandles.filterArguments was clarified to state more clearly that filter arguments are invoked in left to right order. The implementation of this method was also fixed to ensure it conformed to the specification. Prior to the fix the implementation incorrectly invoked filters in right to left order. For the majority of usages it is expected such a change in behavior will not be observable. Only in the minority of cases where two or more filters have side-effects that affect their results will such behavior be observable
- See JDK-8194554

core-libs/javax.naming ➜ Improve LDAP support:
- Endpoint identification has been enabled on LDAPS connections
- To improve the robustness of LDAPS (secure LDAP over TLS ) connections, endpoint identification algorithms have been enabled by default.
- Note that there may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification
- Define this system property (or set it to true) to disable endpoint identification algorithms.
- JDK-8200666 (not public)

core-libs/java.io:serialization ➜ Better stack walking:
- New access checks have been added during the object creation phase of deserialization. This should not affect ordinary uses of deserialization. However, reflective frameworks that make use of JDK-internal APIs may be impacted. The new checks can be disabled if necessary by setting the system property jdk.disableSerialConstructorChecks to the value "true". This must be done by adding the argument -Djdk.disableSerialConstructorChecks=true to the Java command line
- JDK-8197925 (not public)

Bug fixes:
hotspot/gc ➜ JVM Crash during G1 GC:
- A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the ClassLoaderData/SystemDictionary, and its _java_mirror or _class_loader fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass
- In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash
- This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded

Fixed:
- JDK-8203368: core-libs: java.io:serialization: ObjectInputStream filterCheck method throws NullPointerException
- JDK-8194554: core-libs: java.lang.invoke: filterArguments runs multiple filters in the wrong order
- JDK-8187577: hotspot: gc: JVM crash during gc doing concurrent marking
- JDK-8200556: hotspot: runtime: AArch64: assertion failure in debug builds
- JDK-8196011: javafx: web: Intermittent crash when using WebView from JFXPanel application
- JDK-8200418: javafx: web: webPage.executeCommand("removeFormat", null) removes the style of the body element
- JDK-8199910: tools: javac: Compiler crashes with -g option and variables of intersection type inferred by `var`

Join our mailing list

Stay up to date with latest software releases, news, software discounts, deals and more.

Subscribe