Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Quoi de neuf à Devoxx France 2017 ?

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Prochain SlideShare
Introduction à spring boot
Introduction à spring boot
Chargement dans…3
×

Consultez-les par la suite

1 sur 23 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Quoi de neuf à Devoxx France 2017 ? (20)

Publicité

Plus récents (20)

Quoi de neuf à Devoxx France 2017 ?

  1. 1. #DevoxxFR Quoi de neuf à Devoxx France 2017 ? Antoine Rey 1
  2. 2. 2
  3. 3. #DevoxxFR Les modules débarquent enfin ! 3 10 ans d’attente pour voir débarquer les modules dans Java 9 Le JDK fait sa révolution : • Graphe de dépendances au runtime • Le classpath est mort, vive le module-path • Adieu au rt.jar et au tools.jar • Deep reflection interdite Migration facilitée par le mixed mode, les auto-modules et les options de débrayage de la JVM
  4. 4. #DevoxxFR Les modules débarquent enfin ! 4 Exemple de module-info.java : module com.myapp.dao { requires java.sql; requires transitive com.myapp.utils; export com.myapp.dao.api; } Par défaut, aucun package n’est exporté vers l’extérieur.
  5. 5. #DevoxxFR Java 9, what else ? 5 Sortie prévue pour le 27 juillet 2017 Evolutions du langage : • Méthodes privées dans les interfaces • Opérateur <> dans classe anonyme • @SafeVarags sur méthodes privées • Identifiant _ désormais interdit Nouvelles API : • StackWalking API • Reactive Stream • HTTP/2 Client
  6. 6. #DevoxxFR Java 9, what else ? 6 Evolutions des APIs : • Améliorations de l’API Process • Fabrique de collections immutables • Classe Optional et API Stream enrichies • Spin-wait hints Mise à jour des outils du JDK : • Réorganisation de la structure du JDK • Syntaxe GNU pour les options de la ligne de commande • Multi-release jar files • JShell : interpréteur interactif en ligne de commandes Map<String, String> map = Map.of("key1", "value1", "key2", "value2"); ProcessHandle.current().getPid())
  7. 7. #DevoxxFR Java 9, what else ? 7 Amélioration de la JVM : • G1 devient le Garbage Collector par défaut • Compact String • Indify String concatenation Support de standards : • JavaDoc générée en HTML 5 + JS • UTF-8 dans les fichiers properties • Support de SHA-3 dans JCE
  8. 8. #DevoxxFR Vue.js, le petit nouveau <v-beer v-on:ajout="ajoutPanier" :item="produit"></v-beer>
  9. 9. #DevoxxFR Vue.js, le petit nouveau <template lang="html"> <div class="thumbnail » :class="{ last: item.stock == 1 }"> <img :src="item.image" alt=""> <div class="caption"> <h4>{{item.price | currency}}</h4> <h4><a href="#">{{ item.label | uppercase }}</a> </h4> <p>{{item.description}}</p> </div> <button @click="ajouter">Ajouter</button> </div> </div> </template> <script> export default { name: 'beer', props: ['item'], methods: { ajouter () { this.$emit('ajout', this.item) } } } </script> <style lang="css"> </style> Fichier Beer.vue
  10. 10. La France dans le cyberespace
  11. 11. #DevoxxFR Spring Framework 5 Sortie prévue pour juin 2017 Pré-requis : Java 8 et +, Java EE 7 et JUnit 5 Amélioration des performances et diminution de l’empreinte mémoire Supporte : Java 9, Kotlin API fonctionnelle pour enregistrer des beans Spring et créer des routes Nouveauté majeure : Spring WebFlux
  12. 12. #DevoxxFR Spring Framework 5
  13. 13. #DevoxxFR Reactive Programming Modèle classique JavaEE d’un thread par requête HTTP : • Tous les I/O sont bloquants • Capacité serveur sous utilisée Nouveau modèle avec nombre réduit de threads : • Un I/O Selector thread va gérer les lectures/écritures • Plusieurs Worker Threads qui vont toujours travailler
  14. 14. #DevoxxFR Reactive Streams Architectures micro-services entrainent de nombreuses communications Sans gestion de débit : risque de saturation d’une application Buzzword : stratégie de back-pressure La back-pressure consiste à signaler au producteur que le consommateur est en surcharge Un groupe d’experts a créé la spécification Reactive Streams • Ensemble minimaliste de 4 interfaces • Implémentées par RxJava, Reactor et Akka Streams
  15. 15. #DevoxxFR Reactive Streams onSubscribe() requestMore(n) onNext() requestMore(n) subscribe() (x n fois)
  16. 16. #DevoxxFR Spring WebFlux @GetMapping(path = "/persons", produces = "text/event-stream") Flux<Person> getPersons() { return this.repository.findAll(); } public interface PersonRepository { Mono<Person> findOne(String id); Flux<Person> findAll(); Mono<Void> save(Mono<Person> user); }
  17. 17. #DevoxxFR Allo Docker ? Apparentée à de la virtualisation légère  Les conteneurs partagent de nombreuses ressources avec l’OS hôte Initialement : Docker est une technologie d’Ops mais pour les dévs Full Stack versionning : un même artefact contient OS, middleware et applicatif Travail conjoint entre Ops et Dév pour construire les images Disponible nativement sous Linux, BSD et Windows CaaS platform
  18. 18. #DevoxxFR Docker Swarm mode .Swarm est un orchestrateur de conteneurs Docker Sécurisé : tous les nœuds discutent en TLS Modèle déclaratif pour arriver à l’état souhaité  Cluster , Service, Task, Network … Possibilité de réplica pour le même service Mécanisme de DNS dynamique Lorsqu’un nœud du cluster tombe, les conteneurs sont déployés sur d’autres nœuds
  19. 19. #DevoxxFR REX sur les Microservices Quelques conseils suite aux retour d’XP de la BNP et de Clever Cloud : • L’architecture doit être drivée par la developper happiness • Utiliser le DDD pour identifier les frontières des microservices • Infra as code avec Docker + automatisation du l’orchestration des déploiements • Utiliser un Discovery Server (API Gateway) pour simplifier les déploiements et augmenter la résilience • Pattern CQRS/ES pour garantir la cohérence des données cross-domaines • Authentifier les appels sans utiliser un serveur d’authentification : JWT ou Macaroons • Ne pas trop découper : le réseau est lent, vraiment très lent
  20. 20. #DevoxxFR Log me tender De l’intérêt d’un service de log en 2017 @Service class MyService { private final LogService logService; public MyService(LogServiceFactory factory) { this.logService = factory.getLogService(MyService.class); } public void foo() { logService.info("Hello World"); } }
  21. 21. #DevoxxFR Log me tender • Injection par IoC, testable et mockable • Expose une API métier et technique • Centralise la gestion des messages : niveau, format … • API restreinte et moderne utilisant des Supplier : • Factory toujours nécessaire pour le cas d’utilisation « 1 logger par classe » void restApiCalled(String path, long ms, int code); void userLogged(Principal user, Device device); void log(LogLevel level, Supplier<String> msg, Throwable ex);
  22. 22. #DevoxxFR En route vers Java 10 Projet Valhalla - Value Types : petites structures de données, efficientes, sans héritage - Generic Specialization : List<int> Projet Panama - Vise à remplacer JNI pour faire communiquer la JVM et le code natif Projet Amber - Local Variable Type Inference : var a = 3 ; - Enhanced Enum : enum FavoriteNumber<T extends Number> - Lambda leftovers : (i, _) -> String.valueOf(i); Pattern Matching : swith case sur des types
  23. 23. #DevoxxFR Questions ? 23

Notes de l'éditeur

  • DAG au runtime
    Initialement Jigsaw était prévu pour Java 7.
    Les outils de build (Maven, Gradle) résolvent des dépendances à la compilation (dependency tree maven).
    Pour la Machine Virtuelle, on a plein de JAR linéaires scannés les uns après les autres. En moyenne, une application Java comporte une centaine de JAR. Problème lorsque 2 Jar de la même librairies sont dans le classpath : la JVM prend le JAR de la 1ière classe trouvée. Une classe fille nouvellement introduite dans ASM 3.1 peut hériter d’une classe parent présente dans ASM 2.3.
    Objectif de Jigsaw : utiliser l’arbre (DAG) vu à la compilation lors du runtime.

    Modularisation du JDK
    Autre problème : taille du RT.jar : 66 MB
    L’un des objectifs de Jigsaw est de réduire la taille de la JVM. Les classes de RT.jar ne sont pas signées : problèmes potentiels de sécurité.
    Dans Java 9, rt.jar et tools.jar disparaissent. Ils sont remplacés par des modules.
    Gros module : java.base
    Tous les modules ont des dépendances vers d’autres modules. Ils s’appuient tous sur java.base (qui contient le package java.lang).
    On ne sera pas obligé d’attendre que toutes les librairies deviennent des modules afin de pouvoir utiliser des modules.

    Deep reflection
    Deep reflection : changement de propriétés privées ou final.
    Consiste à utiliser la méthode field.setAccessible(true). Le framework Hibernate l’utilise massivement. Par défaut, setAccessible ne fonctionne plus. Pour que des classes d’un module puisse être utilisée par deep reflection à l’extérieur du module, il faut utiliser le mot clé opens dans le descripteur de modules (à la place de export). Un intérêt est que le JIT sait à présent que des propriétés peuvent être considérées comme final.

    Slides : http://prez.sewatech.fr/devoxxfr17-uni/
  • Formes de dépendances :
    requires : pas de transitivité (pour rappel, par défaut, Maven est transitif)
    requires transitive : permet d’ajouter de la transitivité mais uniquement de niveau 1.
    requires static : dépendance vérifiée à la compilation, mais pas au runtime (la dépendance est facultative)
    Par défaut, setAccessible ne fonctionne plus. Pour que des classes d’un module puisse être utilisée par deep reflection à l’extérieur du module, il faut utiliser le mot clé opens dans le descripteur de modules (à la place de export).
      Par défaut, lors de la création d’un module, rien n’est exporté vers l’extérieur. Une classe publique doit être exportée (ou plus exactement son package). L’utilisation de la syntaxe * est interdite.
    L’export a un impact sur le niveau de visibilité des classes. Un package ne peut pas être splitté sur plusieurs JAR. Un package Java doit forcément être dans un seul et unique module. Impact sur les tests unitaires. On peut exporter un package à une liste déterminée de modules. Sorte d’export restreint : exports com.app.internal to app.api
  • Les méthodes privées dans les interfaces permettront de mutualiser du code de 2 default methods
    private int _ = 0 ; génèrera une erreur de compilation Autres évolutions : amélioration du try with resources
    StackWalking API : permet de parcourir, filtrer et récupérer des infos sur les stacktraces : nom du fichier, numéro de la ligne … Nouvelle classe StackWalker thread-safe manipulant un Stream.
    Reactive Stream : ensemble minimal de 4 interfaces (Flow, Flow.Subscriber, Flow.Subscription, Flow.Processor) qui pourront être utilisés par certains framework pour mettre en œuvre les Reactive Stream (http://www.reactive-streams.org/), mécanisme de type publication/souscription asynchrone. Intérêt : mécanisme de type back pressure (le consommateur pilote) HTTP/2 Client (en incubation): nouveau client HTTP implémentant HTTP/2 et les WebSocket. API fluente pouvant remplacer la classe legacy HttpURLConnection

    Slides : https://fr.slideshare.net/jmdoudoux/java-9-modulo-les-modules-devoxx-fr-2017
  • Evolutions des API
     
    API Process (JEP 102)
    L’interface ProcessHandle permet d’obtenir le processus courant (méthode current()), terminer un processus, lister tous les processus d’un système …
    Permet de déclencher des traitements à la fin du processus
    Fabrique pour les collections (JEP 269). Avant Java 9, nous n’avons pas de solution simple pour créer des instances immutables (ex : Collections.unmodiableSet(set)). Dans les interfaces List, Set et Map, Java 9 ajoute des fabriques statiques. 12 surcharges de la méthode of(). Limitations : pas le choix de l’instance de la collection, on ne peut passer null, pas d’interface dédiée pour savoir qu’une collection immuable.
    La classe Optional est enrichie de 3 méthodes : stream, or et ifPresentOrElse
    4 nouvelles méthodes dans l’API Stream : takeWhile, dropWhile (attention à leur utilisation sur des streams non ordonnés), ofNullable, surcharge de méthode iterate
    Spin-wait hints. C’est une première, la JEP 285 n’a pas été proposée par Oracle. Ajout de la méthode onSpinWait() dans la classe Thread. Méthode vide annotée avec @HotSpotIntrinsicCandidate. Permet de réduire la consommation CPU lors de l’attente d’un thread.
     
    Mise à jour des outils du JDK
     
    Réorganisation du JDK. Avant Java 9, on avait un JRE inclus dans le JDK. En Java 9, la structure des répertoires est similaire pour JRE et JDK
    Des mécanismes ont été retirés : mécanisme endorsed, mécanisme d’extension. Les fichiers rt.jar et tools.jar sont retirés
    Les options de la ligne de commande Java 8 et inférieur ne sont pas homogènes : un ou deux -. La JEP 293 permet d’homogénéiser les options en s’inspirant la syntaxe GNU. Exemple : --module-path path. Les anciennes options restent pour des raisons de compatibilité.
    Des options GC sont supprimées
    Nouvelle politique pour déterminer quelle version de Java va être supportée par un compilateur. A partir de Java 9, le compilateur ne supportera que les 3 versions précédentes de Java : 8, 7 et 6.
    Multi-release jar files (JEP 238) : permet d’avoir un seul JAR pour plusieurs versions de Java. Le jar peut contenir plusieurs .class pour chaque version de Java. Version courante à la racine. Autres versions dans META-INF/versions/N.
    JShell : interpréteur interactif en ligne de commandes. Nouvel outil issu du projet Kulla.
    Outils retirés de Java 9 : jhat, Java DB,
  • Améliorations de la JVM
     
    Nouvelle numérotation des versions de Java. Le format de version introduit par Oracle est abandonné. Le nouveau format est inspiré de SemVer décomposé en 4 parties : $MAJOR, $MINEUR, $SECURITY et $PATCH. Une API est fournie pour récupérer ces informations depuis la JVM
    Le ramasse miette G1 devient le GC par défaut. Ce GC permet de réduire le temps de pause, particulièrement sur les heaps de grande taille.
    Compact String : réduction de l’empreinte mémoire. 1ière tentative en Java 6 retirée à cause de bugs. En Java 9, une String est un tableau de byte et un octet supplémentaire indiquant le format.
    Indify String concatenation : réécriture de la concaténation de chaine : InvokeDynamic à la place de StringBuilder

    Support de standards
     
    JavaDoc : HTML 5, recherche (implémentée en JavaScript)
    PKCS12 par défaut dans le Keystore
    Support de SHA-3 dans JCE : SHA3-224 à SHA3-512
    Support du UTF-8 dans le fichier properties. Avant Java 9, un fichier properties devait être encodé en ISO-8859-1
  • Vue.JS est une librairie qui permet de créer des composants. C’est la toute dernière librairie à la mode. Elle permet de créer rapidement une application.
  • Beer.vue
  • Les cyberpuissances et l’Union Européenne
    Extrait de la Keynote « Révolution Cyberindustrielle en France » de Laurent Bloch Slides : https://www.ossir.org/jssi/jssi2015/JSSI_2015_2B_Revolution_cyberindustrielle_et_facteurs_de_cyberpuissance.pdf

    Reste 2 fonderies en Europe :
    STMicroelectronics France, Crolles
    GlobalFoundries Allemagne, Dresde
    Fonderie : 4 milliards d’euros minimum

    Producteur pour la photolithographie : ASML (néerlandais, 2/3 du marché mondial)
  • Spring Framework 5.0
    5.0 M5 sorti il y’a quelques semaines
    RC1 prévue pour fin avril 2017
    GA prévu pour juin 2017
    Spring Boot 2 est basé sur Spring Framework 5
    Pré-requis revus à la hausse :
    JDK 8 et +
    Java EE 7 : Servlet 3.1, JMS 2, JPA 2.1
    JUnit 5 (possibilité d’utiliser Jupiter pour continuer à utiliser JUnit 4)
    Génération 4.x releasée en 2013


    Amélioration de performances
     
    Cible : temps de démarrage et occupation mémoire
    Avec l’arrivée des conteneurs, le temps de démarrage d’une application est central. L’un des mythes : le classpath scanning est lent. Fonctionnalité de création d’un index. Peu d’intérêt pour gagner du temps au démarrage. Mais finalement utilisé pour améliorer le cache. Optimisation du path matcher dans @RequestMapping. Non activée par défaut. Support de zéro copie : servir les ressources statiques sans solliciter le CPU.

    Support du JDK 9
     
    Optimisations : compact Spring + G1
    API de collections immutables
     
    Build qui compile avec les earlier version du JDK 9
    Le décalage de la sortie de Java 9 a impacté la sortie de Spring Framework 5. Utilisation des modules automatiques de Jigsaw. Autre déception : absence du support de http2 (module externe expérimental)

    Functional APIs
    API fonctionnelle pour enregistrer des beans Spring : le contexte applicatif peut être créé de manière programmatique, sans aucune annotation. API fonctionnelle sur WebFlux : série de building blocks à combiner. Exemple de création de toutes de manière programmatique
    Support de Kotlin
     
    Pour aller plus loin dans l’approche fonctionnelle, Kotlin est particulièrement intéressant. Spring Framework 5 apporte un support explicite : inférence de types, ajout d’extensions (pour RestTemplate, Spring Boot, Spring Data), …

  • Reactive Spring
     
    Nouvelle offre pour le développement d’applications web. Depuis 2 ans, beaucoup de travail a été réalisé sur ce sujet.
    Aujourd’hui, un thread traite l’exécution d’une servlet. Plus il y’a de clients, plus il faut de threads. Il y’a une limite en termes de mémoire et CPU.
    Reactive Progamming : se focalise sur la stabilité du serveur en cas de forte concurrence.
  • Problématique récurrente :  
    Services en attente d’autres services lents
    Clients mobiles avec beaucoup de latence

    Modèle un thread par requête http : tous les I/O sont bloquants. Pendant ce temps, le thread attend. Les threads passent leur temps à attendre. La capacité des serveurs n’est pas utilisé

    Passe d’un modèle IO bloquant à du event-based : la latence devient neutre.
  • Back-pressure : système de piles de messages Groupe d’expert de Reactive Streams : RedHat, Netflix, Typesafe
    Reactive Steams API : Publisher, Subscriber ; Subscription, Processor, Mono, Flux. Spécifications : http://www.reactive-streams.org/ Un Publisher va pousser de l’information à un Subscriber. Mono retourne 0 ou 1 élément. Flux retourne une collection d’éléments.
  • Diagramme des échanges en Reactive Streams
    Source : http://blog.octo.com/les-strategies-de-gestion-de-pression-partie-i/
  • Spring WebFlux s’appuie sur Reactor, Servlet 3.1 / Undertow / Netty (Netty par défaut sous Spring Boot)
    Le modèle d’annotations de Spring MVC est conservé
    En réactif, la méthode findAll() rend la main immédiatement et renvoie un Flux<Person>. Ce Flux peut renvoyer les Person au fur et à mesure de leur disponibilité (pas besoin de tous les avoir chargé avant de pouvoir utiliser le 1er).

    WebFlux gère à la fois du client et du serveur. Client et serveur partagent l’event loop de Netty.

    Les autres projets Spring sont en cours d’évolution pour prendre en compte l’aspect Reactive : Spring Data, Spring Security, Spring Boot, Spring Cloud.

    Spring Framework 5 utilise Reactor pour ses fonctionnalités internes Reactive. Dans nos applications, on a le choix d’utiliser la librairie Reactive de notre choix grâce à l’API Reactive : RxJava, Reactor et Akka Streams.
  • Propriétés intéressantes :
    Imutabilité. On le reconstruit. On ne le met pas à jour.
    Full Stack versionning : dans un même artefact, on a de l’OS, du middleware et d’application. Artefact auto-portant. Tout est packagée. Passe sur tous les environnements. Artefact construit automatiquement et versionné. Le cycle de vie de l’application et de l’environnement sont réconciliés.
    Réorganise les rôles et les responsabilités : pour construite une image Docker, il y’a un travail conjoint entre Ops et Dév.
    Le Docker container intègre le paradigme du Continuous Delivery avec Jenkins et le repo d’entreprise Nexus.


    Depuis Windows Server 2016 et la dernière maj de Windows 10, on a des conteneurs sous Microsoft Windows. 2 types de container : Windows Server containers (comme Docker) et Hyper V-containters (embarque une machine virtuelle). Ce n’est qu’au déploiement qu’on choisit le type de container (Windows Server vs Hyper-V).
  • Docker Swarm met régulièrement à jour les clés.
    Système d’élection dans le Cluster

    Docker Swarm visualize : https://github.com/dockersamples/docker-swarm-visualizer

    Les composants parlent entre eux au travers du Docker Networks. Permet de ne pas faire sortir leurs échanges à l’extérieur. Arrivée des topologies décrivant la stack et les composants. CaaS platform avec Docker Swarm pour l’orchestration. Dans Docker 1.12 l’orchestration a beaucoup changé : il y’a plusieurs managers et workers dans le cluster. Managers et workers dialoguent de manière sécurisée en TLS. On peut également créer des services : plusieurs instances de la même image => on peut ordonner la création de 4 réplicas du même service. Tous les conteneurs du même réseau peuvent dialoguer entre eux. Load balancer intégré à Docker (IPVS – load-balancer de niveau 4). Il suffit de connaître l’IP que d’un seul nœud du service. Mécanisme de DNS dynamique intégré à Docker : afin de dialoguer entre eux, les microservices peuvent utiliser le nom de l’image comme host. Lorsqu’un nœud du cluster tombe, les conteneurs sont déployés sur d’autres nœuds.
  • REX BNP : monolithe découpé en microservices puis déployés dans le Cloud
    Slides : https://speakerdeck.com/fanfansama/cloudifie-ton-monolithe
    REX Clever Cloud : les problèmes que l’on rencontre en microservice : configuration, authentification et autres joyeusetés Slides : https://fr.slideshare.net/quentinadam/problems-youll-face-in-the-microservice-word-configuration-authentication-devoxx-france-2017


    No dogma, full developer happiness oriented architecture L’architecture doit être drivée par la developper hapiness => développeurs efficaces
    Le développeur doit retrouver du plaisir à coder
    A la BNP, ils sont testés Spring Boot et Drop Wizard. Ils ont retenu Spring Boot et Spring Cloud (avec serveur Eureka)

    Utilisez les sous domaines et les cartes de contexte du DDD pour identifier les Frontières de vos microservices

    Comment faire de la recherche multi-critères sur des domaines / micro-services distincts ? Faut-il un agrégateur de réponses ? A la BNP, utilisation du Command Query Responsability Segregation (CQRS) et de l’Event Sourcing : chaque événement d’écriture est publié dans le bus d’évènements Kafka qui sert d’Event Store. Un micro service d’historique d’ordre souscrit au bus d’événement et les stocke dans un cache (Elasticsearch).

    Distribution d’authentification (REX Clever Cloud)
     
    Comment sait-on quel est l’utilisateur et si il a le droit d’y accéder ? Solutions existantes :
    Shared data repository (par exemple avec Redis) : très mauvaise idée
    Proxy : reverse-proxy qui authentifie l’utilisateur puis réinjecte l’utilisateur dans les headers de la requête. Pas super : le développeur doit avoir le reverse-proxy sur son poste + code métier dans le reverse-proxy + SPOF + dégradation des perfs du proxy
    Central API call to authenticate request : Chaque service authentifie la requête en attaquant une API d’Authentification. L’API Authentification reste un SPOF. Assez lent. Difficulté à mocker. C’est ce qui est majoritairement utilisé chez Clever. Nécessité d’outils comme JWT ou Macaroons.
    JWT (JSON Web Token) : les services ont justes à vérifier si le token reçu a été signé par le serveur d’authentification.
    Macaroons (vient de chez Google) : type de token. Partage d’une clé entre 2 serveurs. Plus besoin de service d’authentification. Dans un Macaroon, on peut ajouter des droits. A partir d’un Macaroon, on peut en créer un autre avec autant de droits ou moins puis le donner à quelqu’un d’autre.
  • Extrait de la conférence Log me tender animée par Olivier Croisier Slides : http://thecodersbreakfast.net/public/2017-04-10-devoxxfr-log-me-tender/LMT-DevoxxFR-2017.pdf Réflexion d’Olivier sur l’utilisation d’un service de logs
  • 1. Référence non-statique. Notion de « service de log »
    Injectable par IOC
    Testable (test du service de log)
    Mockable (test des services utilisateurs)
    AOP-able (performances, coupe-circuit) : mieux vaut ne pas logger que de ralentir toute la chaine si problème dans logger

    2. Service de log de haut niveau
    Façade du framework technique
    Expose une API technique et métier ad hoc : plus limité au niveau info, debug, error. On peut ajouter des méthodes. Exemple : beginProcess.
    Centralise la gestion des messages (format, niveau)
    Possibilité de raisonner en termes d’évènements
    Un événement => 1..N logs

    Proposition LogService
     
    Ce n’est pas un framework, mais une simple réflexion. Les méthodes dépendent du métier, du framework de log …
    Design goals :
    Une API restreinte et moderne : ne prend plus que des supplier Java 8
    Rétro-compatibilité et extensibilité : transition en douceur avec les méthodes debug, info …
    Façade pour SLF4J : standard
    Composant IOC : service Spring
    Factory toujours nécessaire pour le cas d’utilisation « 1 logger par classe ». Le LogService n’est alors pas accéder directement mais on passe par un LogServiceFactory


  • Disclaimer : syntaxe non figée et invitée à ne pas prendre à la lettre

    Value Types Les value types doivent être des struct du language C. Le code ressemble à une classe mais se comporte comme une valeur à l’exécution. Pas d’identité. Pas d’adresse mémoire. Doivent être immutables.
    En Java, on ne peut pas récupérer l’adresse de quelque chose sur la pile. C’est ce qui permet à Java d’être plus performant que le C.

    Projet Panama
    On veut que Java puisse à parler avec du C sans JNI. Relativement simple : demander au JIT de générer le code. Autre évolution : laisser au développeur la possibilité d’accéder aux nouvelles instructions SIMD/AVX. Nécessité de définir un type primitif sur 128, 256 ou 512 bits. Le nombre de changement est limité au JDK.

    La grosse feature : Pattern Matching
    Fonctionnalité demandée depuis 1997 (via un switch sur les types)
     

×