to investigate further. Set its value on the
command line to one of the following:
Run the command
-Dfile.encoding=COMPAT
<your
application>
on JDK 18 and later to get the previous
behaviour, and check if there are any differences.
The
COMPAT
locale data provider, which represents the
locale data that is compatible with releases prior to JDK 9, is planned to be removed in a
future release.
See if your applications rely on
COMPAT
. Do this by
checking if the value
COMPAT
is specified in the system property
java.locale.providers
. If so, or you're migrating from JDK 8, then
test your applications with the latest JDK and the default
CLDR
locale
provider with respect to locale-related functions, such as the formatting and parsing of
dates, times, and numbers. If your tests yield unexpected results, then one workaround
is to provide your own SPI implementation. For example, the short month name for
September differs between
CLDR
and
COMPAT
in the UK
locale. The following SPI implementation addresses this incompatibility:
package spi;
import java.text.DateFormatSymbols;
import java.text.spi.DateFormatSymbolsProvider;
import java.util.Locale;
public class ShortMonthModifier extends DateFormatSymbolsProvider {
@Override
public DateFormatSymbols getInstance(Locale locale) {
assert locale.equals(Locale.UK);
return new DateFormatSymbols() {
@Override
public String[] getShortMonths() {
var ret = new DateFormatSymbols(Locale.UK).getShortMonths().clone();
ret[Calendar.SEPTEMBER] = "Sep";
return ret;
@Override
public Locale[] getAvailableLocales() {
return new Locale[]{Locale.UK};
}
Package this implementation as described in the section
Packaging of Locale Sensitive Service
Provider Implementations
in the
LocaleServiceProvider
JavaDoc API documentation. Afterward, place it on
the classpath and then run your applications with the
-Djava.locale.providers=SPI,CLDR
command-line option.
See
JEP 252: Use CLDR Locale Data by Default
.
Some tools and libraries use reflection to access parts of the JDK that are
meant for internal use only. This use of reflection negatively impacts the security and
maintainability of the JDK. To aid migration, JDK 9 through JDK 16 allowed this reflection
to continue, but emitted warnings about
illegal reflective access
. However, JDK 17
and later is
strongly encapsulated
, so this reflection is no longer permitted by
default. Code that accesses non-public fields and methods of
java.*
APIs
will throw an
InaccessibleObjectException
.
Note that the
sun.misc
and
sun.reflect
packages are available for reflection by tools and libraries in all JDK releases,
including JDK
22
.
The
java
launcher option
--illegal-access
allowed reflection to JDK internals in JDK 9 through JDK 16. You could specify the
following parameters:
ParNew + SerialOld
Incremental CMS
The foreground mode for CMS has also been removed. The command-line flags that were removed are
-Xincgc
,
-XX:+CMSIncrementalMode
,
-XX:+UseCMSCompactAtFullCollection
,
-XX:+CMSFullGCsBeforeCompaction
, and
-XX:+UseCMSCollectionPassing
.
The command-line flag
-XX:+UseParNewGC
no longer has an effect. The
ParNew
flag can be used only with CMS and CMS requires
ParNew
. Thus, the
-XX:+UseParNewGC
flag has been deprecated and is eligible for removal in a future release.
The CMS garbage collector has been removed. See
The permanent generation was removed in JDK 8, and the related VM options cause a warning to be printed. You should remove these options from your scripts:
Tools that are aware of the permanent generation may have to be updated.
Changes to GC Log Output
Garbage collection (GC) logging uses the JVM unified logging framework, and there are some differences between the new and the old logs. Any GC log parsers that you’re working with will probably need to change.
You may also need to update your JVM logging options. All GC-related logging should use the
gc
tag (for example,
—Xlog:gc
), usually in combination with other tags. The
—XX:+PrintGCDetails
and
-XX:+PrintGC
options have been deprecated.
See
Enable Logging with the JVM Unified
Logging Framework
in the
Java Development Kit Tool Specifications
and
JEP 271: Unified GC Logging
.
If you still rely on applets, it might be possible to launch them on Windows systems
by using JRE 8 with Microsoft Edge in Internet Explorer mode. See
Microsoft Edge + Internet Explorer
mode: Getting Started guide
.
As of September 2021, the Java Plugin required to launch Applets, remains
updated on Windows in Java 8 but may be removed at any time in a future update
release.
Oracle Customers can find more information at
My.Oracle.Support Note 251148.1 - Java SE 8 End
of Java Plugin Support
(requires login).
The
java.util.regex.Pattern
class defines character classes
in regular expressions with square brackets. For example,
[abc]
matches
a,b
, or
c
. Negated character classes are
defined with a caret immediately following the opening square brace. For example,
[^abc]
matches any character except
a,b
,
or
c
.
In JDK 8 and earlier, negated character classes did not negate nested character
classes. For example,
[^a-b[c-d]e-f]
matches
c
but does not match
a
or
e
as they are not within the nested class.
The operators are applied one after another. In this example, the
negation operator
^
is applied before nesting. In
JDK 8 and earlier, the operator
^
was applied only
to the outermost characters in the character class but
not
to
nested character classes. This behaviour was confusing and difficult
to understand.
However, in JDK 9 and later, the negation operator was
applied to all nested character classes. For example,
[^a-b[c-d]e-f]
does not match
To explain further, consider the following regular
expression:
[^a-d&&c-f]
In JDK 8, the
^
operator is applied first,
hence this example is interpreted as
[^a-d]
intersected with
[c-f]
. This matches
e
and
f
but not
a
,
b
,
c
,
or
d
.
In JDK 9 and later, the
&&
operator
is applied first, hence this example is interpreted as the
complement of
[a-d]&&[c-f]
. This matches
a
,
b
,
e
,
and
f
but not
c
or
As a best practice, look for regular expressions that use
character classes with some combination of negation, intersection,
and nested classes. These regular expressions may need to be
adjusted to account for the changed behavior.
In JDK 17, the Security Manager and APIs related to it have been deprecated and are
subject to removal in a future release. There is no replacement for the Security
Manager. See
JEP 411
for discussion and alternatives.
