Changements dans Java 11

point de changement

Java 11 est sorti le 25 septembre 2018.

Vous trouverez ci-dessous le JEP en Java 11.

• 181: Nest-Based Access Control
• 309: Dynamic Class-File Constants
• 315: Improve Aarch64 Intrinsics
• 318: Epsilon: A No-Op Garbage Collector
• 320: Remove the Java EE and CORBA Modules
• 321: HTTP Client (Standard)
• 323: Local-Variable Syntax for Lambda Parameters
• 324: Key Agreement with Curve25519 and Curve448
• 327: Unicode 10
• 328: Flight Recorder
• 329: ChaCha20 and Poly1305 Cryptographic Algorithms
• 330: Launch Single-File Source-Code Programs
• 331: Low-Overhead Heap Profiling
• 332: Transport Layer Security (TLS) 1.3
• 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
• 335: Deprecate the Nashorn JavaScript Engine
• 336: Deprecate the Pack200 Tools and API

Modèle de version de JDK9

À partir de JDK9, le modèle de version a été changé pour des versions de fonctionnalités tous les 6 mois (mars et septembre). De plus, des contre-mesures de vulnérabilité et des corrections de bogues ont été corrigées afin qu'elles soient disponibles quatre fois par an en janvier, avril, juillet et octobre. Concernant la fourniture binaire Jusqu'à présent, le binaire était fourni gratuitement par Oracle, mais après 9, le binaire gratuit sera fourni par OpenJDK. Oracle JDK 9 ou version ultérieure sera facturé. De plus, avant 8, il y avait une différence technique entre Oracle JDK et Open JDK, mais cela a disparu.

LTS Après JDK11, Oracle JDK sera publié une fois tous les trois ans. Support payant pour Oracle Fournit des mises à jour de sécurité pour un minimum de 8 ans. De plus, depuis JDK11, il sera disponible gratuitement à des fins de développement, de test, de production d'essai et de démonstration.

Java est toujours gratuit (autre, non lié à JDK)

Un document japonais intitulé Java Is Still Free écrit par des dizaines de champions Java concernant la prise en charge et les mises à jour de Java a été publié. C'était.

JEP qui semble avoir un grand impact sur le codage

JEP181 Nest-Based Access Control Jusqu'à Java10, le code qui appelait la méthode privée de la classe externe à partir de la classe interne était une sortie de code d'octet étrange.

Jetez un œil au code suivant dans JDK 10.

Outer.java

public class Outer {
    private int i = 0;
    
    public class Inner {
        public int i() {
            return i;
        }
    }
}

Après la compilation, essayez de désassembler le fichier de classe.

python

$ javap -p -c Outer\$Inner
Compiled from "Outer.java"
public class Outer$Inner {
  final Outer this$0;

  public Outer$Inner(Outer);
    Code:
       0: aload_0
       1: aload_1
       2: putfield      #1                  // Field this$0:LOuter;
       5: aload_0
       6: invokespecial #2                  // Method java/lang/Object."<init>":()V
       9: return

  public int i();
    Code:
       0: aload_0
       1: getfield      #1                  // Field this$0:LOuter;
       4: invokestatic  #3                  // Method Outer.access$000:(LOuter;)I
       7: ireturn
}

Ensuite, compilez le même code avec JDK 11 et essayez l'assemblage inversé.

python

$ javap -p -c Outer\$Inner
Compiled from "Outer.java"
public class Outer$Inner {
  final Outer this$0;

  public Outer$Inner(Outer);
    Code:
       0: aload_0
       1: aload_1
       2: putfield      #1                  // Field this$0:LOuter;
       5: aload_0
       6: invokespecial #2                  // Method java/lang/Object."<init>":()V
       9: return

  public int i();
    Code:
       0: aload_0
       1: getfield      #1                  // Field this$0:LOuter;
       4: getfield      #3                  // Field Outer.i:I
       7: ireturn
}

Pour ceux qui compilent avec JDK10, la classe Inner appelle l'accès à la méthode statique d'Outer $ 000. Dans JDK11, la classe Inner appelle directement la classe Outer Outer.i au lieu de la méthode d'accès $ 000.

Une vidéo à ce sujet est disponible au JVM Language Summit 2018.

JEP309　Dynamic Class-File Constants Étend le format de fichier de classe Java pour prendre en charge les constantes dynamiques. Jusqu'à Java10, seules les chaînes avec des primitives et des littéraux pouvaient être stockées dans le pool de constantes, mais d'autres chaînes peuvent désormais être gérées dans le pool de constantes. L'avantage des constantes dynamiques semble être qu'elles vous donnent plus de liberté dans votre langage et compilateur, et plus de liberté dans votre bytecode.

Une vidéo à ce sujet est disponible au JVM Language Summit 2018.

JEP320 Remove the Java EE and CORBA Modules Les modules JavaEE et CORBA ont été supprimés. Les cibles sont CORBA, JAXB, JAX-WS, Common Activation Framework et JTA. Ces modules proxy sont les suivants.

• JAX-WS -> jaxws-api
• JAXB -> jaxb-api
• JAF -> javax.activation-api
• Common Annotations -> javax.annotation-api
• JTA -> javax.transaction-api

La raison de la suppression semble être que la différence de vitesse de développement ne peut pas suivre la vitesse de Java SE. Il semble qu'il sera développé sous le nom de Jakarta EE à l'avenir.

JEP321 HTTP Client (Standard) L'API du client HTTP a été normalisée. Prend en charge asynchrone et HTTP / 2. Le nom du module est java.net.http.

Une vidéo à ce sujet a été publiée.

JEP323 Local-Variable Syntax for Lambda Parameters Vous pouvez désormais utiliser var avec des paramètres lambda ainsi que l'inférence de type de variable locale introduite dans Java 10. D'autres annotations peuvent être ajoutées. Une vidéo à ce sujet a été publiée.