skip to content

Explain Kotlin's `import ... as` aliasing. When is it necessary, and what exactly does the alias rename?

level: middleimportance: should knowfreq 50%

answer

  1. Syntax: import x.Foo as Bar
  2. Main use: resolve name clashes
  3. File-scoped, compile-time only
  4. Does not change real FQN/bytecode
  5. Different from typealias (which is exported)

basics

~10 s

Import aliasing lets you rename something on import, e.g. import a.Foo as Bar. It's mainly used to resolve name clashes between two classes or functions with the same simple name from different packages.

solid answer

~40 s

Kotlin supports `import x.Foo as Bar`, which introduces a **local alias** valid only in the current file. Its primary use is resolving **name collisions**: when two classes/functions share a simple name (e.g., `java.util.Date` and `java.sql.Date`), you import one normally and alias the other (`import java.sql.Date as SqlDate`). It also improves readability for verbose names. The alias renames the reference at use sites in that file—the underlying declaration's real name and FQN are unchanged, so it doesn't affect callers in other files or reflection. You can alias classes, functions, properties, enum entries, and typealiases. Unlike a `typealias`, an import alias is file-scoped and not exported as part of your API. It's a clean alternative to fully qualifying one of the clashing names everywhere.

code

kotlin · 4 lines
kotlin
import java.util.Date as UtilDate
import java.sql.Date as SqlDate

fun bridge(u: UtilDate): SqlDate = SqlDate(u.time)

go deeper

for a junior

Knows the import x as Y syntax and that it renames on import.

for a middle

Identifies clash resolution as the core use and that the alias is file-scoped.

for a senior

Distinguishes import alias from typealias and explains no effect on FQN/reflection/bytecode.

for a principal

Advises when to prefer typealias for API design vs local aliases, and codebase conventions for disambiguation.

## Syntax ```kotlin import java.util.Date as UtilDate import java.sql.Date as SqlDate fun now(): UtilDate = UtilDate() ``` The form is `import <fqn> as <Alias>`. The alias is a **file-local name**; outside this file the declaration keeps its original name. ## Why it exists: name collisions Kotlin imports declarations by **simple name**. If two packages export the same simple name, you cannot have both as plain imports—they'd clash. Aliasing renames one (or both) so the file can reference each unambiguously without writing the full FQN everywhere. ## What can be aliased - Classes/interfaces: `import a.Repo as ARepo` - Top-level functions: `import a.util.parse as parseA` - Properties / enum entries / object members - Even an existing `typealias` ## What the alias does and does not change - **Does**: change how you *refer* to it in this file. - **Does not**: change the declaration's real name, FQN, generated bytecode, reflection name, or how other files see it. It is purely a compile-time, file-scoped rename. ## Aliasing functions to disambiguate overloads from different sources ```kotlin import com.lib.a.log as logA import com.lib.b.log as logB fun audit() { logA("x"); logB("y") } ``` ## Import alias vs typealias - `import as` is **file-scoped**, lightweight, not part of your public API. - `typealias Name = Type` is a **declaration** with its own visibility, can be public/exported, and is usable across files. Use `typealias` when you want a reusable alternate name; use `import as` for local clash resolution. ## Gotcha An alias does not let you import two *different* members under the *same* alias, and you still cannot import two things with the same simple name without aliasing at least one.

  • How does `import as` differ from `typealias`?
    `import as` is file-local and never exported; `typealias` is a real declaration with visibility that other files can use and that becomes part of your API surface.
  • Does aliasing change the class's name seen by reflection or Java callers?
    No. It's purely a local renaming at the call site; the FQN, bytecode, and reflective name stay the same.

It's a nickname you use in one room (file); the person's legal name everywhere else is unchanged.

saying these in an interview costs you the question

  • Thinking the alias is visible in other files
  • Confusing import alias with typealias semantics
  • Believing aliasing changes the runtime/reflection name
  • Saying you can't import two same-named classes at all
  • Using aliasing where a typealias is actually needed for reuse

context

resolving links…