Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Carey Brown
  • Stephan van Hulst
  • Tim Holloway
  • Peter Rooke
  • Himai Minh
Bartenders:
  • Piet Souris
  • Mikalai Zaikin

New Version of Java 8

 
Marshal
Posts: 77926
373
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Please download and install JDK8u60.
 
Saloon Keeper
Posts: 14856
334
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

New Features and Changes


Documentation Updates due to Nashorn Enhancements

JDK 8u60 includes new enhancements to Nashorn. As a result the following documentation changes should be read in conjunction with the current Nashorn documentation:

  • Addition:
    In the previous section, we mentioned that every JavaScript object when exposed to Java APIs implements the java.util.Map interface. This is true even for JavaScript arrays. However, this behavior is often not desired or expected when the Java code expects JSON-parsed objects. Java libraries that manipulate JSON-parsed objects usually expect arrays to expose the java.util.List interface instead. If you need to expose your JavaScript objects so that arrays are exposed as lists and not maps, you can use the Java.asJSONCompatible(obj) function, where obj is the root of your JSON object tree.

  • Correction:
    The caution mentioned at the end of Mapping Data Types section, is no longer applicable.

    Nashorn ensures that internal JavaScript strings are converted to java.lang.String when exposed externally.

  • Correction:
    The statement in the section Mapping Data Types, that mentions "For example, arrays must be explicitly converted,........." is not correct.

    Arrays are automatically converted to Java array types, such as java.util.List, java.util.Collection, java.util.Queue and java.util.Deque and so on.

Changes in Deployment Rule Set v1.2

JDK 8u60 implements Deployment Rule Set (DRS) 1.2, which includes the following changes:

  • Add "checksum" element as sub element of "id" which can allow unsigned jars to be identified by the SHA-256 checksum of the uncompressed form of a jar:

    • The "checksum" element will match only unsigned jars, and the given hash will be compared only against the uncompressed form of the jar.
    • The "checksum" element (similar to "certificate" element) has two arguments "hash" and "algorithm", however, unlike "certificate" element, the only supported value for "algorithm" is "SHA-256". Any other value provided will be ignored.
  • Allow "message" element to apply to all rule types, where previously it only applied to a block rule:

    • In a run rule, a message sub element will cause a message dialog to be displayed where without a run rule, the default behavior would be to show certificate or unsigned dialog. The message will be displayed in the message dialog.
    • In a default rule, the message will only be displayed if the default action is to block. In such a case the message will be included in the block dialog.
  • Echo "customer" blocks in the Java Console, trace files, and Java Usage Tracker records.

    • Previous to DRS 1.2, "customer" elements could be included (with any sub-elements) in the ruleset.xml file. This element and all its sub elements are ignored. In DRS 1.2, the elements are still functionally ignored. However:
      • When parsing the ruleset.xml file, all "customer" blocks will be echoed to the Java Console and deployment trace file (if Console and Tracing are enabled).
      • When using a rule, all "customer" records included within that rule will be added to the Java Usage Tracker (JUT) record (if JUT is enabled).
  • As a result of the above changes, the DTD for DRS 1.2 is as follows:

    
    <!ELEMENT ruleset (rule*)>
    <!ATTRIBUTE ruleset href CDATA #IMPLIED>
    <!ATTRIBUTE ruleset version CDATA #REQUIRED>
    
    <!ELEMENT rule (id, action)>
    
    <!ELEMENT id (certificate?) (checksum?) >
    <!ATTRIBUTE id title CDATA #IMPLIED>
    <!ATTRIBUTE id location CDATA #IMPLIED>
    
    <!ELEMENT certificate EMPTY>
    <!ATTLIST certificate algorithm CDATA #IMPLIED>
    <!ATTLIST certificate hash CDATA #REQUIRED>
    
    <!ELEMENT checksum EMPTY>
    <!ATTLIST checksum algorithm CDATA #IMPLIED>
    <!ATTLIST checksum hash CDATA #REQUIRED>
     
    <!ELEMENT action (message?)>
    <!ATTRIBUTE permission (run | block | default) #REQUIRED>
    <!ATTRIBUTE version CDATA #IMPLIED>
    <!ATTRIBUTE force (true|false) "false">
    
    <!ELEMENT message (#PCDATA)>
    <!ATTLIST message locale CDATA #IMPLIED>
    
    

Bug Fixes


For a list of bug fixes included in this release, see JDK 8u60 Bug Fixes page.

The following are some of the notable bug fixes included in JDK 8u60 release:

Area: security-libs/org.ietf.jgss:krb5
Synopsis: dns_lookup_realm should be false by default

The dns_lookup_realm setting in Kerberos' krb5.conf file is by default false.

See 8080637.

Area: security-libs/javax.net.ssl
Synopsis: Disable RC4 cipher suites

RC4-based TLS ciphersuites (e.g. TLS_RSA_WITH_RC4_128_SHA) are now considered compromised and should no longer be used (see RFC 7465). Accordingly, RC4-based TLS ciphersuites have been deactivated by default in the Oracle JSSE implementation by adding "RC4" to "jdk.tls.disabledAlgorithms" security property, and by removing them from the default enabled ciphersuites list. These cipher suites can be reactivated by removing "RC4" form "jdk.tls.disabledAlgorithms" security property in the java.security file or by dynamically calling Security.setProperty(), and also readding them to the enabled ciphersuite list using the SSLSocket/SSLEngine.setEnabledCipherSuites() methods.

You can also use the -Djava.security.properties command line option to override the jdk.tls.disabledAlgorithms security property. For example:

java -Djava.security.properties=my.java.security ...

where my.java.security is a file containing the property without RC4:

jdk.tls.disabledAlgorithms=SSLv3

Even with this option set from commandline, the RC4 based ciphersuites need to be re-added to the enabled ciphersuite list by using the SSLSocket/SSLEngine.setEnabledCipherSuites() methods.

See 8076221.

Area: security-libs/java.secuirty
Synopsis: Support keystore type detection for JKS and PKCS12 keystores

Keystore Compatibility Mode:
To aid interoperability, the Java keystore type JKS now supports keystore compatibility mode by default. This mode enables JKS keystores to access both JKS and PKCS12 file formats. To disable keystore compatibility mode set the Security property keystore.type.compat to the string value false.

See 8062552.

Area: core-libs/java.lang
Synopsis: Deprecate Unsafe monitor methods in JDK 8u release

The methods monitorEnter, monitorExit and tryMonitorEnter on sun.misc.Unsafe are marked as deprecated in JDK 8u60 and will be removed in a future release. These methods are not used within the JDK itself and are very rarely used outside of the JDK.

See 8069302.

Area: hotspot/jfr
Synopsis: Extract JFR recording from the core file using SA

DumpJFR is a Serviceability Agent based tool that can be used to extract Java Flight Recorder(JFR) data from the core files and live Hotspot processes. DumpJFR can be used in one of the following methods:

  • Attach DumpJFR to a live process:

    java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <pid>
     
  • Attach DumpJFR to a core file:

    java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>

DumpJFR tool dumps the JFR data to a file called recording.jfr in the current working folder.

See 8065301(not public).

Area: tools/javac
Synopsis: Local variables named 'enum' lead to spurious compiler crashes

The javac parser is incorrectly parsing local variables with name 'enum'; this results in spurious failures when a program containing such local variables is compiled with a 'source' flag corresponding to a release in which the enum construct is not available (such as '-source 1.4').

See 8069181.

 



 
You firghten me terribly. I would like to go home now. Here, take this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic