Java SE 13 : Les nouveautés -JEP 325: Switch Expressions

JEP 325: Switch Expressions

Afin d'éviter plusieurs "break ", qui rendent le code très verbeux, cette JEP propose de s'en passer, avec ce changement de syntaxe :

Le code :

switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
    case TUESDAY                -> System.out.println(7);
    case THURSDAY, SATURDAY     -> System.out.println(8);
    case WEDNESDAY              -> System.out.println(9);
}

Remarque : 

• On peut mettre plusieurs cas dans le même case séparer par une virgule (,)
• Plus besoin de break
• L'utilisation de  default. devient optionnel.

Remplacera :

switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        System.out.println(6);
        break;
    case TUESDAY:
        System.out.println(7);
        break;
    case THURSDAY:
    case SATURDAY:
        System.out.println(8);
        break;
    case WEDNESDAY:
        System.out.println(9);
        break;
}

JPA & Hibernate : equals et hashCode

L’égalité entre les objets est une notions importante lorsque'on utilise des ORM comme Hibernate et pas que pareil pour les TreeSet et TreeMap étant implémenté sous forme d'arbre binaire, il doit comparer les objets entre eux pour les organiser en implémentant comparable et/ou comparator .

Hibernate utilise la notion de proxy (Voir la définition sur Wikipedia) .

Quand nous avons deux objets en mémoire, nous devrons faire attention à ne pas comparer un proxy avec l’objet qu’il proxyfie.

Pour comparer sémantiquement deux instances, la classe java.lang.Object est pourvue de la méthode equals que toute classe est libre de redéfinir en respectant les règles suivantes :

• l'implémentation doit être réflexive, symétrique, transitive et cohérente, il est généralement nécessaire de redéfinir hashCode lorsque equals est implémentée.
•  les objets égaux doivent avoir des codes de hachage égaux

Maven : Maven Wrapper

https://github.com/takari/maven-wrapper

mvn -N io.takari:maven:wrapper

http://bennet-schulz.com/2018/04/12/quicktip-use-a-maven-wrapper/

Paradigm : Pure functions are thread-safe

https://alvinalexander.com/scala/fp-book/benefits-of-pure-functions

Servlet : Why-servlets-are-not-thread-safe

I need to know why the servlets are not thread safe ?

Servlet instances are inherently not thread safe because of the multi threaded nature of the Java programming language in general. The Java Virtual Machine supports executing the same code by multiple threads. This is a great performance benefit on machines which have multiple processors. This also allows the same code to be executed by multiple concurrent users without blocking each other.

Imagine a server with 4 processors wherein a normal servlet can handle 1000 requests per second. If that servlet were threadsafe, then the web application would act like as if it runs on a server with 1 processor wherein the servlet can handle only 250 requests per second (okay, it's not exactly like that, but you got the idea).

If you encounter threadsafety issues when using servlets, then it is your fault, not Java's nor Servlet's fault. You'd need to fix the servlet code as such that request or session scoped data is never assigned as an instance variable of the servlet. For an in-depth explanation, see also How do servlets work? Instantiation, sessions, shared variables and multithreading.

https://stackoverflow.com/questions/9555842/why-servlets-are-not-thread-safe

Maven: Lifecycle vs. Phase vs. Plugin vs. Goal

https://stackoverflow.com/questions/26607834/maven-lifecycle-vs-phase-vs-plugin-vs-goal

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Built-in_Lifecycle_Bindings

Maven : mvn dependency:purge-local-repository

Pour nettoyer le cache local, essayez d'utiliser le plug-in de dépendance.

1. mvn dependency:purge-local-repository : Il s'agit d'une tentative de suppression des fichiers du référentiel local, mais elle se poursuit toujours et remplit le référentiel local une fois les éléments supprimés.
2. mvn dependency:purge-local-repository -DreResolve=false : Cela évite la re-résolution des dépendances mais semble toujours aller sur le réseau à certains moments.
3. mvn dependency:purge-local-repository -DactTransitively=false -DreResolve=false : Ceci a été ajouté par Paweł Prażak et semble bien fonctionner. J'utiliserais le troisième si vous voulez que le repo local soit vidé, et le premier si vous voulez juste jeter le repo local et récupérer les dépendances.

https://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html
https://code.i-harness.com/fr/q/710ba1