Автор статьи: Сергей Прощаев @sproshchaev
Руководитель направления Java‑разработки в FinTech
Kotlin, современный язык программирования от JetBrains, уже давно зарекомендовал себя не только в Android‑разработке, но и как мощная альтернатива Java для бэкенд‑разработки. Kotlin полностью совместим с Java, работает на JVM и предлагает более лаконичный, безопасный и выразительный синтаксис.
Kotlin — это синтез лучших практик из Java, Scala, C#, Groovy, Swift и других языков, с акцентом на:
Совместимость с Java,
Null‑безопасность,
Поддержку функционального и объектно‑ориентированного программирования,
Лаконичность и читаемость кода,
Безопасность и производительность.
В этой статье мы рассмотрим, на примерах — почему Kotlin становится все более привлекательным выбором для бэкенд‑разработчиков.
Почему Kotlin лучше для бэкенда?
Читаемость кода: Kotlin позволяет писать значительно меньше шаблонного кода. Функции, такие как
data classes, автоматически генерируютgetters,setters,equals,hashCodeиtoString. Выраженияwhen, расширения функций и лямбды делают код более читаемым и логичным.Безопасность: безопасность от NullPointerException (Null‑safety) встроена в систему типов, что снижает количество ошибок на этапе компиляции. Система типов Kotlin различает nullable и non‑nullable типы, что практически исключает NullPointerException. Иммутабельность по умолчанию (val вместо var) способствует написанию более предсказуемого и потокобезопасного кода.
Интероперабельность с Java: Kotlin работает на той же JVM, что и Java, и полностью совместим с существующим Java‑кодом. Это означает, что вы можете постепенно переносить проект, используя существующие библиотеки и фреймворки (Spring, Hibernate и т. д.) без переписывания всего с нуля.
Современные возможности языка: Kotlin предлагает такие функции, как корутины (coroutines) для асинхронного программирования, делегированные свойства, объекты‑компаньоны и многое другое, что упрощает разработку.
Поддержка сообщества и инструментов: JetBrains активно развивает Kotlin, обеспечивая отличную поддержку в IDE (IntelliJ IDEA). Фреймворки, такие как Ktor и Spring (с официальной поддержкой Kotlin), предоставляют мощные инструменты для бэкенд‑разработки.
Читаемость кода или про то, "как это пишется в Java и как это можно сократить в Kotlin"
Чтобы не погрязнуть в теории — давайте на примерах рассмотрим базовые конструкции и посмотрим как это пишется в Java и как это можно сократить в Kotlin. Давайте остановимся на data classes, when и расширениях функций
Что такое data classes и с чем их едят в Kotlin?
Kotlin позволяет писать значительно меньше шаблонного кода. Например такие конструкции, как data classes, автоматически генерируют: getters, setters, equals, hashCode и toString.
Так в Java при создании простых классов‑контейнеров (например, для хранения данных), приходилось писать много повторяющегося кода. Давайте создадим класс Person с двумя полями: имя и возраст.
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public int getAge() { return age; }
public void setAge(int age) { this.age = age; }
@Override
public boolean equals(Object o) { /* много строк */ }
@Override
public int hashCode() { /* ещё больше строк */ }
@Override
public String toString() { /* и снова... */ }
}Это пример типичного шаблонного кода — он почти всегда одинаков, но при этом занимает много места и отвлекает от сути. А ведь в нем всего лишь два поля, а что будет с размером класса, если полей будет с десяток или даже два?
В Kotlin для таких случаев есть специальный класс — data class. Он автоматически генерирует все необходимые методы и вот как будет выглядеть выглядеть наш Person:
data class Person(val name: String, val age: Int)Всего‑лишь одна строчка кода!
Что такое when и чем он лучше switch?
Выражение when в Kotlin — это мощная и гибкая конструкция, которая заменяет собой традиционный switch из Java и даже больше.
В Java оператор switch имеет много ограничений:
switch (day) {
case 1:
System.out.println("Понедельник");
break;
case 2:
System.out.println("Вторник");
break;
// ... много case'ов
default:
System.out.println("Неверный день");
}В switch нужно не забывать писать break, иначе будет fall‑through, в самой конструкции мы можем использовать только ограниченные типы данных (int, char, enum, String с Java 7+), нельзя использовать сложные условия и не возвращаются значение напрямую.
В Kotlin when — это выражение, а не просто оператор. Это значит, что оно может возвращать значение:
val dayName = when (day) {
1 -> "Понедельник"
2 -> "Вторник"
3 -> "Среда"
4 -> "Четверг"
5 -> "Пятница"
6 -> "Суббота"
7 -> "Воскресенье"
else -> "Неверный день"
}Преимущества when на лицо: нет необходимости в break, поддерживает любые типы и может возвращать значение!
Но это еще не все — если нужны множественные значения в одном case, то можно написать так:
when (x) {
1, 2, 3 -> println("x равен 1, 2 или 3")
in 4..10 -> println("x между 4 и 10")
!in 10..20 -> println("x не в диапазоне 10-20")
else -> println("другое значение")
}Мы можем тут же проверять типы:
when (obj) {
is String -> println("Длина строки: ${obj.length}")
is Int -> println("Квадрат числа: ${obj * obj}")
is List<*> -> println("Размер списка: ${obj.size}")
else -> println("Неизвестный тип")
}Или добавить условия:
when {
x > 0 -> println("Положительное число")
x < 0 -> println("Отрицательное число")
else -> println("Ноль")
}И, наконец возвращать значения:
val result = when (grade) {
"A" -> "Отлично"
"B" -> "Хорошо"
"C" -> "Удовлетворительно"
else -> "Неизвестная оценка"
}Но это еще не все when можно рассматривать как замену трудно читаемой if‑else цепочки, например так мы напишем на Java:
if (x.isOdd()) {
println("x нечетное")
} else if (x.isEven()) {
println("x четное")
} else if (x > 100) {
println("x больше 100")
} else {
println("другое условие")
}Выглядит как «многобукаф» и вообще не понятно, что имелось ввиду. А вот как это можно написать на Kotlin:
when {
x.isOdd() -> println("x нечетное")
x.isEven() -> println("x четное")
x > 100 -> println("x больше 100")
else -> println("другое условие")
}Курто! Не правда ли?
А вот как можно обрабатывать значения из enum‑класса:
enum class Status { ACTIVE, INACTIVE, PENDING }
fun handleStatus(status: Status) = when (status) {
Status.ACTIVE -> "Пользователь активен"
Status.INACTIVE -> "Пользователь неактивен"
Status.PENDING -> "Ожидает подтверждения"
}Расширения функций в Kotlin
Расширения функций (extension functions) — это одна из самых удобных фич Kotlin, которой нет в Java. Расширения функций позволяют добавлять новые функции к существующим классам, не изменяя их исходный код и не используя наследование.
Давайте решим практическую задачку — добавим метод к классу String, который считает количество слов в строке.
В Java нельзя добавлять методы к существующим классам напрямую. Приходится использовать либо утилитарные классы (helper classes), либо наследование (если класс не final) или wrapper классы. Давайте используем первый подход через утилитарный класс:
// Утилитарный класс
public class StringUtils {
public static int wordCount(String str) {
if (str == null || str.isEmpty()) {
return 0;
}
return str.trim().split("\\s+").length;
}
}
// Использование:
public class Main {
public static void main(String[] args) {
String text = "Привет мир Kotlin";
int count = StringUtils.wordCount(text);
System.out.println("Количество слов: " + count);
}
}И сразу проблемы налицо — нужно помнить имя утилитарного класса, вызывать как статический метод, а не как метод строки.
Что предлагает Kotlin для решение этой же задачи через расширение функций:
// Расширение для String
fun String.wordCount(): Int {
return if (this.isBlank()) 0 else this.trim().split("\\s+".toRegex()).size
}
// Использование:
fun main() {
val text = "Привет мир Kotlin"
val count = text.wordCount()
println("Количество слов: $count")
}Расширенная функция wordCount() вызывается как обычный метод строки! Интуитивно все понятно и нет необходимости создавать дополнительные классы при этом код стал читабельнее.
Заключение
Надеюсь, что из этих примеров уже стало понятно о тех преимуществах, которые несет в себе Kotlin в бэкенд‑разработке. Kotlin позволяет значительно сократить объем кода, повысить его читаемость и уменьшить количество ошибок благодаря таким возможностям, как null‑безопасность, расширения функций и мощные конструкции типа when. В отличие от Java, Kotlin предлагает более современный и выразительный синтаксис, что делает разработку быстрее и приятнее. Эти особенности делают Kotlin отличным выбором для создания надежных и поддерживаемых серверных приложений.
В заключение приглашаем вас на два открытых урока, где разберем ключевые аспекты Kotlin для бэкенд‑разработки.
12 августа в 20:00 — «Почему все переходят на Kotlin? Секреты успешной миграции с Java для бэкенд‑разработчиков». На занятии рассмотрим, как Kotlin помогает сократить объем кода за счет data‑классов, расширений функций и выражения when.
19 августа в 20:00 — «Нововведения Kotlin 1.9–2.2 для JVM». Уделим внимание последним обновлениям языка, которые полезны для серверной разработки. Обсудим изменения в работе корутин, новые возможности стандартной библиотеки и оптимизации производительности.
Кроме того, пройдите вступительное тестирование, чтобы оценить свой уровень и узнать, подойдет ли вам программа курса «Kotlin Backend Developer. Professional».
Комментарии (28)
Antoshink
07.08.2025 17:06Я может какой то не такой, но для меня вот эта лаконичность val превращает код в какое то не читаемое месиво, особенно когда начинается сложная бизнес логика размазанная на тысячи строк. Как пример stream в java. классно придумали, но как этим пользуются, это ужас. Каждый божий раз пытаешься развернуть в своей голове, что же автор отбирает в этой коллекции.
TastaBlud
07.08.2025 17:06Мне, наоборот, кажется именование val-var более удачным, чем var-let-const в JS.
Stream API в джаве, согласна, напрягает, но надо понимать, что целых 7 версий и 15 лет и его не было, прилепили сбоку. Если бы оно было в языке сразу, уверена, выглядело бы элегантнее.
Собственно, Kotlin решает эту проблему кардинально, чтобы не тянуть груз не совсем удачных, как оказалось на дистанции в десятилетия, решений проектирования.
Java только с 8 версии стала развиваться, до этого было идеологическое сопротивление "мы не будем кардинально менять язык", следствием чего стал, например, Lombok. и только в последних версиях появились такие фишки, как мультистроки или расширенный switch, и то, они выглядят больше костыльно, словно их туда впихнули очень нехотя и со стыдом.
Antoshink
07.08.2025 17:06Вопрос не var-let-const. Вопрос в том, что я хочу всегда видеть возвращаемый тип, а не непонятный val.
TastaBlud
07.08.2025 17:06Его можно не указывать (он выводится), а можно указывать, и хорошим тоном считается последнее, особенно если он не очевиден (например в записи val so: SomeObject = SomeObject() указание типа не несёт полезной информации). Впрочем, если пользоваться Idea, то она покажет и выводимый, если автор не указал.
В Java тоже появился вывод типов через var, так что здесь на равных.
TimurBaldin
07.08.2025 17:06Eсли отбросить вкусовщину...то, особыми преимуществами Kotlin перед современной Java не обладает.
И как следствие, непонятно зачем тратить время на переобучение команду под Kotlin, если можно просто взять более современную версию Java, а если очень хочется "красоты", то добавить Lombok
A1WEB
07.08.2025 17:06Да, если нет прироста в производительности и трудозатраты сопоставимы, нет смысла лезть в Kotlin.
TastaBlud
07.08.2025 17:06Перейти с Java очень легко, писать и читать код намного более приятно. Трудозатраты могут быть если использовать сразу какой-нибудь Ktor вместо Spring - всё же сообщество Spring обширнее, и ответ на вопрос можно нагуглить, в случае с Ktor первое время придется почесать тыковку, как всё то же сделать.
Но на длинных дистанциях всё же оправдывается, усилий меньше и багов на ровном месте гораздо меньше.
С фронтом и нативом всё ещё печальнее - документации впапперов почти нет, вопросов-ответов нет или для legacy. Зато в андроид разработке этот язык прижился очень хорошо и почти вытесняет "родную" джаву, собственно и ответы про Kotlin обычно попадаются для android больше, чем для бэка.
TastaBlud
07.08.2025 17:06Я очень люблю Kotlin. Долго искала язык, который мне понравится, пробовала и экзотические, такие как Julia и Ceylon. Сначала мне понравился Ruby, особенно его перегрузкой операторов и свободой имен для идентификаторов (назвать переменную 123 или #id - можно!), но отпугнул странными синтаксическими решениями вроде использованием @ и @@. Затем кандидатом в фавориты стал Swift, но увы, до недавнего времени он означал привязку к mac, практически невозможно его использовать если у тебя Windows или linux... И тут появился Kotlin!
В статье как-то хоть и упомянуты важные свойства языка, но почему-то много внимания уделено одному switch оператору, а другим, более важным - в основном по одной строчке. В итоге читатели не видят преимуществ перед современной Java, а они есть:
Kotlin Multiplatform: возможность писать на одном Kotlin и backend и frontend и android/ios приложения, даже нативные для llvm
Закрытость по умолчанию: без специальных модификаторов open классы и методы нельзя расширять, val переменные и параметры методов нельзя переопределять. Таким образом, язык не только мотивирует использовать иммутабельность, но и при правильном проектировании позволяет писать защищённые от порчи извне модули, тогда как в Java надо визуально перегружать словом final и не забывать это делать, что чревато ошибками по невнимательности. Сюда же относится разделение на мутабельные и иммутабельные коллекции (List и Map по умолчанию неизменяемы, для изменяемости нужно использовать их Mutable родичей) - в Java есть иммутабельные коллекции, но они являются скорее удобным дополнением, тогда как вся экосистема построена на изменяемых.
Функциональные операции map, filter и самые разные другие встроены в язык, не нужно как в Java сначала коллекцию трансформировать в Stream а потом обратно - однозначный выигрыш в читаемости и лаконичности. В сочетании с предыдущим пунктом это даёт возможность функционального программирования с сохранением ООП, что позволяет использовать лучшее из двух миров.
Flow functions такие как run, apply, let дополняют пункт выше и позволяют обходиться без временных переменных, захватывая контекст this и it, что снова позволяет повысить читаемость и писать однострочные выражения, что (опять же, если использовать с умом) выражает логику "что мы здесь делаем" а не "как делаем*. При этом они являются inline, а значит, нулевой оверхед (мы не вызываем утилитную функцию, что важно не только в плане экономии нескольких процессорных тактов, но и для функций, которым важно, кто их вызывает - такие как Thread.getStackTrace или Class.getResource, они в исходниках Java помечены как @CallerSensitive).
Свойства - поля и переменные, которые на самом деле являются парами getXXX() и setXXX(), в Java до сих пор необходимо писать ручками, а в Kotlin можно переопределить логику. Естественно, этим не следует злоупотреблять, но если использовать только там, где необходимо, можно повысить понимание логики (а можно и наоборот, вызвать недоумение "какого чёрта чтение из поля приводит к триггеру побочных эффектов", поэтому не нужно пользоваться этим без необходимости)
Делегаты и делегированные поля: можно привязать поле к другому или использовать иную логику. Так, встроенный делегат lazy позволяет лениво инициализировать поле, SQL билдер Kotlin Exposed определяет Entity через таблицы, а библиотека внедрения зависимостей Koin использует делегат inject() для внедрения бина. В Java до сих пор этого нет и для того же необходимо использовать многословные паттерны.
Поля и переменные по умолчанию должны быть явно инициализированы, поэтому невозможно забыть проинформировать поле и неожиданно получить NullPointerException. Для случаев где это надо есть lateinit var, при этом сам модификатор указывает на возможную ситуацию.
Конечно же, nullable types, которые безусловно повышают дисциплину программирования, и действительно риск отхватить NPE на ровном месте ниже, и очень грамотное решение управлять нуллабельностью через суффиксы ? и !, а явное превращение через !! обозначает точки отказа явно.
Перегрузка операторов при правильном использовании даёт значительный буст как к читаемости, так и переиспользованию кода. Всем противникам "магии" напоминаю, что в Java она тоже есть, но только для String для прозрачного превращения в StringBuilder и обратно.
С помощью infix functions и разрешению выносить последний функциональный аргумент за скобки (и не использовать скобки если он один) раскрывает всю мощь DSL. Почему это удобно, элегантно и насколько, объяснять не надо любому, кто использовал Gradle. И такой подход в Kotlin мире более принят, чем подход с аннотациями (можно сказать, что последний - это Spring-стиль, там зачастую аннотаций больше, чем кода).
Удачное и разделение на классы и objects / companion objects вместо статических полей. Сначала, конечно, подход кажется странным, но на практике оправдывается. Во-первых, мы получаем потокобезопасный паттерн Singleton из коробки, во-вторых, разделение повышает читаемость, в третьих, стимулирует ещё раз подумать, где это нужно и не нужно.
Функции-расширения, как было упомянуто в статье, смотрится сильно читаемее, чем аналогичные утилитные методы, их легче писать и легче использовать. По моему опыту, также в рефакторинге кода сильно помогает.
Алясы (typealias и import...as) позволяют спроектировать мощную систему типов без собственно объявления новых классов и также избежать многословности, чем точно стоит пользоваться.
Интерполяция строк через $ и ${}, а также многострочные String (которые в Java появились только относительно недавно), равно как и билдеры buildString {} ,и buildList {} также более приятны и полезны.
Модификатор override удачнее чем джавовская аналогичная аннотация строгостью проверки.
Наоборот, замена символом : слов extends и implements на практике оказывается более удачным решением.
Туда же решение не использовать checked exceptions.
Suspended functions для асинхронного программирования выигрышнее, чем аналогичные async/await из Typescript, тем что в сигнатуре функции указывается само значение, а не Promise, хотя async { } и .await() всё ещё присутствуют.
Огромная стандартная библиотека всяческих функций не только снижает количество must-have зависимостей типа Apache Commons, Lombok и других, но и минимизует искушение писать снова и снова собственные велосипеды.
Вот самые основные преимущества, которые даёт Kotlin даже перед современной Java, почему я всё же предпочитаю этот язык. Недостатки, конечно, тоже есть - небольшой оверхед при компиляции по сравнению с Java - особенно из-за проверок на null на каждом шагу (цена non-nullable types в nullable jvm) - но он всё же намного меньше, чем Scala или Groovy (попробуйте декомпилировать скомпилированный код на этих языках и почувствуйте разницу), но всё же психические затраты при проектировании и написании кода при переходе всё же ощутимы.
TastaBlud
07.08.2025 17:06Да, забыла ещё одну важную деталь:
В Kotlin строгая типизация и явное приведение типов. Т.е. нельзя Long переменной просто так взять и присвоить значение Int переменной, надо вызвать .toLong() конверсию. Сначала кажется излишним, но на практике снимает головную боль помнить о правилах неявного присваивания и внимательно выискивать баг (все помнят, что в джаве 5/2*2==4? А это легко не заметить при беглом чтении кода). Есть конверсии бросающие исключения и есть возвращающие null, что очень удобно от ситуации к ситуации, вместо оборачивания в try-catch
И ещё: все операторы возвращают значение, возможно Unit, но в выражениях можно использовать. Правда, тернарного оператора нет, приходится использовать if-else в качестве выражения, но есть удобный оператор ?, для следования по null-цепочке и элвис ?:, что удобно для немедленного возврата или бросания исключения при невыполнении условия.
TastaBlud
07.08.2025 17:06И ещё одна приятная деталь, обычная для всех языков, но где джава опять отличилась: оператор == вместо .equals() ,и === для сравнения по ссылке, при этом сравнение с null возможно без возможности NPE. Да, в джаве есть Objects.equals(), но выглядит громоздко.
TastaBlud
07.08.2025 17:06Увидела ещё нюанс, связанный с nullable types: Да, в джаве есть Optional, который позволяет элегантно обходить NPE ,и избежать проверок, причём в функциональном стиле. Но! Он параметризированный, что означает проблемы type erasure и проблемы при перегрузке методов - и это уже серьезный недостаток.
JajaComp
07.08.2025 17:06Согласен. После kotlin вообще не хочется возвращаться к джаве. Для меня самые крутые фичи это extensions, data class силды и синтаксис без лишних слов
TastaBlud
07.08.2025 17:06И "главный" плюс Kotlin - полностью поддерживается в бесплатной JetBrains Idea Community, что может быть критичным на сегодняшний день.
TastaBlud
07.08.2025 17:06И как резюме: из комментария выше можно подумать, что преимущество Kotlin только в синтаксическом сахаре (а среди Java разработчиков немало противников этого). Но главное преимущество - то, что в Java достигается с помощью различных шаблонов (паттернов) - а ими любят мучать особенно джуниоров на собеседованиях (если честно, то я сама уже теорию забыла) - в Kotlin достигается на уровне синтаксиса.
Например, как в Java сделать singleton? в Kotlin - , object. А ленивый? by lazy {}. А ленивый и потокобезопасный? А истинно потокобезопасный с правильными блокировками не каждый помнит, как написать. В Kotlin для этого достаточно средств языка и стандартной библиотеки.
И ещё преимущество по сравнению с джавой - отсутствие boxing-unboxing как явления (что особенно мучительно было до autoboxing). А ещё - решение типовых проблем связанных с generics, в основном с помощью inline-reified.
lxvkw
07.08.2025 17:06Благодарю вас за столь детальный комментарий, из которого можно сделать статью.
Именно за подобным и стоит заходить в комментарии
HemulGM
07.08.2025 17:06Я увидел только сравнение switch/when и, а не конкретные преимущества создания бэкенда.
DTO классы можно (и чаще делается именно так) генерировать.
Комментарий выше больше преимуществ привел и вышел ценнее самой статьи
TastaBlud
07.08.2025 17:06Преимущества именно в бэкэнде, а не в самом языке относительны. Так, использование Ktor и Koin вместо Spring чуть-чуть затратнее, чем использование Spring. Но Spring можно продолжать использовать, есть только пара моментов:
забудьте про implements Serializable и джавовскую сериализацию вообще, используйте плагин/библиотеку Kotlin Serialization или столкнетесь с проблемами. По этому же поводу сериализация Java<=>Kotlin требует доп.затрат, лучше всего использовать kotlin-serialization-json и Jackson на Java стороне. Зато сама библиотека лучше спроектирована, без использования специальных методов, а явными серилизаторами, которые кстати очень легко писать, а в большинстве случаев плагин их сгенерирует сам.
По причине выше есть нюансы с использованием Hibernate
Зато, действительно, data classes и value classes освобожают от ручного написания бойлерплейта, и must-have в джаве Lombok здесь не нужен вообще. Иммутабельность поощряется, именованные и .copy() методы делают клонирование (с изменениями) очень простым.
Деструкторов в Kotlin нет, поэтому вполне можно использовать подход Closeable/AutoCloseable как в Java.
Благодаря DSL можно на Kotlin описать и html и css.
Для фронтенда можно использовать Kotlin Multiplatform и уже есть готовые впапперы для самых популярных библиотек, например, React (впрочем, лучше использовать Jetpack Compose, KVision или вот мне зашёл Fritz2 с его идеологией реактивного программирования, построенного на kotlin.coroutines.Flow, аналогично Spring WebFlow).
Как это выглядит на практике, можно посмотреть в моём пробном проекте бложика https://github.com/tasta-blud/darkladyblog
9lLLLepuLLa
07.08.2025 17:06Так в Java при создании простых классов‑контейнеров (например, для хранения данных), приходилось писать много повторяющегося кода.
data class Person(val name: String, val age: Int)Java:
record Person(String name, int age) {}Расскажите всем, кто пишет на котлин, что 8я джава вышла 11 лет назад
В 2025м году стоит сравнивать хотя бы с 21й версией джавы. И тут окажется, что преимущества котлина не так очевидны (а то и вообще отсутствуют).
TastaBlud
07.08.2025 17:06В Kotlin мы можем контролировать, являются ли поля изменяемыми (var) или нет(val). И опять же, Java не следует своим же соглашениям именования методов JavaBean (.xxx() а не .getXxx())
И после Котлина действительно назад на Джаву возвращаться не хочется, даже на 21. А надо, по работе...
9lLLLepuLLa
07.08.2025 17:06Неизменяемые поля в джава с ключевым словом final. Без - изменяемые по-умолчанию.
Только у final более широкое применение, не только для полей классов.
Я не понимаю про именования каких бинов идёт речь. Рекорды не являются бинами.
9lLLLepuLLa
07.08.2025 17:06val dayName = when (day) { 1 -> "Понедельник" 2 -> "Вторник" 3 -> "Среда" 4 -> "Четверг" 5 -> "Пятница" 6 -> "Суббота" 7 -> "Воскресенье" else -> "Неверный день" }var dayName = switch (day) { case 1 -> "Понедельник"; case 2 -> "Вторник"; case 3 -> "Среда"; case 4 -> "Четверг"; case 5 -> "Пятница"; case 6 -> "Суббота"; case 7 -> "Воскресенье"; default -> "Неверный день"; };
9lLLLepuLLa
07.08.2025 17:06enum class Status { ACTIVE, INACTIVE, PENDING } fun handleStatus(status: Status) = when (status) { Status.ACTIVE -> "Пользователь активен" Status.INACTIVE -> "Пользователь неактивен" Status.PENDING -> "Ожидает подтверждения" }Java:
enum Status { ACTIVE, INACTIVE, PENDING } String handleStatus(Status status) { return switch (status) { case ACTIVE -> "Пользователь активен"; case INACTIVE ->"Пользователь неактивен"; case PENDING ->"Ожидает подтверждения"; }; }
LeshaRB
В switch нужно не забывать писать break, иначе будет fall‑through, в самой конструкции мы можем использовать только ограниченные типы данных (int, char, enum, String с Java 7+), нельзя использовать сложные условия и не возвращаются значение напрямую.
Это сравнение с 8 Java?
sproshchaev
Добрый день!
Да. Это сравнение с Java 8. К версии Java 21 switch стал более функциональным, но в ряде случаев Kotlin превосходит и его.