Ahhh Java... Je me souviens de mon tout premier code en Java. J'étais encore au lycée, je voulais apprendre à faire des sites web pour notre club d'anglais et j'avais entendu parlé de JavaScript. Alors j'ai demandé un bouquin à mes parents mais vu le prix des livres à l'époque j'avais fait une croix dessus... Puis à Noël...

J'ai reçu un libre qui s'appelait Total Java ! Et mes parents tout fiers à l'époque : "Le libraire nous a dit que tu pourrais faire des sites avec ça"... Oui avec des Applets Maman #Facepalm.

En réalité, j'ai très vite adoré Java et puis j'ai appris à le détester en migrant vers Kotlin. Le langage en lui-même n'est trop pas mal :

• Il gère la programmation par structures.
• Il gère la programmation orientée objets.
• Il gère la programmation fonctionnelle.
• Il gère la programmation par aspects.
• Il gère la programmation asynchrone.
• Il gère la programmation concurrentielle.
• Il gère programmation réactive.
• Il gère la programmation événementielle.

A présent je me rends compte de la lourdeur de sa syntaxe, que sa capacité à gérer autant de paradigmes différents font de lui un langage dont la syntaxe devient au final incohérente, que la rétro-compatibilité ascendante garantie n'a jamais permis à Java de trier le bon grain de l'ivraie pour ne se focaliser que sur le nouveau ; rétro-compatibilité depuis 1995 quand même !

@Warrior Du Dimanche si tu as des questions en Java demande, je tâcherai d'y répondre :-*. Mais quitte à bosser sur JVM, je te recommande Kotlin, bien plus élégant, bien plus expressif, bien mieux !

Retour d'expérience d'une équipe d'Amazon Prime sur l'utilisation de Kotlin à la place de Java.

Overall : 75% de devs satisfaits de la transition.

La polygot maven extension permet de produit des pom en Yaml (j'avais fait un tuto ici en son temps) et maintenant en Kotlin. Vous savez que j'adore Kotlin et pourtant je vois dans cette opportunité une immondice sans nom pour ne pas dire la plus grande des saloperies !

Pourquoi ?
Parce que le DSL Kotlin permet de coder dans le pom dont le but est qu'il soit pourtant 100 % déclaratif. Car du code dans un pom n'aura jamais de TU, a un probabilité très haute de ne pas être portable et surtout, chaque évolution du code ne profitera ni à la communauté (car pas de plugin) et deviendra un risque pour l'entreprise qui va accentuer l'effet "copier-coller".

Non vraiment, si c'était pour faire de Maven la même horreur de maintenance que l'est Gradle, mais les performances en moins, je pense qu'il valait mieux s'abstenir.

Voici l'exemple qui m'a fait vomir deux fois (vous saurez apprécier le code à copier-coller dans chaque projet d'entreprise en début de pom n'est-ce pas ?) :

import java.io.File

// define a comparable data class to simplify handling versions
data class Version(val major: Int, val minor: Int, val patch: Int) : Comparable<Version> {
    override fun compareTo(other: Version): Int =
            compareValuesBy(this, other, Version::major, Version::minor, Version::patch)

    override fun toString(): String = "$major.$minor.$patch"
}

// define a function to execute the git command and return its standard output
fun git(vararg args: String): String {
    // use the basedir of the project as the command's working dir if it contains a '.git' subdir
    // otherwise use the current working directory of this script if it contains a '.git' subdir
    // if both conditions are false the result will be null; the git command will probably fail
    val workingDir = basedir.takeIf { it.resolve(".git").exists() }
            ?: File(".").takeIf { it.resolve(".git").exists() }
    // run the git command with the provided arguments
    val process = ProcessBuilder()
            .directory(workingDir)
            .redirectErrorStream(true)
            .command(listOf("git") + args)
            .start()
    // read the standard output completely as a String
    val output = process.inputStream.bufferedReader().readText().trim()
    // return the output if the exit value is 0 or throw an exception otherwise
    if (process.waitFor() == 0) return output
    else throw IllegalStateException(output)
}

val gitVersions by lazy {
    // run the `git tag` command
    git("tag")
            // the returned list of tags is separated by newlines
            .split("\n")
            // filter out only tags that are versions (such as 1.231.15)
            .filter { it.matches(Regex("[0-9]+\\.[0-9]+\\.[0-9]")) }
            // the separate parts of each version are separated by dots,
            // also parse each part as an int
            .map { it.split('.').map { it.toInt() } }
            // map each triple of numbers to an instance of the `Version` class
            .map { (major, minor, patch) -> Version(major, minor, patch) }
            // sort the list of versions
            .sorted()
}

// the last release is always the tag with the highest version number
val lastRelease by lazy {
    gitVersions.max()
}

// the next version is determined based on the git commit log
val nextVersion by lazy {
    // use the lsat released version as the base
    val baseVersion = lastRelease
    // if there are no releases yet, we use the version 0.0.1
    if (baseVersion == null) Version(0, 0, 1)
    else {
        // split the base version in each separate part using destructuring
        val (major, minor, patch) = baseVersion
        // create a separator to split each log message on (log messages are multiline)
        val separator = "-".repeat(5) + "commit" + "-".repeat(5)
        // get all log messages from the last release tag until the current HEAD
        // for each commit the separator is printed + the full commit message
        val logMessages = git("log", "--pretty=format:$separator%n%B", "$baseVersion..HEAD")
                // split the output on each separator generated earlier
                .split(separator)
                // trim each message, removing excess newlines
                .map { it.trim() }
                // only keep non-empty messages
                .filter { it.isNotEmpty() }
        when {
            // increment the major and reset the minor + patch if any 
            // message contains the words 'BREAKING CHANGE'
            logMessages.any { it.contains("BREAKING CHANGE") } -> Version(major + 1, 0, 0)
            // increment the minor and reset the patch if any message starts with 'feat'
            logMessages.any { it.startsWith("feat") } -> Version(major, minor + 1, 0)
            // increment the patch in all other cases
            else -> Version(major, minor, patch + 1)
        }
    }
}

project {

    // use the next version calculated above when defining our project id
    id("nl.craftsmen.blog.kotlin:kotlin-rest-service:${nextVersion}")

    dependencies {
        compile("org.glassfish.jersey.inject:jersey-hk2:2.29")
        compile("org.glassfish.jersey.containers:jersey-container-netty-http:2.29")
        compile("org.glassfish.jersey.media:jersey-media-json-jackson:2.29")

        runtime("ch.qos.logback:logback-classic:1.2.3")
    }

    properties {
        "project.build.sourceEncoding" to "UTF-8"
        "maven.compiler.source" to "11"
        "maven.compiler.target" to "11"
    }

    distributionManagement {
        repository("local") {
            url(basedir.resolve("repo").toURI().toASCIIString())
        }
    }

    build {
        execute(id = "release", phase = "deploy") {
            // create a new tag using the next version calculated above
            git("tag", "-am", "Release $nextVersion", "$nextVersion")
            // print some output
            println("Tagged current HEAD as $nextVersion")
        }
    }
}

De mon côté Kotlin est constaté dans deux banques et un géant de l'énergie (secteur Parisien) et nous sommes en train de le pousser comme langage par défaut sur le développements d'API qui doivent être utilisées sur des infrastructures ultra legacy (Weblogic + Java 7 #Pleure) pour les remplacer, car Kotlin permet justement de coder avec les features de 2021 et de transcompiler le bytecode vers de vielles JVM 6/7/8.

Rappelons que Java a mis 10 ans pour devenir Java et que quelques années plus tard il est à 1/8ème de son paroxysme, cf. cette Google Trend du 1er janvier 2004 au 7 mars 2021 montrant l'évolution de Java sur ces 17 dernières années.

En comparaison, Kotlin va seulement fêter sa 6ème année... Laissons-lui encore 4 ou 5 ans histoire de voir.

Encore une très bonne nouvelle pour Kotlin ! Le fait d'avoir une fondation à part, disposant d'un modèle économique clair et qui assure au langage sa survit et mieux encore son évolution est ce qu'il fallait faire.

Le parfait contre-exemple que je pourrais donner est ce qu'a fait la fondation Apache avec Maven dans le sens où Apache étant "anti-argent", la fondation a toujours refusé que des contributeurs majeurs de Maven mettent en place un modèle économique de financement de leurs contributions. 15 ans plus tard, le projet n'a qu'une mise à jour tous les 18 mois... Heureusement, des forks sont apparus comme Maven Daemon mais cela fragmente le marché.

Bref, je suis très contente pour Kotlin.

Parser des fichiers CSV avec la lib OpenCSV en Java et en Kotlin.

Extrait du petit code qui va bien pour une lecture de trèèèès gros fichiers :

try (CSVReader reader = new CSVReader(new FileReader("file.csv"))) {
      String[] lineInArray;
      while ((lineInArray = reader.readNext()) != null) {
          System.out.println(lineInArray[0] + lineInArray[1] + "etc...");
      }
  }

Je découvre le mot-clef expect de Kotlin. Son objectif est de dire que pour une même classe, il va y avoir différentes implémentations en fonction de la plateforme.

Par exemple pour la classe (vide) :

expect class KMPDate(formatString: String) {
    fun asString(): String
}

Nous aurons cette première implémentation pour Android :

actual class KMPDate actual constructor(formatString: String) { // 1
    private val dateFormat = SimpleDateFormat(formatString) // 2
    actual fun asString(): String {
        return dateFormat.format(Date()) // 3
    }
}

et cette seconde pour iOS :

actual class KMPDate actual constructor(formatString: String) { // 1
    private val dateFormatter = NSDateFormatter().apply { // 2
        this.dateFormat = formatString
    }
    actual fun asString(): String {
        return formatter.stringFromDate(NSDate()) // 3 
    }
}

KPMDate n'est pas une interface mais bien une classe concrète avec plusieurs implémentions dites "platform-dependent" dans le même fichier.

Mieux encore, c'est compatible avec GraalVM et Kotlin native pour produire des binaires natifs (AMD64 et ARM64 principalement) compilés et linkés statiquement (+ compilation AOT + tree shaking pour les optims) sans avoir besoin d'une JRE d'installée sur l'environnement cible, donc parfait dans des conteneurs très légers par exemple :D

Tout est dans le titre.

Attention à l'extraction de fichiers dont le chemin dans l'archive sont des chemins absolus ! Si c'est root qui décompresse, il est alors possible d'écraser le /etc/profile par exemple, voir modifier des démons gérés par systemctl et compromettre le système.

Bref, toujours concaténer le répertoire de décompression en début de chemin du fichier.

Cela faisait quelques temps que je me demandais quel ORM choisir pour remplacer ActiveJDBC car ce dernier est très bien mais je souhaitais un framework qui accentue d'avantage l'OOP.

D'ailleurs ActiveJDBC avait remplacé depuis bientôt 5 ans maintenant Hibernate & OpenJPA chez moi, car eux-mêmes étaient beaucoup trop orientés procédurale (@Sweet clin d’œil à ce sujet) au point de rendre impossible de respecter le principe d'encapsulation et aussi parce que l'usage intensif de l'API réflexion par Hibernate ne permet pas la compilation en natif via GraalVM.

Bref, j'hésitais entre trois frameworks et je pense que je vais partir du Ktorm qui a une super doc, de bonnes performances et une façon très simple de requêter la base :

J'ai sorti Kuery car il n'est plus maintenu depuis trois ans et qu'il lui manque certaines fonctionnalités et j'ai aussi mis de côté Exposed car trop orienté fonctionnel et donc incitant à violer l'encapsulation à l'image d'Hibernate.

Bref Ktorm est dans le pipe.

@Animal attention ce que tu écris ne fonctionne QUE parce que ton fichier se trouve dans le classpath de test (car intégré au jar de test).

Dès que le fichier est en dehors du classpath, ça ne marchera pas.