This repo is a continuation of the bsd-port tree, still maintained by
the FreeBSD ports java people.
It is forked from (and merges regularly from) AdoptOpenJDK.
They accept patches for other BSDs, so we should see if we have anything
in our tree worth contributing.
As a side effect, this changes updates openjdk8 to u222.
Changelog:
New Features
security-libs/javax.net.ssl
➜ Support for Customization of Default Enabled Cipher Suites via System Properties
The system property jdk.tls.client.cipherSuites can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property jdk.tls.server.cipherSuites can be used for customization on the server side.
The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicit setting of enabled cipher suites will override the system properties.
Please refer to the "Java Cryptography Architecture Standard Algorithm Name Documentation" for the standard JSSE cipher suite names, and the "Java Cryptography Architecture Oracle Providers Documentation" for the cipher suite names supported by the SunJSSE provider.
Note that the actual use of enabled cipher suites is restricted by algorithm constraints.
Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations.
Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk.
See JDK-8162362
Bug Fixes
This release contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 8u192 Bug Fixes page.
Security bugs:
CVE-2018-3183
CVE-2018-3209
CVE-2018-3169
CVE-2018-3149
CVE-2018-3211
CVE-2018-3180
CVE-2018-3214
CVE-2018-3157
CVE-2018-3150
CVE-2018-13785
CVE-2018-3136
CVE-2018-3139
Having a language install a printing system violates the Principle of
Least Astonishment. Add a comment to be replaced with an explanation
of why this is necessary or helpful.
Changelog:
core-libs java.time (tz) Upgrade time-zone data to tzdata2018d
xml jax-ws Newlines in JAXB string values of SOAP-requests are escaped to " "
hotspot compiler Crash with assert(handler_address == SharedRuntime::compute_compiled_exc_handler(..) failed: Must be the same
deploy webstart JRE bundled in App-V package will not start Java Web Start applications
deploy webstart javaws.exe failed to launch UTF-8 encoded JNLP file
javafx web Intermittent crash when using WebView from JFXPanel applicationS
hotspot runtime Hotspot crash on Cassandra 3.11.1 startup with libnuma 2.0.3
security-libs org.ietf.jgss Kerberos krb5 authentication: AuthList's put method leads to performance issue
hotspot gc Performance drop with Java JDK 1.8.0_162-b32
This happened to build only because the BUILDLINK_PREFIX was already passed
through, however the dependency will have been incorrectly registered as
full rather than build-only so bump PKGREVISION.
This should be the last part of the renaming operation for print/cups to
print/cups-base.
Rationale: packages depending on CUPS but not relying on a functional
printing setup only need to depend on print/cups-base (equivalent to the
former print/cups). The new print/cups now depends on print/cups-base
and on print/cups-filters, thus directly providing a functional printing
setup. This bump reflects this change of dependency.
As discussed on tech-pkg@
This is with the notable exception of meta-pkgs/desktop-gnome, which I
believe implies a fully functional cups.
This is still missing revision bumps - I'll be right there (first time I
am doing this on so many packages at a time).
As discussed on tech-pkg@
Changelog:
Changes
* MD5 added to jdk.jar.disabledAlgorithms Security property
* New system property to control caching for HTTP SPNEGO connection.
* New system property to control caching for HTTP NTLM connection.
* New version of VisualVM
Bugfixes
* Introduced a new window ordering model
* Correction of IllegalArgumentException from TLS handshake
Changelog:
http://www.oracle.com/technetwork/java/javase/8u121-relnotes-3315208.html
core-libs/javax.naming
Improved protection for JNDI remote class loading
Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. To enable remote class loading by the RMI Registry or COS Naming service provider, set the following system property to the string "true", as appropriate:
com.sun.jndi.rmi.object.trustURLCodebase
com.sun.jndi.cosnaming.object.trustURLCodebase
JDK-8158997 (not public)
security-libs/java.security
jarsigner -verbose -verify should print the algorithms used to sign the jar
The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak.
Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property, jdk.jar.disabledAlgorithms, it will be labeled with "(weak)".
For example:
- Signed by "CN=weak_signer"
Digest algorithm: MD2 (weak)
Signature algorithm: MD2withRSA (weak), 512-bit key (weak)
Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
Timestamp digest algorithm: SHA-256
Timestamp signature algorithm: SHA256withRSA, 2048-bit key
See JDK-8163304
New Features
core-libs/java.io:serialization
Serialization Filter Configuration
Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the "jdk.serialFilter" patterns are described in JEP 290 Serialization Filtering and in <JRE>/lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled.
See JDK-8155760
core-libs/java.rmi
RMI Better constraint checking
RMI Registry and Distributed Garbage Collection use the mechanisms of JEP 290 Serialization Filtering to improve service robustness.
RMI Registry and DGC implement built-in white-list filters for the typical classes expected to be used with each service.
Additional filter patterns can be configured using either a system property or a security property. The "sun.rmi.registry.registryFilter" and "sun.rmi.transport.dgcFilter" property pattern syntax is described in JEP 290 and in <JRE>/lib/security/java.security.
JDK-8156802 (not public)
security-libs
Add mechanism to allow non-default root CAs to not be subject to algorithm restrictions
*New certpath constraint: jdkCA*
In the java.security file, an additional constraint named "jdkCA" is added to the jdk.certpath.disabledAlgorithms property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression.
Example: To apply this constraint to SHA-1 certificates, include the following: SHA1 jdkCA
See JDK-8140422
Changes
tools/javadoc(tool)
New --allow-script-in-comments option for javadoc
The javadoc tool will now reject any occurrences of JavaScript code in the javadoc documentation comments and command-line options, unless the command-line option, --allow-script-in-comments is specified.
With the --allow-script-in-comments option, the javadoc tool will preserve JavaScript code in documentation comments and command-line options. An error will be given by the javadoc tool if JavaScript code is found and the command-line option is not set.
JDK-8138725 (not public)
security-libs/javax.xml.crypto
Increase the minimum key length to 1024 for XML Signatures
The secure validation mode of the XML Signature implementation has been enhanced to restrict RSA and DSA keys less than 1024 bits by default as they are no longer secure enough for digital signatures. Additionally, a new security property named jdk.xml.dsig.SecureValidationPolicy has been added to the java.security file and can be used to control the different restrictions enforced when the secure validation mode is enabled.
The secure validation mode is enabled either by setting the xml signature property org.jcp.xml.dsig.secureValidation to true with the javax.xml.crypto.XMLCryptoContext.setProperty method, or by running the code with a SecurityManager.
If an XML Signature is generated or validated with a weak RSA or DSA key, an XMLSignatureException will be thrown with the message, "RSA keys less than 1024 bits are forbidden when secure validation is enabled" or "DSA keys less than 1024 bits are forbidden when secure validation is enabled."
JDK-8140353 (not public)
docs/release_notes
Restrict certificates with DSA keys less than 1024 bits.
DSA keys less than 1024 bits are not strong enough and should be restricted in certification path building and validation. Accordingly, DSA keys less than 1024 bits have been deactivated by default by adding "DSA keySize < 1024" to the "jdk.certpath.disabledAlgorithms" security property. Applications can update this restriction in the security property ("jdk.certpath.disabledAlgorithms") and permit smaller key sizes if really needed (for example, "DSA keySize < 768").
JDK-8139565 (not public)
security-libs
More checks added to DER encoding parsing code
More checks are added to the DER encoding parsing code to catch various encoding errors. In addition, signatures which contain constructed inparsing. Note that signatures generated using JDK default providers are not affected by this change.
JDK-8168714 (not public)
core-libs/java.net
Additional access restrictions for URLClassLoader.newInstance
Class loaders created by the java.net.URLClasslasses from a list of given URLs. If the calling code does not have access to one or more of the URLs and the URL artifacts that can be accessed do not contain the required class, then a ClassNotFoundException, or similar, will be thrown. Previously, a Sege can be disabled by setting the jdk.net.URLClassPath.disableRestrictedPermissions system property.
JDK-8151934 (not public)
core-libs/java.util.logging
A new configurable property in logging.properties java.util.logging.FileHandler.maxLocks
A new "java.util.logging.FileHandler.maxLocks" configurable property is added to java.util.logging.FileHandler.
This new logging property can be defined in the logging configuration file and makes it possible to configure the maximum number of concurrent log file locks a FileHandler can handle. The default value is 100.
In a highly concurrent environment where multiple (more than 101) standalone client applications are using the JDK Logging API with FileHandler simultaneously, it may happen that the default limit of 100 is reached, resulting in a failure to acquire FileHandler file locks and causing an IO Exception to be thrown. In such a case, the new logging property can be used to increase the maximum number of locks before deploying the application.
If not overridden, the default value of maxLocks (100) remains unchanged. See java.util.logging.LogManager and java.util.logging.FileHandler API documentation for more details.
See JDK-8153955
Bug Fixes
The following are some of the notable bug fixes included in this release:
client-libs/javax.swing
Trackpad scrolling of text on OS X 10.12 Sierra is very fast
The MouseWheelEvent.getWheelRotation() method returned rounded native NSEvent deltaX/Y events on Mac OS X. The latest macOS Sierra 10.12 produces very small NSEvent deltaX/Y values so rounding and summing them leads to the huge value returned from the MouseWheelEvent.getWheelRotation(). The JDK-8166591 fix accumulates NSEvent deltaX/Y and the MouseWheelEvent.getWheelRotation() method returns non-zero values only when the accumulated value exceeds a threshold and zero value. This is compliant with the MouseWheelEvent.getWheelRotation() specification (https://docs.oracle.com/javase/8/docs/api/java/awt/event/MouseWheelEvent.html#getWheelRotation):
"Returns the number of "clicks" the mouse wheel was rotated, as an integer. A partial rotation may occur if the mouse supports a high-resolution wheel. In this case, the method returns zero until a full "click" has been accumulated."
For the precise wheel rotation values, use the MouseWheelEvent.getPreciseWheelRotation() method instead.
See JDK-8166591
This release also contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see the JDK 8u121 Bug Fixes page.
Known Issues
deploy/packager
javapackager and fx:deploy bundle the whole JDK instead of JRE
There is a known bug in the Java Packager for Mac where the entire JDK may be bundled with the application bundle resulting in an unusually large bundle. The work around is to use the bundler option -Bruntime option. For example: -Bruntime=JavaAppletPlugin.plugin sets where the JavaAppletPlugin.plugin for the desired JRE to bundle is located in the current directory.
See JDK-8166835
install/install
Java Installation will fail for non-admin users with UAC off
The Java installation on Windows will fail without warning or prompting, for non-admin users with User Access Control (UAC) disabled. The installer will leave a directory, jds<number>.tmp, in the %TEMP% directory.
JDK-8161460 (not public)
* Include a patch from PR pkg/51221
Changelog:
security-libs/java.security
SunPKCS11 Provider no longer offering SecureRandom by default
SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg
Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation have allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method.
See JDK-8098581
Fix following security bugs:
CVE-2016-5556
CVE-2016-5582
CVE-2016-5573
CVE-2016-5597
CVE-2016-5554
CVE-2016-5542
Changelog:
IANA Data 2016d
JDK 8u102 contains IANA time zone data version 2016d. For more
information, refer to Timezone Data Versions in the JRE Software.
See JDK-8151876
Enhancements
core-libs/java.lang.invoke
Internal package sun.invoke.anon has been removed
The internal package sun.invoke.anon has been removed. The
functionality it used to provide, namely anonymous class loading
with possible constant pool patches, is available via the
Unsafe.defineAnonymousClass() method.
See JDK-8081512
hotspot/runtime
New property jdk.lang.processReaperUseDefaultStackSize
When a large TLS (Thread local storage) size is set for Threads,
the JVM results in a stack overflow exception. The reason for this
behavior is that the reaper thread was created with a low stack
size of 32768k. When a large TLS size is set, it steals space from
the threads stack, which eventually results in a stack overflow.
This is a known glibc bug. To overcome this issue, we have introduced
a workaround (jdk.lang.processReaperUseDefaultStackSize) in which
the user can set the reaper threads stack size to a default instead
of to 32768. This gives the reaper thread a bigger stack size, so
for a large TLS size, such as 32k, the process will not fail.
Users can set this flag in one of two ways:
1. -Djdk.lang.processReaperUseDefaultStackSize=true
2. System.setProperty("jdk.lang.processReaperUseDefaultStackSize",
"true")
The problem has been observed only when JVM is started from JNI
code in which TLS is declared using "__thread"
See JDK-8130425
hotspot/compiler
Implemented performance improvements for BigInteger.montgomeryMultiply
We have implemented improvements that will improve performance of
several security algorithms, especially when using ciphers with
key lengths of 2048-bit or greater. To turn on these improvements,
use the options -XX:+UseMontgomeryMultiplyIntrinsic and
-XX:+UseMontgomerySquareIntrinsic. This improvement is only for
Linux and Solaris on x86_64 architecture.
See JDK-8130150
Changes
security-libs/javax.crypto
MSCAPI KeyStore can handle same-named certificates
Java SE KeyStore does not allow certificates that have the same
aliases
(http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html).
However, on Windows, multiple certificates stored in one keystore
are allowed to have non-unique friendly names.The fix for JDK-6483657
makes it possible to operate on such non-uniquely named certificates
through the Java API by artificially making the visible aliases
unique.
Please note, this fix does not enable creating same-named certificates
with the Java API. It only allows you to deal with same-named
certificates that were added to the keystore by 3rd party tools.
It is still recommended that your design not use multiple certificates
with the same name. In particular, the following sentence will not
be removed from the Java documentation: "In order to avoid problems,
it is recommended not to use aliases in a KeyStore that only differ
in case."
(http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html)
See JDK-6483657
security-libs/javax.net.ssl
Modify requirements on Authority Key Identifier extension field
during X509 certificate chain building
The requirement to have the Authority Key Identifier (AKID) and
Subject Key Identifier (SKID) fields matching when building X509
certificate chains has been modified for some cases.
See JDK-8072463
hotspot/gc
Providing more granular levels for GC verification
This enhancement provides a way to specify more granular levels
for the GC verification enabled using the VerifyBeforeGC, VerifyAfterGC,
and VerifyDuringGC diagnostic options. It introduces a new diagnostic
option VerifySubSet with which one can specify the subset of the
memory system that should be verified.
With this new option, one or more sub-systems can be specified in
a comma separated string. Valid memory sub-systems are: threads,
heap, symbol_table, string_table, codecache, dictionary,
classloader_data_graph, metaspace, jni_handles, c-heap, and
codecache_oops.
During the GC verification, only the sub-systems specified using
VerifySubSet get verified:
D:\\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC
-XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test
[0.095s][debug ][gc,verify] Threads
[0.099s][debug ][gc,verify] C-heap
[0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms
[0.120s][debug ][gc,verify] Threads
[0.124s][debug ][gc,verify] C-heap
[0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms
[0.148s][debug ][gc,verify] Threads
[0.152s][debug ][gc,verify] C-heap
If any invalid memory sub-systems are specified with VerifySubSet,
the Java process exits with the following error message:
D:\\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC
-XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom
Error occurred during initialization of VM VerifySubSet: 'hello'
memory sub-system is unknown, please correct it
See JDK-8072725
hotspot/compiler
Removed PICL warning message
In 8u40 and 7u80, a new feature was introduced to use the PICL
library on Solaris to get some system information. If this library
was not found, we printed an error message:
Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing.
Performance will not be optimal.
This warning was misleading. Not finding the PICL library is a very
minor issue, and the warnings mostly lead to confusion. In this
release, the warning was removed.
See JDK-8144957
core-libs/javax.naming
Improved exception handling for bad LDAP referral replies
The JDK was throwing a NullPointerException when a non-compliant
REFERRAL status result was sent but no referral values were included.
With this change, a NamingException with message value of "Illegal
encoding: referral is empty" will be thrown in such circumstances.
See JDK-8149450 and JDK-8154304
Bug Fixes
The following are some of the notable bug fixes included in this
release:
security-libs/javax.net.ssl
Fix to resolve "Unable to process PreMasterSecret, may be too big"
issue
Recent JDK updates introduced an issue for applications that depend
on having a delayed provider selection mechanism. The issue was
introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen
corresponded to an exception like the following :
handling exception: javax.net.ssl.SSLProtocolException: Unable to
process PreMasterSecret, may be too big
See JDK-8149017
This release also contains fixes for security vulnerabilities
described in the Oracle Java SE Critical Patch Update Advisory.
For a more complete list of the bug fixes included in this release,
see the JDK 8u102 Bug Fixes page.
the java/openjdk8/jre/bin/ directory. In particular, apache-ant will
execute java from this directory rather than the copy in the non-jre
directory!
Bump package revision.
Fixes my problem building misc/libreoffice.
Changelog:
Bug Fixes
The following table lists the bug fixes included in JDK 8u92 release:
Bug Id Category Subcategory Description
JDK-8041900 client-libs 2d [macosx] Java forces the use of discrete GPU
JDK-8132890 client-libs 2d Text Overlapping on Dot Matrix Printers
JDK-8132503 client-libs java.awt [macosx] Chinese full stop symbol cannot be entered with Pinyin IM on OS X
JDK-8138764 client-libs java.awt In some cases the usage of TreeLock can be replaced by other synchronization
JDK-8041501 client-libs javax.imageio ImageIO reader is not capable of reading JPEGs without JFIF header
JDK-8134828 client-libs javax.swing Scrollbar thumb disappears with Nimbus L&F
JDK-8131129 core-libs java.lang.invoke Attempt to define a duplicate BMH$Species class
JDK-8067800 core-libs java.time Clarify java.time.chrono.Chronology.isLeapYear for out of range years
JDK-8062901 core-libs java.util Iterators is spelled incorrectly in the Javadoc for Spliterator
JDK-8140587 core-libs java.util.concurrent Atomic*FieldUpdaters should use Class.isInstance instead of direct class check
JDK-8145539 core-libs java.util:collections (coll) AbstractMap.keySet and .values should not be volatile
JDK-8143297 core-libs jdk.nashorn Nashorn compilation time reported in nanoseconds
JDK-8143896 core-libs jdk.nashorn java.lang.Long is implicitly converted to double
JDK-8144020 core-libs jdk.nashorn Remove long as an internal numeric type
JDK-8144131 core-libs jdk.nashorn ArrayData.getInt implementations do not convert to int32
JDK-8146147 core-libs jdk.nashorn Java linker indexed property getter does not work for computed nashorn string
JDK-8147845 core-libs jdk.nashorn Varargs Array functions still leaking longs
JDK-8147857 core-svc javax.management RMIConnector logs attribute names incorrectly
JDK-8140244 core-svc tools Port fix of JDK-8075773 to AIX and possibly MacOSX
JDK-8139773 deploy Add more debug traces to deployment registration process (RegFx.cpp)
JDK-8142982 deploy Race Condition can cause CacheEntry.getJarSigningData() to return null.
JDK-8143294 deploy cookie handler can't get JSESSIONID on linux
JDK-8145217 deploy Fix GenericCookieHandlerTest
JDK-8143314 deploy packager Runtime not respected with INI-configuration while creating native bundle
JDK-8139389 deploy webstart Register a protocol handler for Java Webstart
JDK-6869327 hotspot compiler Add new C2 flag to keep safepoints in counted loops.
JDK-8058563 hotspot compiler InstanceKlass::_dependencies list isn't cleared from empty nmethodBucket entries
JDK-8080650 hotspot compiler Enable stubs to use frame pointers correctly
JDK-8129847 hotspot compiler Compiling methods generated by Nashorn triggers high memory usage in C2
JDK-8131782 hotspot compiler C1 Class.cast optimization breaks when Class is loaded from static final
JDK-8139421 hotspot compiler PPC64LE: MacroAssembler::bxx64_patchable kills register R12
JDK-8140483 hotspot compiler Atomic*FieldUpdaters final fields should be trusted
JDK-8144487 hotspot compiler PhaseIdealLoop::build_and_optimize() must restore major_progress flag if skip_loop_opts is true
JDK-8144935 hotspot compiler C2: safepoint is pruned from a non-counted loop
JDK-8145754 hotspot compiler PhaseIdealLoop::is_scaled_iv_plus_offset() does not match AddI
JDK-8065579 hotspot gc WB method to start G1 concurrent mark cycle should be introduced
JDK-8138966 hotspot gc Intermittent SEGV running ParallelGC
JDK-8145442 hotspot gc Add the facility to verify remembered sets for G1
JDK-8029630 hotspot runtime Thread id should be displayed as hex number in error report
JDK-8046611 hotspot runtime Build errors with gcc on sparc/fastdebug
JDK-8087120 hotspot runtime [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms
JDK-8138745 hotspot runtime Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
JDK-8139258 hotspot runtime PPC64LE: argument passing problem when passing 15 floats in native call
JDK-8143963 hotspot runtime improve ClassLoader::trace_class_path to accept an additional outputStream* arg
JDK-8029726 hotspot svc On OS X some dtrace probe names are mismatched with Solaris
JDK-8029727 hotspot svc On OS X dtrace probes Call<type>MethodA/Call<type>MethodV are not fired.
JDK-8029728 hotspot svc On OS X dtrace probes SetStaticBooleanField are not fired
JDK-8130910 hotspot svc hsperfdata file is created in wrong directory and not cleaned up if /tmp/hsperfdata_<username> has wrong permissions
JDK-8140031 hotspot svc SA: Searching for a value in Threads does not work
JDK-8144885 hotspot svc agent/src/os/linux/libproc.h needs to support Linux/SPARC builds
JDK-8145099 hotspot svc Better error message when SA can't attach to a process
JDK-8074935 security-libs java.security jdk8 keytool doesn't validate pem files for RFC 1421 correctness, as jdk7 did
JDK-8139436 security-libs java.security sun.security.mscapi.KeyStore might load incomplete data
JDK-8064330 security-libs javax.net.ssl Remove SHA224 from the default support list if SunMSCAPI enabled
JDK-8131665 security-libs javax.net.ssl Bad exception message in HandshakeHash.getFinishedHash
JDK-8136442 security-libs javax.net.ssl Don't tie Certificate signature algorithms to ciphuites
JDK-8038184 security-libs javax.xml.crypto XMLSignature throws StringIndexOutOfBoundsException if ID attribute value is empty String
JDK-8038349 security-libs javax.xml.crypto Signing XML with DSA throws Exception when key is larger than 1024 Exception when calling super with Object<>()
JDK-8066974 tools javac Compiler doesn't infer method's generic type information in lambda body
JDK-8068254 tools javac Method reference uses wrong qualifying type
JDK-8130506 tools javac javac Assertien invoking MethodHandle.invoke with lambda parameter
JDK-8134007 tools javac Improve string folding
JDK-8134759 tools javac jdb: Incorrect stepping inside finally block
JDK-8139751 tools javac Javac crash with -XDallowStringFolding=false
JDK-8145466 tools javac javac: No line numbers in compilation error
JDK-8145722 tools javadoc(tool) NullPointerException in javadoc
JDK-8133924 xml jaxp NPE may be thrown when xsltc select a non-existing node after JDK-8062518
Originally reported from abs@ on tech-pkg@.
From random(4) man page:
Applications should read from /dev/urandom when they need randomly
generated data, e.g. key material for cryptography or seeds for
simulations.
