This document describes the API specification changes made in Java SE 8 relative to Java SE 7, except for features or changes specified in related Component JSRs.
All changes to the specification made between Java SE 7 and Java SE 8, including trivial changes such as corrections of typographical errors and misspellings, are indicated in Annex 2, where insertions are conveniently shown on a light green background and deletions are shown struck through on a light red background.
Significant features, enhancements, bug fixes, and clarifications are described in the following sections of this document.
Core Libraries | ||
User Interface | Tool Interface | |
Beans: Specify behavior on
null
argument for methods in PersistenceDelegate & DefaultPersistenceDelegateThe specification for all methods in java.beans.PersistenceDelegate and java.beans.DefaultPersistenceDelegate that have an encoder as a parameter was modified to throw a
NullPointerException
if the encoder isnull
. This is the complete list of methods: PersistenceDelegate.writeObject(), PersistenceDelegate.instantiate(), PersistenceDelegate.initialize(), DefaultPersistenceDelegate.instantiate(), and DefaultPersistenceDelegate.initialize().The bug associated with this change is 6412286.
Beans: Specify behavior on
null
argument for PropertyChangeEvent constructorThe specification of the java.beans.PropertyChangeEvent() constructor was modified to document the long-standing behavior for it to throw
IllegalArgumentException
if the bean that fired the event isnull
.The bug associated with this change is 7087429.
Beans: Re-write the BeanInfo interface
The specification of the java.beans.BeanInfo interface was entirely re-written to eliminate grammatically incorrect and confusing sentences. The intent of the specification was not changed.
The bug associated with this change is 7121905.
Collections: Update Collections
The following methods were added to java.util.Collections:
- java.util.Collections.emtpySortedSet() returns an immutable empty sorted set similar to the existing Collections.emptyList(), Collections.emptyMap(), and Collections.emptySet().
The enhancement associated with this change is 4533691.
- java.util.Collections.emtpyNavigableSet() returns an immutable empty navigable set similar to the existing Collections.emptyList(), Collections.emptyMap(), and Collections.emptySet().
- java.util.Collections.checkedQueue() returns a dynamically typesafe view of the specified queue.
The enhancement associated with this change is 5029031.
- Multiple methods for checked/empty/unmodifiable wrappers for the core collection interfaces java.util.SortedSet, java.util.SortedMap, java.util.NavigableMap, and java.util.NavigableSet were added. The complete list is as follows: java.util.Collections.checkedNavigableMap(), java.util.Collections.checkedNavigableSet(), java.util.Collections.emptyNavigableMap(), java.util.Collections.emptyNavigableSet(), java.util.Collections.emptySortedSet(), java.util.Collections.synchronizedNavigableMap(), java.util.Collections.synchronizedNavigableSet(), java.util.Collections.unmodifiableNavigableMap(), and java.util.Collections.unmodifiableNavigableSet().
The enhancement associated with this change is 7129185.
Collections: Add warning for some deep traversal operations
The interface specification for java.util.Collection and java.util.Map was refined to provide a warning that deep traversal operations on self-referential collections/maps may fail. While some implementations may optionally handle the self-referential scenario, most current implementations do not.
The bug associated with this change is 7057785.
Collections: Refine Collection.removeIf() UnsupportedOperationException conditions
The general description for java.util.Collection.removeIf() was refined to indicate that an
UnsupportedOperationException
will be thrown if removal is not supported or the particular matching element cannot be removed.The bug associated with this change is 8023339.
Collections: Add PriorityQueue(Comparator)
A new constructor, java.util.PriorityQueue(Comparator) was added to create a new PriorityQueue which orders its elements according to the specified comparator.
The enhancement associated with this change is 6799426.
Collections: Remove reference to Deque.push() return value
The specification for java.util.Deque.push() was updated to eliminate the phrase “returning true upon success” since the method has a void return type.
The bug associated with this change is 7178639.
Collections: Add in-place methods to Iterable, Collection, & List
Default methods java.lang.Iterable.forEach(), java.util.Collection.removeIf(), java.util.List.sort(), and java.util.List.replaceAll() were added to make operations over collections more concise for users of functional interfaces.
The enhancement associated with this change is 8001647.
Collections: Implement Parallel Array Sorting
Utility methods in java.util.Arrays that use the Fork/Join parallelism common pool to provide sorting of arrays in parallel were added. Sort method were defined for all primitive array types except
boolean
, Comparable object types, and arbitrary Object types using a supplied java.util.Comparator. The sorting algorithm is guaranteed to be stable for elements of reference types. New methods include java.util.Arrays.parallelSort(T[]) and java.util.Arrays.parallelSort(byte[]).Additional details may be found in JEP 103 Parallel Array Sorting.
The enhancements associated with this change are 8003981 and 8014076.
Collections: Add Arrays.parallelPrefix()
Eight overloads of java.util.Arrays.parallelPrefix() were added to cumulate, in parallel, each element of the given array in place, using the supplied function.
The enhancement associated with this change is 8012647.
I/O & NIO: Clarify Console.reader() behavior for line termination
The specification of java.io.Console.reader() was clarified to indicate that a line termination is required for characters to be returned. Prior to this change, the specification only said that characters beyond line termination weren’t returned per invocation.
The bug associated with this change is 6341345.
I/O & NIO: Clarify File attribute methods to describe behavior when run as a superuser
The specification for all java.io.File methods which set or query the read, write, or execute attributes (e.g. java.io.File.setReadOnly(), java.io.File.setWritable(), java.io.File.canExecute()) was updated to document the expected behavior when run as a superuser. Since the superuser may ignore these permissions, the results of invocation may not be predicted by the file’s actual permissions.
The bug associated with this change is 6931128.
I/O & NIO: Define behavior of AutoCloseable & Closeable when resources aren’t successfully released
An advisory note was added to java.lang.AutoCloseable (and a reminder in java.io.Closeable) to recommend that implementations release resources prior to throwing the exception. Following this advice means that resources will be released in a timely manner, particularly if used with try-with-resources. When multiple resources are involved, or one stream wraps another, this helps to keep the state of the resources synchronized.
The bug associated with this change is 7015589.
I/O & NIO: Update InputStream.skip() & FileInputStream.skip() to describe result for negative value
The java.io.InputStream.skip() specification was updated to indicate that subclasses may have different implementations for negative values. The java.io.FileInputStream.skip() specification was updated to describe the current long-standing behavior. The method will try to skip backwards but will throw an IOException if the backing file does not support backward skip. A negative value will be returned if it skipped backwards.
The enhancement associated with this change is 8011136.
I/O & NIO: Add methods to Files
JSR 335: Lambda Expressions for the Java Programming Language added the method java.nio.file.Files.lines(Path,Charset), to read lines of a text files as a Stream. A version of this method that has only the
Path
as a parameter, java.nio.file.Files.lines(Path), was added so that it may be used without method references. This method uses UTF-8 as the Charset for encoding and decoding.These four additional methods which also use UTF-8 as the Charset were added: java.nio.file.Files.newBufferedReader(Path), java.nio.file.Files.newBufferedWriter(Path,OpenOption…), java.nio.file.Files.readAllLines(Path), and java.nio.file.Files.write(Path,Iterable,OpenOption…).
The enhancement associated with this change is 8015314.
I/O & NIO: Update Files.move() to describe precision loss of last-modified-time
The specification of java.nio.file.Files.move() was updated to that the last-modified-time may be copied to the target file with some potential precision loss.
The enhancement associated with this change is 8006645.
java.lang: Update the primitive wrapper classes
The following changes were made to the primitive wrapper classes:
- Methods were added to java.lang.Byte, java.lang.Short, java.lang.Integer, and java.lang.Long to support unsigned integer arithmetic. The supported operations are unsigned text/numeric conversion, unsigned widening operations between integral formats, unsigned comparison, and unsigned divide and remainder on
int
andlong
.The enhancement associated with this change is 4504839.
- Methods to determine whether a floating-point value is finite were added to java.lang.Float and java.lang.Double.
The enhancement associated with this change is 7092404. This enhancement also added methods to java.lang.Math and java.lang.StrictMath as described in the Updates to Math & StrictMath.
- Static
hashcode()
methods were added to all of the of the primitive wrapper classes to calculate thehashCode
for the corresponding primitive type. The implementation of each is such that the following is always true:
Primitive.hashCode(primitive) == Primitive.valueOf(primitive).hashCode()The enhancement associated with this change is 7088913.
- The
BYTES
constant was added to all of the primitive wrapper classes to contain the smallest number of bytes necessary to represent the type. The value is calculated as follows:
Primitive.SIZE / Byte.SIZEThe enhancement associated with this change is 7088952.
- Methods
min()
,max()
, andsum()
were added to java.lang.Double, java.lang.Float, java.lang.Integer, and java.lang.Long. java.lang.Boolean was enhanced with the addition oflogicalAnd()
,logicalOr()
, andlogicalXor()
.The enhancement associated with this change is 8004201.
java.lang: Update String, StringBuilder, & StringBuffer
The following changes were made to String and related classes.
- A blanket
null
-handling statement was added to the class specifications of String, StringBuilder, and StringBuffer. All redundant@throws NullPointerException
clauses where removed.The bug associated with this change is 4247235.
- New methods String.join(CharSequence, CharSequence…) and String.join(CharSequence, Iterable) were added to suppport inserting a delimiter between concatenated elements of a provided
String
array. String.join() is the opposite of String.split().The enhancement associated with this change is 5015163.
- The specification of String.toLowerCase() and String.toUpperCase() was modified to recommend using java.util.Locale.ROOT to obtain locale insensitive Strings.
The bug associated with this change is 8023943.
- The specification of CharSequence.subSequence() was relaxed to no longer require creation of a new CharSequence, but still require mutable
CharSequences
to be independent. The specification of String.subSequence() was relaxed correspondingly.The bug associated with this change is 8028757.
- The specification of all methods in String which say or imply that a new String object is created was relaxed to no longer require String instance creation. This is the complete list of methods: String.concat(), String.valueOf(), String.replace(), String.subSequence(), String.substring(), and String.trim().
The bug associated with this change is 7174936.
- All String.copyValueOf() overloads were clarified to explicitly state that the method are identical to the corresponding String.valueOf() .
The bug associated with this change is 7174936.
- The incomplete and inconsistent specification in String.serialPersistentFields() was replaced with a reference to the serialization specification.
The bug associated with this change is 8028041.
java.lang: Update SecurityManager
- SecurityManager.checkMemberAccess() was deprecated in favor of the appropriate permission check. All specification which explicitly mentions invocation of this method were updated as necessary. This the complete list of methods: Class.getDeclaredField(), Class.getDeclaredFields(), Class.getDeclaredMethod(), Class.getDeclaredMethods(), Class.getEnclosingMethod(), Class.getEnclosingConstructor(), Class.getField(), Class.getFields(), Class.getMethod(), Class.getMethods(), Class.newInstance(), Class.getClasses(), Class.getConstructor(), Class.getConstructors(), Class.getDeclaredClasses(), Class.getDeclaredConstructor, Class.getDeclaredConstructors(), and java.lang.invoke.MethodHandles.Lookup().
Compatibility Note: The listed methods no longer invoke SecurityManager.checkMemberAccess(). If a custom
SecurityManager
overrides this method to do something other than the default implementation, the application may exhibit alternate behavior.- SecurityManager.checkTopLevelWindow(), SecurityManager.checkSystemClipboardAccess(), SecurityManager.checkAwtEventQueueAccess() were deprecated. All specification which explicitly mentions invocation of this method are updated to invoke SecurityManager.checkPermission() with an appropriate value. This is the complete list of methods: java.awt.Toolkit.getSystemClipboard(), java.awt.Toolkit.getSystemSelection(), java.awt.Toolkit.getSystemEventQueue(), java.awt.Window(Frame), java.awt.Window(Window), java.awt.Window(Windows,GraphicsConfiguration), and java.awt.Windows.getWarningString().
Compatibility Note: The listed methods no longer invoke the deprecated methods. If a custom SecurityManager overrides these methods to do something other than the default implementation, the application may exhibit alternate behavior.
The enhancement associated with this change is 8008981.
- Enhance the specification of methods which check java.awt.AWTPermission, SecurityManager.checkTopLevelWindow(), SecurityManager.checkSystemClipboardAccess(), and SecurityManager.checkAwtEventQueueAccess(). If AWT is not present as in the case of subset Profiles of Java SE, AllPermissions will be checked.
The bug associated with this change is 8008793.
java.lang: Retire Thread.stop(Throwable)
The implementation of Thread.stop(Throwable) was modified to always throw
UnsupportedOperationException
.Compatibility Note: All Thread.stop() methods are inherently unsafe as the cause threads to have objects in an inconsistent state or by handling Throwables that it was never intended to handle. This method has been deprecated since 1998 (Java SE 1.2) and research on Maven Central, grepcode.com, and other places has indicated that the method is relatively unused.
java.lang: Add ThreadLocal.withInitial()
A public static factory method, ThreadLocal.withInitial(java.util.function.Supplier) was added. The method returns an instance of ThreadLocal that obtains its initial value from a java.util.function.Supplier. Existence of this method enables initialization deferral and removes a layer of indirection when a Supplier is doing something like incrementing a serial number for each instance.
The enhancement associated with this change is 8003246.
java.lang: Implement mechanism to forcibly destroy a Process
Three new methods,
waitFor()
,destroyForcibly()
, andisAlive()
were added to the abstract class. These new methods provide the means to terminate the subprocess represented by the Process object.The enhancement associated with this change is 4244896.
java.lang: Update Math & StrictMath
The following changes were made to java.lang.Math and java.lang.StrictMath.
- Rounding: The specification of java.lang.Math.round(float), java.lang.Math.round(double), java.lang.StrictMath.round(float), and java.lang.StrictMath(double) was modified to be more precise when describing behavior for values midway between two mathematical integers. In all cases, for ties, rounding will now be “to positive infinity” instead of “up”. This is the complete list of methods: java.lang.Math.floorDiv(int,int), java.lang.Math.floorDiv(long,long), java.lang.Math.floorMod(int,int), java.lang.Math.floorMod(long,long), java.lang.StrictMath.floorDiv(int,int), java.lang.StrictMath.floorDiv(long,long), java.lang.StrictMath.floorMod(int,int), and java.lang.StrictMath.floorMod(long,long).
The bug associated with this change is 8010430.
- Div & Mod: Four static methods each to java.lang.Math and java.lang.StrictMath were added to support integer division that rounds to negative infinity and the corresponding modulus operation.
The enhancement associated with this change is 6282196.
- Support for exact arithmetic: Static methods were added to java.lang.Math and java.lang.StrictMath to support addition, subtraction, multiplication, conversion from
long
toint
, negation, increment, and decrement: java.lang.Math.incrementExact(int), java.lang.Math.decrementExact(int), java.lang.Math.negateExact(int), java.lang.Math.incrementExact(long), java.lang.Math.decrementExact(long), and java.lang.Math.negateExact(long). All exact methods throwArithmeticException
if the result is out of range.The enhancements associated with this change are 6708398 and 8022109.
- Next Down: Static methods were added to java.lang.Math and java.lang.StrictMath to return the floating-point value adjacent the argument in the direction of negative infinity: java.lang.Math.nextDown(double), java.lang.Math.nextDown(float), java.lang.StrictMath.nextDown(double), and java.lang.StrictMath.nextDown(float).
The enhancement associated with this change is 7092404. This enhancement also added methods to the wrapper classes java.lang.Float and java.lang.Double as described in Updates to the Primitive wrapper classes.
java.lang: Add new InternalError & VirtualMachineError constructors
Two new constructors supporting exception chaining were added to both InternalError and VirtualMachineError. This is the complete list of constructors: InternalError(String, Throwable), InternalError(Throwable), VirtualMachineError(String, Throwable), and VirtualMachineError(Throwable).
The enhancement associated with this change is 7080020.
java.lang: Support Native Libraries
The specifications for java.lang.System.Load(), java.lang.Runtime.load(), java.lang.System.loadLibrary(), and java.lang.Runtime.loadLibrary() were changed to describe how the native library will be located and statically linked. Additional conditions for throwing an
UnsatisfiedLinkError
were added.The enhancement associated with this change is 8005716.
java.lang: Clarify that support of
-javaagent
is not requiredThe java.lang.instrument specification was clarified to indicate that implementations with a command-line interface are not required to provide a way to start agents from the command-line.
The bug associated with this change is 8006565.
java.lang: Update LockInfo to remove ConstructorProperties annotation & add LockInfo.from()
The following changes were made to LockInfo.
- The java.beans.ConstructorProperties annotation from java.lang.management.LockInfo constructor was removed.
- A new static method LockInfo.from() was added. This method allows a LockInfo instance to be reconstructed in any JMX client running on JDK 6 or later release as it continues to confirm the specification of javax.management.MXBean.
These changes were necessary to remove an API dependency on java.beans.PropertyChangeListener which itself is tightly bound to areas of the platform such as applet, AWT, and Swing. This dependence makes it impossible to have a small footprint environment which does not include the entire client/desktop stack. This change was made in preparation for modules in a future release. For more information about changes for the modular platform see JEP 162 Prepare for Modularization.
The enhancement associated with this change is 7193302.
Reflection: Update Class
- Various Class methods did not correctly specify what they returned for array types. The long-standing behavior for these five methods was documented. Class.getIntefaces() returns Cloneable and Serializable in that order. Class.getMethod(), Class.getMethods(), Class.getDeclaredMethod(), and Class.getDeclaredMethods() does not return the clone() method.
The bug associated with this change is 4987375.
- The specification for Class.Method() and Class.Methods() was was aligned with the long-standing behaviour. Specifically these methods do not return any implicitly declared object methods that are not overridded in a superinterface.
The bug associated with this change is 8029117.
- Class.getField() and Class.getFields() did not include String[].length in their return values. The long-standing behavior for Class.getField() and Class.getFields() was documented to indicate that they do not return String[].length if the Class object represents an array type.
The bug associated with this change is 5047859.
- Class.toGenericString() was added for uniformity with other classes in core reflection. Class.getTypeName() was added to ease use of types. A default method, java.lang.reflect.Type.getTypeName(), was added.
The enhancement associated with these changes is 6298888.
- Class.getEnclosing*() were missing some access checks so the signatures of Class.getEnclosingClass(), Class.getEnclosingConstructor(), and Class.getEnclosingMethod() were all changed to throw SecurityException which may occur as a result of new invocations to SecurityManager.checkPackageAccess() and possibly SecurityManager.checkMemberAccess().
- Class.getDeclaredClass() was also missing some access checks. The signature of Class.getDeclaredClass was changed to throw SecurityException which may occur as a result of new invocation of SecurityManager.checkPackageAccess().
Reflection: Implement method parameter reflection
Several changes were necessary to implement parameter reflection.
- java.lang.reflect.Parameter class with 19 methods was added.
- A new method java.lang.reflect.Executable.getParameters() was added to return an array of Parameter objects representing the parameters of the method or constructor.
- A new JNI method
JVM_GetMethodParameters
was added to obtain method parameter data from the JVM if it exists.- java.lang.reflect.Modifier.parameterModifiers() was added similar to other methods in that class.
- The specification of these three methods in javax.lang.model.element.Element was refined to define behavior when the
Element
is aParameter
: Element.getSimpleName(), Element.getEnclosingElement(), Element.getModifiers().The enhancement associated with this change is 8004730.
Additional enhancements associated with this change are 8004729, 8007073, 8004728, 8007405, and 8014249.
Reflection: Update Proxy
The following changes were made to java.lang.reflect.Proxy.
- The java.lang.reflect.Proxy(InvocationHandler) specification was modified to throw a
NullPointerExcpetion
when passednull
.The enhancement associated with this change is 4487672.
- java.lang.reflect.Proxy.getInvocationHandler() was missing an access check so a
SecurityExcpetion
was added to the list of throwable exceptions.- Proxy classes that implement a non-public interface are now non-public, final, and not abstract. Proxy.getProxyClass() and Proxy.newProxyInstance() were missing some access checks so the signature of these methods was changed to throw SecurityException. A new java.lang.reflect.ReflectPermission of “newProxyInPackage.[package name]” was added to determine if Proxy.newProxyInstance() was invoked to create a proxy instance implementing a non-public interface.
Reflection: Add abstract superclass Executable
Common functionality of java.lang.reflect.Method and java.lang.reflect.Constructor is captured with the addition of java.lang.reflect.Executable which declares the 14 common methods. The declarations of Method and Constructor were modified to have Executable as their only direct supertype.
The enhancement associated with this is 7007535.
Reflection: Add GenericSignaturFormatError constructor
A new constructor, java.lang.reflect.GenericSignatureFormatError(String) was added.
The enhancement associated with this change is 7055295.
Reflection: Add missing access check to TypeVariable.getGenericDeclaration()
java.lang.reflect.TypeVariable.getGenericDeclaration() was missing an access check so the signature of the method was modified to throw a
SecurityException
.Reflection: Define Array.newInstance() maximum dimension
The specification of the two overloads of Array.newInstance() was modified to explicitly state that the number of array dimensions must not exceed 255. A
@throws IllegalArgumentException
will be thrown if an attempt is made to instantiate an array which exceeds this value.The bug associated with this change is 7044282.
Reflection: Add @Native annotation
A new annotation type, java.lang.annotation.Native was added so that constant fields annotated with
@Native
could be identified by tools which generate native header files.The bug associated with this change is 8000404.
Reflection: Add support for repeating annotations
Multiple changes were necessary to implement repeating annotations:
- java.lang.reflect.AnnotatedElement was enhanced by the addition of three new methods: getAnnotationsByType(Class) and getDeclaredAnnotationsByType(Class) which are annotation-aware and getDeclaredAnnotation(Class) which ignores inherited annotations in classes. These methods is declared to be a default method.
The enhancements associated with this change are 8007278 and 8005294.
- A new annotation
@Repeatable
was added via the associated interface, java.lang.annotation.Repeatable to indicate that the annotation type whose declaration it (meta-)annotates is repeatable.The enhancement associated with this change is 8005713.
- javax.lang.model.element.Element.getAnnotations() that behaves like java.lang.reflect.AnnotatedElement.getAnnotationsByType() was added.
The enhancements associated with this change are 7193719 and 8007279.
Additional details may be found in JEP 120 Repeating Annotations.
Additional enhancements associated with these changes are 8005712, 8008279, 7188442.
Reflection: Upgrade AnnotatedElement.isAnnotationPresent() to be a default method
The default method of java.lang.reflect.AnnotatedElement.isAnnotationPresent() was specified as follows:
getAnnotations(annotationClass) != nullThe enhancement associated with this change is 8007113.
Reflection: Clarify “present” & annotation ordering
The class documentation and the following six methods in AnnotationElement were updated to use better terminology to describe the presence of annotations as tested by different methods on the interface: isAnnotationPresent(), getAnnotation(Class), getAnnotations(), getAnnotationsByType(), getDeclaredAnnotation(), and getDeclaredAnnotationByType().
The enhancement associated with this change is 8010679.
Reflection: Update TypeVariable to extend AnnotatedElement
The declaration of the java.lang.reflect.TypeVariable interface was modified to extend AnnotatedElement.
The enhancement associated with this change is 7086192.
Reflection: Specify IncompleteAnnotationException constructor’s behavior on
null
inputjava.lang.annotation.IncompleteAnnotationException(Class,String) was modified to throw a
NullPointerException
when either parameter isnull
The bug associated with this change is 7021922.
Reflection: Modify declaration of GenericDeclaration
The declaration of java.lang.reflect.GenericDeclaration interface was modified to extend AnnotatedElement. All concrete implementations of
GenericDeclaration
already implementAnnotatedElement
.The enhancement associated with this change is 8014836.
Reflection: Modify model for the intersection type
A new javax.lang.model.type.IntersectionType was added as part of JSR 335: Lambda Expressions for the Java Programming Language to represent the upper bounds of a type variable. The specification of javax.lang.model.type.DeclaredType, javax.lang.model.type.IntersectionType, and javax.lang.model.type.TypeVariable were updates to replace older usage of javax.lang.model.type.DeclaredType to model the intersection types.
The bug associated with this change is 6657966.
java.lang.invoke: Specification maintenance
The following changes were made to align the specification with long-standing behavior.
- Adjust alignment between access checks for
CONSTANT_MethodHandle
and MethodHandles.Lookup.find* methods.- Add wildcard to raw type in
unreflectedConstructor()
parameter.- Clarify
@CallerSensitive
interactions- Clarify bytecode behavior and access checking
The bug associated with this change is 8024438.
java.lang.invoke: Specify behavior for method
"<init>"
The existing behavior of four methods in java.lang.invoke.MethodHandles.Lookup was documented. When Lookup.findStatic(), Lookup.findVirtual(), Lookup.findConstructor(), or Lookup.findSpecial() is invoked on a method named “<init>”a
java.lang.reflect.NoSuchMethodException
is thrown.The bug associated with this change is 8001108.
java.lang.invoke: Specify arity limits in MethodHandle and MethodHandles
Because of JVM limits on the arity of methods, any non-static method may have at most 254 arguments, for a total argument count of 255 (including receiver). The limit is lower if any of the argumetns are doubles or longs.
Updates were made to the following entities to specify arity limits for method arguments: java.lang.invoke.MethodHandle class specification and its methods MethodHandle.asSpreader() and MethodHandle.asCollector(), java.lang.invoke.MethodHandles.Lookup class specification and its methods Lookup.spreadInvoker(), Lookup.exactInvoker(), Lookup.invoker(), Lookup.dropArguments(), and Lookup.filterArguments().
The bug associated with this change is 8019417.
java.lang.invoke: Document behavior for method handle arity mismatch
The existing behavior of java.lang.invoke.MethodHandles.spreadInvoker() and java.lang.invoke.MethodHandle.asSpreader() was documented. An
IllegalArgumentException
is thrown when the passed array is of unexpected length. Anull
array is now considered a degenerate case so it also throws anIllegalArgumentException
instead of aNullPointerException
.The bug associated with this change is 8001109.
java.lang.invoke: Add MethodHandles.collectArguments()
java.lang.invoke.MethodHandles.collectArguments(mh pos, collector) was added to produce a method handle which acts as follows:
lambda(a*, b*, c*) { x = collector(b*); return mh(a*, x, c*)}Where the span of arguments
b*
is located bypos
and the arity of the collector.The enhancement associated with this change is 8001110.
java.lang.invoke: Upgrade MethodHandleInfo to public
java.lang.invoke.MethodHandleInfo was made a public interface containing 9 fields describing the reference kind and 8 methods to examine direct method handles. Methods handles that are not direct are left for the future. New methods MethodHandles.Lookup.revealDirect() which cracks a direct method handle and MethodHandles.Lookup.reflectAs() which acts as a bridge to core reflection were also added.
The enhancement associated with this change is 8008688.
java.lang.invoke: Remove specification requiring eager initialization in Lookup
Specification that demanded that java.lang.invoke.MethodHandles.Lookup.findStatic() and similar factory methods eagerly initialize were removed. Specification was added to affirms that the bytecode behavior, by stating that initialization happens when the method handle is invoked (if ever). This is the complete list of affected methods: Lookup.findStatic(), Lookup.findConstructor(), Lookup.findStaticGetter(), Lookup.findStaticSetter(), Lookup.unreflectConstructor(), Lookup.unreflectGetter(), and Lookup.unreflectSetter().
The bug associated with this change is 8024599.
java.math: Add exact primitive type conversion methods to BigInteger
Methods supporting exact conversion to primitives, java.math.BigInteger.byteValueExact(), java.math.BigInteger.shortalueExact(), java.math.BigInteger.intValueExact(), and java.math.BigInteger.longValueExact(), were added. All exact methods throw
ArithmeticException
if the result is out of range. These methods are similar to those which already exist for java.lang.BigDecimal.The enhancement associated with this change is 6879143.
java.math: Declare when BigDecimal.stripTrailingZeros returns BigDecimal.ZERO
The specification of java.math.BigDecimal.stripTrailingZeros() was augmented to state that BigDecimal.ZERO will be returned if the following is
true
:
BigDecimal.compareMagnitude(BigDecimal.ZERO) == 0The bug associated with this change is 6480539.
java.math: Define the range of values supported by BigInteger
The class specification of java.math.BigInteger was modified to declare the precise range of supported values. Attempts to construct a
BigInteger
outside of that range throw java.lang.ArithmeticException. The@throws ArithmeticException
of the BigInteger.probablePrime() and BigInteger. nextProbablePrime() methods was updated to indicate when these overflow conditions will occur.The bugs associated with this change are 6910473, 8021203, 8021204, and 80222780.
Concurrency: Add CountedCompleter & methods to ForkJoin{Pool,Task}
Modifications to java.util.concurrent.ForkJoinPool that allow them to be used more effectively were made. New features include support for completion-based designs that are often most appropriate for I/O bound usages, among others. Additions include a default ForkJoin common pool, markers/tags to ForkJoinTasks, and java.util.concurrent.CountedCompleter (a ForkJoinTask with a completion action performed when triggered).
Additional details may be found in JEP 155 Concurrency Updates.
The enhancement associated with this change is 8002356.
Concurrency: Add Scalable Updatable Variables
A small set of new classes (java.util.concurrent.atomic.DoubleAccumulator, java.util.concurrent.atomic.DoubleAdder, java.util.concurrent.atomic.LongAccumulator, and java.util.concurrent.atomic.LongAdder) were added which internally employ contention-reduction techniques that provide huge throughput improvements as compared to atomic variables. This was made possible by relaxing atomicity guarantees in a way which is acceptable to most applications.
Additional details may be found in JEP 155 Concurrency Updates.
The enhancements associated with this change are 8005311 and 8026344.
Concurrency: Add CompletableFuture
An implementation of java.util.concurrent.Future, java.util.concurrent.CompletableFuture, was added. It is used for
Futures
which may be explicitly completed and may include dependent functions and actions that trigger when completed. This change also included the introduction of java.util.concurrent.CompletionException and the marker interface java.util.concurrent.CompletableFuture.AsynchronousCompletionTask.Additional details may be found in JEP 155 Concurrency Updates.
The enhancement associated with this change is 8005696.
Concurrency: Add StampedLock
java.util.concurrent.locks.StampedLock was added. This class introduces a capability-based lock with three modes for controlling read/write access. The class provides more flexibility, and better performance in most cases over java.util.concurrent.locks.ReadWriteLock.
Additional details may be found in JEP 155 Concurrency Updates.
The enhancement associated with this change is 8005697.
Concurrency: Update ConcurrentHashMap
Changes to java.util.concurrent.ConcurrentHashMap and java.util.concurrent.ConcurrentHashMap.KeySetView include the following:
- A view of ConcurrentHashMap as a java.util.Set of keys and a new public type java.util.concurrent.ConcurrentHashMap
- Methods to support sequential and parallel bulk operations
- Overrides of default java.util.Map methods
- Clarifications around internal sizing, load factor, and concurrency
Additional details may be found in JEP 155 Concurrency Updates and JEP 107 Bulk Data Operations for Collections.
The enhancement associated with this change is 8005704.
Concurrency: Refine Atomic*FieldUpdater.newUpdater() RuntimeException conditions
The specification for java.util.concurrent.atomic.AtomicIntegerFieldUpdater.newUpdater(), java.util.concurrent.atomic.AtomicLongFieldUpdater.newUpdater(), and java.util.concurrent.atomic.AtomicReferenceFieldUpdater.newUpdater() was updated to document the wrapped access-control exceptions that can be thrown if the field to be updated is not accessible to the caller.
The bug associated with this change is 7103570.
Concurrency: Support ForkJoinPool parallelism
The specification of property
java.util.concurrent.ForkJoinPool.common.parallelism
was relaxed to allow it to be set to0
. This setting removes sharing of a static common pool of threads which may be undesirable. If this property is set to0
, then the tasks submitted to the pool are executed by the submitting thread.java.util.concurrent.ForkJoinPool.awaitQuiescence() was added to provide a notification mechanism for any program that relies on asynchronous task processing to complete before program termination.
The enhancement associated with this change is 8008378.
Concurrency: Remove padding fields from ThreadLocalRandom serial form
The serialized form of java.util.concurrent.ThreadLocalRandom incorrectly included eight padding fields
pad[0-7]
since they weren’t declaredtransient
. They were removed. Hence they will be set to a default value of0L
since they will not be explicitly set during object reconsititution.The bug associated with this change is 8006409.
The following changes have been made in the java.util package, in addition to changes detailed elsewhere in this document.
java.util: Add Objects.requireNonNull()
java.util.Objects.requireNonNull() was added to check that the specified object reference is not
null
otherwise it throws a customizedNullPointerException
.The enhancement associated with this change is 8011800.
java.util: Update Formatter
The following changes were made to Formatter.
- The conversion table description for %a for floating-point arguments was modified to more forcefully state that it is not supported for BigDecimal.
The bug associated with this change is 5035569.
- The specification for the optional
width
was aligned with the implementation to require that it always be positive rather than non-negative.The bug associated with this change is 6178739.
- Specification for how the precision field is handled for formatting subnormal doubles as hexadecimal was added. Formerly, precision for
'a'
and'A'
was not supported.The bug associated with this change is 6476168.
java.util: Support Base64 Encoding & Decoding
A simple utility class, java.util.Base64, was added to provide support for base64 encoding and decoding. This supported API replaces all unsupported (or internal) APIs in the JDK which provide similar functionality including
sun.misc.BASE64Encoder
,sun.misc.BASE64Decoder
,com.sun.org.apache.xml.internal.security.util.Base64
, andcom.sun.net.httpserver.Base64
. Existing usages and implementation of Base64 in the JDK and user applications should be examined for opportunities to replace and use this new API.Additional details may be found in JEP 135 Base64 Encoding & Decoding.
The enhancements associated with this change are 4235519, 8025003, 8026330, and 8028397.
java.util: Add StringJoiner
A new java.util.StringJoiner class was added. It may be used to construct a sequence of characters separated by a delimiter. Support for an optional prefix and/or suffix is provided. This class supports the new String.join() methods.
The bug associated with this change is 7172553.
java.util: Clarify ServiceLoader.iterator()
The specification for java.util.ServiceLoader.iterator() was clarified to further explain the order the
Iterator
locates resource files.Additionally notes were added to both java.lang.ClassLoader.getResource() and java.lang.ClassLoader.getResources() suggesting that subclasses needing to override one method consider overriding the other method to keep them consistent with each other.
The enhancement associated with this change is 8024704.
java.util: Update Properties.{loadFrom,storeTo}XML to only require UTF-8 and UTF-16
The specification for java.util.Properties.storeToXML() and java.util.Properties.loadFromXML() was amended to only require implementations to support UTF-8 and UTF-16. Implementations may support other encodings. These changes are consistent with the XML specification. Additionally, these methods will throw a java.io.UnsupportedEncodingException when an unrecognized encoding is encountered.
These changes were made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization.
java.util: Inherit behavior on
null
argument for AbstractPreferences.remove()java.util.prefs.AbstractPreferences.remove(String) was modified to inherit the specification for
@throws NullPointerException
from java.util.prefs.Preferencs.remove(String).The bug associated with this change is 7165118.
Logging: Deprecate LogManager.{add,remove}PropertyChangeListener
Two methods, java.util.logging.LogManager.addPropertyChangeListener() and java.util.logging.LogManager.removePropertyChangeListener() were deprecated. These methods create an API dependency on java.beans.PropertyChangeListener which itself is tightly bound to areas of the platform such as applet, AWT, and Swing. This dependence makes it impossible to have a small footprint environment which does not include the entire client/desktop stack. This change was made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization. They will be removed when the platform is modularized.
The enhancement associated with this change is 7192274.
Logging: Enhance resource bundle handling
The documented temporary solution for locating resource bundles was replaced by the following APIs:
- The class specification for java.util.logging.Logger was enhanced to describe how a java.util.ResourceBundle for logging is set, mapped, and located.
- A new method, java.util.logging.Logger.setResourceBundle(), was added to allow applications to set a java.util.ResourceBundle. The method requires the
LoggingPermission("control")
permission.- Two new overloads of java.util.logging.Logger.logrb() which have specify a java.util.ResourceBundle parameter as the resource bundle were added.
- The four old
Logger.logrb()
overloads which specify the resource bundle as aString
were deprecated in favor of the newly added overloads.- Add java.util.ResourceBundle.getBaseBundleName().
The enhancement associated with this change is 8013839.
Logging: Update for anonymous logger support
The specification for the two java.util.logging.Logger.getAnonymousLogger() methods was updated to document the long-standing behaviour that requires
LoggingPermission("control")
forLogging.setParent()
to succeed. The specification of the existingSecurityException
for the following methods was updated to indicate that it would be thrown if the calling thread does not haveLoggingPermission("control")
: java.util.logging.Logger.addHandler, java.util.logging.Logger.removeHandler, java.util.logging.Logger.setFilter, java.util.logging.Logger.setLevel, java.util.logging.Logger.setResourceBundle, and java.util.logging.Logger.setUseParentHandler.Logging: Modify specification of handler to require fully qualified class names
The specification for each of the handler implementations (java.util.logging.ConsoleHandler, java.util.logging.FileHandler, java.util.logging.MemoryHandler, java.util.logging.SocketHandler, and java.util.logging.StreamHandler) was modified to clearly state that properties are named using the fully-qualified class name of the handler.
The bug associated with this change is 7159567.
Logging: Remove stack search of resource bundle for a Logger
The java.util.logging.Logger class specification was updated to remove the “temporary transition feature” of searching up the class stack using successive
ClassLoaders
to locate a java.util.ResourceBundle. Now only the Thread’s context ClassLoader and the system ClassLoader are used. All non-normative text describing the stack search was also removed.Logging: Downgrade references to
${java.home}/lib
The reference to
${java.home}
in the file location oflogging.properties
in java.util.logging.LogManager was updated to provide an informative, rather than normative, reference so that file may be re-located. This change was made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization.Additionally, specification indicating that the Preferences API may be used to load the default configuration has been removed as this has never been true.
The enhancement associated with this change is 8003949.
Regular Expressions: Add five Perl regular expression constructs
The following fives pre-defined Perl regular expression character classes were added:
'\h'
matches any horizontal whitespace character'\H'
matches any character not considered horizontal whitespace'\v'
matches any vertical whitespace character'\V'
matches any character not considers vertical whitespace'\R'
matches all line ending characters and sequencesAdditional details may be found in JEP 111 Additional Unicode Constructs for Regular Expressions.
The bug associated with this change is 7014640.
Regular Expressions: Add two convenience methods to Matcher
java.util.regex.Matcher.start(String) and java.util.regex.Matcher.end(String) were added to provide a more detailed group name-based match result.
The bug associated with this change is 8013252.
Regular Expressions: Specify corner-case behaviours for Pattern.split() and Patter.splitAsStream()
The specification java.util.regex.Pattern.split() and java.util.regex.Pattern.splitAsStream() was extended to define behaviour for zero-length input sequences and positive-width/zero-width match at the beginning of the input stream.
The bug associated with this change is 8027645.
These are the changes relating to internationalization support, primarily in the java.util and java.text packages and in java.lang.Character.
Internationalization: Support Unicode 6.2.0
The supported version of the Unicode standard for Character and String was changed from 6.0.0 to 6.2.0. As a result, 11 new constants were added to java.lang.Character.UnicodeBlock and seven enums were added to java.lang.Character.UnicodeScript. The majority of the changes occurred when updating to 6.1.0 since changes for 6.2.0 support were small.
Additional details may be found in JEP 133 Unicode 6.2.
The enhancements associated with this change are 7070436 and 7198195.
Internationalization: Update Calendar
The following changes were made to java.util.Calendar.
- A new inner class, java.util.Calendar.Builder, was added to support construction of java.util.Calendar objects with various parameters. The new class contains 14 methods which support method chaining as the means to create the target object. A static method, java.util.Calendar.getAvailableCalendarTypes(), was also added to verify the specified calendar type in the
Builder
. This class may be used for conversions from JSR 310: Date & Time API objects to java.util.Calendar objectsThe enhancement associated with this change is 4745761.
- Support for context-dependent month names for languages which require different stand-alone and embedded format forms was added via the following changes:
- The display name support was extended so that stand-alone and embedded format forms may be specified.
- The default month names and abbreviations in java.text.DateFormatSymbols was changed from stand-alone to embedded format as necessary.
- The interpretation of the java.text.SimpleDateFormat pattern specifier
'M'
was modified to be context sensitive. The stand-alone form will only be used for month-name-only patterns, such as"MMMM"
.- A new java.text.SimpleDateFormat pattern specifier
'L'
was added for stand-alone form.The enhancement associated with this change is 7079560.
- A methods to return the calendar type as defined by the Unicode Locale Data Markup Language (LDML) specification were added: java.util.Calendar.getCalendarType() and java.util.GregorgianCalendar.getCalendarType().
The enhancement associated with this change is 7151414.
- Support for narrow display names for java.util.Calendar fields of era, month, day-of-week, etc. was added. Narrow names are typically single character strings, such as
"M"
forMonday
. Constants forjava.util.Calendar.NARROW_FORMAT
andjava.util.Calendar.NARROW_STANDALONE
were added. Methodsjava.util.Calendar.getDisplayName()
,java.util.Calendar.getDisplayNames()
,java.util.spi.CalendarNameProvider.getDisplayName()
, andjava.util.spi.CalendarNameProvider.getDisplayNames()
were modified to include the new constants as acceptable parameters.The enhancement associated with this change is 8000983.
- Two methods,
getFirstDayOfWeek()
andgetMinimumDaysInFirstWeek()
, were added to java.util.spi.CalendarDataProvider. These methods are locale-dependent on country.The enhancement associated with this change is 7058206.
- A new class java.util.spi.CalendarNameProvider with two methods was added This class contains which is dependent on the language.
The enhancements associated with this change are 7058206. and 8000986.
- Support for Minguo (Taiwan) and Hijrah (Islamic) calendars was added. Era names of the additional calendars was added to java.util.spi.CalendarNameProvider.
The enhancement associated with this change is 8004489.
Internationalization: Update Locale
The following changes were made to java.util.Locale.
- Support was provided for Unicode Common Locale Data Repository (CLDR) which contains XML-based locale data that are agreed upon by major entities in the world. A locale data adapter which reflects both the underlying operating system’s locale data and the current user’s customizations on the underlying operating system’s settings was provided. The search order of locale-sensitive services may be configured using the
java.locale.providers
system property.Additional details may be found in JEP 127 Improve Locale Data Packaging and Adopt Unicode CLDR Data.
The enhancements associated with this change are 6336885 and 8013903.
- Support for BCP47 locale matching as defined in RFC 4647 was provided. This support was accomplished via the addition of new static method in java.util.Locale for filtering and lookup. Also, a nested class (java.util.Locale.LanguageRange) and an enum (java.util.Locale.FilteringMode), were added to support language ranges and filtering behavior.
Additional details may be found in JEP 128 BCP 47 Locale Matching.
The enhancement associated with this change is 6336885.
- Clarification of the default locale for each locale-sensitive operation was provided. This affected java.util.Formatter, java.util.Scanner, java.util.Locale, java.util.Calendar, java.util.GregorianCalendar, java.time.format.DateTimeFormatSymbols, and most classes in java.text. The typical change was to modify references to “the default locale” to “the default java.util.Locale.Category.FORMAT locale”.
The bug associated with this change is 7092447.
- The LocaleServiceProvider was made aware of Locale extensions by changing its lookup mechanism with the following changes:
- A method java.util.spi.LocaleServiceProvider.isSupportedLocale(Locale) was added so that the provider may programmatically determine whether a given Locale, including extensions, is supported. The default implementation of this new method is compatible with the pre-existing provider look-up.
- The class specification for java.util.spi.LocaleServiceProvider and subclasses java.text.spi.DecimalFormatSymbolsProvider was enhanced to include Locale extension support requirements, such as numeric systems.
- java.util.Locale.hasExtensions() and java.util.Locale.stripExtensions() were added to manipulate extensions.
The enhancement associated with this change is 7168528.
Internationalization: Support for multiple sets of digits & symbols per Locale
The specification for java.text.DecimalFormatSymbols(Locale) and java.text.DecimalFormatSymbols.getInstance(Locale) was augmented to allow passing different numbering system information as a Unicode extension in the
Locale
argument.For instance, this may be used to obtain an Arabic number format instance in the Latin numbering system:
NumberFormat.getNumberInstance(Locale.forLanguageTag("ar-EG-u-nu-latn"))to use an Arabic numbering system, this code should be used:
NumberFormat.getNumberInstance(Locale.forLanguageTag("ar-EG-u-nu-arab"))The enhancement associated with this change is 7073852.
Internationalization: Change computation of default time zone
A new system property
user.timezone
was introduced to hold the value of the default time zone ID if it’s available. In java.util.TimeZone.getDefault(), the algorithm to determine the default was defined. java.util.TimeZone.setDefault() was missing an access check so the signature of the method was modified to throw aSecurityException
.Compatibility Note: Existing code which attempts to invoke
TimeZone.setDefault()
may not always succeed as it did in past releases.Internationalization: Support generic time zone names in TimeZoneNameProvider
Generic time zone names are standard/daylight savings time neutral, for example “Pacific Time” is a generic name of “America/Los_Angeles”. A new method java.util.spi.TimeZoneNameProvider.getGenericDisplayName() was added to return the required string which is suitable for presentation to the user. The default of this implementation returns
null
.The feature associated with this change is 8003267.
Internationalization: Update Currency
The following changes were made to java.util.Currency and associated support for currency.
- Optional cutover dates to indicate when a currency change may come into effect were implemented in
${java.home}/lib/currency.properties
. The date is specified as a UTC timestamp in this ISO 8601 format:'yyyy-MM-dd'T'HH:mm:ss'
. The timestamp is placed at the end of the property describing the affected currency. If the entry is duplicated or syntactically malformed, it will be ignored and the remaining entries in the file will be processed.The enhancement associated with this change is 7180362.
- The system property
java.util.currency.data
was added to identify the location of a properties file to override the currency data. If the property is undefined,${java.home}/lib/currency.properties
should be consulted as before.This change was made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization.
The enhancement associated with this change is 8003846.
Internationalization: Specify thread-safety for {List,Property}?ResourceBundle
The class specification for java.util.ResourceBundle, java.util.ListResourceBundle, and java.util.PropertyResourceBundle was enhanced to indicate that default implementations of all non-abstract methods in the class are thread-safe. Furthermore, any implementations of those classes must also be thread-safe.
The bug associated with this change is 8028368.
Internationalization: Add conditions for throw IllegalArgumentException in PropertyResourceBundle constructors
The specification of java.util.PropertyResourceBundle(InputStream) and java.util.PropertyResourceBundle(Reader) was updated to say that an
IllegalArgumentException
will be thrown if the argument contains a malformed Unicode escape sequence.The bug associated with this change is 6251788.
Internationalization: Add ResourceBundle.Control global binding support
A new SPI for service providers, java.util.spi.ResourceBundleControlProvider, was added to enable load via service-loader by
ResourceBundle.Control
implementations. Additional changes were made to the specifications of the ResourceBundle class and java.util.ResourceBundle(String,Locale,ClassLoader) to include potential customizations of resource bundle loading via the new SPI.The enhancement associated with this change is 6380549.
Networking: Remove SocketException from DatagramPacket constructor declaration
The specifications for java.net.DatagramPacket(byte[],int,int.SocketAddress) and java.net.DatagramPacket(SocketAddress) wer updated remove
@throws SocketException
from the declaration. It was incorrectly added to these constructors when they were originally introduced. The condition for throw results in the uncheckedIllegalArgumentException
.Compatibility Note: While this change is binary- but not source-compatible, current practice suggests that its impact will be minor.
The bug associated with this change is 8022126.
Networking: Update URL
The following changes were made to java.net.URL and associated support for URLs (e.g. java.net.URLStreamHandler) and protocols.
- The two overloads of URL.set() were declared package-private. They were effectively package visible because java.net.URL was declared
final
. Also, the deprecation message of the two overloads of URLStreamHandler.setURL() was modified to say that “Only classes derived from URLStreamHandler are able to use the method…” rather than “Only classes derived from URLStreamHandler are supposed to be able to use the method”.Note that this change will result in these methods no longer appearing in the API specification.
The bug associated with this change is 4880778.
- The legacy protocol handler, ftp, was removed from the list of required protocol handlers as listed in java.net.URL(String,String,int,String) and java.net.ProxySelector.select(URI).
The bug associated with this change is 8000941.
- The reference in java.net.URLConnection.getFileNameMap() to
${java.home}
was updated to not specify where thedefault/built-in
MIME table is loaded from. This change was made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization.The class specification’s historical note regarding releases prior to JDK 1.1.6 was also removed.
The bug associated with this change is 8004963.
- In java.net.HttpCookie(String,String), the specification was relaxed to say that reserved keywords are not illegal. This aligns the specification with the long-standing behavior.
The bug associated with this change is 7188517.
- The class java.net.URLPermission was added to provide the ability to manage network permissions. Each permission contains a URI which identifies the applicable resource(s), a list of HTTP request methods that are permitted, and a list of HTTP request headers that are permitted.
URLPermission
has capabilties similar to java.net.SocketPermission including the support for wildcard hostnames and port ranges. The class specification describes how the new permission is used.Additional details may be found in JEP 184 HTTP URL Permissions.
The enhancements associated with this change are 8010464, 8014718. and 8029354.
Networking: Specify URLClassLoader behaviour on
null
inputThe specification for all the constructors and several methods in java.net.URLClassLoader was modified to throw a
NullPointerException
when some parameters arenull
. The complete list is as follows: URLClassLoader(URL[]), URLClassLoader(URL[],ClassLoader), URLClassLoader(URL[],ClassLoader,URLStreamHandlerFactory), URLClassLoader.newInstance(URL[]), URLClassLoader.newInstance(URL[],ClassLoader), URLClassLoader.findClass(String), and URLClassLoader.getPermissions(CodeSource).The bug associated with this change is 7179567.
Networking: Update Socket{Impl?}.shutdownInput()
The specifications for java.net.Socket.shutdownInput() and java.net.SocketImpl.shutdownInput() were updated to indicate how the underlying stream’s available() and read() methods will behave. In both classes, available() will return
0
and read() will return-1
(end of stream).The bug associated with this change is 7014860.
Networking: Enhance client socket binding
Client socket binding was enhanced via the following changes:
- The class specification for java.net.SocketPermission(), was updated to re-define the “listen” action to refer to generally binding to a specified port. It also designates port value
0
for use as the reference to ephemeral ports. It is up to theSocketPermission
itself to determine the actual ephemeral port range based on system-dependent information.- In java.lang.SecurityManager.checkListen(), references to special case handling for port
0
were removed.- In the specification for java.net.Socket(InetAddress,int), java.net.Socket(InetAddress,int,InetAddress), and java.net.Socket.bind(SocketAddress), the conditions for the existing
SecurityException
were enhanced to indicate that the permission “checkListen” would be consulted.Networking: Add access check for all methods which retrieve the machine’s local address
The specification of all methods in java.net and java.nio (such as java.net.Socket.getLocalAddress() and java.nio.channels.SocketChannel.getLocalAddress() was updated to throw a
SecurityException
if the permission to “resolve” the localhost address is not granted.The bug associated with this change is 7014860.
Networking: Remove requirement of external networking
The specification of java.net.NetworkInterface.getNetworkInterfaces() was clarified to indicate that at least one
NetworkInterface
will always be returned however it make be a loopback interface. This implies that that external networking is not supported.The enhancement associated with this change is 7120665.
Networking: Update SSL protocol support
The following changes were made to javax.net.ssl.
- A new system property,
jsse.enableCBCProtection
with default valuetrue
was introduced to disable implementation enhancements which protect against cipher block chaining. This change also updated the specification of javax.net.ssl.SSLEngine.wrap() to say that the method will produce multiple SSL/TLS records (rather than one as previously stated).- Support for Server Name Indication (SNI) extension was provided. This allowed HTTPS servers to be virtually hosted in cases where multiple domains share the same IP address. The following changes accomplished this:
- A class, javax.net.ssl.StandardConstants, providing the
SNI_HOST_NAME
constant was added.- An abstract class, javax.net.ssl.SNIServerName, representing a server name was added.
- An abstract class, javax.net.ssl.SNIMatcher, which allows match operations on an SNIServerName was added.
- A new final class, javax.net.ssl.SNIHostName, which represents a server name of type
StandardConstants.SNI_HOST_NAME
was added.- A new method javax.net.ssl.ExtendedSSLSession.getRequestedServerNames() was added to obtain a java.util.List containing all SNIServerNames of the requested SNI extension.
- The existing class, javax.net.ssl.SSLParameters, was updated to include an SNI in the class specification’s list of parameters it encapsulates for an SSL/TLS connection. Additional changes include adding the server names and matchers to the set of values initialized to
null
tojavax.net.ssl.SSLParameters()
, and adding the following new final methods:javax.net.ssl.SSLParameters.setServerNames()
,javax.net.ssl.SSLParameters.getServerNames()
,javax.net.ssl.SSLParameters.setSNIMatchers()
, andjavax.net.ssl.SSLParameters.getSNIMatchers()
.- A new method javax.net.ssl.SSLSocketFactory.createSocket(Socket, InputStream, boolean) to create a server mode Socket layered over an existing connection socket.
- Modify the specifications of javax.net.ssl.SSLEngine.setSSLParameters(), javax.net.ssl.SSLServerSocket.setSSLParameters(), and javax.net.ssl.SSLSocket.setSSLParameters() to define how the SNI server name and matcher will be initialized.
Additional details may be found in JEP 114 TLS Server Name Indication (SNI) Extension.
The enhancements associated with this change are 7068321 and 8000954.
- The specification of javax.net.ssl.HttpsURLConnection.setSSLSocketFactory() was updated to throw a
SecurityException
if the SecurityManager.checkSetSecurity() does not allow a socket factory to be specified.The bug associated with this change is 6096936.
- The specification of javax.net.ssl.SSLContext was updated to remove typos such as changing “TrustManagerFactorySpi” to “SSLContextSpi” in the
@throws NoSuchAlgorithmException
ofSSLContext.getInstance(String)
and replacing “KeyManagerFactorySpi” with “SSLContextSpi” inSSLContext.getInstance(String,Provider)
.- The ability for the server side to select the cipher suites based on their preferences rather than the client’s preference was provided. The main changes were new methods javax.net.ssl.SSLParameters.setUseCipherSuitesOrder() and javax.net.ssl.SSLParameters.getUseCipherSuitesOrder().
The bug associated with this change is 7188657.
JAR & ZIP APIs: Update Pack200.{Packer,Unpacker}.{add,remove}PropertyChangeListener
Two key changes were applied to four methods, java.util.jar.Pack200.Packer.addPropertyChangeListener(), java.util.jar.Pack200.Packer.removePropertyChangeListener(), java.util.jar.Pack200.Unpacker.addPropertyChangeListener(), and java.util.jar.Pack200.Unpacker.removePropertyChangeListener().
- They were deprecated.
The enhancement associated with this change is 8000362.
- They were changed to default methods. The default implementation does nothing and has no side-effects.
The enhancement associated with this change is 8004931.
These methods create an API dependency on java.beans.PropertyChangeListener which itself is tightly bound to areas of the platform such as applet, AWT, and Swing. This dependence makes it impossible to have a small footprint environment which does not include the entire client/desktop stack. This change was made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization. They will be removed when the platform is modularized.
JAR & ZIP APIs: Update Adler32 & CRC32
The following changes were made to the classes which compute checksums, java.util.zip.Adler32 and java.util.zip.CRC32.
- Two methods were added to compute the Adler32 and CRC checksums for ByteBuffers. The addition of java.util.zip.Adler32.update(ByteBuffer) and java.util.zip.CRC32.update(ByteBuffer) allows applications to avoid the need to copy the content of the ByteBuffer into a
byte []
.- The specification of java.util.zip.CRC32.update(byte[],int,int) and java.util.zip.Adler32.update(byte[],int.int) was modified to describe conditions for the long-standing behavior to throw
ArrayIndexOutOfBoundsException
.The enhancement associated with this change is 7154662.
RMI: Allow activation to be optional
A total of 23 methods and constructors in the java.rmi.activation package were modified to throw an unchecked
UnsupportedOperationException
if activation is not supported by the implementation. If activation is supported, its operation is unchanged. This change was made in preparation for modules in a future release.The enhancement associated with this change is 8023447.
RMI: Enhance CORBA initialization
Initialization of third-party ORBs via org.omg.CORBA.ORB.init() now uses the system class loader. When an alternative ORB (org.omg.CORBA.ORBClass) or alternative (org.omg.CORBA.ORBSingletonClass) is specified, those third-party classes must reside on the application
CLASSPATH
.Compatibility Note: Significant information on how third-party ORBs are deployed in conjuction with JDK is lacking; however, there is some evidence that some legacy applications may need some re-configuration to include the ORB in the
CLASSPATH
.RMI: Deprecate unused/obsolete APIs
These unused or obsolete API classes in RMI were deprecated:
- The class java.rmi.RMISecurityManager in favor of java.lang.SecurityManager.
- The class java.rmi.server.SocketSecurityException in favor of java.rmi.server.ExportException.
- The obsolete interface java.rmi.server.ServerRef.
The enhancement associated with this change is 8026427.
RMI: Deprecate HTTP proxing from RMI (JRMP)
The HTTP proxying/tunneling mechanism for RMI/JRMP (not RMI IIOP for CORBA) as described in the package specification of java.rmi.server and the class specification of java.rmi.server.RMISocketFactory was deprecated. This mechanism can result in unexpectedly long time-outs and didn’t adequately enable processing for RMI requests through firewalls. Tunneling has been disabled by default via the system property
java.rmi.server.disableHttp
.The enhancement associated with this change is 8023862.
RMI: Deprecate static stub generation for RMI (JRMP)
Support for statically-generated stubs from RMI/JRMP was deprecated as described in the package specification of java.rmi.server, the entire class specification of java.rmi.server.RemoteStub, and portions of java.rmi.server.UnicastRemoteObject. Since RMI stubs have been generated dynamically since Java SE 5.0, static gerneration is unencessary and potentially confusing to new users. Deprecation also includes runtime support for static stubs and runtime support for RMI skeletons (the skeleton APIs were deprecated in a previous release).
The class specification of java.rmi.server.UnicastRemoteObject was re-factored to separate descriptions about the static/dynamic stub aquisition and selection between static and dynamic stubs.
Also included in this change was re-organization of some specification regarding socket factories and clarification of
null
for client and server socket factory parameters.The enhancement associated with this change is 8023863.
Security: Implement Limited doPrivileged
Methods were added to java.security.AccessController to enable code to assert a subset of its privileged without otherwise preventing full access-control stack walk to check for other permissions. The new
doPrivileged()
method variant, java.security.AccessController.doPrivileged(PrivilegedAction, AccessControlContext,Permission), takes a variable number of Permission arguments which are used to test whether the usual access control stack walk for the permission being checked should stop at the method or continue as if thedoPrivileged()
method had not been invoked. For consistency with existingdoPrivileged()
methods, three additional variants with a variable number of Permissions as the final argument were also added.Additional details may be found in JEP 140 Limited doPrivileged.
The features associated with this change are 8014097 and 8021191.
Security: Enhance KeyStore API
The KeyStore API was enhanced with several goals in mind:
- Facilitate migrating data from JKS and JCEKS keystores by adding equivalent support to the PKCS#12 keystore.
- Enhance the KeyStore API to support new features such as entry metadata and logical views spanning several keystores.
- Enable the strong crypto algorithms introduced in JEP 121 (Stronger Algorithms for Password-Based Encryption) to be used to protect keystore entries.
The following changes were made:
- These changes were made to support metadata for KeyStore entries:
- The interface java.security.KeyStore.Entry.Attribute was added to contain a
keystore
entry.- The method java.security.KeyStore.Entry.getAttributes() was added to retrieve the attributes associated with the entry.
- New constructors java.security.KeyStore(SecretKey, Set), java.security.KeyStore.PrivateKeyEntry(PrivateKey, Certificate90, Set), and java.security.KeyStore.TrustedCertificateEntry(Certificate, Set) were added.
java.security.PKCS12Attribute
representing an attribute associated with a PKCS12 keystore entry was added.- To support stronger entry protection algorithms a constructor java.security.KeyStore.PasswordProtection() and two methods (java.security.KeyStore.PasswordProtection.getProtectionAlgorithm() and java.security.KeyStore.PasswordProtection.getProtectionParameters()) were added.
- These changes were made to support the destruction of sensitive key information:
- Default method implementations were specified for javax.security.auth.Destroyable.destroy() and javax.security.auth.Destroyable.isDestroyed().
- The java.security.PrivateKey and javax.crypto.SecretKey interface declarations were updated to extend Destroyable.
- To support the logical grouping of keystores and entries a new class, java.security.DomainLoadStoreParameter was added.
Additional details may be found in JEP 166 Overhaul JKS-JCEKS-PKCS12 Keystores.
The features associated with this change are 8005408 and 8008171.
Security: Improve support of high entropy random numbers
The API for secure random-number generation was enhanced so that it can be configured to operate within specified quality and responsiveness constraints. This following changes were applied:
- A new method, java.security.SecureRandom.getInstanceStrong() which allows developers to receive an instance of a strong
SecureRandom
implementation as defined by the system-wide security property,securerandom.strongAlgorithms
, was added. SecureRandom.getInstanceStrong() requires at least one implementation.- The
java.security
file containing security property settings was re-written to eliminate incorrect information.Additional details may be found in JEP 123 Configurable Secure Random-Number Generation.
The features associated with this change are 8014838 and and 8025694.
java.security: Relax CodeSource.implies() check order
All references to specific check ordering were removed from java.security.CodeSource.implies(). For instance, the list of numbered checks are now a an unordered sequence of bullet points, and references to “in order” were dropped.
The bug associated with this change is 2222762.
Security: Clarify invalid input in BasicPermission
The specification of java.security.BasicPermission and several subclasses including java.net.NetPermission, java.util.PropertyPermission, and java.lang.RuntimePermission was clarified to say that non-matching wildcards do not constitute an invalid input.
This updated text from java.lang.RuntimePermission is typical of the modifications “Also, an asterisk may appear at the end of the name, following a “.”, or by itself, to signify a wildcard match. For example: “loadLibrary.*” and “*” signify a wildcard match, while “*loadLibrary” and “a*b” do not.”
The bug associated with this change is 7167056.
Security: Add SecurityPermission “insertProvider”
A new “insertProvider” SecurityPermission target name was added. The specification of java.security.Security.addProvider and java.security.Security.insertProviderAt() were updated to check the new permission, before checking the legacy
insertProvider.{provider name}
. Continued use of the old permission is discouraged.The bug associated with this change is 8001319.
Security: Support NSA Suite B Crytography algorithms
Class java.security.spec.DSAGenParameterSpec was added to support for FIPS 186-3 Digital Signature Standard (DSS). This standard defines larger DSA key sizes than what is currently supported and defines the mechanism of how the corresponding parameters are generated. The current public APIs for DSA parameter generation in java.security.interfaces.DSAKeyPairGenerator was enhanced to account for larger keys.
Additional details may be found in JEP 129 NSA Suite B Cryptographic Algorithms.
The feature associated with this change is 7044060.
Security: Implement SHA-224 message digests
A new constant for SHA-224, java.security.spec.MGF1ParameterSpec.SHA-224, was added. The class specifications for java.security.spec.MGF1ParameterSpec and java.security.spec.PSSParameterSpec were updated to include SHA-224 in their lists of supported message digest algorithms.
The feature associated with this change is 4963723.
Security: Add Principal.implies()
The new method java.security.Principal.implies() with default implementation was added to eliminate dependency on package
com.sun.security.auth
. This change was made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization.The enhancement associated with this change is 7019834.
Security: Add Hastable override methods to Provider
The java.security.Provider class implements the java.util.Map interface indirectly. New mutator methods add to
java.security.Provider.compute(), java.security.Provider.computeIfAbsent(), java.security.Provider.computeIfPresent(), java.security.Provider.merge(), java.security.Provider.putIfAbsent(), java.security.Provider.remove(), java.security.Provider.replace(K key, V oldValue, V newValue()), java.security.Provider.replace(K key, V value()), and java.security.Provider.replaceall().Map
need corresponding overrides inProvider
to add security checks. The complete list of methods is as follows:Security: Update specification of X500Principal constructors
The specification of the applicable javax.security.auth.x500.X500Principal() constructors was updated to indicate that it implements the more restrictive object identifier (OID) syntax as defined in RFC 4512 which requires that OIDs contain at least 2 digits.
The bug associated with this change is 7024604.
Security: Modify KerberosPrincipal.equals() to ignore name-type
The specification of javax.security.auth.kerberos.KerberosPrincipal.equals() was modified to remove checking of the name-type since RFC 4120 6.2 declares that the name-type should be treated as a hint with no significance when checking for equivalence.
The bug associated with this change is 8015669.
Security: Add property to KeyTab to denote who-am-i-for
To restrict javax.security.auth.kerberos.KeyTab for use by a single Principal or everybody, a new property was added to denote “who-am-i-for”. Methods KeyTab.getUnboundInstance(), KeyTab.getInstance(), KeyTab.getPrincipal(), and KeyTab.isBound() were added. The specification of existing methods KeyTab.getInstance(File), KeyTab.getInstance(), and KeyTab.getKeys() was modified.
The enhancement associated with this change is 8001104.
Security: Enhance the Certificate Revocation-Checking API
The certificate revocation-checking API to support best-effort checking, end-entity certificate checking and mechanism-specific options and parameters was improved. The primary proposed API changes (all in java.security.cert) are as follows:
- A new interface, java.security.cert.CertPathChecker, was defined for use by any type of certificate.
- A new class, java.security.cert.PKIXRevocationChecker, was added to accept revocation specific parameters for the PKIX algorithm. This class implements the PKIXCertPathChecker. It also defines a static enum, java.security.cert.PKIXRevocationChecker.Option, which specifies the set of settable revocation options. This class will be used as the mechanism for checking revocation regardless of the value of the java.security.cert.PKIXParameters.isRevocationEnabled setting.
A PKIXRevocationChecker checks the revocation status of certificates with the Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) as described in RFC 2560. OSCP is a network protocol for determining the status of a certificate. A CRL is a time-stamped list identifying revoked certificates. RFC 5280 describes an algorithm for determining the revocation status of certificates using CRLs.
- Four methods that return a java.security.cert.CertPathChecker were added: java.security.cert.CertPathBuilder.getRevocationChecker(), java.security.cert.CertPathBuilderSpi.engineGetRevocationChecker(), java.security.cert.CertPathValidator.getRevocationChecker(), and java.security.cert.CertPathValidatorSpi.engineGetRevocationChecker().
- The specification for java.security.cert.CertPathBuilder.getRevocationChecker() and java.security.cert.CertPathBuilder.getRevocationChecker() was updated to state that each invocation returns a new java.security.cert.CertPathChecker instance.
Additional details may be found in JEP 124 Enhance the Certificate Revocation-Checking API.
The enhancements associated with this change are 6854712, 7171570, 8010748, and 8023362.
Security: Allow creation of signature Providers which are not registered
Methods java.security.cert.Certificate.verify(PublicKey, Provider) and java.security.cert.X509CRL.verify(PublicKey, Provider) were added. These methods do not require that the Provider be registered in the provider list and so all variants of Signature.getInstance() are now consistently supported. For compatibility with existing Provider implementations, default implementation of java.security.cert.X509Certificate.verify(PublicKey, Provider) and java.security.cert.X509CRL.verify(PublicKey, Provider) were added.
The enhancement associated with this change is 7026347.
Support AEAD CipherSuites
Modify the specification of javax.crypto.Cipher to describe the uniqueness requirement on IVs used in encryption with the given key and recommend re-initialization of cipher objects with GCM parameters which has a different IV value.
Additional details may be found in JEP 115 AEAD CipherSuites.
The bug associated with this change is 6750584.
Security: Modify PBEParameterSpec to support arbitrary parameters
Two methods, javax.crypto.spec.PBEParameterSpec(byte[],int,AlgorithmParameterSpec) and javax.crypto.spec.PBEParameterSpec.getParameterSpec(), were added to support arbitrary parameters. Applications that wish to use a PBE algorithm can supply an AlgorithmParameterSpec that is appropriate for the underlying cipher.
Additional details may be found in JEP 121 Stronger Algorithms for Password-Based Encryption.
The features associated with this change are 6383200 and 8013170.
Security: Document UnsupportedOperationException for Cipher wrap/unwrap methods
The specification of methods in javax.crypto.Cipher and javax.crypto.CipherSpi was updated to document that an
UnsupportedOperationException
is thrown if theWRAP_MODE
and/orUNWRAP_MODE
are not implemented in the underlyingCipher
orCipherSpi
. The complete list of changes is as follows:javax.crypto.Cipher.wrap()
,javax.crypto.Cipher.unwrap()
,javax.crypto.Cipher.init()
,javax.crypto.CipherSpi.engineWrap()
,javax.crypto.CipherSpi.engineUnwrap()
, andjavax.crypto.CipherSpi.engineInit()
.The bug associated with this change is 6750584.
Security: Generify SecretKeyFactory and SecretKeyFactorySpi
The following method declarations acquired an unbounded wildcard type parameter (
<?>
) for thekeySpec
argument: javax.crypto.SecretKeyFactory.getKeySpec() and javax.crypto.SecretKeyFactorySpi.engineGetKeySpec().The bugs associated with this change are 7064075 and 7145789.
Security: Provide SASL service for multiple hostnames
The SASL service was modified to allow it to serve clients from different networks by exposing different service names. The specification of the parameter for the server name in javax.security.sasl.Sasl.createSaslServer() and javax.security.sasl.SaslServerFactory.createSaslServer() was modified to require that the name be fully qualified or
null
to represent a server that is not bound to any specific host name. A new constant,javax.security.sasl.Sasl.BOUND_SERVER_NAME
was added to specify the bound server name for an unbound server.The bug associated with this change is 7110803.
Security: Downgrade references to
${java.home}/lib/security/java.security
References to
${java.home}
in all security APIs were updated to provide an informative, rather than normative, reference so that file may be re-located. This change was made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization.The enhancement associated with this change is 8004064.
Scripting: Update ScriptEngineManager default constructor
In the default constructor for javax.script.ScriptEngineManager, the line describing caller-based access checks was removed.
java.sql: Add access check to DriverManger.deregisterDriver
The specification for java.sql.DriverManager.deregisterDriver() was modified to indicate that a “deregisterDriver” permission check would be performed. The existing conditions for
SQLException
were extended to cover this failure. A new Permission, “deregisterDriver” was added to permission table in the class specification for java.sql.SQLPermission.The bug associated with this change is 8009732.
JAXWS: Generify Resource.type()
The javax.annotation.Resource.type() method declaration acquired an unbounded wildcard return type.
The enhancement associated with this change is 8014083.
Client: Implement lightweight embedding in other Java UI toolkits
APIs for a lightweight frame which overrides the common Frame’s functionality enabling render to an off-screen image were introduced.
The enhancement associated with this change is 8006406.
Client: Downgrade references to
${java.home}/lib
All file or resource references to
${java.home}
were updated to provide an informative, rather than normative, reference so that those files may be re-located. For example, in javax.swing.UIManger reference to${java.home}/lib/swing.properties
was replaced withswing.properties
file in thelib
subdirectory of the Java installation directory. Similar changes were also made to the class specification for java.awt.datatransfer.SystemFlavorMap, javax.imageio.spi.IIORegistery, javax.sound.mid.MidiSystem, and javax.sound.sampled.AudioSystem. This change was made in preparation for modules in a future release and has been noted in JEP 162 Prepare for Modularization.The enhancement associated with this change is 8005250.
Client: Update specification of GIF stream metadata for aspect ratio
The GIF stream metadata format specification describing the calculation for the pixel aspect was aligned with the implementation.
The bug associated with this change is 5082749.
Client: Update Accessibility API
The following changes were made to APIs supporting accessibility:
- The following protected fields were removed:
- The access modifier for java.awt.Component.accessibleContext was changed from package-private to protected.
- The method java.awt.Conatiner.AccessibleAWTContainer.removePropertyChangeListener() was added to remove stale listeners when an Assistive Technology is no longer in use.
- The method javax.swing.JComponent.getAccessibleContext() was removed in favor of using its superclass method java.awt.Component.getAccessibleContext().
- Deprecate the field javax.swing.JComponent.AccessibleJComponent.accessibleFocusHandler in favor of java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler.
The bug associated with this change is 7179482.
Client: Update AccessibleJLabel.getCharacterBounds() to specify behavior on invalid index
The specification of javax.swing.JLabel.AccessibleJLabel.getCharacterBounds() was enhanced to declare that
null
will be returned on invalid indices.
AWT: Update Component.setFocusTraversalKeys() and similar for inherited type checking
The specification for java.awt.Component.setFocusTraversalKeys(), java.awt.Container.setFocusTraversalKeys(), java.awt.KeyboardFocusManager.setDefaultFocusTraverslaKeys(), and javax.swing.JComponent.setFocusTraversalKeys() was updated to indicate that the unchecked
ClassCastException
may be thrown if the parameter representing the keystroke is not a java.awt.AWTKeyStroke rather than anIllegalArgumentException
.Compatibility Note: Existing applications may handle IllegalArgumentException differently than ClassCastException.
The bug associated with this change is 7146237.
AWT: Update Windows.*AlwaysOnTop*()
The specification for java.awt.Windows.setAlwaysOnTop() was updated to include information for behaviour when invoked with a value of
false
. Furthermore, the specifications for java.awt.Windows.setAlwaysOnTop() java.awt.Windows.isAlwaysOnTopSupported() were updated to explicitly state that the window’s toolkit is used formerly toolkit was implied.The bugs associated with this change are 7081584 and 8025225.
AWT: Update KeyboardFocusManager
Multiple methods in java.awt.KeyboardFocusManager were missing some access checks.
- The signatures of protected methods
KeyboardFocusManager.setGlobalFocusOwner()
,KeyboardFocusManager.setGlobalPermanentFocusOnwer()
,KeyboardFocusManager.setGlobalFocusedWindow()
, andKeyboardFocusManager.setGlobalActiveWindow()
was changed to throwSecurityException
. It may be thrown if the calling thread does not have “replaceKeyboardFocusManager” permission. The signature of public methodKeyboardFocusManager.setGlobalCurrentFocusCycleRoot()
was changed similarly.- The specification of the existing
SecurityException
for the following protected peer getters was updated to indicate that it would be thrown if the calling thread does not have “replaceKeyboardFocusManager” permission:KeyboardFocusManager.getGlobalFocusOwner()
,KeyboardFocusManager.getGlobalPermanentFocusOwner()
,KeyboardFocusManager.getGlobalFocusedWindow()
,KeyboardFocusManager.getGlobalActivewindow()
, andKeyboardFocusManager.getGlobalCurrentFocusCycleRoot()
.A new method
KeyboardFocusManager.clearFocusOwner()
which clears the focus owner at both the Java and native levels.AWT: Update Scrollbar methods to account for operating system-specific behavior
The specification of java.awt.Scrollbar.getUnitIncrement() and java.awt.Scrollbar.setUnitIncrement() was modified to indicate that the unitIncrement may be ignored by the underlying controls of some operating systems.
The bug associated with this change is 7057770.
AWT: Clarify FileDialog.setFile()
The specification of java.awt.FileDialog.setFile() was clarified to describe how the selected file could be visually represented based on the native file dialog implementation.
The bug associated with this change is 8000425.
AWT: Enhance Toolkit.beep()
The specification of java.awt.Toolkit.beep() was enhanced to indicate that the beep will depend on hardware and native system settings.
The bug associated with this change is 8003965.
AWT: Use extended modifiers for MouseEvents
“Extended modifiers” were defined in java.awt.event.InputEvent.getModifiersEx(). The “modifiers” parameter description for the three public constructors of java.awt.event.MouseEvent and the package-private constructor java.awt.event.InputEvent() was updated to require use of extended modifiers.
The bug associated with this change is 7109991.
AWT: Indicate when WindowsEvent.WINDOW_CLOSED event is delivered
The specification for java.awt.event.WindowsEvent.WINDOW_CLOSED was enhanced to indicate that the event will be delivered after the displayable windows has been closed after invocation of
Window.dispose()
.The bug associated with this change is 8020851.
AWT: Add alternate mechanism to track the event lifecycle
A new constructor, java.awt.event.InvvocationEvent(Object,Runnable,Runnable,boolean), with a
Runnable
listener parameter was added.Runnable.run()
is invoked after the event is dispatched or disposed. The specification of the protected field java.awt.event.InvvocationEvent.notifier and thenotifier
parameter of in allInvocationEvent
constructors were updated to include references to the newRunnable
.The enhancement associated with this change is 8025588.
AWT: Add DataFlavors for different HTML formats
Additional data flavors in the form of three new fields, java.awt.datatransfer.DataFlavor.fragmentHtmlFlavor(), java.awt.datatransfer.DataFlavor.selectionHtmlFlavor(), and java.awt.datatransfer.DataFlavor.allHtmlFlavor() were added. This allows uniform HTML content transfer on Windows and X11 platforms.
The enhancement associated with this change is 7075105.
Swing: Deprecate ImageIcon.component and ImageIcon.tracker
Two protected fields, javax.swing.ImageIcon.component() and javax.swing.ImageIcon.tracker() were deprecated. These fields were last used in JDK 6 but can not be removed since they weren’t declared
private
.The bug associated with this change is 7035495.
Swing: Update JScrollBar to ignore {block,unit}Increment
The javax.swing.JScrollBar specification for the getters and setters of unitIncrement and blockIncrement was updated to indicate that some look and feels may ignore those properties. This is the complete list of methods:
javax.swing.JScrollBar.getUnitIncrement(),
javax.swing.JScrollBar.setUnitIncrement(),
javax.swing.JScrollBar.getBlockIncrement(),
andjavax.swing.JScrollBar.setBlockIncrement()
.The bug associated with this change is 7057769.
Swing: Allow JPopupMenu locations to be modified by the native windowing system
The specification for javax.swing.JPopupMenu.setLocation() was updated to indicate that the native windowing system may either ignore the request or modify it to correspond closely to desktop settings,
Swing: Add warning about focus behavior to JMenuBar
A warning was added to the javax.swing.JMenuBar class specification indication that pressing the
Tab
key does not transfer focus from a JMenuBar because the default value of the propertyfocusTraversalKeysEnabled
isfalse
. To transfer focus, invokeJMenuBar.setFocusTraversalKeysEnabled(true)
.The bug associated with this change is 8000326.
Swing: Update JTextComponent to allow platform-specific modifiers
The specification of javax.swing.text.JTextcomponent.setFocusAccelerator() was modified to indicate that the accelerator will be key combination of the platform-specific modifier key and the uppercase equivalent of the given character.
The bug associated with this change is 7156658.
Swing: Make BorderFactory.createTitleBorder() Look and Feel dependent
The six overloaded methods javax.swing.BorderFactory.createTitledBorder() which are relating to TitledBorder.DEFAULT_POSITION were defined to be look-and-feel dependent.
The bug associated with this change is 7149090.
Swing: Clarify method delegation for RootPaneContainer
The class specification for javax.swing.RootPaneContainer was clarified to indicate that implementing classes should override their
add()
,remove()
, andsetLayout()
methods to delegate to the corresponding methods of theContentPane
. The class specification for the implementing subclasses, javax.swing.JApplet, javax.swing.JApplet, javax.swing.JDialog, javax.swing.JFrame, javax.swing.JInternalFrame, and javax.swing.JWindow, was similarly updated.The bug associated with this change is 7165112.
Swing: Make BorderFactory.createTitleBorder() Look and Feel dependent
The six overloaded methods javax.swing.BorderFactory.createTitledBorder() which are relating to TitledBorder.DEFAULT_POSITION were defined to be look-and-feel dependent.
The bug associated with this change is 7016396.
Swing: Specify valid parameters for {Async,Composite,Glyph}?View.getNextVisualPositionFrom()
The methods which compute the next visually represented model location where one might place a caret,
javax.swing.text.View.getNextVisualPositionFrom(), javax.swing.text.AsyncBoxView.getNextVisualPositionFrom(), javax.swing.text.CompositeView.getNextVisualPositionFrom(), and javax.swing.text.GlyphView.getNextVisualPositionFrom().getNextVisualPositionFrom()
, did not specify a valid range for the parameter describing the position to convert. The specification for the thrown javax.swing.text.BadLocationException was extended to describe the long-standing behaviour if the provided position is outside of that range. This is the complete list of methods:The bug associated with this change is 7016396.
Swing: Generify DefaultTreeSelectionMode.notifyPathChange()
The declaration of the
changedPaths
argument to javax.swing.tree.DefaultTreeSelectionModel.notifyPathChange() acquired an unbounded wildcard type parameter (<?>
). This change was motivated by a desire to reduce build warnings.The bug associated with this change is 7116950.
JVMTI: Update JVMTI specification to support statically linked agents
The
Agent_OnLoad
,Agent_OnUnload
, andAgent_OnAttach
symbols of the JVMTI Specification were modified so that when they are used in static libraries they reflect the library that contains these symbols. To accomplish this, the following changes were necessary.
- The
-agentlib
description was changed to indicate how native libraries are located and when theAgent_OnLoad
function will be invoked by the VM.- Additional specification was added to the
-agentpath
option.- The JVMTI Native Interface was modified to describe how static linking will occur.
- Consistent with a new major release, the version number of the JVMTI specification is incremented to
JDK18_JVMTI_VERSION
.Additional details may be found in JEP 178 Statically-Linked JNI Libraries.
The bug associated with this change is 8014135.