Java 10 will come out. There was no Java 9! However, I'm not sure what kind of function it has, so I will summarize it. It's like a brief introduction to the JEPs lined up here. http://openjdk.java.net/projects/jdk/10/
Changes other than JEP, such as the addition of API, are summarized here. Summary of changes other than JEP of Java 10 --Qiita
All the changes are summarized here. 109 New Features In JDK 10 - Azul Systems, Inc.
Click here to download OpenJDK JDK 10 GA Release
Click here to download the Oracle JDK Java SE Development Kit 10- - Downloads
286: Local-Variable Type Inference http://openjdk.java.net/jeps/286
Probably the biggest and only change in writing code is local variable type inference.
var str = "123";
var list = List.of("123");
You will be able to write like this. Normally, when you use it when writing code, you often don't know the type of the variable, and it's easy to dislike not knowing the type you knew so far, so I feel that there are few situations that can be used unexpectedly. Is it possible to use it for the time being when the type is explicit to some extent as follows?
var strs = new ArrayList<String>(); //new
var props = (Map<String, List<String>>)input.getAsObject("props"); //cast
var map = Map.of("apple", "Apple",
"grape", "Grape"); //Factory or builder
In summary, if the type is written on the right side, it is unnecessary on the left side and var can be used, otherwise var is not used.
However, it is unconditionally convenient in JShell.
The lambda argument is where var seems to work but not.
Stream.of("abc").forEach(s -> System.out.println(s));
Is
Stream.of("abc").forEach((String s) -> System.out.println(s));
Is type inferred, but this is
Stream.of("abc").forEach((var s) -> System.out.println(s));
Cannot be written. Well, it's a local variable type inference, and the lambda argument is not a local variable, so it can't be used.
Well, it looks like it can be used, so starting with Java 11, you can use var with lambda arguments as well.
Also, with the introduction of var, the language specifications have changed a bit. As a big thing, var is introduced as a reserved word, not as a reserved word. So you can use var for variable names, method names, package names, etc., but you can no longer use var for class names. In the language specification, Type Identifier is introduced instead of Identifier for types, and the part where the type can be written has been changed from Identifier to Type Identifier.
Also, you can do this.
var anon = new Object() {
private int a() {
return 3;
}
};
System.out.println(anon.a());
By the way
var s = List.of("a", 1);
Compiling code with the -g option causes javac to crash in build 46.
These are ok.
var t = List.of("a");
var u = List.of("a", 1, Optional.empty());
var v = List.of("a", 1, List.of());
Bitterfox has already sent the patch.
296: Consolidate the JDK Forest into a Single Repository http://openjdk.java.net/jeps/296
So, from here on, it doesn't really matter when writing code, so I'll just throw it away. JEP 296 integrates repositories on OpenJDK. It follows the trend of recent single repositories. Until now, getting the source of OpenJDK was like collecting from various repositories with a script, but now you can get the source with a single Mercurial command. I think development will be easier.
As you can see by looking at the JDK9 repositories, each contains 7 repositories. http://hg.openjdk.java.net/jdk9
The old repository remains in JDK10, but it is integrated into master. http://hg.openjdk.java.net/jdk10
And with the integration of repositories, it feels like creating each version repository under the jdk project, which used to be a separate project for each version. http://hg.openjdk.java.net/jdk
304: Garbage-Collector Interface http://openjdk.java.net/jeps/304
We have introduced a GC interface to make the GC independent of the JVM. This increases the modularity of the GC, making it easier to add and remove GCs. Java 11 also includes a nice GC called Epsillon GC (a GC that does not release memory at all), ZGC becomes open source, Shenandoah, etc., so I think that future GC movements will be easier to do.
307: Parallel Full GC for G1 http://openjdk.java.net/jeps/307
The worst case latency in G1GC is to be improved by parallelizing Full GC. G1GC became the default from Java 9 but it seems that the default GC up to Java 8, parallel GC, was doing Full GC in parallel, so the migration can be made smoother.
310: Application Class-Data Sharing http://openjdk.java.net/jeps/310
By making class data sharing (CDS) introduced in JDK5 available for application classes, class metadata can be shared between Java processes, and startup time and memory usage can be improved.
312: Thread-Local Handshakes http://openjdk.java.net/jeps/312
Allow individual thread callbacks to be performed without affecting the safetypoint of the entire VM. It seems that this will improve stack trace acquisition and GC.
313: Remove the Native-Header Generation Tool (javah) http://openjdk.java.net/jeps/313
Since Java 8 can generate C headers for JNI with javac, javah will be removed.
314: Additional Unicode Language-Tag Extensions http://openjdk.java.net/jeps/314
java.util.Locale Expanded support for BCP47 language tags in other APIs. What was supported by calendar ca and number nu in Java 7 will be extended to support currency cu, week start fw, region rg, and time zone tz. ..
316: Heap Allocation on Alternative Memory Devices http://openjdk.java.net/jeps/316
Allows Java object heaps to be placed on other user-specified memory devices, such as NV-DIMMs. Future systems will have a complex memory architecture with memory like 3D XPoint, which will use non-DRAM with different characteristics in addition to DRAM. As an application example, it is considered that a high-priority process uses DRAM, a low-priority process uses NV-DIMM, or NV-DIMM is used for big data or in-memory DB.
317: Experimental Java-Based JIT Compiler http://openjdk.java.net/jeps/317
As a test, enable Graal, a Java-based JIT compiler, on Linux / x64 platforms. Although Graal is the basis of the pre-compilation (AoT) introduced in JDK 9, it can also be used as a JIT compiler to explore the next stage of Java-based JIT.
319: Root Certificates http://openjdk.java.net/jeps/319
As it is, OpenJDK does not have a root certificate by default, and security-important functions such as TLS did not work, so prepare a root certificate to make it easier to develop with OpenJDK and to make a difference with Oracle JDK. It seems.
322: Time-Based Release Versioning http://openjdk.java.net/jeps/322
The version description will be revised in response to the time-based release.
It has the following format.
$FEATURE.$INTERIM.$UPDATE.$PATCH
With a semi-annual release, $ FEATURE will increase by one and $ UPDATE will be 0. $ INTERIM is always 0. A $ UPDATE will be added for maintenance releases one month and four months after the feature release. $ PATCH is not normally used.
The next release in March will be October, the release in April will be 10.0.1. The release in July will be 10.0.2, and the release in September will be 11.
These version numbers can be obtained with feature (), ʻinterim (), patch (), ʻupdate () of java.lang.Runtime.Version.
Recommended Posts