寫Java程式一直編譯失敗,JDK到底該不該裝

What's new in this version:

IANA DATA 2017b:
- JDK 8u141 contains IANA time zone data version 2017b

CERTIFICATE CHANGES:
- Let's Encrypt certificates added to root CAs. One new root certificate has been added

NEW FEATURES:
security-libs/java.security. Improved algorithm constraints checking:
- With the need to restrict weak algorithms usage in situations where they are most vulnerable, additional features have been added when configuring the jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms security properties in the java.security file.
- jdk.certpath.disabledAlgorithms: The certpath property has seen the most change. Previously it was limited to two Constraint types; either a full disabling of an algorithm by name or a full disabling of an algorithm by the key size when checking certificates, certificate chains, and certificate signatures. This creates configurations that are absolute and lack flexibility in their usage. Three new Constraints were added to give more flexibility in allowing and rejecting certificates.
- "jdkCA" examines the certificate chain termination with regard to the cacerts file. In the case of "SHA1 jdkCA". SHA1's usage is checked through the certificate chain, but the chain must terminate at a marked trust anchor in the cacerts keystore to be rejected. This is useful for organizations that have their own private CA that trust using SHA1 with their trust anchor, but want to block certificate chains anchored by a public CA from using SHA1.
- "denyAfter" checks if the given date is before the current date or the PKIXParameter date. In the case of "SHA1 denyAfter 2018-01-01", before 2018 a certificate with SHA1 can be used, but after that date, the certificate is rejected. This can be used for a policy across an organization that is phasing out an algorithm with a drop-dead date. For signed JAR files, the date is compared against the TSA timestamp. The date is specified in GMT.

"usage" examines the specified algorithm for a specified usage. This can be used when disabling an algorithm for all usages is not practical. There are three usages that can be specified:
- TLSServer' restricts the algorithm in TLS server certificate chains when server authentication is performed as a client
- TLSClient' restricts the algorithm in TLS client certificate chains when client authentication is performed as a server
- SignedJAR' restricts the algorithms in certificates in signed JAR files. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter
- For example, "SHA1 usage TLSServer TLSClient" would disallow SHA1 certificates for TLSServer and TLSClient operations, but SignedJars would be allowed
- All of these constraints can be combined to constrain an algorithm when delimited by '&'. For example, to disable SHA1 certificate chains that terminate at marked trust anchors only for TLSServer operations, the constraint would be "SHA1 jdkCA & usage TLSServer"
- jdk.jar.disabledAlgorithms: One additional constraint was added to this .jar property to restrict JAR manifest algorithms
- "denyAfter" checks algorithm constraints on manifest digest algorithms inside a signed JAR file. The date given in the constraint is compared against the TSA timestamp on the signed JAR file. If there is no timestamp or the timestamp is on or after the specified date, the signed JAR file is treated as unsigned. If the timestamp is before the specified date, the .jar will operate as a signed JAR file. The syntax for restricting SHA1 in JAR files signed after January 1st 2018 is: "SHA1 denyAfter 2018-01-01". The syntax is the same as that for the certpath property, however certificate checking will not be performed by this property

CHANGES:
core-svc/java.lang.management. JMX Diagnostic improvements:
- com.sun.management.HotSpotDiagnostic::dumpHeap API is modified to throw IllegalArgumentException if the supplied file name does not end with “.hprof” suffix. Existing applications which do not provide a file name ending with the “.hprof” extension will fail with IllegalArgumentException. In that case, applications can either choose to handle the exception or restore old behavior by setting system property 'jdk.management.heapdump.allowAnyFileSuffix' to true.

security-libs/javax.net.ssl. Custom HostnameVerifier enables SNI extension:
- Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body.

xml/jax-ws. Tighter secure checks on processing WSDL files by wsimport tool:

The wsimport tool has been changed to disallow DTDs in Web Service descriptions, specifically:
- DOCTYPE declaration is disallowed in documents
- External general entities are not included by default
- External parameter entities are not included by default
- External DTDs are completely ignored

To restore the previous behavior:
- Set the System property com.sun.xml.internal.ws.disableXmlSecurity to true
- Use the wsimport tool command line option –disableXmlSecurity
- NOTE: JDK 7 and JDK 6 support for this option in wsimport will be provided via a Patch release post July CPU

BUG FIXES:
- JFileChooser with Windows look and feel crashes on win 10
- Race Condition in java.lang.reflect.WeakCache
- java.nio.Bits.unaligned() doesn't return true on ppc
- After updating to Java8u131, the bind to rmiregistry is rejected by registryFilter even though registryFilter is set
- sun.management.LazyCompositeData.isTypeMatched() fail for composite types with items of ArrayType
- SafePointNode::_replaced_nodes breaks with irreducible loops
- NPE when JavaFX loads default stylesheet or font families if CCL is null
- WebEngine.getDocument().getDocumentURI() no longer returns null for loading a String of HTML
- Failed to load RSA private key from pkcs12
- Improved algorithm constraints checking
- Custom HostnameVerifier disables SNI extension