Red Hat pèse déjà plus de 33 millions d’installations sur le marché des outils Java, devant Oracle qui plafonne à 25 000. Pourtant, l’entreprise travaillerait sur quelque chose de plus ambitieux qu’une simple extension. Voici ce que les signaux disponibles permettent d’établir.
L’écosystème Java open source de Red Hat en 2024
Red Hat ne part pas de zéro. Depuis 2016, l’entreprise a construit une présence structurée autour de plusieurs outils Java open source qui coexistent sans se remplacer vraiment.
L’extension vscode-java, lancée par Gorkem Ercan en mai 2016, a posé les fondations. Sa démonstration lors du keynote DevNation, puis le hackathon de Zurich avec Microsoft, IBM et CodeEnvy ont ancré Red Hat comme acteur central du support Java dans les éditeurs modernes. L’extension repose sur le protocole LSP (Language Server Protocol), ce qui la rend portable au-delà de VS Code.
À cette base s’ajoutent deux environnements de développement cloud : Eclipse Che, environnement basé sur le navigateur, et OpenShift Dev Spaces, sa déclinaison intégrée à la plateforme OpenShift. Ces outils s’adressent aux équipes qui travaillent dans des contextes containerisés et veulent éviter l’installation locale de toute la chaîne de développement.
La trajectoire est donc cohérente : Red Hat pousse depuis huit ans vers des environnements Java reproductibles, cloud-compatibles, et entièrement open source. Un IDE dédié s’inscrirait dans cette logique, pas comme un pivot, mais comme une consolidation.
Pourquoi Red Hat mise sur un IDE Java dédié?
VS Code a absorbé une large partie des développeurs Java ces dernières années. La communauté Java sur cet éditeur dépasse 2,5 millions de développeurs actifs, selon les données publiées par l’écosystème. Red Hat en est le premier fournisseur d’outillage, loin devant Oracle.
Le problème, c’est que VS Code reste un éditeur généraliste. Les fonctionnalités Java spécifiques – gestion des dépendances Maven/Gradle, débogage d’applications distribuées, intégration Quarkus – restent fragmentées entre plusieurs extensions qui ne partagent pas toujours bien leur état.
IntelliJ IDEA de JetBrains domine les environnements de développement Java professionnels, avec une version Community Edition open source mais fonctionnellement limitée. Oracle, de son côté, n’a jamais réussi à imposer NetBeans comme référence depuis son acquisition. Red Hat aurait donc une fenêtre réelle pour proposer une alternative crédible, cohérente, et alignée avec ses propres stacks techniques (Quarkus, OpenShift, Podman).
Ce que l’on sait des fonctionnalités attendues
Aucune feuille de route officielle n’a été publiée à ce stade. Les caractéristiques pressenties s’appuient sur l’existant et sur la direction que prend l’outillage Red Hat.
- Support natif du Language Server Protocol : la base technique est déjà là avec eclipse.jdt.ls, le serveur Java maintenu par Red Hat et Eclipse.
- Intégration Quarkus de première classe : génération de projets, hot reload, configuration des extensions Quarkus directement depuis l’IDE.
- Débogage cloud-natif : connexion directe à des pods OpenShift ou des conteneurs Podman sans configuration manuelle de tunnels.
- Compatibilité DevWorkspace : les fichiers de configuration DevWorkspace utilisés dans Eclipse Che pourraient devenir le format de référence pour les projets ouverts dans l’IDE.
- Interface basée sur Electron ou équivalent : hypothèse plausible si Red Hat vise une distribution desktop multiplateforme sans dépendance à VS Code.
Ce dernier point reste incertain. Red Hat pourrait tout aussi bien opter pour une distribution packagée de VS Code avec son propre profil – ce que fait déjà partiellement OpenShift Dev Spaces en contexte cloud.
Red Hat reste en avance sur les autres acteurs open source Java
Eclipse IDE existe depuis 2001 et reste utilisé, notamment dans les grandes organisations industrielles. Mais son adoption stagne. L’interface date, l’expérience utilisateur a vieilli, et la fondation Eclipse n’a pas les ressources pour rivaliser avec l’investissement de JetBrains ou de Microsoft sur VS Code.
VS Codium – la version sans télémétrie de VS Code – attire les développeurs soucieux de leur vie privée, mais ne résout pas le problème de fragmentation des extensions Java. IntelliJ Community Edition manque des fonctionnalités professionnelles (débogage avancé, support complet des frameworks d’entreprise) que la version payante réserve à ses abonnés.
Avec 33 millions d’installations de son extension vscode-java, Red Hat a déjà une base de confiance que personne dans l’open source Java ne peut revendiquer à ce niveau. C’est un avantage de distribution considérable au moment de lancer un nouvel outil.
Quel impact pour les équipes Java qui utilisent déjà les outils Red Hat?
Pour les développeurs qui travaillent avec l’extension VS Code de Red Hat au quotidien, la transition serait probablement peu coûteuse. La configuration LSP, les profils de build Maven ou Gradle, les paramètres de débogage – tout cela pourrait migrer sans friction si l’IDE cible conserve la même base technique.
Les équipes sur OpenShift Dev Spaces ou Eclipse Che ont un peu plus à anticiper. Ces environnements reposent sur des fichiers DevWorkspace et des images de développement containerisées. Si le nouvel IDE adopte ce format, la migration devient une opportunité de standardiser ce qui existe déjà. Sinon, il faut reconfigurer.
Le vrai enjeu pour les équipes n’est pas l’outil lui-même, c’est la gouvernance. Un IDE open source porté par Red Hat restera sous la coupe de sa stratégie produit – comme l’a montré l’évolution de CentOS. Les équipes qui s’appuient dessus auraient intérêt à surveiller le modèle de licence dès le premier commit public.