La conversion `java int to string` paraît élémentaire, mais le bon choix dépend du contexte: affichage simple, logs, base 2 ou 16, ou sortie destinée à un utilisateur. En Java, plusieurs méthodes donnent le même résultat pour un entier décimal, mais elles ne sont pas interchangeables dès qu’on sort du cas standard. Je vais te montrer celles que j’utilise, les pièges à éviter et la manière la plus propre de garder un code lisible.
Les points à retenir avant de choisir votre méthode
- Pour un `int` décimal standard, `String.valueOf(n)` et `Integer.toString(n)` donnent le même résultat.
- `String.valueOf(n)` est souvent le choix le plus lisible quand je veux une conversion simple et directe.
- Pour une autre base, `Integer.toString(n, radix)` couvre le binaire, l’hexadécimal et les cas intermédiaires.
- Si la variable est un `Integer` nullable, `String.valueOf(obj)` évite une `NullPointerException` là où `obj.toString()` peut casser.
- Pour un affichage destiné à un utilisateur français, je préfère un formatage localisé à une conversion brute.
- `"" + n` fonctionne, mais je le réserve aux cas rapides ou aux prototypes.
La conversion la plus directe en Java
Quand je convertis un `int`, je pars presque toujours de `String.valueOf(n)` ou de `Integer.toString(n)`. Pour un entier primitif, ces deux appels produisent une représentation décimale identique, sans détour inutile ni création d’objet intermédiaire. En pratique, le vrai critère n’est pas la “magie” de la conversion, mais la lisibilité du code pour la personne qui le maintiendra demain.
int age = 42;
String s1 = String.valueOf(age);
String s2 = Integer.toString(age);Je retiens surtout une chose: si ton besoin est simplement “transformer un nombre en texte”, inutile de compliquer. La différence entre ces deux formes est faible, et dans un code propre, je choisis souvent celle qui rend l’intention la plus évidente. La vraie question devient donc: quelle méthode est la plus adaptée au contexte ?
Quelle méthode choisir selon le contexte
Pour sortir du réflexe automatique, je compare les options selon l’usage réel. Le tableau ci-dessous résume les cas les plus fréquents et évite de surcharger le code avec une méthode trop sophistiquée pour un besoin simple.
| Méthode | Ce qu’elle fait | Quand je l’utilise | Limites |
|---|---|---|---|
String.valueOf(n) |
Retourne la chaîne décimale du `int` | Par défaut, pour un besoin clair et lisible | Ne formate pas le nombre pour l’utilisateur |
Integer.toString(n) |
Retourne la même chaîne décimale | Quand je veux une API centrée sur le type `int` | Pas de mise en forme locale |
"" + n |
Concatène le nombre à une chaîne vide | Petits scripts, debug, code très ponctuel | Moins explicite dans une base de code sérieuse |
String.format("%d", n) |
Insère le nombre dans un modèle de texte | Quand la conversion fait partie d’une phrase plus large | Plus lourd qu’une conversion simple |
NumberFormat |
Formate selon la locale | Interfaces utilisateur, affichage français, séparateurs de milliers | Ce n’est plus une conversion brute |
Mon réflexe est simple: conversion brute pour du code technique, formatage localisé pour de l’affichage humain. Cette distinction évite beaucoup d’erreurs, surtout dans les applications qui mêlent backend, logs et interface utilisateur. Et dès qu’on a besoin d’une base autre que 10, il faut passer à une autre variante.
Passer à une autre base sans se tromper
Java ne limite pas la conversion à la base décimale. Avec Integer.toString(n, radix), on peut écrire un entier en binaire, en octal, en hexadécimal, ou dans toute base comprise entre 2 et 36. C’est utile pour les masques de bits, les identifiants techniques, les flags, ou les outils de diagnostic bas niveau.
int n = 255;
String decimal = Integer.toString(n, 10); // "255"
String binary = Integer.toString(n, 2); // "11111111"
String octal = Integer.toString(n, 8); // "377"
String hex = Integer.toString(n, 16); // "ff"Je fais attention à deux points. D’abord, le radix doit rester dans la plage attendue, sinon Java retombe sur la base 10. Ensuite, une valeur négative garde son signe moins dans la représentation signée. Si ton cas d’usage demande une lecture “non signée”, il faut regarder du côté de Integer.toUnsignedString(n, radix). C’est plus rare, mais indispensable quand on manipule des représentations binaires proches du matériel ou des protocoles.
Autrement dit, dès qu’on quitte le décimal, la question n’est plus “comment convertir un int”, mais “quelle représentation veux-tu vraiment produire ?”. Cette nuance change la qualité du résultat final.
Le cas des `Integer` nuls et de l’autoboxing
Pour un `int` primitif, il n’y a pas de valeur nulle. Le piège arrive avec Integer, le wrapper objet, parce qu’un objet peut être `null`. Dans ce cas, String.valueOf(obj) est plus sûr que obj.toString(), car la première forme peut retourner la chaîne "null" alors que la seconde peut déclencher une `NullPointerException`.
Integer boxed = null;
String a = String.valueOf(boxed); // "null"
String b = boxed.toString(); // NullPointerExceptionJe vois souvent ce bug dans du code qui a été écrit vite, puis oublié. L’autoboxing masque le problème pendant un moment, jusqu’au jour où une donnée absente remonte depuis une API, une base ou un formulaire. Si tu veux éviter l’ambiguïté, teste explicitement la nullité et choisis une valeur de repli claire:
String result = boxed == null ? "" : String.valueOf(boxed);Ce détail vaut le coup d’être traité proprement, surtout dans du code de production où une simple conversion peut devenir un point de rupture.
Conversion brute ou affichage localisé
Je distingue toujours la conversion technique de l’affichage métier. Une conversion brute donne des chiffres sans décoration, ce qui est parfait pour un identifiant, un log applicatif ou un payload JSON. En revanche, dès qu’il faut montrer le nombre à un utilisateur en France, un format localisé est souvent plus approprié: séparateurs de milliers, conventions régionales, lisibilité immédiate.
NumberFormat format = NumberFormat.getIntegerInstance(Locale.FRANCE);
String display = format.format(1000000);Ce choix change vraiment l’expérience de lecture. Un million affiché comme une simple suite de chiffres n’a pas le même impact qu’un nombre formaté selon la locale. Pour une interface, je préfère donc une vraie stratégie d’affichage plutôt qu’une conversion technique recyclée au dernier moment. C’est plus robuste, et surtout plus honnête vis-à-vis de l’utilisateur.
À l’inverse, si le nombre sert à identifier une ressource, à construire une clé ou à passer dans un protocole, je garde la forme brute. Mélanger les deux mondes crée des bugs subtils, surtout quand une chaîne “jolie” finit là où une chaîne “exacte” était attendue.
Les réflexes que je garde pour un code propre
Avec le temps, j’ai gardé quelques règles simples. Elles évitent les surcouches inutiles et réduisent les surprises au moment de la maintenance.
- Je choisis `String.valueOf(n)` ou `Integer.toString(n)` pour une conversion décimale directe.
- Je passe à `Integer.toString(n, radix)` dès que la base n’est plus 10.
- J’utilise `NumberFormat` pour l’affichage humain, pas pour un échange technique.
- Je traite explicitement les `Integer` potentiellement nuls.
- J’évite de créer un wrapper juste pour obtenir une chaîne.
Si je devais résumer l’approche la plus saine, je dirais ceci: garde la conversion simple tant que le besoin reste simple, puis change d’outil dès que le format de sortie devient un vrai sujet métier. C’est exactement ce qui permet d’écrire un Java plus lisible, plus prévisible et plus facile à faire évoluer.
