Java : how to check the jdk version used to compile a .class file

On Unix/Linux:

javap -verbose MyClass | grep "major"

On Windows:

javap -verbose MyClass | findstr "major"

major version number of the class file format being used

Java 14 uses major version 58
Java 13 uses major version 57
Java 12 uses major version 56
Java 11 uses major version 55
Java 10 uses major version 54
Java 9 uses major version 53
Java 8 uses major version 52
Java 7 uses major version 51
Java 6 uses major version 50
Java 5 uses major version 49
Java 1.3 uses major version 47
Java 1.2 uses major version 46
Java 1.4 uses major version 48

https://en.wikipedia.org/wiki/Java_class_file#General_layout

https://stackoverflow.com/questions/1096148/how-to-check-the-jdk-version-used-to-compile-a-class-file

Quick guide to API Versioning Strategies to avoid breaking changes pros and cons of each strategie non exhaustive

Here's 5 strategies for API versionning, the most popular strategies : URI via Path Param, Custome header via Accept

Coordinating a breaking change is not easy

First identify if it's a Breaking changes:

• Non-Breaking changes (No effect on existing API)
• Breaking changes (Not backword compatible, Versioning helps transition) -->  HTTP Status 500 Relaese changes and still support the older one
• Overhaul (All new API, Beyond versioning)

API Versioning typical lifespan:
v1 - first release
v2 - second release, notify consumers v1 version is deprecated
v3 - remove v1 (optional)

Recap for API lifecycle :

Semantic Versioning 2.0.0 smever.org

API URLs typically use MAJOR versions

API Versioning Strategies :

• URI  (via Path Param): Version is embededded in URI --> v1, v2 works with caching where is key
• Cons : 
• creates whole new tree in each version, require testing and validation.
• URI itself is changing 
• Pors  : developer friendly
• Content Negotiation via Media Type :  like application/json, used server side to determine what version to use for call
• Define vendor specific media types
• Example : application/vnd.softwarquality.v1+json 
• application/vnd.softwarquality.v2+json 
• Pors : URI does not change.
• Cons : non standard media type used
• Header via Custom header (Accept): Define custom header for version information
• Example : Accpet-version : v1,  and define a value like v1 or v2
• Server neds to look for the header and value to determine which version to use
• Pors : URI  does not change, better than overloaded media type
• Cons : 
• Request parameter (Query Param): parameter with version information, parsed with to server to determine which version to use
• Example : /api/products?version=v1
• Pors : URI does not change.
• Cons : routing request more difficult 
• No strategy rewrite

Most popular strategies : URI, Custom header

Conculsion : 
INMO Custom header is the best strategie, since URL resource is unique even if we change API version.
Please add in the comment section other pros and cons.

Docker Get IP address on Windows

docker-machine ip default should give you the IP to connect to

Si vous utilisez une machine virtuelle Docker (par exemple, créée à l'aide de VirtualBox), vous pouvez utiliser la commande docker-machine ip pour récupérer l'adresse IP de la machine virtuelle. Vous devrez peut-être également configurer le port forwarding pour accéder aux conteneurs depuis votre ordinateur local.

https://devilbox.readthedocs.io/en/latest/howto/docker-toolbox/find-docker-toolbox-ip-address.html

[Mockito] verify order / sequence of method calls

Exemple d'utilsation de InOrder :

@Mock ServiceClassA firstMock;
@Mock ServiceClassB secondMock;

doNothing().when(firstMock).methodOne();   
doNothing().when(secondMock).methodTwo();  

//create inOrder object passing any mocks that need to be verified in order
InOrder inOrder = inOrder(firstMock, secondMock);

//following will make sure that firstMock was called before secondMock
inOrder.verify(firstMock).methodOne();
inOrder.verify(secondMock).methodTwo();

https://stackoverflow.com/questions/21901368/mockito-verify-order-sequence-of-method-calls

[Mockito] implementation de l'argumentCaptor

Argument Captor est un Arugment Matcher

Exemple d'utilisation de l'argumentCaptor :

final ArgumentCaptor captor = ArgumentCaptor.forClass(UUID.class); verify(service).method(captor.capture()); 
assertThat(captor.getValue(), is(equalTo(tonUUID)));

Callbacks vs Promises vs Observables vs async/ await

JavaScript s'exécute d'une manière non bloquante, il exécute ligne par ligne, ce qui veut dire qu'il n'attends pas le résultat d'un code qui est asynchrone.

Nous pouvons travailler avec des opérations asynchrones, avec l'une des solutions suivantes :

• Callback : 
• Pros : qui est une fonction anonyme que nous passons en argument à notre méthode, et qui peut a son tour prendre des arguments (données), et permet de faire une exécution d'une manière asynchrone.
• Cons : "callback Hell", lorsqu'on plusieurs dépendances asynchrones, cela devient difficile à débugger et a gérer les erreurs.
• Promises :  Introduit depuis ES6 nativement sans besoin d'une librairie tier.
• Pros :  à l'intérieur de la méthode on crée une Promise avec le constructeur qui peut prendre des fonction en arguments : resolve , reject.  Puis, on appel resolve(data),  après l'appel de then() pour le retour des données.
• utile lorsque nous avons plusieurs dépendances asynchrones.
• Gestion des erreurs avec le bloc catch().
• Promise.all(iterable) 
• Promise.race(iterable)
• 
  
• Cons : Une seul opération asynchrone par promise.
• Ne permet pas de gérer plusieurs événements.
• Exemple : chargement des données avec une promesse
• const loadData = () => {
• return new Promise((resolves, rejects) => {
• const api  = 'xxx';
• const request = new XMLHttpRequest();
• request.open('GET', api);
• request.onload = ()  => {
• if (request.status === 200 ){ resolves(JSON.parse (reuqest.reponse));
• }else { rejects (Error(request.statusText));
• }
• };
• request.onerror = err => rejects (err);
• request.send();
• });
• }; 
•  Appel avec then()
• fetch()  est une bonne alternative pour faire des appels d'API. C'est une fonction native dans le navigateur et dans Nodejs aussi.
• RxJS Observables : utile lorsqu'on a un flux de données au lieu d'une seul valeur.
• 
• Async et await:  ne remplacent pas les promesses, ils les complètent.

Le mot-clé await permet d’attendre la résolution d’une opération asynchrone et d’en récupérer le résultat. Dès que le mot-clé await est utilisé au sein d’une fonction, celle-ci doit avoir le mot-clé async présent dans sa signature. Ce mot-clé définit que la fonction contient une opération asynchrone et que le moteur JavaScript doit attendre sa résolution pour poursuivre l’exécution du code de la fonction.

le mot-clé async a également un autre impact : une fonction déclarée async retourne toujours une promesse.

https://academind.com/learn/javascript/callbacks-vs-promises-vs-rxjs-vs-async-awaits/
https://stackoverflow.com/questions/37364973/what-is-the-difference-between-promises-and-observables

file downloading in restful web services

Exemple d'utilisation de ResponseBuilder