JSqlParser : un analyseur SQL en Java, du texte à l'arbre et retour

Ce que JSqlParser résout concrètement

JSqlParser s'adresse aux développeurs Java qui doivent manipuler du SQL sans passer par une base de données. Le problème est simple : une requête est une chaîne de caractères, mais pour la valider, la réécrire ou l'analyser, il faut une structure. JSqlParser transforme cette chaîne en une hiérarchie d'objets Java, un arbre de syntaxe abstraite (AST). L'exemple du README montre une requête SELECT 1 FROM dual WHERE a = b, qui devient un objet PlainSelect avec des SelectItem, une Table et une expression EqualsTo. L'intérêt est double : on peut parcourir l'arbre avec le pattern Visiteur pour extraire des informations, et on peut construire un arbre en Java pour générer du SQL. C'est un outil pour les projets qui ont besoin d'analyser des requêtes dynamiques, comme les outils de formatage, de traçabilité ou de traduction entre dialectes. Le README mentionne des projets frères, JSQLFormatter et JSQLTranspiler, qui utilisent justement cette capacité. Si vous n'avez pas ce besoin, un simple regex peut suffire, mais dès que la requête devient complexe, une vraie grammaire est nécessaire.

Une grammaire pour douze dialectes, un choix risqué

Le README annonce une grammaire unique pour couvrir le standard SQL et douze dialectes : BigQuery, Snowflake, DuckDB, Redshift, Oracle, MS SQL Server, Sybase, PostgreSQL, MySQL, MariaDB, DB2, H2, HSQLDB, Derby, SQLite. C'est un pari audacieux. Chaque dialecte a ses particularités, comme les hints Oracle, les crochets T-SQL ou les politiques RLS de PostgreSQL. Le README précise que les syntaxes manquantes sont ajoutées à la demande, en ouvrant une issue. Cela signifie que la couverture n'est pas exhaustive et que vous pourriez tomber sur une syntaxe non supportée. La gestion de l'ambiguïté entre les crochets T-SQL et les littéraux de tableau est citée comme un exemple de complexité. Pour un projet qui vise une large compatibilité, c'est un compromis : une seule grammaire simplifie la maintenance, mais chaque dialecte est moins bien couvert qu'un parseur dédié. Si votre application ne cible qu'un seul SGBD, un parseur spécifique pourrait être plus fiable.

Le mécanisme : un AST navigable et réversible

Le cœur de JSqlParser est l'API CCJSqlParserUtil.parse, qui prend une chaîne SQL et retourne un objet Statement. Dans l'exemple du README, on caste le résultat en PlainSelect, puis on accède aux éléments : selectItems, fromItem, where. Chaque nœud est un objet typé, comme LongValue pour les nombres, Column pour les colonnes, EqualsTo pour les comparaisons. Le pattern Visiteur permet de parcourir l'arbre sans écrire des switch interminables. La particularité est que le modèle est réversible : on peut construire un arbre avec une API fluide et le rendre en SQL. Cela ouvre des cas d'usage comme la modification ciblée d'une requête : on parse, on modifie un nœud, on re-sérialise. Le README mentionne que la même hiérarchie sert à la construction et à l'analyse, ce qui est un gain de cohérence. Cependant, cette double fonction impose des contraintes de conception qui peuvent rendre certains nœuds plus complexes qu'un simple parseur.

Installation et versions : un point critique

Le README est très clair sur ce point : il recommande d'utiliser les builds Manticore, publiés en continu, plutôt que l'artefact historique com.github.jsqlparser sur Maven Central, qu'il qualifie de considérablement plus ancien. La dépendance Maven est com.manticore-projects.jsqlformatter:jsqlparser avec une version [5.3.218,), ce qui signifie que vous obtiendrez la dernière version 5.3.x. Pour Gradle, c'est implementation("com.manticore-projects.jsqlformatter:jsqlparser:+"). Il existe aussi une version 5.3 sous com.github.jsqlparser, mais le README la déconseille implicitement. C'est un point déroutant : le projet s'appelle JSqlParser, mais la distribution principale est sous un groupe Maven différent. Si vous utilisez l'artefact historique, vous risquez de manquer des correctifs et des améliorations de performance. Vérifiez bien quelle version vous tirez dans votre build.

Performances annoncées : à prendre avec précaution

Le README affirme des performances spectaculaires : 11 fois plus rapide que la version 5.3, et 19 fois plus rapide que sqlglot[c] sur la suite de tests SELECT. Un benchmark est fourni avec des chiffres précis : 7,6 ms par opération pour la version latest contre 84,7 ms pour 5.3. Ces résultats proviennent d'un dépôt externe, jsqlparser-bench, et la méthodologie est décrite. Mais il faut être prudent. Ces benchmarks sont réalisés par le projet lui-même, sur ses propres requêtes, et la comparaison avec sqlglot[c] peut être biaisée selon les cas. Pour un usage réel, la performance dépend de la complexité de vos requêtes et de la fréquence d'analyse. Si vous analysez des milliers de requêtes par seconde, ces chiffres sont importants, mais si c'est pour un usage ponctuel, la différence est négligeable. Je recommande de reproduire le benchmark sur vos propres requêtes avant de vous fier à ces affirmations.

Le piped SQL : une fonctionnalité en devenir

Le piped SQL est une syntaxe qui écrit les requêtes dans l'ordre d'exécution, comme FROM puis WHERE puis AGGREGATE, au lieu de l'ordre historique SELECT FROM WHERE. JSqlParser annonce un support progressif. Le README donne un exemple complet avec des pipes |> et des étapes AGGREGATE et ORDER BY. C'est une fonctionnalité intéressante pour les utilisateurs de BigQuery ou DuckDB, qui promeuvent cette syntaxe. Mais le mot clé est « progressif » : cela signifie que toutes les constructions piped ne sont pas encore gérées. Si votre code utilise des fonctionnalités avancées comme des fenêtres ou des jointures dans ce contexte, vous pourriez rencontrer des erreurs de parsing. C'est un point à vérifier si vous avez besoin de cette syntaxe. Le README renvoie à des ressources externes, comme le papier de recherche de Google, ce qui montre que le projet suit de près les évolutions du domaine.

Limites et alternatives : où le bât blesse

La principale limite est la couverture des dialectes. Avec une seule grammaire, il est impossible de gérer toutes les subtilités de chaque SGBD. Par exemple, les hints Oracle ou les politiques RLS de PostgreSQL sont mentionnés, mais il y a forcément des angles morts. Le README indique que les syntaxes manquantes sont ajoutées à la demande, ce qui implique que vous devrez peut-être contribuer ou attendre une issue. Une autre limite est la version Java : JSqlParser 5.x nécessite JDK 11 pour l'exécution, et la compilation requiert une toolchain JDK 17 pour la version 5.1 et plus. Si vous êtes sur Java 8, vous êtes bloqué à la version 4.9, qui n'a plus les améliorations récentes. Côté alternatives, le README mentionne JOOQ, un parseur écrit à la main, avec une licence double (commerciale et open source). JOOQ offre une traduction entre dialectes et une transformation SQL, mais il est payant pour un usage commercial. La différence d'approche est nette : JOOQ mise sur une couverture par dialecte avec des modules dédiés, tandis que JSqlParser tente une grammaire unifiée. Selon votre besoin, l'une ou l'autre approche sera plus adaptée.

Maintenance et licence : ce qu'il faut savoir

Le projet est actif, avec des versions 5.1, 5.2 et 5.3 publiées entre janvier et mai 2025, et un dernier push en mai 2025. La licence est Apache-2.0, ce qui est permissif pour une utilisation commerciale, sans obligation de partager vos modifications. C'est un point positif par rapport à JOOQ, qui a une licence commerciale. Cependant, la maintenance est assurée par la communauté, et le README mentionne que les versions Manticore sont publiées en continu, ce qui suggère un rythme soutenu mais aussi une dépendance à un acteur tiers (Manticore Projects). Pour les mises à jour, le coût est modéré : l'API est stable depuis la version 5.0, mais les changements dans les visitors (mentionnés dans le guide de migration) peuvent casser du code. Il faut prévoir un travail de mise à jour si vous passez de 4.9 à 5.x. Enfin, vérifiez que l'artefact Manticore est bien celui que vous voulez, car le nom de groupe différent peut créer de la confusion dans les audits de dépendances.

Conclusion éditoriale

Adoptez JSqlParser si vous devez analyser ou générer du SQL en Java, notamment pour des outils de validation, de reformatage ou de transpilation. Évitez-le si votre besoin se limite à un seul dialecte et que vous cherchez un parseur maintenu par une entité commerciale, ou si vous ne pouvez pas tolérer les versions 5.x qui exigent JDK 11 et une toolchain JDK 17 pour la compilation. Avant de l'intégrer, vérifiez que votre dialecte cible est bien couvert par la grammaire, en particulier pour les syntaxes récentes comme les requêtes pipe, et testez la version Manticore (com.manticore-projects.jsqlformatter) plutôt que l'artefact historique com.github.jsqlparser, dont le README affirme qu'il est nettement plus ancien. La version 5.3, par exemple, ne gère pas encore tout le piped SQL, donc un test sur vos requêtes réelles est indispensable.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes