Java *

Добрый день. Делюсь своей старой исследовательской мини-статьей. Не ругайтесь, мне просто было скучновато.

Я, как и любой программист, люблю изучать что-то новое. Все мы знаем о киношных хакерах, которые могут парой нажатий кнопок на любом холодильнике, взломать инсту маминой подруги.

Очередное желание изучить что-то новое привело меня к попытке написать программу (на rust), которая должна без инъекции взаимодействовать с запущенным java приложением. Я хотел читать и изменять память нужных мне java объектов без загрузки java-agent модулей, без использования jni, без загрузки новых классов в приложение и т.п. У меня есть PID процесса и знание о том, что это java приложение.

При разработке рабочего проекта, локальный запуск которого дело достаточно ресурсоемкое, у меня возникла идея попробовать облегчить себе работу путем создания плагина, который налету при разработке может анализировать блок кода, тем самым выдавая рекомендации по оптимизации или находя ошибки.

Команда Spring АйО перевела статью, в которой Steve Reisenberg рассказал о множестве полезных улучшений для работы с OAuth2 в Security 6.4. 

Прочитав статью вы узнаете, как отправлять запросы к защищенным ресурсам без дополнительных зависимостей, а также переопределять параметры в запросах токенов доступа для реализации сложных сценариев.

Некоторые компании, работающие с персональными данными пользователей, сталкиваются с невозможностью хранить их в течение долгого периода времени из-за правовых ограничений. Такое часто можно встретить в финтехах. Позволяется сохранить данные на очень короткое время, которые также должны быть удалены сразу после использования в целях сервиса. Существует несколько вариантов решения этой задачи. В данном посте я показываю упрощенный пример микросервиса, работающего с чувствительной информацией, используя Spring и Redis. 

Недавно была опубликована статья под заголовком "Глобально оптимальный, восьмой и наиболее быстрый вид интерпретаторов байткода". Несколько тезисов из статьи вызвали у меня сомнения в их справедливости. Об этом я попробовал написать ряд комментариев тире вопросов к указанной статье. Но основной лейтмотив всех ответов сводился к тому - "а ты напиши свою статью". Подход не столько инженерно-научный, сколько детсадовский. Мне бы хватило и содержательных ответов в формате комментариев, но как говорится - уговорили :).

Итак, что же утверждается автором статьи про наиболее быстрый интерпретатор:

Это статья-туториал. Рассмотрим в ней, как сделать компонент, который поможет забыть о необходимости дублировать механизмы аутентификации и авторизации. Цель статьи - реализовать starter, который можно будет легко и удобно подключить к Spring Boot проекту. Предлагаемая цель актуальна?

Всем привет! 👋 👋 👋 👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

В этом выпуске обсуждаем последние обновления в экосистеме Java и популярных инструментах для разработчиков — от уменьшения размера хедеров объектов и новых API для файлов классов до новинок в IntelliJ IDEA. Делимся полезными статьями и видео об ускорении сборок, работе с JPA и Elasticsearch и даем рекомендации по разработке собственного Kafka Connector. Не пропустите интересные подкасты и практические примеры! 

REST API — один из самых популярных типов веб‑сервисов. Но несмотря на множество туториалов по его созданию, на практике встречаются сервисы, которые вызывают лишь разочарование у пользователей.

Это подтолкнуло Костю, проектного разработчика в Naumen, создать краткое руководство по написанию плохого REST‑сервиса. Уже несколько лет он занимается поддержкой и развитием проектов на Naumen Service Management Platform, часто сталкивается с проектированием REST API и точно знает, каких ошибок лучше не допускать.

В статье Костя поделился основными антипаттернами и рассказал, что не нужно нести на прод.

Привет, Хабр! На связи Александр Бобряков, техлид в команде МТС Аналитики. Это мой десятый материал про Apache Flink. В предыдущей части мы закончили разбирать оператор с Flink-таймерами, использующими внутреннее состояние. Также я показал, как их можно тестировать с помощью классов TestHarness или Flink MiniCluster. В дополнение тестами была покрыта вся Flink-джоба, включая E2E-тесты.

В этой части мы посмотрим сериализацию данных и состояний в операторах. Также напишем свой сериализатор, поддерживающий эволюцию схемы. В следующих частях протестируем его и внедрим в наше приложение.

Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии статей. Эта часть соответствует релизной ветке с названием release/9_JacksonStateSerializer.

По мере выхода новых материалов на Хабре ссылки на них будут появляться ниже.

Команда Spring АйО перевела и адаптировала доклад "Garbage Collection in Java: The progress since JDK 8" Стефана Йоханссона(Stefan Johansson) с последнего Devoxx Belgium.

Доклад получилось поделить на две статьи. В первой вы узнаете об основах работы сборки мусора в Java, различных сборщиках мусора, а также об их особенностях, плюсах и минусах. Вторая часть будет посвящена сравнению производительности сборщиков и их прогрессу с момента выхода JDK 8.

Виртуальные потоки вызвали большой интерес в сообществе разработчиков Java, включая такие фреймворки, как Open Liberty. Команда инженеров по производительности Liberty провела оценку, чтобы выяснить, может ли эта новая фича принести пользу пользователям или даже потенциально заменить текущую логику пула потоков, используемую в среде выполнения Liberty. Как минимум, мы хотели лучше понять технологию виртуальных потоков и её производительность, чтобы предоставить обоснованные рекомендации пользователям Liberty.

В этой статье представлены наши результаты, включая:

- Обзор реализации виртуальных потоков в Java
- Обзор текущей технологии пула потоков в Liberty
- Оценку по ряду показателей производительности, включая неожиданные наблюдения
- Сводный обзор наших выводов

20 октября после продолжительной борьбы с глиобластомой скончался первоначальный автор декомпилятора Java Fernflower Стивер.

Стивер был немецким программистом русского происхождения, в основном разрабатывавшим программное обеспечение для медицинского оборудования. Двадцать лет назад у него появился глубокий профессиональный интерес к внутренним устройствам виртуальной машины Java. Вы можете помнить его исследовательские записи в блоге, например, эту (на русском) от 2006 года о том, как настроить иерархию классов Java с помощью Unsafe, когда Java 1.5 только вышла. Примерно в 2008 году Стивер увлекся декомпиляцией Java.

В то время ландшафт декомпиляции Java был очень беден. Время первого поколения декомпиляторов, таких как JAD или JODE, подходило к концу. В то время как Java как язык развивался, существующие декомпиляторы в основном не поддерживались, что затрудняло работу с новыми языковыми конструкциями, такие как операторы утверждений, аннотации и универсальные типы. Более того, прекращение поддержки инструкций JSR/RET в байт-коде Java привело к существенной разнице в том, как компилируются блоки try-finally. Декомпиляторы не смогли обрабатывать новый байт-код.

Еще одной большой проблемой существующих декомпиляторов был их подход к декомпиляции. Они просто искали определенные шаблоны байт-кода и переводили их в соответствующие операторы и выражения Java. Несмотря на простоту, этот подход является нестабильным - любое незначительное семантически эквивалентное изменение в сгенерированном байт-коде делало надлежащую декомпиляцию невозможной. Это серьезно ограничивало применение декомпилятора.

Привет, Хабр! Меня зовут Константинов Александр, я Android-разработчик в «Студии Олега Чулакова». Сегодня мы сравим операторы RxJava 3 и Flow. Статья будет полезна как для изучения операторов, так и для более легкого перехода с RxJava на Flow.

Это предупреждение, которое выведет хибернейт, если для осуществления пагинации ему придется загрузить ВСЕ данные из таблицы, а не по одной странице.

Команда Spring АйО перевела статью, раскрывающую преимущества использования OpenTelemetry для мониторинга и трассировки Spring Boot приложений.

В статье показано, как интеграция с OpenTelemetry с использованием OTLP и других компонентов позволяет легко встроить стандартизированный сбор метрик, логов и трассировок в экосистему Spring.

В первом выпуске подкаста Spring АйО в студии собрались 4 эксперта сообщества, чтобы попытаться раз и навсегда ответить на вопрос: "Чем же для нас стал Spring: эволюцией или революцией?"

Привет, Хабр!

В этой статье наш взор упадет на на Tribuo — библиотеку машинного обучения на Java от Oracle.

Tribuo поддерживает различные алгоритмы для классификации, регрессии, кластеризации и многого другого. Но сегодня мы сосредоточимся на регрессии — фундаментальной задаче, которая позволяет предсказывать непрерывные значения. Одним из главных плюсов Tribuo является её удобный API, который позволяет быстро строить модели и оценивать их эффективность.

В продолжении статьи автор углубляется в возможности генерации с поддержкой поиска (RAG), чтобы LLM могла учесть некоторую контекстуальную информацию данных, первоначально невходившую в ее обучающую выборку.

В новом переводе от команды Spring АйО рассматривается польза Spring AI и хранилища векторов, благодаря которым система не просто сопоставляет ключевые слова, но и понимает смысловые запросы пользователей, делая взаимодействие с приложением еще более естественным.

Микросервисная архитектура — это новый черный: кажется, уже все бигтехи пилят монолиты на сервисы и и ищут гошников в штат. Спрос рождает предложение — всё больше ребят переходят с других бэкенд-языков на Golang. 

Мы попросили наших разработчиков поделиться своим опытом перехода на Go и рассказать, почему они решили освоить новый язык программирования, какие плюсы и минусы видят в нём, дал ли переход на Go буст в новых карьерных возможностях и кому и в каких случаях они бы они советовали освоить golang. 

Эта статья может быть полезна тем, кто тоже хочет добавить Go в копилку знаний, но пока не решился. Приступим!

Привет! Особенно @kesn, сейчас расскажу почему!

Ко мне в телеграмм постучалась очень приветливая и милая девушка HR из Яндекса, с предложением о работе. Я очень обрадовалась, особенно потому, что рынок IT в 2023 очень нестандартный :)

Созвонились на 15 минут, мне рассказали об этапах - три алгоритмических интервью, по две задачи в течение часа, третье - с независимым экспертом Яндекса и на целых 1,5 часа. Скинули ссылки на leetcode, CodeRun, пара видео с разбором задачек на доске с фломастером и статья Яндекса о том, как они нанимают бэкэнд разработчиков.

Я просмотрела эти материалы и достаточно быстро нашла статью. Хм, интересно! Изначально у меня не было высоких ожиданий относительно интервью, у меня двухлетний опыт Java разработки, и нет идей как алгоритмический live-coding в три этапа поможет вычленить нужного проекту кандидата. И да, я не готовилась.

Интервью 1. Очень приятный молодой человек, прекрасно вел интервью и поддерживал, так как видел мое волнение.