Avec l'adoption de Google comme langue officielle d'Android, la commune de Kotlin se développe. Pendant ce temps, nous sommes passés de Java, qui est utilisé comme langage côté serveur, à Kotlin côté serveur.

Avantages et inconvénients de l'adoption de Kotlin: baby_chick:

Voici quelques-uns des avantages de la migration vers Kotlin. C'est une introduction légère car il s'agit d'une spécification linguistique de la partie dont on parle souvent.

mérite

Null Safety :ok_woman: --Dans la déclaration val Immuable: no_entry_sign:
Assurer l'exhaustivité du dénombrement par expression: muscle: --Outlook avec volume de code réduit et interface conviviale UP: Sparkles:

Démérite

L'écosystème Server Side Kotlin est faible à ce stade

Kotlin ne vous permet pas d'attribuer null à une variable de type qui n'est pas facultative. C'est très sûr car le compilateur garantit qu'il n'est pas nul. De plus, s'il est facultatif, une vérification est requise lors de la récupération de la valeur.

fun main(vararg args: String) {
    val user: User? = null
    println(user?.fullName ?: "unknown")
}

data class User(val familyName: String, val firstName: String) {
    val fullName: String
    	get() = "${this.familyName} ${this.firstName}"
}

Kotlin a une expression when similaire à la correspondance de Scala. Il correspond à un commutateur en Java, mais la différence est qu'il renvoie une valeur et garantit l'exhaustivité de l'énumération.

fun method(license: License) {
    val service = license.createService()
}

enum class License {
    FREE,
    ENETERPRISE;
    
    fun createService(): Service {
        return when (this) {
            FREE -> FreeService()
            ENETERPRISE -> EnterpriseService()
        }
    }
}

interface Service { ... }
class FreeService: Service { ... }
class EnterpriseService: Service { ... }

Cette (Licence) est transmise dans l'expression when. Nous savons que la licence est GRATUITE ou ENTREPRISE, nous n'avons donc pas à écrire le processus par défaut (ou bien dans kotlin) dans l'expression when. En outre, ** S'il y a une omission dans le modèle d'énumération, une erreur de compilation se produira, donc l'exhaustivité peut être garantie *. ( Il y a quelques restrictions)

・・・

Le système prend beaucoup de temps pour évoluer et prendre le relais. Kotlin est livré avec des spécifications linguistiques valides pour les exécuter en toute sécurité. Je pense que les fonctionnalités mentionnées dans le mérite sont des fonctionnalités notables qui adoptent Kotlin car elles ont un support plus fort que Java.

En passant, puisque le système existant a été construit avec Spring-boot + Mavan, pouvoir l'utiliser tel quel a également été un facteur majeur de la transition car le coût d'apprentissage a été considérablement réduit.

Problèmes lors de l'adoption de Kotlin côté serveur + Spring-boot: pieds:

Même avec les avantages, il y avait des obstacles au développement réel. Je voudrais en présenter quelques-uns.

Impossible de trouver la méthode d'exécution statique pour SpringApplication

En Java, SpringApplication est décrit comme suit, mais il ne fonctionnait pas lorsqu'il était utilisé tel qu'il a été généré par Spring Initializr.

@EnableAutoConfiguration
@SpringBootApplication
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

La statique de Kotlin est implémentée via Companion (ainsi que Scala), alors écrivez: Ajoutez également l'annotation JvmStatic afin qu'elle puisse être appelée depuis Java.

@SpringBootApplication
@EnableAutoConfiguration
class MyApplication {
    companion object {
        @JvmStatic fun main(vararg args: String) {
            SpringApplication.run(MyApplication::class.java, *args)
        }
    }
}

Mockito's any ou anyObject lève une exception

Any / anyObject de Mockito est implémenté en interne pour retourner null. Quand j'essaye d'utiliser ceci dans Kotlin, j'obtiens une exception IllegalStateException ** lorsqu'elle est passée à un argument non nul **.

En guise de solution, il semble possible de passer la vérification nulle en utilisant les génériques de Kotlin. Vous pouvez utiliser la classe Helper suivante.

class MockitoHelper {
    companion object {
        fun <T> any(): T {
            return Mockito.any() ?: null as T
        }
    }

    fun <T> eq(value: T): T {
        return if (value != null) Mockito.eq(value)
               else null ?: null as T
    }
}

J'ai fait référence à l'article ici. Merci: arc: *** Veuillez noter que cette solution peut ne plus être disponible **.

Impossible de trouver le constructeur principal pour la classe de données avec l'annotation RequestBody

Json n'a pas pu mapper à DataClassResource et a lancé une exception lorsque je viens de déposer le code Java habituel dans Kotlin.

data class DataClassResource(val key: String, val value: String)

@RestController
@Component
class DataClassController {
  
    @ResponseStatus(HttpStatus.OK)
    @RequestMapping(value = "/update", method = arrayOf(PUT), produces = arrayOf(APPLICATION_JSON_VALUE))
    fun update(@RequestBody resource: DataClassResource) {
        ...
    }
}

J'appelle le constructeur d'une classe avec l'annotation RequestBody pour l'initialiser, mais je n'arrive pas à trouver le constructeur principal de Kotlin.

Ce problème peut être résolu en ajoutant une version compatible Kotlin du module Jackson en tant que dépendance. Ajoutons le package suivant en tant que dépendance.

<dependency>
    <groupId>com.fasterxml.jackson.module</groupId>
    <artifactId>jackson-module-kotlin</artifactId>
    <version>2.8.0</version>
</dependency>

Tips :cookie:

Les classes Java ne peuvent pas être étendues car la méthode statique Extension ne peut être qu'une classe avec un objet compagnon

Lorsque vous étendez des méthodes statiques dans Kotlin, implémentez-les via Companion. Cependant, les classes Java n'ont pas d'objets compagnons, elles ne peuvent donc pas implémenter des fonctions d'extension ou des propriétés telles que:

fun JavaClass.Companion.extensionMethod() {
    ...
}

Il existe également un problème sur YouTrack. Je veux que vous le mettiez en œuvre. https://youtrack.jetbrains.com/issue/KT-11968

Prise en charge des méthodes Java qui peuvent être nulles avec facultatif

Les méthodes Java peuvent être nulles même si elles ne sont pas facultatives. Si vous souhaitez assurer la sécurité dans la zone de Kotlin, il semble préférable de recevoir le résultat de la méthode Java en option.

val maybe: String? = javaClass.method()

Injection de haricots définie comme val

Lors de la définition de la propriété à injecter avec l'annotation Autowired, si vous la définissez normalement, cela provoquera une erreur de compilation due à la désinitialisation, définissez-la donc avec lateinit pour une initialisation retardée.

@Component("sample")
class Sample {
    @Autowired
    private lateinit var dependency: Dependency
}

Cependant, «lateinit» ne peut être défini qu'avec «var». Si vous voulez définir avec val, utilisez le constructeur principal.

@Component("sample")
class Sample @Autowired constructor(private val dependency: Dependency) {
}

Je veux définir des propriétés qui ne changent pas autant que possible avec Immutable.

À la fin

Nous avons pu procéder au développement avec une vitesse stable, malgré quelques obstacles. Il est plus sécurisé au niveau du compilateur et offre une meilleure visibilité du code. Je pense que la puissance de ce soutien sera démontrée lors de la mise à l'échelle à l'avenir. Il y a aussi une description propre à Kotlin, il serait donc bon de continuer tout en explorant la politique dans la revue! Cependant, j'ai senti que le seuil de migration de Java vers Kotlin et le coût de l'apprentissage étaient à nouveau bas. Je veux que Kotlin côté serveur soit de plus en plus excitant: tada:

Migrer de Java vers Kotlin côté serveur + Spring-boot