Comme outil de génération de code pour les développeurs de logiciels, Github Copilot domine le marché aujourd’hui. Cette situation devrait perdurer, d’autant plus que l’outil s’est enrichi d’une fonctionnalité de messagerie instantanée à la ChatGPT. Propriété de Microsoft, Github bénéficie d’une ligne directe avec OpenAI, et est donc le premier à profiter du rôle de pionnier que cette société continue de jouer dans le développement de grands modèles de langage (abrégé LLM en anglais) 

On en oublierait presque qu’il existe d’autres options. La première alternative à grande échelle construite sur une base open source, incluant des jeux de données d’apprentissage ouverts, est StarCoder, dont une version 2 a récemment vu le jour. Elle est développée dans le cadre de l’initiative BigCode de ServiceNow et de HuggingFace. L’article qui l’accompagne offre un aperçu fascinant de la construction d’un modèle de langage pour la génération de code. Peu après StarCoder, WizardCoder, CodeLLama, DeepSeekCoder et quelques autres sont apparus sur la scène, pas tous fondés sur un ensemble de données ouvertes, mais librement accessibles et réutilisables via HuggingFace.  

Aujourd’hui, il existe aussi suffisamment d’outils pour faciliter l’exécution de ces modèles sur votre propre machine. Vous pouvez donc avoir votre propre assistant de codage personnel, hébergé par vous-même et entièrement privé. Pour cela, il vous faut un matériel suffisamment puissant, un LLM axé sur les tâches de code completion ou sur les conversations concernant le code, et une extension pour l’environnement de développement (IDE). Le LLM et l’extension de l’IDE communiquent entre eux via une API, qui peut être compatible ou non avec celle d’OpenAI, ce qui permet de passer facilement d’un modèle commercial (OpenAI) à un modèle open source le cas échéant. 

Extensions pour IDE

L’installation d’une extension est simple en soi. Github Copilot existe depuis longtemps en tant qu’extension pour VSCode et aujourd’hui également pour IntelliJ IDEA – même si au moment de la rédaction de cet article, la version d’IntelliJ contient encore un peu moins de fonctionnalités.  

Parmi les alternatives open source, Continue figure probablement parmi les meilleures à ce jour. Il en existe d’autres – Huggingface a développé llm-vscode par exemple – et il ne fait aucun doute que d’autres viendront s’ajouter. Tout comme Github Copilot, Continue existe également sous forme d’extension pour VSCode ou IntelliJ. L’outil peut utiliser à la fois des générateurs commerciaux basés sur le cloud (notamment GPT-4) et des solutions open source auto-hébergées, qui ne doivent pas nécessairement émuler l’API d’OpenAI et autorisent de nombreuses personnalisations. 

Il demeure important de prendre le temps de se familiariser avec l’extension. La documentation de Continue constitue une bonne base à cet effet. Pour chaque serveur et chaque LLM, il se peut que vous deviez définir différentes options de configuration et que vous souhaitiez apporter des modifications à l’invite de commande sous-jacente. Il convient également de savoir comment activer et désactiver l’extension dans l’IDE et de connaître les raccourcis et commandes disponibles. YouTube peut être un bon point de départ pour trouver des tutoriels et des exemples d’autres utilisateurs. 

Un LLM sur votre ordinateur portable 

Notamment sous l’impulsion du projet open source llama.cpp, des efforts considérables ont été faits au cours de l’année écoulée pour faire en sorte que les LLM puissent également être déployés sur du matériel informatique grand public. Un processeur graphique (GPU) au coût prohibitif n’est plus nécessaire, même s’il offre un gain de temps considérable. Globalement, llama.cpp permet de reconditionner un modèle au format GGUF (GPT-Generated Unified Format). Il s’agit ici d’appliquer un maximum d’optimisations : 

• l’utilisation de jeux d’instructions du processeur ( CPU) efficaces tels que  AVX-512 – il va sans dire que le matériel sur lequel le modèle fonctionnera plus tard doit également prendre en charge ces jeux d’instructions ; 
• l’utilisation de bibliothèques hautement optimisées pour les calculs sous-jacents, telles que openBLAS ou Accelerate et Metal d’Apple ; 
• la quantification du modèle, par la réduction de la précision des poids dans les couches des réseaux neuronaux. Les nombres (à virgule flottante) de 16 ou 32 bits du modèle original sont ici convertis en nombres entiers de 8 bits, voire de 6 bits ou même de 4 bits. Cela permet d’économiser de la mémoire et d’accélérer les calculs, au prix d’une perte de qualité relativement faible. 

L’hébergement local d’un LLM peut être réalisé à l’aide d’outils tels que LM Studio. Ceux-ci vous permettent de télécharger différents modèles au format GGUF. Un onglet séparé dans l’application vous permet de démarrer un serveur d’inférence utilisant le protocole HTTP autour d’un modèle téléchargé et activé, qui simule l’API d’OpenAI. Une fois ce serveur mis en place, par exemple sur le port 1234, le modèle est accessible via un appel à http://localhost:1234/v1/chat/completions .

Cette configuration dans l’extension Continue se fait par l’ajout du LLM au fichier .continue/config.json, suivant ces instructions et selon les directives pour LM Studio en tant que fournisseur de modèle. Vous pouvez adapter le titre et le modèle comme bon vous semble, et il vous suffit d’ajouter la ligne "apiBase":"http://127.0.0.1:1234/v1" Dans l’extension, vous verrez alors apparaître une nouvelle option, et vous pourrez commencer à l’utiliser. 

Interlude : à propos du matériel

La gestion des GPU n’est déjà pas une partie de plaisir pour un développeur sur une seule machine. Les problèmes d’incompatibilité entre les différentes versions de toutes sortes de bibliothèques logicielles et de pilotes de GPU peuvent prendre des jours à résoudre. L’offre du marché des GPUs pour data centers, dominée par le monopole de nVIDIA, reste d’un coût prohibitif. À cela s’ajoute le coût de l’acquisition des connaissances très spécialisées nécessaires au fonctionnement de ces systèmes. Le matériel que vous choisirez sera probablement complètement obsolète dans quelques années. Un nouveau matériel, conçu spécifiquement pour accélérer le type de calculs des modèles d’IA, fait l’objet d’un travail acharné. Google a déjà présenté le TPU, mais d’autres fabricants se concentrent aujourd’hui pleinement sur les NPU (Neural Processing Units), et certains osent entrer en concurrence directe avec nVIDIA.  

Si vous n’avez pas le temps de vous occuper des pilotes de GPU et que vous n’avez pas l’ambition d’entraîner les modèles vous-même, la possibilité de les utiliser sur un CPU ordinaire est plus que bienvenue. Bien sûr, vous êtes alors limité aux LLM ou aux modèles d’IA dont la taille le permet. Les LLM “domestiques” typiques ont 3, 7 ou 13 milliards de paramètres ; les modèles plus grands sont agressivement quantifiés pour économiser de l’espace sur le disque et la mémoire.  Ils ne seront pas en mesure d’égaler la qualité de GPT-4 aujourd’hui, mais heureusement, des classements existent pour aider à opérer un choix – pour les LLM ouverts en général, spécifiquement avec des benchmarks de vitesse (débit), ou pour les LLM générateurs de code en particulier. 

Plus les LLM sont grands, plus la qualité du résultat est élevée (en général), mais plus la mémoire et la puissance de traitement requises sont importantes. Un LLM doit de préférence pouvoir être entièrement chargé dans la mémoire, de sorte que 16 GB de RAM n’est pas un luxe – plus c’est encore mieux, surtout si vous voulez faire fonctionner un IDE sur la même machine. Pour fournir une réponse, le modèle complet doit souvent être exécuté plusieurs fois. Par conséquent, le goulot d’étranglement est souvent la bande passante entre le CPU et la RAM. Les CPU dotés d’une grande mémoire cache interne semblent avoir une longueur d’avance (voir également les benchmarks spécifiques à l’IA [1,2] d’Anandtech). Lors du choix du reste du matériel, la bande passante de la mémoire devrait certainement entrer en ligne de compte. Même ceux choisissant un GPU pourraient préférer considérer cette bande passante plutôt que le nombre de cœurs du GPU. Enfin, dans les environnements virtualisés (VM, VPS), il est important que le CPU virtuel prenne en charge les mêmes jeux d’instructions avancés, tels que AVX-512. 

Un LLM sur votre serveur 

Si vous disposez d’une machine plus puissante, il peut être intéressant d’y exécuter le LLM. ollama est probablement l’outil le plus populaire pour héberger des modèles sur Mac ou Linux sans trop de difficultés, et depuis peu également sur Windows. LocalAI est toutefois une option tout aussi intéressante dans la liste des fournisseurs de LLM pour Continue, car il propose des conteneurs Docker, avec ou sans support GPU. Sur une machine Linux équipée de Docker, un one-liner dans le terminal suffit pour télécharger le modèle CodeLlama open source et l’héberger sur le port 1234 : 

docker run -ti -p 1234:8080 localai/localai:v2.7.0-ffmpeg-core codellama-7b-gguf 

Cependant, son démarrage prend un certain temps, car le modèle est téléchargé dans le conteneur. Il est plus intéressant de stocker soi-même une série de modèles dans un répertoire local et d’y associer une API à l’aide d’un conteneur LocalAI. Des instructions relativement simples sont disponibles pour cela aussi. Nous pouvons par exemple les appliquer au LLM LLM DeepSeek de 6,7 milliards de paramètres, quantifiés à 4 bits. Il peut être téléchargé directement depuis Huggingface dans le répertoire local ./models-gguf à l’aide d’une commande wget du type : 

wget https://huggingface.co/TheBloke/deepseek-coder-6.7B-instruct-GGUF/resolve/main/deepseek-coder-6.7b-instruct.Q4_K_M.gguf -O ./models-gguf/deepseek-6.7b-instruct-Q4

Démarrer une API autour des modèles de ce répertoire sur le port 8001 (vous pouvez aussi placer plusieurs modèles dans le même répertoire et les héberger simultanément), peut alors se faire avec la commande suivante . Ajoutez éventuellement -d pour qu’elle s’exécute en arrière-plan, et n’hésitez pas à expérimenter les paramètres context-size et threads en fonction de la puissance de votre serveur :

docker run -p 8001:8080 -v $PWD/models-gguf:/models -ti --rm quay.io/go-skynet/local-ai:v2.7.0-ffmpeg-core --models-path /models --context-size 1600 --threads 16

Exemple

Nous pouvons maintenant comparer différents LLM pour le code. Nous nous en tiendrons ici à l’anecdote et prendrons l’écriture d’un script shell bash comme exemple simple. Nous partons du problème suivant : une routine de sauvegarde a effectué des sauvegardes nocturnes d’un système pendant des années. Pour libérer de l’espace disque, nous voulons supprimer toutes les sauvegardes qui ne diffèrent pas des précédentes. Nous lançons la commande suivante, en décrivant la tâche le plus précisément possible afin d’obtenir les meilleurs résultats : “Write a bash script that, given a directory, iterates over all its files in order of date of creation. For each file, if the filesize is equal to the filesize of the previous file, the file has to be deleted.” 

Le fichier .continue/config.json de notre extension Continue contient la liste suivante de modèles : un sur le propre ordinateur portable dans LM Studio chargé sur le port 1234, et deux sur un serveur séparé, mais sur le même réseau local, hébergé par LocalAI sur le port 8001. 

    {
      "title": "myLaptop-LMStudio",
      "model": "whatever is loaded in LMstudio",
      "apiBase": "http://127.0.0.1:1234/v1",
      "completionOptions": {},
      "provider": "lmstudio"
    },       
    {
      "title": "localAI-mistral",
      "model": "mistral-7b-code16kqlora-Q4",
      "apiBase": "https://192.168.0.100:8001/v1",
      "apiKey": "",      
      "completionOptions": {},
      "provider": "openai"
    },
    {
      "title": "localAI-deepseek",
      "model": "deepseek-6.7b-instruct-Q4",
      "apiBase": "https://192.168.0.100:8001/v1",
      "apiKey": "",
      "completionOptions": {},
      "provider": "openai"
    },

Comme référence, nous prenons ChatGPT, qui propose la solution (correcte) suivante.  
En outre, elle est également suivie d’une explication détaillée de la signification des différentes parties (non présentée ici) : 

#!/bin/bash

# Directory containing the files
DIR="/path/to/your/directory"

# Variable to hold the size of the previous file. Initialized to 0.
prev_size=0

# List all files in the directory, sorted by creation date
# Note: '%T@' sorts by creation time, '%p' prints the file's name
# 'sort -n' ensures the list is sorted numerically
# Note that creation time sorting may depend on filesystem and OS support
files=$(find "$DIR" -type f -printf "%T@ %p\n" | sort -n | cut -d ' ' -f 2-)

# Iterate over the sorted list of files
for file in $files; do
  # Get current file size
  current_size=$(stat -c %s "$file")
  
  # Check if current file size is equal to the previous file's size
  if [ "$current_size" -eq "$prev_size" ]; then
    # Sizes are equal, delete the current file
    echo "Deleting file: $file"
    rm "$file"
  fi
  
  # Update previous size to current file's size
  prev_size=$current_size
done

Dans LMStudio, nous chargeons le modèle “CodeNinja 1.0 openchat 7B Q4_K_M“. Il faut plus d’une minute pour générer la réponse à la même question : 20 secondes d’attente pour l’apparition de la première lettre de la réponse, puis environ 2 secondes par ligne (bien sûr, notre ordinateur portable n’est pas très puissant : un CPU Core i7-10610U avec 32GB de RAM). Le résultat se présente comme suit : 

#!/bin/bash

for f in $(ls -t -l --time-style=full /path/to/directory)
do
  if [[ $f == "total"* ]]; then
        continue;
    fi
    filename=$(basename "${f% *}")

    # Checks whether the file is already deleted. If not, compares it with the previous file:
    prev_file=""
    while IFS= read -r line; do
        if [[ $line == $filename ]]; then
            prev_file=$line
            break;
        fi
    done <<<"$(ls -l /path/to/directory | tail -n 2)"

    if [[ -z $prev_file || "$f" = "${prev_file}" ]]; then
        # If the file is deleted, nothing to do. If not, deletes it:
        if [[ -z $prev_file ]] || [[ "$(stat -c %s ${filename})" == "$(stat -c %s ${prev_file})" ]]; then
            rm /path/to/directory/$filename
        fi
    fi
done

Nous chargeons le modèle DeepSeek de 6,7 milliards de paramètres dans LocalAI sur une VM Debian dans Proxmox. La VM se voit allouer beaucoup de mémoire vive et 12 cœurs du micro-processeur AMD Threadripper 3960X sous-jacent (24 cœurs au total mais pas de support AVX-512). Nous créons ainsi à un rythme d’environ 3 lignes par seconde le résultat suivant : 

#!/bin/bash

# Check if directory is provided
if [ $# -ne 1 ]; then
  echo "Usage: $0 directory"
    exit 1
fi

# Check if directory exists
if [ ! -d "$1" ]; then
    echo "Directory $1 does not exist"
    exit 1
fi

# Change to the directory
cd "$1"

# Get the list of files in order of creation date
files=$(ls -t)

# Initialize previous_size to 0
previous_size=0

# Iterate over the files
for file in $files; do
    # Get the size of the file
    size=$(stat -c%s "$file")

    # If the size is equal to the previous size, delete the file
    if [ $size -eq $previous_size ]; then
        rm "$file"
        echo "Deleted $file"
    fi

    # Update previous_size
    previous_size=$size
done

Enfin, sur la même VM, nous pouvons également essayer Mistral, pour lequel nous choisissons au hasard la version mistral-7B-code-16K-qlora qui a été légèrement adaptée par fine-tuning pour le code par un internaute. Il s’avère que sa réponse est rapide, générant le résultat compact suivant en quelque 2 secondes (malheureusement sans documentation, et en proposant la commande complexe awk ) : 

for file in $(find directory -type f -exec du -sh {} + | sort -h | awk '{print NR ":\t" $1}'); do
    size=$(du -sh "$file" | awk '{print $1}')
    if [[ $size == $previous_size ]]; then
      rm "$file"
    fi
    previous_size=$size
done

Je laisse volontiers au lecteur le soin de procéder à une comparaison plus approfondie de ces résultats. Si nous devons tirer une dernière leçon de cette expérience, c’est que même si les modèles ont le même nombre de paramètres et sont entraînés dans le même but, il peut y avoir de très grandes différences de résultat et de style entre eux !  

Conclusion

À la vitesse de l’éclair, toutes sortes de fonctions alimentées par l’IA trouvent leur place dans l’IDE. Les dernières notes de mises à jour de Visual Studio Code mentionnent, par exemple, la prise en charge de la reconnaissance vocale dans plusieurs langues, en plus de plusieurs fonctionnalités de CoPilot. En tant que développeur, il est inévitable que vous soyez confronté à cette situation. Les développeurs qui travaillent avec des données sensibles ou du code protégé par des droits d’auteur doivent se méfier à juste titre de ces outils qui envoient le contenu de leur IDE à un service cloud tiers pour proposer des suggestions.  

Grâce notamment au projet llama.cpp, une voie alternative open source a récemment vu le jour, qui permet de mettre en place et d’exploiter soi-même une telle assistance au codage avec des LLM. Les modèles plus petits qui peuvent fonctionner sur du matériel grand public n’offrent actuellement pas la même qualité et la même vitesse que Github CoPilot ou ChatGPT. Toutefois, de nouvelles améliorations apparaîtront régulièrement au cours des prochaines années, de sorte que la voie à suivre semble prometteuse à tous points de vue.  

______________________

Ce post est une contribution individuelle de Joachim Ganseman, spécialisée en intelligence artificielle chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Als code-genererend hulpmiddel voor softwareontwikkelaars domineert Github Copilot vandaag de markt. Dat zal wellicht nog wel even aanhouden, zeker nu de tool ook wordt uitgebreid met chatfunctionaliteit à la ChatGPT. Als eigendom van Microsoft, geniet Github van een directe lijn met OpenAI en zo kan het als eerste meegenieten van de voortrekkersrol die dat bedrijf blijft spelen inzake de ontwikkeling van Large Language Models (LLMs).

Men zou haast vergeten dat er ook andere mogelijkheden zijn. Het eerste grootschalige alternatief dat van de grond af open-source was opgebouwd, inclusief open trainingsdata, is StarCoder, waar sinds kort ook een versie 2 van is uitgekomen. Het wordt ontwikkeld onder het BigCode initiatief van ServiceNow en HuggingFace. De bijhorende paper geeft een fascinerende inkijk in de opbouw van een taalmodel voor het genereren van code. Kort na StarCoder verschenen WizardCoder, CodeLLama, DeepSeekCoder en nog enkele anderen ten tonele – niet allemaal met een open dataset erachter, maar wel vrij toegankelijk en herbruikbaar via HuggingFace.

Ondertussen is er voldoende tooling beschikbaar om deze modellen gemakkelijker op een eigen machine te draaien. “Your Own Personal Coding Assistant”, self-hosted en volledig privaat, is vandaag haalbare kaart. We hebben daarvoor nodig: voldoende krachtige hardware, een LLM toegespitst op code completion taken of op conversaties over code, en een plugin voor de IDE. LLM en IDE plugin spreken met elkaar via een API, die al dan niet compatibel kan zijn met die van OpenAI – wat desgewenst toelaat gemakkelijk te wisselen tussen commerciële (OpenAI) en open source modellen.

IDE plugins

Een plugin installeren is op zich gemakkelijk. Github Copilot bestaat al langer als plugin voor VSCode en vandaag ook voor IntelliJ IDEA – al bevat de IntelliJ versie op moment van schrijven nog wat minder functionaliteit.

Onder de open-source alternatieven hoort Continue momenteel waarschijnlijk bij de top. Er zijn er andere – Huggingface zelf heeft bijvoorbeeld llm-vscode ontwikkeld – en ongetwijfeld zullen er nog bijkomen. Net zoals Github Copilot bestaat Continue ook als plugin voor VSCode of IntelliJ. Het kan zowel gebruikmaken van commerciële cloud-based generatoren (waaronder GPT-4) als van zelf gehoste open-source oplossingen. Die hoeven niet noodzakelijk de OpenAI API na te volgen, en er is veel customizatie mogelijk.

Het blijft belangrijk om tijd te investeren om met de plugin te leren werken. De documentatie van Continue is een goed startpunt. Voor elke server en elke LLM kunnen er andere configuratieopties zijn die ingesteld moeten worden, en misschien wil je custom aanpassingen maken aan de achterliggende prompt. Daarnaast is het nodig om te weten hoe de plugin geactiveerd en gedeactiveerd kan worden in de IDE, en welke shortcuts en commando’s er bestaan. YouTube kan een goed startpunt zijn om tutorials en voorbeelden van andere gebruikers te vinden.

Een LLM op je laptop

Vooral onder impuls van het open-source project llama.cpp, zijn er het afgelopen jaar enorme inspanningen gebeurd om LLMs ook inzetbaar te maken op gewone consumentenhardware. Een peperdure GPU is niet meer noodzakelijk, al gaat het met GPU wel nog steeds sneller. In grote lijnen laat llama.cpp toe om een model te herverpakken in het GGUF formaat (GPT-Generated Unified Format). Daarbij worden zoveel mogelijk optimalisaties toegepast:

• gebruik van efficiënte CPU-instructiesets zoals AVX-512 – het spreekt voor zich dat de hardware waarop het model later moet draaien, deze instructiesets ook moet ondersteunen,
• gebruik van sterk geoptimaliseerde high-performance libraries voor de achterliggende berekeningen, zoals openBLAS of Apples Accelerate en Metal,
• het kwantiseren van het model, door het reduceren van de precisie van de gewichten in de lagen van de neurale netwerken. De 16-bit of 32-bit (komma)getallen uit het originele model worden daarbij omgezet naar gehele getallen (integers) van 8-bit, zelfs 6-bit of 4-bit. Dit bespaart geheugen en versnelt de berekeningen, ten koste van een relatief klein kwaliteitsverlies.

Lokaal een LLM hosten kan met tools zoals LM Studio. Die geven je de mogelijkheid om verschillende modellen te downloaden in GGUF formaat. Een apart tabblad in de applicatie laat toe om een HTTP Inference server rond een gedownload en ingeladen model op te starten, die de API van OpenAI simuleert. Eens deze opgezet is, bijvoorbeeld op poort 1234, is het model aanspreekbaar via een call naar http://localhost:1234/v1/chat/completions .

Dit instellen in de Continue plugin gebeurt door de LLM toe te voegen aan het bestand .continue/config.json , volgens deze instructies en volgens de richtlijnen voor LM Studio als model provider. Daarbij kan je de titel en het model aanpassen naar eigen goeddunken, en hoef je enkel nog de lijn "apiBase":"http://127.0.0.1:1234/v1" toe te voegen. In de plugin zal je dit dan als nieuwe keuzemogelijkheid zien verschijnen, en kan je ermee aan de slag.

Intermezzo: over hardware

Het beheer van GPU’s is al geen pretje voor 1 developer aan 1 machine. Incompatibiliteitsproblemen tussen verschillende versies van allerlei software libraries en GPU-drivers kunnen dagen duren om op te lossen. Het marktaanbod van GPUs voor datacenters, gedomineerd door nVIDIA in een monopoliepositie, is onnoemelijk duur. Daarbij komt nog de kost van het opbouwen van de heel gespecialiseerde kennis die nodig is om die systemen draaiende te houden. Eender wat je kiest van hardware is over 4 jaar waarschijnlijk al helemaal verouderd. Er wordt hard gewerkt aan nieuwe hardware, specifiek gemaakt om het soort berekeningen van AI-modellen te versnellen – Google kwam eerder al met de TPU, maar andere fabrikanten zetten nu ook hard in op NPUs (Neural Processing Units), en sommigen durven directe concurrentie aan met nVIDIA.

Als je geen tijd hebt om te knoeien met GPU-drivers en niet de ambitie hebt om zelf modellen te trainen, dan is de mogelijkheid om ze te gebruiken op een gewone CPU meer dan welkom. Uiteraard ben je dan wel beperkt tot die LLMs of AI-modellen waarvan de grootte dat ook toelaat. Typische LLMs voor “thuisgebruik” hebben 3, 7 of 13 miljard parameters; grotere modellen worden agressief gekwantiseerd om schijfruimte en geheugen te besparen. Ze gaan vandaag nog niet kunnen tippen aan de kwaliteit van GPT-4, maar er bestaan gelukkig leaderboards om te helpen een keuze te maken – voor open LLMs in het algemeen, specifiek met (doorvoer)snelheidsbenchmarks, of voor code-genererende LLMs in het bijzonder.

Hoe groter de LLMs, hoe kwaliteitsvoller het resultaat (meestal), maar ook hoe meer geheugen en rekenkracht vereist is. Een LLM moet liefst volledig in het geheugen ingeladen kunnen worden, dus 16GB RAM is geen luxe – meer is beter, zeker als je een IDE op dezelfde machine wil draaien. Om een antwoord te kunnen te geven, moet het volledige model vaak meermaals doorlopen worden. De bottleneck wordt bijgevolg vaak gevormd door de bandbreedte tussen CPU en RAM. CPUs met een grote interne cache lijken een streepje voor te hebben (zie ook AI-specifieke benchmarks [1,2] van Anandtech). Bij de keuze van de rest van de hardware moet geheugenbandbreedte zeker meespelen. Ook wie een GPU zou willen kiezen, kijkt misschien liever naar die bandbreedte dan naar het aantal cores. Tot slot is het in gevirtualiseerde omgevingen (een VM, een VPS) belangrijk dat de virtuele CPU dezelfde geavanceerde instructiesets, zoals AVX-512, ondersteunt.

Een LLM op je server

Als je elders een krachtigere machine hebt, kan het de moeite waard zijn om de LLM daarop te draaien. ollama is waarschijnlijk de populairste tool om zonder veel poespas modellen te hosten op Mac of Linux, sinds kort ook Windows. LocalAI is echter een zeker zo interessante optie uit de lijst van mogelijke LLM providers voor Continue, want het biedt Docker containers aan, met of zonder GPU ondersteuning. Op een Linux machine die is uitgerust met Docker, is een oneliner in de terminal voldoende om het open-source CodeLlama model te downloaden en te beginnen hosten op poort 1234:

docker run -ti -p 1234:8080 localai/localai:v2.7.0-ffmpeg-core codellama-7b-gguf 

De opstart ervan duurt echter even, want het model wordt in de container gedownload. Interessanter is het om zelf een reeks modellen in een lokale map te bewaren, en daaromheen een API te zetten middels een LocalAI container. Ook voor die aanpak zijn relatief eenvoudige instructies beschikbaar. We kunnen ze bijvoorbeeld toepassen op de DeepSeek LLM van 6.7 miljard parameters, gekwantiseerd op 4 bits. Deze kan rechtstreeks van Huggingface gedownload worden naar de lokale map ./models-gguf met een wget commando van het type:

wget https://huggingface.co/TheBloke/deepseek-coder-6.7B-instruct-GGUF/resolve/main/deepseek-coder-6.7b-instruct.Q4_K_M.gguf -O ./models-gguf/deepseek-6.7b-instruct-Q4

Een API starten rondom de modellen in die map op poort 8001 (je kan ook meerdere modellen in dezelfde map zetten en ze tegelijk hosten), kan dan met het volgende commando. Voeg eventueel -d toe om het in de achtergrond te laten lopen, en voel je vrij om met de parameters context-size en threads te experimenteren in functie van hoe krachtig je server is:

docker run -p 8001:8080 -v $PWD/models-gguf:/models -ti --rm quay.io/go-skynet/local-ai:v2.7.0-ffmpeg-core --models-path /models --context-size 1600 --threads 16

Voorbeeld

We kunnen nu verschillende LLMs voor code met elkaar vergelijken. We houden het hier louter anekdotisch, en nemen als eenvoudig voorbeeld het schrijven van een bash shellscript. We vertrekken van het volgende probleem: een backup-routine heeft jarenlang een nachtelijke backup genomen van een systeem. Om schijfruimte vrij te maken, willen we alle backups verwijderen die niet verschillen van de vorige. We geven de volgende opdracht, waarbij we de taak zo nauwgezet mogelijk omschrijven voor het beste resultaat: “Write a bash script that, given a directory, iterates over all its files in order of date of creation. For each file, if the filesize is equal to the filesize of the previous file, the file has to be deleted.”

De .continue/config.json file van onze Continue plugin bevat de volgende lijst modellen: eentje op de eigen laptop in LM Studio ingeladen op poort 1234, en twee op een aparte server in het lokaal netwerk, door LocalAI gehost op poort 8001.

    {
      "title": "myLaptop-LMStudio",
      "model": "whatever is loaded in LMstudio",
      "apiBase": "http://127.0.0.1:1234/v1",
      "completionOptions": {},
      "provider": "lmstudio"
    },       
    {
      "title": "localAI-mistral",
      "model": "mistral-7b-code16kqlora-Q4",
      "apiBase": "https://192.168.0.100:8001/v1",
      "apiKey": "",      
      "completionOptions": {},
      "provider": "openai"
    },
    {
      "title": "localAI-deepseek",
      "model": "deepseek-6.7b-instruct-Q4",
      "apiBase": "https://192.168.0.100:8001/v1",
      "apiKey": "",
      "completionOptions": {},
      "provider": "openai"
    },

Als referentie nemen we ChatGPT, die komt met de volgende (correcte) oplossing. Bovendien wordt ze ook gevolgd door een uitgebreide uitleg over wat de verschillende onderdelen betekenen (hier niet weergegeven):

#!/bin/bash

# Directory containing the files
DIR="/path/to/your/directory"

# Variable to hold the size of the previous file. Initialized to 0.
prev_size=0

# List all files in the directory, sorted by creation date
# Note: '%T@' sorts by creation time, '%p' prints the file's name
# 'sort -n' ensures the list is sorted numerically
# Note that creation time sorting may depend on filesystem and OS support
files=$(find "$DIR" -type f -printf "%T@ %p\n" | sort -n | cut -d ' ' -f 2-)

# Iterate over the sorted list of files
for file in $files; do
  # Get current file size
  current_size=$(stat -c %s "$file")
  
  # Check if current file size is equal to the previous file's size
  if [ "$current_size" -eq "$prev_size" ]; then
    # Sizes are equal, delete the current file
    echo "Deleting file: $file"
    rm "$file"
  fi
  
  # Update previous size to current file's size
  prev_size=$current_size
done

In LMStudio laden we het model “CodeNinja 1.0 openchat 7B Q4_K_M” in. Voor het genereren van het antwoord op dezelfde vraag is ruim 1 minuut nodig: 20 seconden wachten tot de eerste letter van het antwoord verschijnt, daarna nog ongeveer 2 seconden per lijn. (Onze laptop is natuurlijk niet superkrachtig: een Core i7-10610U CPU met 32GB RAM). Het volgende komt eruit:

#!/bin/bash

for f in $(ls -t -l --time-style=full /path/to/directory)
do
  if [[ $f == "total"* ]]; then
        continue;
    fi
    filename=$(basename "${f% *}")

    # Checks whether the file is already deleted. If not, compares it with the previous file:
    prev_file=""
    while IFS= read -r line; do
        if [[ $line == $filename ]]; then
            prev_file=$line
            break;
        fi
    done <<<"$(ls -l /path/to/directory | tail -n 2)"

    if [[ -z $prev_file || "$f" = "${prev_file}" ]]; then
        # If the file is deleted, nothing to do. If not, deletes it:
        if [[ -z $prev_file ]] || [[ "$(stat -c %s ${filename})" == "$(stat -c %s ${prev_file})" ]]; then
            rm /path/to/directory/$filename
        fi
    fi
done

Het DeepSeek model van 6.7 miljard parameters laden we in LocalAI op een Debian VM in Proxmox. Aan de VM is ruim voldoende RAM toegekend, en 12 cores van de onderliggende hardware, een AMD Threadripper 3960X processor (24 cores maar geen AVX-512 ondersteuning). Hiermee creëren we aan een snelheid van ongeveer 3 lijnen per seconde het volgende resultaat:

#!/bin/bash

# Check if directory is provided
if [ $# -ne 1 ]; then
  echo "Usage: $0 directory"
    exit 1
fi

# Check if directory exists
if [ ! -d "$1" ]; then
    echo "Directory $1 does not exist"
    exit 1
fi

# Change to the directory
cd "$1"

# Get the list of files in order of creation date
files=$(ls -t)

# Initialize previous_size to 0
previous_size=0

# Iterate over the files
for file in $files; do
    # Get the size of the file
    size=$(stat -c%s "$file")

    # If the size is equal to the previous size, delete the file
    if [ $size -eq $previous_size ]; then
        rm "$file"
        echo "Deleted $file"
    fi

    # Update previous_size
    previous_size=$size
done

Tot slot kunnen we op dezelfde VM ook het recentere Mistral uitproberen, waarvoor we op goed geluk de versie mistral-7B-code-16K-qlora uitkiezen die door een andere gebruiker lichtjes werd bijgetraind voor code. Deze blijkt zeer snel te kunnen antwoorden, en genereert in ongeveer 2 seconden het volgende compacte resultaat (helaas zonder documentatie, en gebruikmakend van het complexe awk commando):

for file in $(find directory -type f -exec du -sh {} + | sort -h | awk '{print NR ":\t" $1}'); do
    size=$(du -sh "$file" | awk '{print $1}')
    if [[ $size == $previous_size ]]; then
      rm "$file"
    fi
    previous_size=$size
done

Ik laat de diepgaandere vergelijking van deze resultaten graag over als oefening aan de lezer. Als we hieruit nog een laatste les moeten leren, dan is het dat er ook tussen modellen onderling, zelfs al hebben ze dezelfde hoeveelheid parameters en zijn ze voor hetzelfde doel getraind, erg grote verschillen kunnen zijn qua output en stijl!

Conclusie

Aan sneltempo vinden allerlei AI-powered features hun weg naar de IDE. De laatste release notes van Visual Studio Code vermelden naast verschillende CoPilot features bijvoorbeeld ook ondersteuning voor spraakherkenning in meerdere talen. Het is onvermijdelijk dat je daar als developer mee in contact zal komen. Developers die werken met gevoelige data of copyrighted code, zijn terecht argwanend over het feit dat zulke tools hun IDE-inhoud naar een of andere clouddienst van een derde partij versturen, om suggesties te kunnen genereren.

Vooral dankzij het llama.cpp project, is er recent een alternatieve open-source route ontstaan die toelaat zulke coding assistentie met LLMs zelf op te zetten en uit te baten. Kleinere modellen die op consumentenhardware kunnen draaien, leveren momenteel niet dezelfde kwaliteit en snelheid als Github CoPilot of ChatGPT. De komende jaren zullen we echter regelmatig verdere verbeteringen zien verschijnen, dus de ingezette weg oogt alleszins veelbelovend.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

In een vorige blog gaven we reeds een uitvoerige inleiding van het “Reactive” paradigma. Vermits dit toch wel een belangrijke en invloedrijke zaak geworden is binnen de developer wereld, lijkt het ons nuttig om hier op terug te komen en wat dieper in te gaan op een voorbeeld van een Reactive framework: het Akka framework, één van de pioniers binnen de Reactive beweging.

Wat is Reactive alweer?

Reactieve systemen worden gezien als één van de belangrijkste ontwikkelingen om systemen responsiever te maken voor meer veeleisende eindgebruikers, en om overweg te kunnen met de grote hoeveelheid data die moderne systemen overspoelt. Zogenaamde “wearables” en andere IoT zaken kunnen bijvoorbeeld een constante stroom aan data genereren. Wanneer men dan de data van vele honderden van zulke devices moet verwerken, komen traditionele systemen vaak in de problemen. Maar ook voor ‘gewone’ toepassingen kan deze technologie heil brengen, doordat de responsiviteit en resiliëntie ook kunnen worden verhoogd.

Aan de grondslag van Reactive ligt het feit dat het “message driven” is (Zie Fig. 1). Men zal een systeem bouwen aan de hand van een aantal met elkaar communicerende subsystemen die berichten zullen uitwisselen. Dit kan zowel rechtstreeks als via het publish/subscribe mechanisme van Events. Deze communicatie is altijd inherent asynchroon. Men weet niet wanneer er op een bericht zal worden gereageerd en men gaat er ook niet expliciet op wachten. Deze vorm van communicatie tussen componenten zorgt ervoor dat ze losjes gekoppeld zijn en locatietransparant. Dit “message driven” fundament leidt verder tot verschillende voordelen.

Eerst en vooral zorgt dit voor resiliëntie. Asynchrone communicatie laat toe om componenten veel onafhankelijker van elkaar te laten opereren dan synchrone communicatie, wat ervoor kan zorgen dat één component verder kan indien de andere (tijdelijk) faalt. De manier waarop berichten behandeld worden bij Reactive maakt ook van foutmeldingen gewone berichten; men behandelt deze als ‘first class citizen’, en niet zozeer als een uitzondering. Het omgaan met fouten en met niet-werkende componenten wordt dan als van nature mee opgenomen in het programmeren van zo’n systeem.

Ten tweede stijgt ook de elasticiteit. Bij reactieve systemen is de berichtenstroom heel belangrijk. Men kan deze gaan monitoren en ingrijpen wanneer deze sterk in volume toe- of afneemt, en snel reageren door meer componenten op te starten (of te stoppen), om deze berichten af te handelen. Ook het feit dat het systeem bestaat uit een heel aantal samenwerkende componenten, en niet afhankelijk is van een centrale bottleneck, komt de schaalbaarheid ten goede.

Ten slotte moet dit alles samen zorgen voor een verhoogde responsiviteit. Men zorgt ervoor dat men tijdig en vooral binnen een bepaalde tijd kan reageren op alle binnenkomende berichten, voor een consistente Quality of Service.

Het Akka raamwerk

Akka zag het licht in 2009 als één van de eerste raamwerken die het principe van het Actor programmeermodel naar een mainstream server programmeertaal bracht. Het is beschikbaar zowel voor de programmeertaal Scala (een taal die werkt op de JVM), waar het in principe voor is gebouwd, als voor Java (waar het iets meer boilerplate code vergt). Tegenwoordig maakt het deel uit van het Lightbend platform, samen met het Play raamwerk en de taal Scala.

Actoren kan men zien als kleine onafhankelijke machines binnen een softwaresysteem. Ze communiceren enkel met de buitenwereld (en dus met andere actors) via asynchrone berichten. Wanneer een actor een bericht krijgt, kan deze een aantal verschillende dingen doen: lokale code uitvoeren, zijn eigen toestand veranderen, zelf berichten uitsturen, andere actoren creëren, en beslissen hoe op het volgende bericht zal worden gereageerd. Een actor leeft dus volledig binnen zijn eigen executie-stack. Men kan deze dus beschouwen als een apart proces of een aparte thread, maar in een raamwerk als Akka is het mogelijk om deze veel efficiënter te instantiëren dan dat (zelfs threads zijn nog relatieve zwaargewichten, terwijl een actor in akka maar een paar honderd bytes hoeft in te nemen; één thread zal dan ook typisch vele actors tegelijk aansturen). Daarnaast kan men er voor zorgen dat een actor een andere actor als “supervisor” krijgt. Deze zal in het oog houden of de gesuperviseerde actor faalt, en kan dus indien nodig gepast reageren.

Eén van de meest interessante zaken aan actors is dat het voor de programmeur transparant kan gemaakt worden waar een actor zich bevindt: het kan een andere actor binnen hetzelfde proces zijn, een actor binnen een ander proces op dezelfde machine, of een actor aan de andere kant van het internet: de programmeur kan deze op dezelfde manier behandelen. Dit is één van de eigenschappen die Akka Cloud Native maakt: het is een technologie gebouwd vóór de Cloud, waarmee men optimaal kan gebruik maken van de eigenschappen van de Cloud.

Naast de ‘core’ Akka bibliotheek, bestaan er ook nog heel wat modulaire uitbreidingen, zoals b.v. voor het werken met streams, persistentie, webservers en http, en allerlei integraties, zoals b.v. met het Play framework, of met Apache Kafka. Ook RESTful APIs worden ondersteund.

Een voorbeeld

In de code duiken zou een beetje te technisch worden, maar we kunnen toch illustreren wat men met deze manier van programmeren kan bereiken aan de hand van een eenvoudig voorbeeld.

In onderstaande figuur zie je een tekening van een aantal actoren in een boekenwinkel systeem en de berichten die ze elkaar sturen: er zijn klanten, de boekenwinkel zelf, en bedienden (die boeken opsturen). Het systeem zal als volgt werken: klanten sturen bestellingen naar de winkel; deze zal de bestellingen verder doorgeven aan een bediende. Deze hebben wat tijd nodig om een bestelling af te handelen, dus er zijn er meerdere, om meer bestellingen aan te kunnen. Hoe de winkel kiest welke taak aan welke bediende te geven, zouden we op verschillende manieren kunnen oplossen (b.v. “neem een willekeurige vrije bediende”), maar zoveel detail laten we hier niet zien.

De bediende die een bestelling krijgt wordt “bezig” (een andere toestand dan “vrij”) en zal uiteindelijk een boek terugsturen naar de klant (in het geval van het IT systeem dat dit systeem modelleert, kan dit b.v. een bericht zijn met de tracking code van het pakket). Daarna wordt de bediende terug “vrij”.

Soms gaat er echter iets mis met de bestelling: de bediende vindt b.v. het boek niet dat de klant wil. In dat geval stuurt deze een verontschuldigend bericht terug naar de klant, met een cadeaubon. Als er echter te vaak van deze dingen gebeuren, krijgt een bediende teveel stress en geeft deze er de brui aan (zijn actor gaat in error-modus). Dit geeft dus een foutmelding, die geëscaleerd wordt naar de supervisor van de bediende, in dit geval de winkel (zie Fig. 3). Deze zal dan moeten beslissen wat er met de fout gebeurt: we kiezen ervoor om de bestelling aan een andere bediende te geven en de gestresseerde bediende een paar dagen “verlof” te geven (waarna zijn actor terug in toestand “vrij” zal komen).

Dit voorbeeld illustreert het principe van resiliëntie, gebruikmakende van actoren: de fout wordt niet speciaal als fout behandeld, maar als een bericht naar de winkel, die het probleem op dat niveau kan oplossen. Er wordt ook niet alleen gezorgd voor fout-tolerantie, maar ook voor veerkracht: uiteindelijk zal de foutieve actor worden hersteld en terug ter beschikking komen van de pool. Deze veerkracht maakt net het verschil tussen gewone fout-tolerantie en echte resiliëntie.

Besluit

De meeste bestaande raamwerken voor Reactive systemen focussen zich op het gebruik van streams van berichten/events, en op hoe deze zo efficiënt mogelijk te behandelen. Een raamwerk zoals Akka doet het net iets anders, door gebruik te maken van het actor paradigma. Dit biedt een verfrissende kijk op multi-threaded programming, en kan het bouwen van sommige systemen net iets gemakkelijker maken.

Het gebruik van actoren verhoogt in ieder geval het niveau van abstractie wanneer men over parallellisme en multi-threading probeert te redeneren, een oefening die berucht is voor zijn moeilijkheid.

Actors lijken erg nuttig voor het modelleren van zaken die een toestand en een gedrag vertonen in de echte wereld, zoals mensen, machines, of bedrijven. In het algemeen zijn ze goed inzetbaar wanneer je systeem goed decomposeerbaar is in een set van onafhankelijke taken, of een set van taken die een bepaalde workflow volgt. Ten slotte zijn ze ook erg geschikt voor het programmeren van Event Driven systemen.

Maar goed, ter zake! Wat brengt Java 7 ons voor vernieuwingen?

Ik moet echter beginnen met een disclaimer: na jaren van ontwikkeling is er natuurlijk heel wat meer bijgekomen in de taal dan ik hier kan beschrijven. Mijn oplijsting is dus niet exhaustief. Het blijkt trouwens vrij moeilijk om een perfect juist beeld bij elkaar te googlen van wat er nu precies wél of niet inzit, en daarbij ook nog eens een goede uitleg over deze zaken te krijgen (maar vandaar ook het nut van een blogpost als deze).

De vernieuwingen dan:

Eerst de zaken die we niet meteen met het blote oog kunnen zien: de virtuele machine heeft een hele evolutie doorgemaakt sinds het begin van Java, en in versie 7 is er voor gezorgd dat er goede support is voor dynamische talen, zoals Groovy. Deze talen zullen nu quasi even performant zijn als Java zelf (no pun intended). Verder zijn er een aantal zaken verbeterd betreffende class loaders, die voor minder bugs zorgen wanneer er meerdere van gebruikt worden, en er is nu ook een URLClassLoader.

Ook de ondersteuning voor parallelisme is nog wat beter geworden, met nieuwe klassen in het concurrency framework zoals de ForkJoinPool en de TransferQueue. Dit lijken mij goeie toevoegingen, maar de ondersteuning voor multithreading, met een hoog niveau van abstractie, was reeds erg goed. Ik bespreek dit raamwerk graag nog uitgebreider in een toekomstige blogpost. Multithreading zal zeker nog aan belang winnen in de toekomst, wanneer we meer en meer cores in onze computers krijgen.

Wat IO en netwerken betreft, zijn er voorts nog een aantal interessante toevoegingen, zoals een vernieuwing van de IO api (New IO: “NIO”), scp en sctp ondersteuning, gebruik van windows vista ipv6 en, last but not least: TLS 1.2 (ook wel SSL 3.3 genoemd).

Voor de security mensen: Elliptic Curve Cryptography is nu out-of-the-box beschikbaar.

En dan één van mijn stokpaardjes: de client, en Swing! Er is nu een nieuwe rendering-pipeline voor Java2D, waardoor een aantal features van moderne gpu’s ter beschikking komen te staan. Verder is er ondersteuning voor translucente en onregelmatig gevormde vensters, een nieuwe Look and Feel, en een nieuwe sound synthesizer. En ten slotte, zoals gewoonlijk, zijn een aantal zaken van SwingLabs gemigreerd naar de standaard Swing api.

Tot zover de ‘saaiere’ vernieuwingen; de echte vraag die echter op ieders lippen ligt, is natuurlijk: Wat zijn de nieuwe dingen die we kunnen doen als programmeur? Give us the language features!

Een eerste kleine verbetering, is de mogelijkheid om Strings te gebruiken in een switch statement. Persoonlijk vind ik dit niet supernuttig, dus ik ga er ook geen voorbeeld van geven. Volgens mij zijn enums veel beter geschikt om ‘of-of-of’ constructies op poten te zetten, en is een goed uitgedacht design, gebruik makende van polymorfisme en dynamische binding, meestal zowiezo een beter alternatief. Maar goed, het was een zinloze beperking, en het is goed dat deze nu is weggewerkt.

Next! Naast hexadecimale, octale en (gewone) decimale getallen, komt er nu ook een voorstellingswijze voor binaire getallen: ik moet zeggen: in quasi alle gevallen: blijf er van weg! Wat wel interessant is, is dat men nu underscores in getallen kan plaatsen om de leesbaarheid te verhogen. Zo is b.v. 1_000_000 vanaf nu een correcte en beter leesbare voorstellingswijze voor het getal 1000000. Ook in de andere voorstellingswijzen, en in floating point getallen, kan men ze gebruiken. Een getal moet wel nog altijd met een cijfer starten en eindigen.

Nog een kleine, eenvoudige verbetering is type inferentie bij het aanroepen van de constructor van generische klassen. Stel: je declareert een List<String> en je wil deze lijst initialiseren als een arraylist. Vroeger moest je dan als volgt de constructor aanroepen: new ArrayList<String>(). Met type inferentie wordt dit gewoon: new ArrayList<>(). De compiler is dus eindelijk slim genoeg geworden om te raden welk type je wou maken. Bemerk dat er nog steeds een diamandje “<>” nodig is, anders heb je een raw type. Vandaar dat men deze verbetering “diamond” heeft gedoopt. Eenvoudig en handig.

Een iets minder voor de hand liggende taaluitbreiding, is automatic resource management (ARM). De standaard manier van werken om een InputStream of File terug vrij te geven in geval van onverwachte gebeurtenissen, is dit in een finally clausule te zetten ( finally { file.close(); } ). Dit kan echter problemen opleveren wanneer je meerdere close-statements moet uitvoeren en de eerste close-methode zelf een foutmelding geeft, waardoor de erop volgende close-statements niet meer worden uitgevoerd. De nieuwe manier van werken, is de resources aan te maken in een statement, ingesloten in haakjes, volgende op het ‘try’-keyword. Een beetje zoals de declaratie van de teller in een for-statement. Bijgevolg krijg je dan iets als volgt: try (InputStream i = …; OutputStream o = …) {…} finally {/*niet meer nodig*/}. Achter de schermen zou dit dan werken alsof men recursieve try-finally statements gebruikt om alle mogelijke fouten op te vangen (dus de eerste close zit nog in een extra try blok, gevolgd door een finally block met daarin de tweede close; het geheel van deze try-finally zit op zijn beurt in het finally blok van de uit te voeren code). Je kan je inbeelden dat, als je dit manueel moest doen voor meer dan twee resources, er nogal wat boilerplate code aan te pas kwam; dit is dus een vrij nuttige feature.

De laatste taaluitbreiding die ik wil bespreken, heeft opnieuw met exception-handling te maken, ditmaal met het catch-blok. Bij het loggen van excepties die men niet onmiddellijk kan afhandelen, zal men deze vaak vangen, loggen, en dan opnieuw gooien. Vaak heeft men echter een try-blok dat verschillende soorten uitzonderingen kan gooien, waardoor men hetzelfde stukje code moet herhalen in een hele resem catch-blokken. Een superklasse gebruiken voor het catch-blok is vaak gevaarlijk, omdat er eventueel exceptie-types kunnen omvat worden waarvoor dit in eerste instantie niet de bedoeling was. Wanneer men b.v. het type “Exception” gebruikt, omvat dit alle mogelijke RuntimeExceptions, terwijl men misschien enkel een aantal niet-gerelateerde checked exceptions wou opvangen. De boilerplate code die hierbij komt kijken, kan men nu voor een deel schrappen, doordat men in de catch-expressie nu een lijst van types kan geven, gescheiden door verticale of-strepen ( “|” ). Men zou bijvoorbeeld kunnen zeggen: catch (NullPointerException | IndexOutOfBoundsException e) {log(e); throw e;}, in plaats van voor elk type uitzondering een apart catch-blok te maken. Ik had nog niet echt stilgestaan bij deze problematiek, maar ik denk wel dat het kan helpen om robuuste code te maken, voorzien van alle toeters en bellen om ze “enterprise-ready” te maken.

Meer uitleg betreffende de kleine, handige taaluitbreidingen, kan je vinden op de site van Project Coin. Een aantal goeie voorbeelden kan je bekijken op een presentatie die een tijdje terug op JavaOne is gegeven.

Tussen haakjes: tijdens mijn zoektocht ben ik ook de filosofie van Java nog eens tegengekomen, wat betreft het evolueren van de taal:

• Reading is more important than writing
• Code should be a joy to read
• The language should not hide what is happening
• Code should do what it seems to do
• Simplicity matters
• A clear semantic model greatly boosts readability
• Every “good” feature adds more “bad” weight
• Sometimes it is best to leave things out

Of deze principes tot nu toe trouw gevolgd zijn, laat ik over aan de lezer.

En als afsluiter: wat zit er niet in? Een aantal zaken zijn reeds lang in ontwikkeling, maar voorlopig blijkbaar toch nog iets te moeilijk: Doorgedreven modularisatie is o.a. al zeker tot Java 8 uitgesteld. Ook de veelgeplaagde, vaak gevraagde closures (Project Lambda), zijn voorlopig nog even terug in de kast gestoken, alsook een meer directe taalondersteuning voor het collection framework. Meer geluk eind 2012?