Oracle will not be providing free long-term support (LTS) for any single Java version since Java 11.
Some of the important Java 11 features are:
- Running
Java File with single command
- New
utility methods in String class- New
utility methods added to the String class, such as repeat(), isBlank(), strip(), lines().
- Local-Variable
Syntax for Lambda Parameters: Improved var handling:
Improved type inference for lambda expressions using var.
- Nested
Based Access Control
- HTTP
Client - The introduction of a standard HTTP
Client API supporting HTTP/1.1, HTTP/2, and WebSocket communication.
- Reading/Writing
Strings to and from the Files
- Epsilon:
A No-Op Garbage Collector - A
no-op garbage collector to test the performance of applications.
· JEP 320: Remove the Java EE and CORBA Modules
· Java Flight Recorder (JFR) Event Streaming: The JFR now supports event streaming, providing more
capabilities for monitoring and profiling Java applications.
· Eliminating Nashorn JavaScript Engine: The removal of the Nashorn JavaScript engine and
associated API, making it unavailable for further use.
- TLS
1.3 Support: The implementation of TLS 1.3, improves
the transport security of Java applications
One major change is that you don’t need to compile
the java source file with javac tool first. You can
directly run the file with java command and it implicitly
compiles. This feature comes under JEP 330.
isBlank() - This instance method returns a boolean value. Empty Strings and
Strings with only white spaces are treated as blank.
But we already have trim(). Then what’s the need of
strip()? strip() is
“Unicode-aware” evolution of trim(). When trim() was introduced,
Unicode wasn’t evolved. Now, the new strip() removes all kinds of whitespaces
leading and trailing(check the method Character.isWhitespace(c) to
know if a unicode is whitespace or not).
JEP 323, Local-Variable Syntax for Lambda Parameters is the only language feature release in Java 11. In Java 10, Local Variable Type Inference was introduced. Thus we could infer the type of the variable from the RHS - var list = new ArrayList<String>(); JEP 323 allows var to be used to declare the formal parameters of an implicitly typed lambda expression. We can now define :
(var s1, var s2) -> s1 + s2
This was possible in Java 8 too but got removed in
Java 10. Now it’s back in Java 11 to keep things uniform. But why is
this needed when we can just skip the type in the lambda? If you need
to apply an annotation just as @Nullable, you cannot do that without
defining the type. Limitation of this feature - You must
specify the type var on all parameters or none. Things like the following are
not possible:
(var s1, s2) -> s1 + s2 //no skipping allowed
(var s1, String y) -> s1 + y //no mixing allowed
Before Java 11 this was possible:
public class Main {
public void myPublic() {
}
private void myPrivate() {
}
class Nested {
public void nestedPublic() {
myPrivate();
}
}
}
private method of the main class is accessible from
the above-nested class in the above manner. But if we use Java Reflection,
it will give an IllegalStateException.
Method method =
ob.getClass().getDeclaredMethod("myPrivate");
method.invoke(ob);
Java 11 nested access control addresses this
concern in reflection. java.lang.Class introduces three methods in
the reflection API: getNestHost(), getNestMembers(), and isNestmateOf().
JEP 318: Epsilon: A No-Op Garbage Collector
Unlike the JVM GC which is responsible for
allocating memory and releasing it, Epsilon only allocates memory. It allocates
memory for the following things:
- Performance
testing.
- Memory
pressure testing.
- VM
interface testing.
- Extremely
short lived jobs.
- Last-drop
latency improvements.
- Last-drop throughput improvements.
Now Elipson is good only for
test environments. It will lead to OutOfMemoryError in
production and crash the applications. The benefit of Elipson is no memory
clearance overhead. Hence it’ll give an accurate test result of performance and
we can no longer GC for stopping it. Note: This is an experimental feature.
JEP
320: Remove the Java EE and CORBA Modules
The modules
were already deprecated in Java 9. They are now completely removed. Following
packages are removed: java.xml.ws, java.xml.bind, java.activation, java.xml.ws.annotation, java.corba, java.transaction, java.se.ee, jdk.xml.ws, jdk.xml.bind
No comments:
Post a Comment