Skip to main content

Notes from Building an IntelliJ IDEA Plugin

· 5 min read
tanzhuo

I had been using a plugin called MyBatis Log Plugin, and the SQL log parameter-filling feature was the part I really liked. Older versions were apparently free, but newer versions became paid. So I decided to build a plugin with similar functionality myself, named mybatis log analysis. For version 1.0.0, the plan is to ship the basics first: SQL log parsing with automatic parameter filling, plus SQL beautification.

Why Build This Plugin​

Anyone who writes business code with MyBatis knows the feeling: the SQL printed to the console is a prepared statement full of ? placeholders, with the parameters printed on a separate line. When you're debugging and want to paste that SQL into a database client to run it directly, you have to fill the parameters back in by hand — and with more than a few parameters, that gets tedious and error-prone fast. Parameter-filling plugins solve exactly this small but high-frequency chore. So when the plugin I relied on went paid, my first instinct wasn't to hunt for an alternative — the feature itself is no mystery, so why not write my own, and use it as an excuse to learn the whole IDEA plugin development path along the way.

Feature Plan​

Version 1.0.0 covers the core, most-used parts first:

  1. SQL log parsing with automatic parameter filling;

  2. SQL beautification (formatted output, making long SQL easier to read).

Later, when time allows, I'll build out the other features: xml/java navigation links, one-click generation of controller, service, entity, mapper, and xml files, and so on.

Version 1.0.0 is already finished and submitted to the IDEA plugin repository.

How Parameter Filling Works​

The mechanism isn't complicated. With the log level set to DEBUG, MyBatis splits one query into two lines of output:

==>  Preparing: select * from user where id = ? and status = ?
==> Parameters: 1024(Long), 1(Integer)

The Preparing line is the prepared SQL with placeholders; the Parameters line lists the parameter values in order, with each value's Java type in parentheses. The plugin's job is to pair the two lines up:

  1. Locate adjacent Preparing and Parameters lines in the log text;

  2. Split the parameter list on commas, and use the type in parentheses to decide how to splice each value in — strings and dates need quotes, numbers are substituted as-is;

  3. Fill the processed parameters back into the ? placeholders in order, producing a complete statement that can be executed directly;

  4. Finally run it through SQL formatting and output the beautified result.

The core logic is just text parsing plus string substitution. What actually eats the time is the IDE integration: how to register a tool window, how to listen to console output, how to hook actions into menus — all of which means dealing with the IntelliJ Platform APIs.

What the Development Process Felt Like​

While building the plugin, simple features were simple to implement, but anything more sophisticated demands a fairly deep understanding of the APIs IDEA exposes — and I couldn't find comprehensive API documentation on the official plugin docs site, only some official demo code. So there was no choice but to spend time reading and digesting the demos. It makes for a rather unfriendly learning curve.

This is very different from everyday business development. With business frameworks the docs usually work like "look up the API, check the example, use it" — whereas on the IntelliJ Platform you mostly feel your way forward through three channels: browsing the official demo repositories, reading the platform source directly, and studying how other open source plugins implement similar features. When you don't know which extension point to use, finding an open source plugin with a similar feature and comparing its plugin.xml and entry classes is often faster than digging through the docs.

Here's the link to the published plugin: https://plugins.jetbrains.com/plugin/14958-mybatis-log-analysis

Pitfalls and Notes​

  • Parameter substitution can't be a naive global string replace. Parameter values may themselves contain commas or question marks; splitting the Parameters line on commas and replacing the ? placeholders one by one, in order, is far more robust than a one-shot regex replace.
  • Use the type information. The type in parentheses on the Parameters line determines whether a value needs quoting; ignore it and the resulting SQL will most likely fail to run in the database.
  • Submitting to the JetBrains Marketplace involves manual review. The plugin description, icon, and compatible IDE version range all have to be spelled out in the configuration — preparing these in advance saves several rounds of back-and-forth.
tip

When the plugin development docs fall short, the IntelliJ Platform SDK documentation read side by side with the source code of open source plugins is by far the best learning path.

Wrapping Up​

The plugin's logic itself is tiny; its value is in automating away a frequent bit of manual work. For me the bigger gain was walking the full path of an IDEA plugin from development to marketplace release: the feature implementation was only a small part of it. Understanding the platform's extension mechanisms and getting used to learning from source code and demos — that is the real barrier on this road. Future versions will add the xml/java navigation and one-click code generation features.

COMMENTS