Non @Sebsauvage le jeu est libre (licence GPL) et ça ne veut pas forcément dire gratuit. Et comme l'explique bien la doc de la licence GPL elle-même : "free means free as in freedom not free as in free beer".

Sinon Red Hat ne pourrait pas vendre son OS ou l'accès à ses repos alors que tout est accessible ailleurs librement et gratuitement sur internet (en sachant que Red Hat ne développe qu'une infime partie de ce qu'ils vendent) 😑

Le mec qui publie O.A.D a repackagé le jeu pour Steam, qu'on le veuille ou non c'est un service comme un autre et ce service demande du temps, de l'argent et un certain savoir-faire. Et si ce type permet bien l'accès au code source (accès qu'il est en droit de faire payer le prix achat du jeu), alors tout est bon, il n'y a pas de problème 🤨

Le problème vient des devs qui se plaignent. Si vous ne supportez pas que les gens puissent être libres de faire ce qu'il veulent de votre travail, alors ne le publier pas sous une licence de logiciels libres. C'est juste carrément écrit dans le nom ! 🤷‍♀️

Ce que tu fais @Sebsauvage c'est de la morale, tu t'offusques qu'une personne s'est permise de faire exactement ce que le contrat qu'on lui a octroyé lui permettait de faire, et tu t'en offusques parce que ? Parce que pourquoi pas en fait... Damned 🤦‍♀️

Avec cela, je devrais être en mesure de me débarrasser de tout ce qui touche à de l'introspection et donc me rapprocher de la compilation native :D (avec ce maudit Spring Boot que j'ai appris à détester avec le temps).

L'exemple donné

package com.zetcode.routes;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.function.server.RouterFunction;
import org.springframework.web.reactive.function.server.ServerResponse;

import static org.springframework.web.reactive.function.BodyInserters.fromValue;
import static org.springframework.web.reactive.function.server.RequestPredicates.GET;
import static org.springframework.web.reactive.function.server.RouterFunctions.route;
import static org.springframework.web.reactive.function.server.ServerResponse.ok;

@Configuration
public class MyRoutes {

    @Bean
    RouterFunction<ServerResponse> home() {
        return route(GET("/"), request -> ok().body(fromValue("Home page")));
    }

    @Bean
    RouterFunction<ServerResponse> about() {
        return route(GET("/about"), request -> ok().body(fromValue("About page")));
    }
}

Edit
En complément il y a ce projet sur lequel jcefmaven est basé.

Problème

• J'ai besoin de développer un client lourd.
• Je préfère mourir que de me remettre à Swing ou d'utiliser JFX (dont la réputation d'API instable avait fait le tour du web il y a quelques années).

Solution
Cette dépendance Maven qui intègre un moteur de rendu WebKit :

<dependency>
    <groupId>me.friwi</groupId>
    <artifactId>jcefmaven</artifactId>
    <version>105.3.36</version>
</dependency>

Avec le tuto pour Java

//Create a new CefAppBuilder instance
CefAppBuilder builder = new CefAppBuilder();

//Configure the builder instance
builder.setInstallDir(new File("jcef-bundle")); //Default
builder.setProgressHandler(new ConsoleProgressHandler()); //Default
builder.addJcefArgs("--disable-gpu"); //Just an example
builder.getCefSettings().windowless_rendering_enabled = true; //Default - select OSR mode

//Set an app handler. Do not use CefApp.addAppHandler(...), it will break your code on MacOSX!
builder.setAppHandler(new MavenCefAppHandlerAdapter(){...});

//Build a CefApp instance using the configuration above
CefApp app = builder.build();

Facile de répondre au besoin du comment avec du code. Je te rejoins sur le pourquoi et pour ce faire :
1) Relire Clean Code de Robert C. Martin.

2) Relire Object Thinking de David West.

3) Coder en FOP (function-object-programming).

4) N'avoir besoin de documenter que les interfaces afin de répondre au pourquoi.

5) Enjoy.

Résumé
IntelliJ instrumente du code juste pour lui lorsqu'il exécute des TU.

Ce faisant, l'annotation @NotNull apposée sur un paramètre produit un NullPointerException lorsque c'est Java ou Maven (via Surefire lors des TU) qui exécute la fonction en lui passant un null mais elle produit un IllegalArgumentException lorsque c'est IntelliJ qui exécute la même fonction avec le même null passé en paramètre.

Solution
Désactiver le paramètre "Add runtime assertions for not-null-annotated methods and parameters" dans le menu Setting > Build > Compiler

Voici le résumé :

• all to suppress all warnings
• boxing to suppress warnings relative to boxing/unboxing operations
• cast to suppress warnings relative to cast operations
• dep-ann to suppress warnings relative to deprecated annotation
• deprecation to suppress warnings relative to deprecation
• fallthrough to suppress warnings relative to missing breaks in switch statements
• finally to suppress warnings relative to finally block that don’t return
• hiding to suppress warnings relative to locals that hide variable
• incomplete-switch to suppress warnings relative to missing entries in a switch statement (enum case)
• nls to suppress warnings relative to non-nls string literals
• null to suppress warnings relative to null analysis
• rawtypes to suppress warnings relative to un-specific types when using generics on class params
• restriction to suppress warnings relative to usage of discouraged or forbidden references
• serial to suppress warnings relative to missing serialVersionUID field for a serializable class
• static-access to suppress warnings relative to incorrect static access
• synthetic-access to suppress warnings relative to unoptimized access from inner classes
• unchecked to suppress warnings relative to unchecked operations
• unqualified-field-access to suppress warnings relative to field access unqualified
• unused to suppress warnings relative to unused code
• varargs to suppress warnings about unsafe usages of variable arguments (varargs) methods, in particular, those that contain non-reifiable arguments.

Nous débattions ce matin de la pertinence d'un modèle RESTful théorique dans le monde réel.

Je fais partie de ceux qui pensent qu'il n'est pas adapté et qu'il vaut mieux un modèle hybride REST/SOA (kysofer m'a convaincu à force). Dans tous les cas voici un ancien cours d'OCTO qui parle du sujet.

Parfait pour Kotlin et Java.

Prérequis
Avoir activé Actuator.

Configuration
Ajouter ceci dans votre fichier bootstrap.yml

server:
  shutdown: graceful

Déclenchement de l'arrêt
Envoyer une requête de type POST sur /actuator/shutdown. Par exemple :

curl -X POST localhost:8080/actuator/shutdown

En résumé si l'on passe par un contexte Spring chargé au moyen de la classe AnnotationConfigApplicationContext nous avons :

@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public RepositoryFactorySupport userRepository(EntityManager entityManager) {
    return new JpaRepositoryFactory(entityManager);
}

@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public UserRepository userRepository(RepositoryFactorySupport factory) {
    return factory.getRepository(UserRepository.class);
}

N.B : j'ai supposé que tout était en scope prototype puisque tout utilise un EntityManager qui est une entité recréée à chaque fois et qui est jetable.