Easy Javadoc: an IntelliJ IDEA plugin that writes Javadoc and KDoc from your method names

The gap Easy Javadoc fills between a method name and a written comment

Javadoc is only useful when it says something a reader cannot already see in the signature. In practice most teams leave it empty, because writing it is a separate chore from writing the code, and reviewers rarely block a pull request over a missing @param. Easy Javadoc attacks that chore directly: it reads the name of the class, method or field under the cursor and produces a comment from it. The README states the plugin helps Java and Kotlin developers generate javadoc and kdoc comments, and that the better your method names are, the better the generated comment reads. That sentence is the whole design in miniature. This is a name-to-prose tool, not a code-understanding tool.

The audience is narrow and identifiable. You write Java or Kotlin in IntelliJ IDEA, you want comments in a consistent shape across a codebase that was never documented, and you are willing to configure at least one translation backend. The README also pitches a second use that has nothing to do with documentation: select Chinese text, press the shortcut, and get an English identifier back, which the README describes as a naming aid for programmers. That feature alone is why some people install it.

How the plugin turns an identifier into a comment

The mechanism is translation, not static analysis of the method body. According to the README, the plugin connects to several translation services, and the quality of the output depends on how well the method name was chosen. A user-defined word mapping takes priority over everything else, so a team can pin the terms that a generic translator would mangle. That mapping layer is the part worth understanding before you judge the output, because it is the only place where project-specific vocabulary enters the pipeline.

The plugin also supports large model APIs. The changelog records v4.5.0, dated 2026-04-12, adding a generic large model interface in OpenAI format, compatible with OpenAI, DeepSeek, Tongyi Qianwen and Moonshot, and v4.5.7, dated 2026-08-04, adding a shortcut translation entry for the same generic model format. Earlier, v4.0.0 on 2024-04-29 added Zhipu Qingyan support. So the translation layer is not fixed: it is a pluggable backend, and the README notes that each provider gives a monthly free quota that is generally enough, with keys you apply for yourself.

One detail in the README is easy to miss and matters for anyone auditing output. The @return tag can be rendered in two modes. In code mode it produces `@return {@code User}` or `@return {@code Map<String, Integer>}`. In link mode it produces `@return {@link User}` or `@return {@link Map}<{@link String}, {@link Integer}>`. That is a formatting decision baked into the template, and it changes how the generated comment renders in an IDE and in generated HTML.

Installing Easy Javadoc and generating your first comment

The README gives one installation path, through the IDE's own plugin marketplace. There is no build-from-source instruction in the README, and the repository does contain a Gradle build with gradlew and gradlew.bat at the top level, so building locally is possible in principle, but the documented route is the marketplace.

Open IntelliJ IDEA, go to plugins, and search for Easy Javadoc under the Java category. Install and restart. The plugin requires IDEA 2023.1 or newer; the v4.5.6 changelog entry, dated 2026-07-29, states support for 2023.1 (build 231) and above with no upper version limit.

打开IntelliJ IDEA -> plugins，java搜索`Easy Javadoc`，安装重启即可

After the restart, place the blinking cursor on a class, method or field name and press the shortcut. On Windows that is ctrl \, on macOS command \. The README is emphatic that the cursor must sit on the name and that you must not double-click to select it first.

| `ctrl \` | 类、方法、属性（光标放上面就行，不要双击选中！） | 生成当前文档注释 |
| `ctrl shift \` | 类 | 生成全部文档注释 |

The same shortcut is overloaded by selection. Select Chinese text and press it, and you get an English identifier suggestion. Select non-Chinese text and press it, and a dialog shows the translation, which the README frames as a way to stop switching between a dictionary and the IDE. The batch shortcut works on classes only, and the README notes KDoc batch generation is not supported.

Before the first run, expect to configure a translation backend, since the README states the free Youdao interface was disabled by the vendor and asks users to switch to another method. Keys are applied for at each provider: Baidu, Tencent, Aliyun, Youdao Zhiyun, Microsoft, Google, or a generic OpenAI-format endpoint.

Where Easy Javadoc gets in the way

The failure modes are documented, which is a good sign, but they are real. The most common complaint is that the shortcut does nothing. The README lists the causes in order: the cursor is not on the name, or the IDE shortcut is already taken. The README also warns that the AI Assistant plugin shipped with recent IDEA versions conflicts with Easy Javadoc's shortcut, and that you must change one of the two. That is a conflict the plugin cannot resolve for you.

The second class of problem comes from IDEA's own formatter, not from the plugin. Single-line field comments turn into multi-line comments because IDEA's default formatting expands them, and the README points to a formatting setting to change. Similarly, if the order of @param and @link tags comes out wrong, the README attributes it to IDEA reordering Javadoc tags and points to a setting that disables Javadoc formatting. In both cases the generated text is fine and the IDE rewrites it afterwards, which is a confusing thing to debug if you do not know where to look.

There is also a translation-quality ceiling. The README says outright that inaccurate translations are common, and that word-level mistakes should be fixed through the custom word mapping page, where user-defined entries outrank everything else. That is a workable escape hatch for a project's own jargon, but it is manual, and it only covers vocabulary rather than sentence structure.

Finally, the plugin is the wrong tool when you need comments that describe intent, invariants or edge cases. A name-to-prose generator cannot tell a reader why a null check exists or what the method does when the input list is empty. If your codebase needs that kind of documentation, this plugin will produce plausible-looking text that adds no information, which is arguably worse than no comment at all.

Easy Javadoc versus IntelliJ IDEA's built-in Javadoc tooling

The obvious comparison is not another plugin but the IDE itself. IntelliJ IDEA already generates Javadoc skeletons through its own intention actions and its Generate menu, and it can render and export Javadoc for a module. The difference is what gets filled in. The built-in generator inserts the structural tags, @param and @return, with the parameter names and types, and leaves the descriptions blank for you to write. Easy Javadoc's contribution is exactly the part the built-in tool leaves empty: the prose. It does not replace the IDE's Javadoc rendering or its export pipeline, and the README does not claim it does.

That split also explains the formatting friction described above. Because Easy Javadoc writes text into the same comment structure the IDE owns, IDEA's formatter and tag-reordering settings act on the plugin's output. A team that already relies on the built-in generator is not choosing between two tools so much as adding a text source to one of them.

Maintenance, licensing and what an upgrade costs you

The repository is not archived, and the last push was on 2026-08-06, which is recent enough that the project is being worked on. The changelog in the README is long and continuous, running from v1.0 in September 2019 to v4.5.8 in August 2026, with entries for IDEA compatibility fixes, provider additions and bug fixes. Two entries are worth noting for planning: v4.5.6 dropped the upper bound on supported IDEA versions, and v4.5.7 fixed compatibility with IDEA 2026.2.x. Compatibility with new IDEA releases is clearly an ongoing maintenance cost borne by the maintainer, not by you, as long as the plugin keeps being updated.

For your own upgrade cost, the plugin is distributed through the JetBrains marketplace, so updates arrive the way other plugin updates do. Configuration is importable and exportable, a feature the README dates to v1.8 in December 2019, which matters if you standardise word mappings across a team.

The project is licensed under Apache-2.0. That is a permissive licence, and it is the same licence family many teams already accept for build tooling. This is not legal advice; if your organisation has rules about IDE plugins that transmit source identifiers to third-party services, the licence is not the question you need to answer. The question is which translation backend you configure, because that determines where your method and field names are sent. The README lists Baidu, Tencent, Aliyun, Youdao Zhiyun, Microsoft, Google and a generic OpenAI-format endpoint as options, and each has its own terms.

Editorial conclusion

Adopt Easy Javadoc if your team already writes Java or Kotlin in IntelliJ IDEA 2023.1 or newer and treats generated comments as a first draft that a human edits. Do not adopt it if you need deterministic, offline output on a locked-down network with no translator configured, or if you expect the plugin to understand behaviour rather than names. Before rolling it out, verify two things in your own IDE: that ctrl \ or command \ does not collide with the AI Assistant plugin, and that IDEA's Javadoc formatting setting is configured the way your team wants, since the plugin inherits it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. starcwang/easy_javadoc on GitHub