What's in a parameter name?

25 Sep 2025

Whether it is Spring MVC, Embabel, or any other framework that invokes methods reflectively, parameter names often play an important role.
This is especially true in the context of convention over configuration, which reduces the number of explicit decisions a user must make.

For example:

• In Spring MVC, a controller method parameter name can be used to resolve a request parameter (@RequestParam).
• In Embabel, an action method parameter name can indicate a blackboard value.

Retrieving parameter names in Java or Kotlin is less straightforward than it first appears. In this post, I will summarize the options.

---

Java

Before Java 8, the only way to retrieve parameter names was to compile with debug information (-g). Even then, names were stored only in the local variable table, an attribute intended for debugging, not reflection.

For years, Spring Framework included a fallback that read parameter names from this table. This worked, but only when debug information was preserved.

Java 8 introduced a proper solution: the -parameters compiler flag, along with the java.lang.reflect.Parameter API. With the flag enabled, the compiler emits a dedicated MethodParameters attribute in the bytecode, which the Java reflection API can read reliably. Without the flag, reflection falls back to synthetic names like arg0, arg1, and so on.

---

Kotlin

Kotlin complicates the picture further. The Kotlin compiler has a -java-parameters flag that behaves like -parameters for javac: it allows the Java reflection API to expose real parameter names instead of synthetic ones.

At the same time, Kotlin has its own reflection API, where parameter names are stored in the @Metadata annotation that the Kotlin compiler adds automatically. This means that with the Kotlin reflection (KFunction.parameters), you always see parameter names without extra flags. Two caveats apply:

1. Kotlin reflection lives in a separate dependency (kotlin-reflect). Unless you make it mandatory, you need to treat it as optional.
2. If you need to reflect on Java methods from Kotlin, those Java classes still need to be compiled with -parameters for names to be available.

---

Fallback strategy

Depending on whether you are calling Kotlin from Java, or Java from Kotlin, you need a fallback strategy for retrieving parameter names.

For Embabel, which is written in Kotlin but needs to invoke both Kotlin functions and Java methods, I use the following approach:

1. If kotlin-reflect is on the classpath, use it (KParameter::name).
2. Otherwise, if the code was compiled with -parameters or -java-parameters (Parameter::isNamePresent is true), use Java reflection.
3. Otherwise, fail with an exception that instructs the user to enable one of the flags.

Spring follows a very similar approach, but from the opposite direction: it is a Java framework that can interact with Kotlin code.

---

The Broader Lesson

Parameter names are a small detail, but they have a big impact on developer experience. Whether you are writing Java or Kotlin, frameworks often rely on them to make convention-based APIs feel natural.

Knowing when to enable -parameters or -java-parameters, and when to use Kotlin reflection, makes it easier to build frameworks that work seamlessly across both languages.

---