Java: fill the gaps

Исключения: сhecked или unchecked? Ошибки бизнес логики бывают двух видов: checked и unchecked. В чём разница? Какой тип выбрать для нового исключения? Об этом сегодняшний пост. Начнём с определений. 🔸Checked исключения - наследники класса Exception:

class IOException extends Exception

Явно указываются в сигнатуре методов:

void write(int c) throws IOException

Исключение обрабатывается в блоке try-catch. Иначе программа не скомпилируется. На практике checked используется, когда метод знает, что делать с ошибкой: попробовать ещё раз, выполнить другой код или вернуть значение по умолчанию. 1️⃣ Работа с внешними ресурсами — файлы, БД, другие сервисы. Повторить попытку или переоткрыть соединение 2️⃣ Ожидаемая ошибка Например, данные в легаси системе хранятся в двух форматах. Если не удалось прочитать одним способом, попробуем другим. 🔸Unchecked исключения — наследники класса RuntimeException:

class NullPointerException extends RuntimeException

О них не пишут в сигнатуре методов. Их редко ловят в блоке try-catch. Компилятор не предупредит о возможных ошибках, но иногда о них предупреждает IDE. Единственная техническая разница между checked и unchecked - за checked исключениями и их обработкой следит компилятор. На уровне JVM разницы нет - производительность обоих типов одинакова. На практике unchecked используются для ошибок, которые никто не ждал и что с ними делать во время работы программы - непонятно. ⭐️Правильный ответ на вопрос 1: обработка checked исключений обязательна и проверяется на этапе компиляции 🔸А что делать с ошибками бизнес-логики? Не найден пользователь, не хватает прав , превышен лимит снятия денег со счёта. Какие это исключения: checked или unchecked? В старых статьях по java и на курсах для новичков ответ однозначен. Все исключение должны быть checked, чтобы пользователь не увидел ошибку. Энтерпрайз - другое дело. Тысячи методов, тысячи проверок и ошибок. Если checked исключений много, код становится запутанным и сложным. Плюс исключения часто обрабатываются одинаково: записать в лог и отправить пользователю стандартное сообщение. В Spring и похожих фреймворках есть обработчики, который перехватывает все исключения. В таких системах бизнесовые ошибки часто делают unchecked, чтобы упростить код. Во многих проектах даже переводят checked исключения в unchecked:

catch (SQLException e) 
{throw new IllegalStateException(e);}

⭐️Правильный ответ на вопрос 2: На практике чаще встречается

extends RuntimeException

но вариант extends Exception тоже ок #core

Вакансии HeadHunter: Москва Четыре месяца назад был пост про вакансии java разработчиков в Петербурге. Следим за ситуацией на рынке, и сегодня обзор вакансий для города Москва. Вакансий в 2 раза больше — 719 против 309 в Петербурге. Интересно, что в Москве разработчиков без опыта ждут в три раза охотнее — таких вакансий 9% против 3% в Спб. BigData и noSQL упоминаются реже, и не попали ни в один топ-10. Тройка лидеров как в Петербурге — Spring, SQL, git. Технологии в списках находятся либо в требованиях, либо в описании проекта. Статистика собрана для разработчиков с разным уровнем опыта. Где-то не совсем технологии, например, библиотека JUnit или протокол SOAP. Разработчики без опыта Вакансий: 66 (9%) 🔸Spring (MVC, Security, Boot, Data) 🔸SQL (Oracle, Hibernate, Postgre) 🔸git 🔸Maven 🔸Jenkins 🔸OpenShift 🔸Docker 🔸Kafka 🔸JUnit 🔸JavaScript Опыт от года до 3х лет Вакансий: 303 (42%) ▪️Spring (Boot, Data, Cloud) ▪️SQL (Hibernate, Postgre, Oracle) ▪️git ▪️Maven ▪️Kafka ▪️Docker ▪️SOAP ▪️JUnit ▪️Jenkins Опыт от 3х до 6 лет Вакансий: 325 (45%) 🔹Spring (Boot, Data, Cloud, Security) 🔹SQL (Postgre, Hibernate) 🔹git 🔹Docker 🔹Maven 🔹Kafka 🔹JUnit 🔹Kubernetes 🔹Gradle 🔹Kotlin 🔹Jenkins Опыт более 6 лет Вакансий: 25 (4%) ▫️Spring (Boot. Data, Cloud) ▫️SQL (Postgre, Hibernate, mySql) ▫️git ▫️Docker ▫️Kubernetes ▫️Kafka ▫️Cloud провайдеры (AWS, GCP) ▫️Scala ▫️Jenkins #статистика

Будущее java: ближайшие 5-7 лет Если вы посмотрите на код, который написали 5 лет назад, он скорее всего вам не понравится. Вы не только стали опытнее, но и поменялся контекст - задачи, требования и языки программирования уже не те, что 5 лет назад. Они меняются и будут меняться дальше. Новые фичи в java не создаются в вакууме, а объединяются в группы с конкретной целью. Каждый релиз - небольшие шаги в сторону этой цели. Проектов много, но особо выделяются Amber, Valhalla, Loom и Panama. Amber Цель: добавить новые конструкции в язык, которые повысят читаемость и снизят вероятность ошибок. Этот проект ближе всего к ежедневной работе программиста. Сюда входит: ▫️Краткая запись типов через var ▫️Текстовые блоки ▫️Pattern matching ▫️Доработка блоков switch ▫️Записи ▫️Sealed классы Фичи должны быть удобными сами по себе, а в будущем хорошо сочетаться между собой. В докладах часто показывают код на java через 5 лет - выглядит классно🥰 Valhalla Цель: новый способ работы с памятью для увеличения производительности. Предыстория: в java 2 типа сущностей — объекты и примитивы. Работа с объектами идёт через указатели: ✅ Полиморфизм, работа с одним объектом из нескольких мест и экономия памяти. ❌ Много перенаправлений и дополнительных структур, сложности с уборкой мусора и многопоточкой. Идея: создать value types — объект с полями и методами, работа с которым идёт как с примитивом: ✅ Передаётся по значению ✅ Компактно лежит в памяти ✅ Не может быть null Вторая идея: создать общую схему работы с примитивами, объектами и value types, избавить программиста от проблемы boxing-unboxing. Loom Цель: поддержка легковесных потоков в JVM. Java стала первым языком, на котором удобно писать многопоточные приложения. Модель памяти сильно облегчает жизнь, а в стандартной библиотеке много полезных классов. Но время не стоит на месте, и реализация 90х уже не подходит для систем с тысячами запросов. Поэтому разрабатывается новая модель. Panama Цель: работа с сущностями за пределами JVM: 🔸 Использовать библиотеки, которых нет на java — линейная математика, 3D графика. Текущая версия JNI неудобна и имеет много недостатков. 🔸 Работа со структурами данных за пределами JVM. ❓Почему так долго? Java упрекают в консервативности и сильном отставании. Но это часть стратегии: не придумывать ничего нового и осторожно выбирать, что войдёт в язык, а что - нет. Собирать отзывы, сценарии использования, смотреть, как решаются проблемы в других языках. Тщательно проектировать новые фичи, пусть даже это займёт 10 лет. Про 10 лет — не преувеличение. Лямбда-выражения в java обсуждались с 2004 года, а увидели свет только в 2014. Основной приоритет - логичность и удобство языка. На java пишут большие системы, которые работают десятки лет. Поэтому всё долго и основательно😌

Новые методы интерфейса List Сегодня разберём вопрос с собеседований по новым методам интерфейса List. Подробно рассмотрим каждый вариант ответа, потому что методы не экзотичные и пригодятся в ежедневной работе. В посте много кода, поэтому для удобства чтения он тут: https://teletype.in/@java_fillthegaps/QN39vs6K0 В конце небольшое лирическое отступление на тему трендов и дизайна методов. #собеседование

Спасибо всем за обратную связь и лайки❤️ Поняла, что зря волновалась По поводу применимости - сборщики действительно нужны больше для общего понимания работы JVM. Возможно, вам никогда не придётся выбирать коллектор и тюнить его. Но! Shenandoah совместим с java 8, и многие проекты сейчас с ним экспериментируют. Вот 2 статьи (первая, вторая) с бенчмарками - при включении Shenandoah в кластерах Cassandra задержки снизились на 25-80%. Кто знает, может новые коллекторы пригодятся и на вашем проекте

Ребята, я добавила чат для обсуждения постов. Пост про сборщики как-то не зашёл, очень мало лайков) Хочу разобраться, почему Новые сборщики мусора не интересны? Или пост не помог понять, как они работают? Или слишком длинный пост для пятницы?🤔

Сборщики мусора, часть 3. Java 15 В java 15 в продакшн стадию вошли 2 новых сборщика мусора — Shenandoah и ZGC. Они подойдут для приложений с памятью до 4 ТБ, где нежелательны длинные задержки. Среднее время паузы не превышает 1 миллисекунду. За такие короткие паузы придётся платить накладными расходами — сборщики занимают до 15% процессорного времени. ❓Как они работают и как получаются такие результаты? Как и в прошлой статье, пропустим 90% деталей и посмотрим на главное. У новых коллекторов 2 особенности: 1️⃣ Расширенные ссылки Обычно в ссылках на объект находится только адрес памяти, где этот объект лежит. Размер поля под ссылку — 64 бита, поэтому в теории можно хранить адрес в пределах 128 ТБ. Это много, поэтому диапазон адресов сокращён до 4 ТБ, а в свободные биты коллектор записывает нужную для себя информацию. Ссылки читаются и обновляются атомарно. Сборщику нужно меньше доп.структур и синхронизации и можно работать почти параллельно с основным приложением. 2️⃣ Load barriers При загрузке объекта сначала читается дополнительная информация из ссылки. Поток приложения или коллектора что-нибудь делает и только потом возвращает адрес в памяти. Что еще. Оба сборщика: ✅ Не используют поколения, работают со всеми объектами ✅ Делят память на множество регионов ✅ Группируют объекты. Дефрагментация помогает быстрее работать с памятью Теперь о разнице между Shenandoah и ZGC: Главное отличие в том, что конкретно записывается в ссылку, и как коллектор с этой информацией работает: 🔹Указатели в Shenandoah используют концепт brook pointers. В ссылке записан адрес объекта и, если объект был перемещён, новый адрес. Допустим, есть объект Х, ссылки на который есть у десятка других объектов. При перемещении Х ссылки станут недействительны и должны быть обновлены. Но поскольку в brook pointers помещается два адреса, старые ссылки можно сразу не трогать. При чтении объекта поток увидит, что есть новая ссылка и сам перезапишет её. 🔹В ZGC у ссылок другой формат – colored pointers. В них коллектор записывает служебную информацию: был ли уже посещён объект, нужно ли его удалить или переместить, есть ли у него финалайзер и т.д Ещё одно отличие — поддержка в JDK. Она зависит от производителя JDK, версии java и ОС. 🔸Shenandoah разрабатывает компания Red Hat. Сборщик доступен в OpenJDK для java 15, сделана поддержка для java 8(!!!) и 11. Oracle отказалась поддерживать Shenandoah, поэтому в OracleJDK его нет. 🔸Разработку ZGC ведёт Oracle. Коллектор включен везде: и в OracleJDK и OpenJDK. В 11 версии есть поддержка Linux, в 14 — Windows. Epsilon GC С java 11 доступен ещё один экспериментальный сборщик —Epsilon GC. С ним приложение работает максимально быстро, потому что сборки мусора как таковой нет. Заканчивается память — JVM завершает работу. Где пригодится: ✅ Короткие разовые задачи Быстро сделал — быстро завершился ✅ Тестирование и эксперименты Без фоновой работы коллектора легче оценить производительность и занимаемую память. #jvm

Сборщики мусора, часть 2. Java 8 В команде java 8 четыре участника: Serial GC, Parallel GC, CMS, G1. Прежде, чем разобрать разницу между ними, повторим теорию. Базовый алгоритм сборки мусора такой: 🔸Построить граф живых объектов 🔸Пометить те, что остались, на удаление 🔸Удалить ненужные объекты 🔸Сгруппировать выжившие *Сборщики в java 8 пропускают последнюю фазу Обходить каждый раз всю память - долго и нерационально. Выгоднее всего убирать локальные переменные и промежуточные объекты. Это суть гипотезы поколений: Память делится на регионы. Новые объекты помещаются в область «новое поколение». Там сборщик будет работать чаще всего. Объекты, которые пережили несколько сборок, считаются «старыми» и переносятся в другую область памяти. Их проверяют реже. Сборка может быть трёх типов: ▫️Minor - обойти только молодое поколение ▫️Major - только старое ▫️Full - память целиком Перейдём к практике. Я опустила 90% деталей, чтобы наглядно показать разницу между коллекторами. Serial GC При любом типе сборки коллектор останавливает потоки основного приложения. Один поток коллектора выполняет все этапы. ✅ Минимум действий при работе приложения ❌ Долгие паузы Когда ок: память до 100 МБ, одно ядро, остановки не критичны Parallel GC Тоже останавливает работу приложения, но запускает несколько потоков для сборки мусора. Сборщик по умолчанию в java 8. ✅ Работает почти незаметно — не более 1% процессорного времени ❌ Чем больше памяти — тем дольше паузы. CMS - Concurrent Mark Sweep Старое и новое поколение обрабатывается по-разному. ▫️Чистка нового поколения как в Parallel GC: основное приложение останавливается, и запускаются несколько потоков коллектора. ▫️Старшее поколение собирается по-другому: Большая часть графа объектов строится параллельно с основным приложением. Объекты удаляются тоже параллельно. Поэтому сборщик и называется Concurrent Mark Sweep - параллельная разметка и удаление. ⛔️ Помечен Deprecated в Java 9, потому что по всем фронтам уступает G1 G1 - Garbage First Предыдущие сборщики делили память на 3-4 большие области — одно для старого поколения и 2-3 для нового. Суть G1 — деление памяти на 2048 регионов, которым присваивается тип - свободный, young, survivor или old. Что это даёт: ▪️Сборщик обрабатывает только несколько регионов, а не всё поколение за раз. ▪️Можно менять количество регионов и регулировать время паузы. ▪️Приложения с большой памятью не тормозят, тк память обрабатывается по частям. ▪️Если регион однородный, можно сразу поменять его тип. Был молодой — стал свободный. Был молодой — стал выживший. ▪️Каждый регион мониторится отдельно. Так G1 выбирает перспективные регионы, куда недавно добавилось много объектов. Отсюда и название - Garbage First. В остальном G1 похож на предыдущие сборщики: 🔹Уборка в молодом поколении останавливает потоки приложения. 🔹Общая проходит как у CMS — некоторые фазы тормозят работу приложения, некоторые работают параллельно ✅ Есть настройка длины паузы и других параметров. Гайд по тюнингу G1 ✅ Работает с большой памятью ✅ Анализирует статистику сборок, хорошо работает с настройками по умолчанию. ❌ Занимает до 10% процессорного времени G1 показывает отличные результаты в энтерпрайзе. В java 9 стал сборщиком мусора по умолчанию. В следующей части посмотрим на новые сборщики — Shenandoah, ZGC и Epsilon GC. #jvm

Сборщики мусора: часть 1. Обзор Сборка мусора — фоновый процесс в JVM, который удаляет уже ненужные объекты. В основном каждая реализация балансирует между двумя параметрами: 🔹Latency: максимальное время обработки запроса 🔹Пропускная способность: сколько запросов обработается в минуту "Запрос" здесь - взаимодействие приложения с памятью: создание, обновление и удаление объектов. Приоритет зависит от приложения: ▪️Для веб-сервисов большие задержки недопустимы. Лучше в среднем ответ будет на четверть секунды дольше, но не будет подвисших запросов. ▪️Приложение работает в фоновом режиме. Например, архивирует записи. Не критично, если каждая сотая запись будет архивироваться 5 секунд, если за час обработается больше данных. Алгоритм коллектора везде один и тот же: 🔸Отмечаем объекты, которые нужны 🔸Помечаем остальные объекты на удаление 🔸Удаляем ненужные объекты 🔸Группируем выжившие Чтобы понять, какие объекты нужны приложению, строится граф достижимых объектов. Самостоятельные объекты называются roots и существуют без привязки к другим. Это локальные и статические переменные, потоки и т.д. Смотрим, на какие объекты ссылаются roots. Идём дальше по ссылкам и получаем граф живых объектов. ⚠️Но есть проблема: объекты в памяти постоянно меняются. Есть две крайности: 1️⃣ Когда памяти останется мало, целиком остановить приложение и убрать мусор. Будет большая пауза, но в остальное время сборщик не будет тормозить основное приложение. 2️⃣ Следить за статусом объектов и ссылок, вести таблицы использования. Так ненужные объекты легко найти, но сам сборщик будет занимать много процессорного времени. Разные коллекторы балансируют между этими крайностями: некоторые фазы происходят параллельно, а для некоторых нужна полная остановка. Универсального сборщика нет, на выбор влияет количество процессоров, памяти, тип нагрузки и так далее. В части 2 мы подробно рассмотрим сборщики мусора в java 8 #jvm

В java 15 в продакшн стадию вошли 2 новых сборщика мусора — Shenandoah и ZGC. Возникает логичный вопрос — зачем они нужны? В java 8 и так 4 сборщика, что с ними не так? Кратко ответить не получилось, поэтому на этой неделе выйдет роман в трёх частях: 🔸Часть 1: обзор и принцип работы 🔸Часть 2: Serial, Parallel, CMS, G1 🔸Часть 3: Shenandoah, ZGC, Epsilon

🍃Spring: статистика использования Есть ли в java мире более популярный фреймворк, чем Spring? Кажется, что нет. Spring упоминается в половине вакансий на HeadHunter и используется в большинстве веб-сервиcов на java. Spring— огромная экосистема из 24 проектов. Все освоить невозможно, да и не нужно. Лучше сфокусироваться на самых актуальных. Компания VMWare занимается виртуализацией и недавно провела опрос более тысячи разработчиков: как и с чем они используют Spring. Результаты опроса собрались в доклад State of Spring 2020: Какие модули Spring используются чаще всего? ▫️>75% - MVC, Security, Data ▫️56% - Cloud ▫️30-40% - Batch, Integration, Kafka Spring Boot на пике популярности: 🔸82% разработчиков пишут на нём новые проекты 🔸53% планируют перевести на Spring Boot легаси проекты Что нравится в Spring Boot: 🔹70% - Готовые конфигурации 🔹64% - Стабильность, безопасность, масштабируемость 🔹61% - Удобство разработки Что вызывает вопросы: ▪️39% - Непонятно, как это работает😅 ▪️34% - Долгий запуск приложений ▪️25% - Высокое потребление памяти *В апреле у Spring появилась поддержка GraalVM. С ним время запуска и расход памяти будут ниже. Какая архитектура встречается в приложениях Spring Boot? ▫️83% - Микросервисы ▫️33% - Реактивная (Project Reactor, Webflux) ▫️12% - Serverless (Spring Cloud Function) Где Spring Boot, там и Docker: 🔸65% уже запускают приложения в контейнерах 🔸30% планируют начать в этом году Где Docker, там и Kubernetes: ▪️44% уже используют Kubernetes для развёртывания ▪️31% планируют перейти в течение 12 месяцев Люблю такие опросы: видно, куда движется разработка бэкенда. Начинающим разработчикам полезно вдвойне - понятно, что и в каком порядке изучать. #статистика

Хочешь хорошую работу? Закрой HH Популярный способ найти работу — открыть HeadHunter и откликнуться на подходящие вакансии. Способ простой, но поиск растянется на недели и маловероятно, что вы найдёте вакансию мечты. Почему так происходит? HR Арина написала прекрасный лонгрид на эту тему: Найти работу и не впасть в отчаяние. Краткий пересказ: На вакансию средних и крупных компанию откликается 100-1000 человек. Даже если вы идеально подходите на должность, резюме могут: 🔸Пропустить 🔸Невнимательно посмотреть 🔸Отбросить за малейший недочёт Попробуйте другие стратегии — целевой поиск и рекомендации. 1️⃣ Целевой поиск Cоставить список интересных компаний и общаться с ними напрямую. В составлении списка поможет HH. Зайдите на сайт каждой компании в списке, найдите вкладку Jobs/Careers и отправьте резюме и сопроводительное письмо. Зафиксируйте в списке контакты, открытые позиции, вопросы с собеседований, обратную связь работодателей. ✅ Рекрутёр оценит вашу инициативность. ✅ Отклик попадает на почту рекрутёру или во внутреннюю систему компании. Шанс, что письмо прочитают, в разы выше, чем на HH. 2️⃣ Рекомендации Напишите бывшим коллегам и начальникам: спросите о текущих проектах в компании. Расскажите, что ищете работу и попросите порекомендовать вас. ✅ Заранее узнаете информацию о проектах и требованиях. ✅ Собеседование скорее всего будет проще. Мои дополнения: 🔹В IT за рекомендацию кандидатов часто выдают бонусы, поэтому бывшие коллеги вам с радостью помогут. 🔹Для джуниор-мидл разработчиков целевой поиск обязателен. Если вам нравится компания, но на сайте нет подходящей по уровню вакансии, то попробуйте следующий способ: На контакт из вкладки Careers отправьте резюме и примерно такое мотивационное письмо: Здравствуйте, меня зовут ... Я давно слежу за компанией Х, и мне очень нравится направление её работы. Ваша платформа помогает сотням интернет-магазинов с бухгалтерией, вы делаете ценный вклад в развитие малого бизнеса. Подскажите, пожалуйста, как можно присоединиться к вашей команде? Я — начинающий java разработчик. Моё резюме - в приложении к письму. С уважением, ... Вы не навязываетесь, всего лишь просите совет. Такие формулировки встречаются редко и увеличивают шанс получить обратную связь или приглашение на собеседование😌

Java 15: анонс Сегодня вышла 15 версия языка, которому посвящён этот канал❤️ В релизе 14 обновлений: 1️⃣ Новый синтаксис — пока в превью фазе: ▫️Текстовые блоки ▫️Sealed classes ▫️Записи ▫️Удобный instanceof:

if (obj instanceof String str)

можно сразу использовать str как переменную. 2️⃣ Новое API: ▪️Алгоритм цифровой подписи EdDSA появился в пакете security. ▪️Foreign-Memory Access API: доступ к памяти за пределами Heap. ▪️Скрытые классы: Большинство фреймворков работают так: помечаете классы аннотациями, фреймворк их находит и создаёт класс-обёртку с дополнительными функциями.

MethodHandles.lookup()
   .defineHiddenClass(…)

Создаст класс, который недоступен коду основного приложения. 3️⃣ Обновились классы DatagramSocket и MulticastSocket. 4️⃣ В финальную стадию вошли 2 сборщика мусора: ZGC и Shenandoah. Оба сборщика подойдут для приложений с RAM до 4 ТБ, в которых нежелательны долгие паузы на сборку мусора. В новых GC задержка не превысит 2 мс, но среднее время работы чуть увеличится. 5️⃣ Некоторые фичи стали недоступны: Nashorn JS Engine, Biased Locking, Solaris and SPARC Ports, RMI Activation for Removal Ответ на вопрос перед постом Как посчитать, когда версия java будет равна вашему возрасту: Пусть Age – возраст в 2020 x – количество лет, через которое версия = возраст. Age + x = 15 + 2*x x = Age - 15

5 шорткатов для быстрого перемещения. 1️⃣ Показать список методов в классе:

Ctrl + F12

Есть функция частичного поиска, просто начните набирать часть имени метода. Список отфильтруется. 2️⃣ Найти класс или файл:

Shift-Shift

Универсальный шорткат для поиска любых файлов в проекте. 3️⃣ Перейти к определению:

Ctrl + B

Для переменных — где она была объявлена, для методов — к их реализации. 4️⃣ В предыдущий класс:

Ctrl + Alt + ⬅️ 
Ctrl + Alt + ➡️ 

IDEA следит за перемещениями между файлами, и по истории можно быстро перемещаться. 5️⃣ Перейти на строку по номеру:

Ctrl + G

"Проверь условие в строке 850". Можно не проматывать огромный класс, а быстро перейти на нужную строку. #IDEA

Records и немного теории 15 сентября выйдет java 15. Если вы отмечаете это событие интеллектуальной беседой под пиццу, то этот пост для вас. Здесь вы найдёте немного computer science на тему records. Неизменяемые типы — основа функциональных языков. Записи — простые структуры, но за этой простотой стоит теоретический фундамент. Система типов — теория, на основе которой проектируется язык программирования. Cегодня разберём классификацию, которая отвечает на вопрос: ❓Как определить тип объекта? 1️⃣ По имени. Тогда это номинальный тип На основе имени проверяется возможность вызова методов и приведения типов друг к другу

record Point(int x,int y){}
record Time(int hours,int min){}

❌ Point p = new Time(1,1); Записи по факту одинаковые — два целых числа. Но имена разные, поэтому типы между собой несовместимы. У номинальных типов проверки часто происходят на этапе компиляции. 2️⃣ По данным внутри объекта. Тогда это структурный тип. Для них возможна запись: ✅ Point p = new Time(1,1); Структурные типы используются в функциональных языках и java script. Они добавляют больше гибкости, но менее управляемы. В java структурных типов нет и скорее всего не будет. В 2013 году обсуждалось, чтобы ввести в язык первый структурный тип под названием arrow type. Выглядел бы он так:

(String) → Integer

Идею отвергли из-за сложностей реализации и адаптации к существующим библиотекам. Альтернативное решение — лямбда-выражения, представляют похожую функциональность, но с чётко определённым типом:

Function<String,Integer> f = 
  str → str.length();

Все структуры в java номинальные. Записи - не исключение. Номинальность была в требованиях для реализации, а в анонсе records называют nominal tuples — номинальные кортежи.