Latest Jdk For Macos

 
Latest Jdk For Macos Average ratng: 8,2/10 6837 reviews

Nov 16, 2018  I found the info on the following link - to get rid of a Facebook plist - worked for me. No more java jdk popups in Mojave 10.14.1. FIX: To use the java command-line tool you need to install a JDK (MAC OS X) - wintips.org - Windows Tips & How-tos. After installing Java for macOS 2012-006, can I continue to use Apple's Java 6 alongside the macOS JDK for Java 12? If you want to continue to develop with Java 6 using command-line, then you can modify the startup script for your favorite command environment.

The following notes describe important changes and information about this release. In some cases, the descriptions provide links to additional detailed information about an issue or a change. This page does not duplicate the descriptions provided by the Java SE 10 (18.3) ( JSR 383) specification, which provides informative background for all specification changes and might also include the identification of removed or deprecated APIs and features not described here. The Java SE 10 (18.3) (JSR 383) specification provides links to:

  • Annex 1: The complete Java SE 10 API Specification.

  • Annex 2: An annotated API specification showing the exact differences relative to Java SE 9. Informative background for these changes may be found in the list of approved Change Specification Requests for this release.

  • Annex 3: Java SE 10 Editions of The Java Language Specification and The Java Virtual Machine Specification. The Java SE 10 Editions contain all corrections and clarifications made since the Java SE 9 Editions, as well as additions for new features.

The descriptions on this Release Note page might also identify potential compatibility issues that you could encounter when migrating to JDK 10. The Kinds of Compatibility page on the OpenJDK wiki identifies three types of potential compatibility issues for Java programs used in these descriptions:

  • Source: Source compatibility concerns translating Java source code into class files.

  • Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link without error.

  • Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.

See the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for information about compatibility as it relates to JDK 10.

The following notes describe some of the enhancements in Java SE 10 and JDK 10. The descriptions might include links to additional documentation that describes the enhancement in greater detail. Another source of information about important enhancements and new features in Java SE 10 and JDK 10 is the Java SE 10 (18.3) ( JSR 383) specification, which documents the changes to the specification made between Java SE 9 and Java SE 10. This document includes descriptions of those new features and enhancements that are also changes to the specification. The descriptions below might also identify potential compatibility issues that you could encounter when migrating to JDK 10. See the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for information about compatibility as it relates to JDK 10.

Optional.orElseThrow() Method

A new method orElseThrow has been added to the Optional class. It is synonymous with and is now the preferred alternative to the existing get method.

See JDK-8140281

APIs for Creating Unmodifiable Collections

Several new APIs have been added that facilitate the creation of unmodifiable collections. The List.copyOf, Set.copyOf, and Map.copyOf methods create new collection instances from existing instances. New methods toUnmodifiableList, toUnmodifiableSet, and toUnmodifiableMap have been added to the Collectors class in the Stream package. These allow the elements of a Stream to be collected into an unmodifiable collection.

See JDK-8177290

System Property to Disable JRE Last Usage Tracking

A new system property jdk.disableLastUsageTracking has been introduced to disable JRE last usage tracking for a running VM. This property can be set in the command line by using either -Djdk.disableLastUsageTracking=true or -Djdk.disableLastUsageTracking. With this system property set, JRE last usage tracking will be disabled regardless of the com.oracle.usagetracker.track.last.usage property value set in usagetracker.properties.

JDK-8192039 (not public)

Hashed Passwords for Out-of-the-Box JMX Agent

The clear passwords present in the jmxremote.password file are now being over-written with their SHA3-512 hash by the JMX agent. Each line for the role follows the format:

role_name W hashedPassword

Where:

  • role_name is any string that does not itself contain spaces or tabs.
  • W = spaces or tabs

The hashed password follows the format:

hashedPassword = base64_encoded_64_byte_salt W base64_encoded_hash W hash_algorithm

Where:

  • base64_encoded_64_byte_salt = 64 byte random salt
  • base64_encoded_hash = Hash_algorithm (password + salt)
  • W = spaces or tabs
  • hash_algorithm = Algorithm string specified using a format in https://docs.oracle.com/javase/10/docs/specs/security/standard-names.html#messagedigest-algorithms. This is an optional field. If not specified, SHA3-512 is assumed to be the algorithm string.

If passwords are in the clear, they are overwritten by their hash if all of the following criteria are met:

  1. com.sun.management.jmxremote.password.toHashes property is set to true in the management.properties file.
  2. The password file is writable.
  3. The system security policy allows writing into the password file if a security manager is configured.

In order to change the password for a role, replace the hashed password entry with a new clear-text password or a new hashed password. If the new password is in the clear, it will be replaced with its hash when a new login attempt is made.

Download MacOS Catalina 10.15.3 beta version (19D49F): MacOS Catalina 10.15.3 DMG Google Drive File; MacOS Catalina 10.15.3 Update (Download From Apple.com) Download macOS 10.15.3 Beta Installer.DMG File Link 2; Download macOS 10.15.3 Beta Profile.DMG File; MacOS Catalina ISO File is available, now you can download it. Google drive for macos 15.3. Download macOS 10.15 Catalina Final ISO File (Google Drive). MacOS Catalina ISO File 7 Parts (Google Drive). The file needs too much speed internet in order to download it successfully. The size of the file is almost 6GB and it is very difficult to install. It is zipped with the WinRAR, while extraction you have to enter the password Geekrar.com. You are using an unsupported browser. If you see some unexpected behavior, you may want to use a supported browser instead. MacOS 10.15.3 Catalina Final VMware & VirtualBox Image (19D76) January 28, 2020 (Recently Updated) Final macOS 10.15.3 Catalina by Geekrar (One Full – Google Drive) — The macOS Catalina VMware and VirtualBox image is the latest version of macOS Catalina.

A given role should have at least one entry in this file. If a role has no entry, it has no access. If multiple entries are found for the same role name, then the last one is used.

A user generated hashed password file can also be used instead of a clear-text password file. If generated by the user, hashed passwords must follow the format specified above.

This file must be made accessible by ONLY the owner, otherwise the program will exit with an error.

In order to prevent inadvertent edits to the password file in a production environment, it is recommended that a read-only hashed password file be deployed. The hashed entries for clear passwords can be generated in advance by running the JMX agent.

It is recommended that the password file not be edited while the agent is running. Edits could be lost if a client connection triggers the hashing of the password file at the same time that the file is externally modified. The integrity of the file is guaranteed, but any external edits made to the file during the short period between the time that the agent reads the file and the time that it writes it back might be lost.

See JDK-5016517

JEP 307 Parallel Full GC for G1

Improves G1 worst-case latencies by making the full GC parallel. The G1 garbage collector is designed to avoid full collections, but when the concurrent collections can't reclaim memory fast enough a fall back full GC will occur. The old implementation of the full GC for G1 used a single threaded mark-sweep-compact algorithm. With JEP 307 the full GC has been parallelized and now use the same amount of parallel worker threads as the young and mixed collections.

See JDK-8172890

JEP 319 Root Certificates

Provides a default set of root Certification Authority (CA) certificates in the JDK.

The cacerts keystore of the OpenJDK 9 binary for Linux x64 has been populated by JEP 319: Root Certificates [1] with a set of root certificates issued by the CAs of Oracle's Java SE Root CA Program. This addresses the problem of the empty cacerts keystore in the OpenJDK 9 binary for Linux x64. The empty cacerts keystore had prevented TLS connections from being established because Trusted Root Certificate Authorities were not installed. As a workaround for OpenJDK 9 binaries, users had to set the javax.net.ssl.trustStore System Property to use a different keystore.

[1] https://bugs.java.com/view_bug.do?bug_id=JDK-8191486

See JDK-8189131

TLS Session Hash and Extended Master Secret Extension Support

Support has been added for the TLS session hash and extended master secret extension (RFC 7627) in JDK JSSE provider. Note that in general, a server certificate change is restricted if endpoint identification is not enabled and the previous handshake is a session-resumption abbreviated initial handshake, unless the identities represented by both certificates can be regarded as the same. However, if the extension is enabled or negotiated, the server certificate changing restriction is not necessary and will be discarded accordingly. In case of compatibility issues, an application may disable negotiation of this extension by setting the System Property jdk.tls.useExtendedMasterSecret to false in the JDK. By setting the System Property jdk.tls.allowLegacyResumption to false, an application can reject abbreviated handshaking when the session hash and extended master secret extension are not negotiated. By setting the System Property jdk.tls.allowLegacyMasterSecret to false, an application can reject connections that do not support the session hash and extended master secret extension.

See JDK-8148421

Bytecode Generation for Enhanced for Loop

Bytecode generation has been improved for enhanced for loops, providing an improvement in the translation approach for them. For example:

List<String> data = new ArrayList<>(); for (String b : data);

The following is the code generated after the enhancement:

{ /*synthetic*/ Iterator i$ = data.iterator(); for (; i$.hasNext(); ) { String b = (String)i$.next(); } b = null; i$ = null; }

Declaring the iterator variable outside of the for loop allows a null to be assigned to it as soon as it is no longer used. This makes it accessible to the GC, which can then get rid of the unused memory. Something similar is done for the case when the expression in the enhanced for loop is an array.

See JDK-8175883

javadoc Support for Multiple Stylesheets

A new javadoc command-line option, --add-stylesheet, has been added to the javadoc tool. The new --add-stylesheet option provides support for the use of multiple stylesheets in the generated documentation. The existing -stylesheetfile option now has an alias, --main-stylesheet, to help distinguish the main stylesheet from any additional stylesheets. For more details, see the javadoc section in the Tools Reference document.

See JDK-8185371

Overriding Methods That Do Not Change the Specification

A new option --overridden-methods=value, has been added to the javadoc tool. Many classes override inherited methods without changing the specification. The --overridden-methods=value option can be used to group these methods with other inherited methods, instead of documenting them in detail with the other methods declared in the class. For more details, see the javadoc section in the Tools Reference document.

See JDK-8157000

Comment Tag for Summary of an API Description

A new inline tag, {@summary ..}, has been added to explicitly specify the text used as the summary of the API description. By default, the summary of an API description is inferred from the first sentence. This is determined by using either a simple algorithm or java.text.BreakIterator. However, the heuristics for this are not always correct and can lead to an incorrect determination of the end of the first sentence. The new tag enables the API summary text to be explicitly set instead of inferred. Please refer to Documentation Comment Specification for the Standard Doclet.

See JDK-8173425

This section describes the APIs, features, and options that were removed in Java SE 10 and JDK 10. Another source of information about features and options removed in Java SE 10 and JDK 10 is the Java SE 10 (18.3) ( JSR 383) specification, which documents changes to the specification made between Java SE 9 and Java SE 10. This document includes the identification of removed APIs and features not described here. The descriptions below might also identify potential compatibility issues that you could encounter when migrating to JDK 10. See the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for information about compatibility as it relates to JDK 10.


Removal of Support for Using Old LookAndFeel

It is no longer possible for applications to use old or unsupported LookAndFeels. Some applications (such as, Nimbus and Aqua) used old class names to instantiate JDK internal Swing LookAndFeels. For example:

  • javax.swing.UIManager.setLookAndFeel
('com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel');
  • javax.swing.UIManager.setLookAndFeel('apple.laf.AquaLookAndFeel');

These classes were internal to the JDK and applications should have always treated them as such. Applications that use these class names to instantiate JDK internal Swing LookAndFeels must migrate now to the following APIs:

  • For Nimbus use:

UIManager.setLookAndFeel('javax.swing.plaf.nimbus.NimbusLookAndFeel');

  • For Aqua use:

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

See JDK-8185683

Removal of Runtime.getLocalizedInputStream and getLocalizedOutputStream Methods

The methods Runtime.getLocalizedInputStream and Runtime.getLocalizedOutputStream have been removed. They were part of an obsolete internationalization mechanism and have no known uses.

See JDK-8177681

Removal of RMI Server-Side Multiplex Protocol Support

The RMI Multiplex protocol was disabled in JDK 9 and has been removed. For the background and history see JDK-8087189.

See JDK-8087189

Removal of Common DOM APIs

The com.sun.java.browser.plugin2.DOM, and sun.plugin.dom.DOMObject APIs have been removed. Applications can use netscape.javascript.JSObject to manipulate the DOM.

JDK-8133601 (not public)

Removal of FlatProfiler

The FlatProfiler, deprecated in JDK 9, has been made obsolete by removing the implementation code. The FlatProfiler was enabled by setting the -Xprof VM argument. The -Xprof flag remains recognized in this release; however, setting it will print out a warning message.

See JDK-8173715

Removal of Obsolete -X Options

The obsolete HotSpot VM options (-Xoss, -Xsqnopause, -Xoptimize, -Xboundthreads, and -Xusealtsigs) have been removed.

See JDK-8179018

Removal of HostServicesgetWebContext Method

The HostServices::getWebContext method, which was deprecated for removal in JDK 9, has been removed. There is no replacement for this functionality. Applications will no longer be able to communicate with the enclosing web page of a JavaFX Applet. Note that the Java Plug-in, on which this functionality depends, is deprecated for removal as well.

See JDK-8187149

Removal of T2K Rasterizer and ICU Layout Engine From JavaFX

The T2K rasterizer and ICU layout engine have been removed from JavaFX.

See JDK-8187147

Removal of Deprecated VP6/FXM/FLV Code From JavaFX

Support for VP6 video encoding format and FXM/FLV container has been removed in JavaFX Media. Users are encouraged to use H.264/AVC1 in the MP4 container or HTTP Live Streaming instead.

See JDK-8187637

Removal of Deprecated Pre-1.2 SecurityManager Methods and Fields

The following pre-1.2 deprecated java.lang.SecurityManager methods and fields that were marked forRemoval=true have been removed:

  • inCheck field
  • getInCheck method
  • classDepth method
  • classLoaderDepth method
  • currentClassLoader method
  • currentLoadedClass method
  • inClass method
  • inClassLoader method

In addition, the deprecated checkMemberAccess method has been changed to throw a SecurityException if the caller has not been granted AllPermission. This method is error-prone and users should instead invoke the checkPermission method directly.

See JDK-8186535

Removal of policytool

The policytool security tool has been removed from the JDK.

See JDK-8148371

Removal of Deprecated Classes in com.sun.security.auth.**

The following deprecated classes that were marked for removal in JDK 9 have been removed:

  • com.sun.security.auth.PolicyFile
  • com.sun.security.auth.SolarisNumericGroupPrincipal
  • com.sun.security.auth.SolarisNumericUserPrincipal
  • com.sun.security.auth.SolarisPrincipal
  • com.sun.security.auth.X500Principal
  • com.sun.security.auth.module.SolarisLoginModule
  • com.sun.security.auth.module.SolarisSystem

See JDK-8159544

Removal of Old (JDK 6, JDK 7, and JDK 8 Era) Standard Doclet

The old (JDK 6, JDK 7 and JDK 8 era) standard doclet, which outputs HTML content, and which has been superseded by a replacement, has been removed in this release. The underlying javadoc API (see com.sun.javadoc in the API documentation) has been deprecated, but is still available for the time being, for use by user-provided doclets.

See JDK-8177511

JEP 313 Remove the Native-Header Generation Tool (javah)

As previously announced, the native-header tool, javah, has been removed.

Native headers can now be generated by using the Java compiler, javac, with the -h option.

See JDK-8182758

Removal of Java Launcher's Data Model Options -d32 and -d64

The java launcher's data model selection options (-d32, -d64, -J-d32 and -J-d64) have been removed. They are obsolete and were previously deprecated. To prevent the launcher from failing, users must remove usages of these options when invoking the java launcher or tools such as javac and javah.

See JDK-8180286

This section describes the deprecated APIs, features, and options that have been identified as deprecated in this release and are subject to removal from future versions of Java SE and the JDK. They should be used with that possibility in mind.

Other sources of information about the APIs, features, and options deprecated in Java SE 10 and JDK 10 include:

  • Deprecated API page (API specification) - Identifies all deprecated APIs including those deprecated in Java SE 10.
  • Java SE 10 (18.3) ( JSR 383) specification - Documents changes to the specification made between Java SE 9 and Java SE 10 that include the identification of deprecated APIs and features not described here.

You should be aware of the contents in those documents as well as the items described in this release notes page.

The descriptions of deprecated APIs might include references to the deprecation warnings of forRemoval=true and forRemoval=false. The forRemoval=true text indicates that a deprecated API might be removed from the next major release. The forRemoval=false text indicates that a deprecated API is not expected to be removed from the next major release but might be removed in some later release.

Note: JEP 277: Enhanced Deprecation provides a detailed description of the updated deprecation policy. You should be aware of the policy described in this document.

The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 10. See the JDK 10 Migration Guide for descriptions of specific compatibility issues. See the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for information about compatibility as it relates to JDK 10.

SNMP Monitoring Support Deprecated forRemoval

The jdk.snmp module that provides the SNMP monitoring and management support for the Java virtual machine has been deprecated and is planned to be removed in a future release.

A warning message for deprecation is emitted when JVM SNMP monitoring is enabled (via the com.sun.management.snmp.port property configured in the management.properties configuration file).

JDK-8194051 (not public)

java.security.{Certificate,Identity,IdentityScope,Signer} APIs Deprecated forRemoval

The deprecated java.security.{Certificate, Identity, IdentityScope, Signer} classes have been marked forRemoval=true and are subject to removal in a future version of Java SE.

See JDK-8175091

java.security.acl APIs Deprecated forRemoval

The deprecated java.security.acl APIs have been marked forRemoval=true and are subject to removal in a future version of Java SE.

See JDK-8175094

javax.security.auth.Policy API Deprecated forRemoval

The deprecated javax.security.auth.Policy class has been marked forRemoval=true and will be removed in a future release. The javax.security.auth.Policy class has been deprecated since JDK 1.4 and superseded or replaced by java.security.Policy.

See JDK-8159535

The following notes describe additional changes and information about this release. In some cases, the following descriptions provide links to additional detailed information about an issue or a change.

client-libs
Class File Version Number is 54.0

The class file version has been changed from 53 (or 44 + 9) to 54 (44 +10), even though JDK 10 did not introduce other changes to the class file format.

The OpenJDK community has adopted a new time-based release model, in which major releases of the Java platform occur every 6 months. As a consequence, it is anticipated that class file changes will also occur more rapidly. To ensure predictability for the tooling that processes class file bytes, the class file version will be incremented every major release even if there are no other changes to the class file format. In effect, the class file version will be 44 + $FEATURE, where $FEATURE is the feature-release counter (previously referred to as the major number) of the Java SE Platform and the JDK version string.

See JDK-8191510

Touch Keyboard for Swing/AWT Text Components

This release adds support for automatically showing the touch keyboard for Swing/AWT text components on Microsoft Windows 8 or later. A user can display the touch keyboard either by using a touch screen to tap the text component area or by using a mouse to click in the area, when a keyboard is not attached to a computer.

The system property awt.touchKeyboardAutoShowIsEnabled controls whether this functionality is enabled in the JDK. This functionality is enabled by default. However, if the functionality is not needed, the user can switch it off from the command line by setting the system property to false:

-Dawt.touchKeyboardAutoShowIsEnabled=false

See JDK-8166772

java.awt.TrayIcon.displayMessage() Reimplemented on macOS

On macOS, the java.awt.TrayIcon.displayMessage() method has been re-implemented to use the NSUserNotification api to show messages to users. New messages on macOS are now shown by using the standard notification center instead of a custom window.

See JDK-8187639

Relax FileInputStream/FileOutputStream Requirement for finalize to Call close

The specifications of FileInputStream and FileOutputStream are changed to require calling the close method when 'there are no more references to the stream' only in the case where it would affect a subclass that has overridden the close method. The stream's finalize method does not call close directly in this case. In other cases, the release of resources is implementation specific. Refer to the FileInputStream and FileOutputStream documentation for recommendations.

See JDK-8080225

Empty Element in -Xbootclasspath/a

The bootstrap class loader has been changed to skip an empty element specified in -Xbootclasspath/a when locating resources. This change might impact existing code that relies on an empty element in the boot class path to find resources in the current working directory. Those applications will now need to use the -Xbootclasspath/a option to properly set the directory that the bootstrap class loader searches when locating resources.

See JDK-8185540

RMI Registry Filter Allows Binding Arrays of Any Type

The RMI Registry built-in serial filter has been modified to check only the array size and not the component type. The maximum array size has been increased to 1,000,000. The override filter can be used to decrease the limit. Array sizes greater than the maxarray limit will be rejected. Sizes less than the maxarray limit will be allowed.

The java.security file contains more information about the sun.rmi.registry.registryFilter property and the conf/security/java.security configuration file has been updated to better describe the default behavior and how to override it.

See JDK-8185346 Macos waiting for dsmos.

MBeanOperationInfo Accepts Any int Value as 'impact'

A new validation for the impact parameter of javax.management.MBeanOperationInfo.MBeanOperationInfo constructor has been introduced. MBeanOperationInfo now throws a new IllegalArgumentException if the impact provided is not one of INFO, ACTION, ACTION_INFO, or UNKNOWN.

See JDK-8024352

Deprecation Warning Dialog for Java Web Start

A deprecation warning dialog has been added that is shown the first time an application is launched via Java Web Start.

JDK-8191920 (not public)

print_tracing_info Uses Unified Logging

The two flags, TraceYoungGenTime and TraceOldGenTime, have been removed. The same information is now available by using Unified Logging and enabling the tag-set gc+heap+exit at the debug level.

See JDK-8184286

Change to Default Value for BiasedLockingStartupDelay

The default value for BiasedLockingStartupDelay has been changed to 0. The flag BiasedLockingStartupDelay previously had the default value 4000 which delayed the use of biased locking with 4 s (4000 ms). The reason for this delay was performance but recent performance runs show no difference between the 4000 ms delay and no delay. Since having the delay will cause other parts of the VM to do extra work, having the default set to 0 makes more sense.

See JDK-8180421

Java Improvements for Docker Containers

The following changes have been introduced in JDK 10 to improve the execution and configurability of Java running in Docker containers:

  • JDK-8146115 Improve docker container detection and resource configuration usage

The JVM has been modified to be aware that it is running in a Docker container and will extract container specific configuration information instead of querying the operating system. The information being extracted is the number of CPUs and total memory that have been allocated to the container. The total number of CPUs available to the Java process is calculated from any specified cpu sets, cpu shares or cpu quotas. This support is only available on Linux-based platforms. This new support is enabled by default and can be disabled in the command line with the JVM option:

-XX:-UseContainerSupport

In addition, this change adds a JVM option that provides the ability to specify the number of CPUs that the JVM will use:

-XX:ActiveProcessorCount=count

Jdk

This count overrides any other automatic CPU detection logic in the JVM.

  • JDK-8186248 Allow more flexibility in selecting Heap % of available RAM

Three new JVM options have been added to allow Docker container users to gain more fine grained control over the amount of system memory that will be used for the Java Heap:

-XX:InitialRAMPercentage
-XX:MaxRAMPercentage
-XX:MinRAMPercentage

These options replace the deprecated Fraction forms (-XX:InitialRAMFraction, -XX:MaxRAMFraction, and -XX:MinRAMFraction).

  • JDK-8179498 attach in Linux should be relative to /proc/pid/root and namespace aware

This bug fix corrects the attach mechanism when trying to attach from a host process to a Java process that is running in a Docker container.

See JDK-8146115

Accept including .conf files in krb5.conf's includedir

If krb5.conf contains the 'includedir DIRNAME' directive and a file in this directory has a name ending with .conf, its content will be included in krb5.conf. Before this change, only those files whose names consisted solely of alphanumeric characters, dashes, or underscores were included.

See JDK-8177085

New Class AST Node With enclosing Instance

New Class AST nodes with an enclosing instance that incorrectly return a null have been fixed. In some cases, the getEnclosingExpression() method of the NewClassTree AST node was returning null for code like:

<enclosing>.new <Class>(..) { .. }

This has been fixed, and getEnclosingExpression() now returns the enclosing expression.

See JDK-8044853

Error Message When java.lang.IllegalAccessError Produced

An enhancement has been made to improve the error message produced by javac when a java.lang.IllegalAccessError is thrown because external tools have loaded javac classes with multiple class loaders.

See JDK-8167638

javadoc Treats Failure to Access a URL as an Error

The javadoc tool has been changed to treat failure to access a URL as an error instead of a warning. If javadoc cannot access the contents of a URL provided with the -link or -linkoffline options, the tool will now report an error. Previously, the tool continued with a warning and produced incorrect documentation output.

See JDK-8180019

HTML Files in doc-files Subdirectories Wrapped with Standard javadoc Decorations

The standard doclet has been updated to copy HTML files in the doc-files subdirectories for the packages being documented to the document output directory. The content of these files are wrapped with the standard header, footer, and navigation bars. In addition, any appropriate comment tags within these files are processed.
Note: Some files may not be wrapped. This is a known bug.

See JDK-8185985

JShell Startup

The time needed to start JShell has been significantly reduced, especially in cases where a start file with many snippets is used.

See JDK-8186694

XMLInputFactory.newFactory Incorrectly Deprecated

The @Deprecated annotation has been removed from the newFactory() method in javax.xml.stream.XMLInputFactory. In Java SE 9, an @Deprecated annotation was incorrectly added to the newFactory() method in javax.xml.stream.XMLInputFactory. The method should not have been deprecated. Applications using the newInstance() method are not affected.

See JDK-8183519

java.xml APIs With Raw Types and Type Parameters

A number of java.xml APIs containing method declarations with raw types have been updated to add a type parameter. The updated methods are:

  • javax.xml.namespace.NamespaceContext

Iterator<String> getPrefixes(String namespaceURI);

  • javax.xml.xpath.XPathFunction

public Object evaluate(List<?> args)

  • org.xml.sax.helpers.NamespaceSupport

public Enumeration<String> getPrefixes ()public Enumeration<String> getPrefixes (String uri)public Enumeration<String> getDeclaredPrefixes ()

See JDK-8181149

This topic includes the following sections:

System Requirements for Installing the JDK on macOS

The following are the system requirements for installing the JDK on macOS:

  • Any Intel-based computer running macOS.

  • Administrator privileges.

    You cannot install Java for a single user. Installing the JDK on macOS is performed on a systemwide basis for all users. Administrator privileges are required to install the JDK on macOS.

Determining the Default JDK Version on macOS

When starting a Java application through the command line, the system uses the default JDK.

There can be multiple JDKs installed on the macOS system.

You can determine which version of the JDK is the default by entering java -version in a Terminal window. If the installed version is 12 Interim 0, Update 0, and Patch 0, then you see a string that includes the text 12. For example:

To run a different version of Java, either specify the full path, or use the java_home tool. For example:

$ /usr/libexec/java_home -v 12 --exec javac -version

Installing the JDK on macOS

  1. Download the JDK .dmg file, jdk-12.interim.update.patch-macosx-x64.dmg.

    Before the file can be downloaded, you must accept the license agreement.

  2. From either the browser Downloads window or from the file browser, double-click the .dmg file to start it.
    A Finder window appears that contains an icon of an open box and the name of the .pkg file.
  3. Double-click the JDK 12.pkg icon to start the installation application.
    The installation application displays the Introduction window.
  4. Click Continue.
  5. Click Install.
    A window appears that displays the message: Installer is trying to install new software. Enter your password to allow this.
  6. Enter the Administrator user name and password and click Install Software.
    The software is installed and a confirmation window is displayed.
After the software is installed, you can delete the .dmg file if you want to save disk space.

Uninstalling the JDK on macOS

Latest Jdk For Macos Download

You must have Administrator privileges.

Note:

Do not attempt to uninstall Java by removing the Java tools from /usr/bin. This directory is part of the system software and any changes will be reset by Apple the next time that you perform an update of the OS.

  1. Go to /Library/Java/JavaVirtualMachines.
  2. Remove the directory whose name matches the following format by executing the rm command as a root user or by using the sudo tool:
    /Library/Java/JavaVirtualMachines/jdk-interim.update.patch.jdk

    For example, to uninstall 12 Interim 0 Update 0 Patch 0:

    $ rm -rf jdk-12.jdk

Installation FAQ on macOS Platform

This topic provides answers for the following frequently asked questions about installing JDK on macOS computers.

1. How do I find out which version of Java is the system default?

When you run a Java application from the command line, it uses the default JDK. If you do not develop Java applications, then you do not need to worry about this. See Determining the Default JDK Version on macOS.

2. How do I uninstall Java?

See Uninstalling the JDK on macOS.

Latest Jdk For Macos Windows

3. After installing Java for macOS 2012-006, can I continue to use Apple's Java 6 alongside the macOS JDK for Java 12?

If you want to continue to develop with Java 6 using command-line, then you can modify the startup script for your favorite command environment. For bash, use this:

$ export JAVA_HOME=`/usr/libexec/java_home -v 12`

Some applications use /usr/bin/java to call Java. After installing Java for macOS 2012-006, /usr/bin/java will find the newest JDK installed, and will use that for all of the Java-related command-line tools in /usr/bin. You may need to modify those applications to find Java 6, or contact the developer for a newer version of the application.

4. Can I restore Apple Java after uninstalling Oracle Java?

Go back to Apple Java using the following instructions:

  1. Uninstall Oracle Java by deleting the plug-in file. From a command-line, enter:

    $ sudo rm -rf '/Library/Internet Plug-Ins/JavaAppletPlugin.plugin'

  2. Create a symlink using the following command, entered on a single line:

    $ sudo ln -s /System/Library/Java/Support/CoreDeploy.bundle/Contents/JavaAppletPlugin.plugin '/Library/Internet Plug-Ins/JavaAppletPlugin.plugin'

5. What happened to the Java Preferences app in Application Utilities?

The Java Preferences app was part of the Apple Java installation and is not used by Oracle Java. Therefore, macOS releases from Apple that do not include Apple Java will not include Java Preferences.