Что такое native методы в Java? 🤓
Ответ:
Ключевое слово native обозначает методы, реализованные на языке C/C++ через JNI (Java Native Interface). Используются для доступа к системным ресурсам.
Пример:
public class NativeExample {
native void print();
static { System.loadLibrary("NativeLib"); }
}
Требует компиляции нативного кода и загрузки библиотеки. Используется редко, но важен для интеграции с низкоуровневыми API.
#собеседование
Ответ:
Пример:
public class NativeExample {
native void print();
static { System.loadLibrary("NativeLib"); }
}
Требует компиляции нативного кода и загрузки библиотеки. Используется редко, но важен для интеграции с низкоуровневыми API.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
С 12.07 по 18.07
Предыдущий пост(с 05.07 по 11.07)
Воскресный мотивационный пост:
Мое обращение к Вам
Выбранная голосованием тема:
Maven в IntelliJ IDEA: Встроенный Maven и его роль
Запись встреч/видео:
не проводились
Обучающие статьи:
Комментарии в Java
Ключевые слова и зарезервированные слова в Java
Введение в Java
Подробная инструкция по установке Maven на Windows
Установка Maven на Linux
Полезные статьи и видео:
Hibernate Best Practices для начинающих
Неблокирующий вызов внешнего сервиса в процессе
Посмеяться
Как и всегда, задачи можно найти под тегом - #Tasks, вопросы с собеседований - #собеседование
#memory
Предыдущий пост(с 05.07 по 11.07)
Воскресный мотивационный пост:
Мое обращение к Вам
Выбранная голосованием тема:
Maven в IntelliJ IDEA: Встроенный Maven и его роль
Запись встреч/видео:
не проводились
Обучающие статьи:
Комментарии в Java
Ключевые слова и зарезервированные слова в Java
Введение в Java
Подробная инструкция по установке Maven на Windows
Установка Maven на Linux
Полезные статьи и видео:
Hibernate Best Practices для начинающих
Неблокирующий вызов внешнего сервиса в процессе
Посмеяться
Как и всегда, задачи можно найти под тегом - #Tasks, вопросы с собеседований - #собеседование
#memory
👍3
Minecraft Forge API 1.16.5
Что такое Forge?
Forge - загрузчик модов в Minecraft, он позволяет быстро и доступно получить доступ к защищённым полям Minecraft.
Установка Forge.
Скачайте Forge MDK 1.16.5 с оф. сайта net.minecraftforge и откройте в IntelliJ.
Установите также плагин Minecraft Development.
Подготовка.
Установите SDK - Java 8 ( OpenJDK / Correto )
Дождитесь инициализации проекта.
Начало.
Запуск клиента происходит так: справа сверху где запуск выберите runClient, и запустите.
Основной класс мода должен содержать:
@Mod("examplemod") - указание ModLoader'у что этот класс основной для Forge. ( examplemod - MODID который указывается по умолчанию в forge mdk)
MinecraftForge.EVENT_BUS.register(this); - регистрирует данный класс для прослушивания ивентов ( т.е если используется прослушивание то зарегистрировать класс что он прослушивает ивенты .)
Перейдём к аннотациям, а точнее к прослушивании ивентов.
Аннотация: @SubscribeEvent
Для чего? - просушивать ивенты ( события игры )
Практика.
Аннотация @SubscribeEvent выполняет прослушку в этом примере: TickEvent.PlayerTickEvent.
Данный ивент позволяет делать почти все что угодно с игроком ( поворот головы, тела, телепортация, скорость и т.д)
Также существуют множество ивентов по типу:
RenderNameplateEvent, RenderGameOverlayEvent, TickEvent.RenderTickEvent, ну и так далее.
Статья написана @forgehook
Что такое Forge?
Forge - загрузчик модов в Minecraft, он позволяет быстро и доступно получить доступ к защищённым полям Minecraft.
Установка Forge.
Скачайте Forge MDK 1.16.5 с оф. сайта net.minecraftforge и откройте в IntelliJ.
Установите также плагин Minecraft Development.
Подготовка.
Установите SDK - Java 8 ( OpenJDK / Correto )
Дождитесь инициализации проекта.
Начало.
Запуск клиента происходит так: справа сверху где запуск выберите runClient, и запустите.
Основной класс мода должен содержать:
@Mod("examplemod")
public class Main {
public Main() {
MinecraftForge.EVENT_BUS.register(this);
}
}
@Mod("examplemod") - указание ModLoader'у что этот класс основной для Forge. ( examplemod - MODID который указывается по умолчанию в forge mdk)
MinecraftForge.EVENT_BUS.register(this); - регистрирует данный класс для прослушивания ивентов ( т.е если используется прослушивание то зарегистрировать класс что он прослушивает ивенты .)
Перейдём к аннотациям, а точнее к прослушивании ивентов.
Аннотация: @SubscribeEvent
Для чего? - просушивать ивенты ( события игры )
Практика.
@SubscribeEvent
public void onTick(TickEvent.PlayerTickEvent event) {}
Аннотация @SubscribeEvent выполняет прослушку в этом примере: TickEvent.PlayerTickEvent.
Данный ивент позволяет делать почти все что угодно с игроком ( поворот головы, тела, телепортация, скорость и т.д)
Также существуют множество ивентов по типу:
RenderNameplateEvent, RenderGameOverlayEvent, TickEvent.RenderTickEvent, ну и так далее.
Статья написана @forgehook
Софт-скиллы, которым не учат в курсах
Вот представь, ты прочитал весь мой канал, изучил синтаксис вдоль и поперек, научился виртуозно делать API, освоил Git, знаешь Spring и WebFlux.
Но вот пришло собеседование — и ты... завис.
— Расскажите о себе.
— Ну… я... типа… учился… кодить...
Знакомо?
А теперь еще предположим: ты уже устроился и тебе дали таску.
И ты видишь, что надо уточнить у тимлида детали.
Но в голове:
«А если я спрошу — подумает, что тупой...»
«Лучше погуглю еще 3 часа, чем покажусь нубом»
«Он ведь профи. Я даже не знаю с чего начать...»
Это называется - коммуникативная тревожность.
Она же — тихий киллер карьеры в IT.
Почему ты боишься говорить
Вот тебе правда: страх общения — это не про характер.
Это навык.
Даже самые «разговорчивые» разработчики когда-то:
- боялись скинуть Pull Request с комментариями,
- часами переписывали сообщение в телеграмме,
- репетировали простой вопрос голосом.
Почему некоторым в IT это так сложно?
Потому что IT часто привлекает интровертов, бывших «отличников», людей, которые учились всё понимать сами, без помощи. И теперь, оказавшись в команде — они просто не умеют задавать вопросы или входить в беседу.
Что происходит в голове?
В когнитивной психологии есть понятие self-presentation concern — это тревога из-за того, как тебя воспримут другие.
Именно она:
- заставляет молчать, когда нужно спросить;
- мешает делиться идеями;
- блокирует на стендапах.
А ещё есть спираль молчания — если ты боишься говорить, ты выпадаешь из общения, и из-за этого боишься ещё больше.
Вот пара моих советов если ты чувствуешь что твой софт-скилл слабоват:
Говори, даже если страшно.
Но не вживую, а письменно.
Заведи привычку активно писать: в рабочем чате, в Telegram, в комментариях к pull request'ам.
Так ты приучаешь мозг к выражению мысли — без страха, что тебя перебьют или осудят.
Это снижает тревожность, активирует рефлексивную речь — внутреннее проговаривание и структуру мысли.
Не бойся задавать глупые вопросы.
Как сказал один умный человек: "В IT нет глупых вопросов, есть чересчур ЧСВ-шные отвечающие"
Микроконтакт — это уже общение
Не нужно фигачить речь на 3 минуты.
Просто начни с одной фразы:
«А почему мы сделали вот так, а не так?»
«Спасибо, крутая реализация»
«Подскажи, я что-то путаюсь в этой части»
Это называется anchored small talk — микровзаимодействия, которые создают эффект «я в теме». Даже если ты мало говоришь.
Заготовь фразы. Да, можно и записать
Серьёзно.
Напиши себе в заметках:
Вопрос на стендап: «Ребят, я правильно понимаю, что…»
Начало диалога: «Можно короткий вопрос про фичу?»
Завершение: «Окей, тогда попробую и отпишусь»
В момент тревоги мозг не придумывает речь с нуля. Он вытаскивает готовое.
Подсунь ему нужные заготовки — и увидишь, как снижается стресс.
Найди «одного своего»
Не команду. Не менторов. Одного союзника, с кем безопасно говорить.
Пишете вместе код — обменивайтесь мыслями.
Работаете на проекте — обсуждай идеи.
В сообществе — шутите, делитесь опытом.
Это снижает страх перед всей группой. Есть ощущение, что ты не один. А с этого и начинается уверенное взаимодействие.
Ты можешь спросить: "А зачем мне это вообще?"
Пойми:
Ты можешь быть классным кодером, но без софт-скиллов — останешься «интровертным сеньором без влияния».
Ты сможешь влиять, если умеешь объяснить, услышать, вдохновить.
Продуктивность команд напрямую зависит от психологической безопасности — и ты можешь её самостоятельно формировать.
А еще спроси себя - кого повысят, из двух одинаково скиловых разработчиков? Того кто грамотно и без страха излагает свои мысли или того кто молчит или отвечает невпопад?
Поэтому, не стесняйся, пиши в комментариях, что ты думаешь об это статье! Прокачай навык
#motivation
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍3 1
Предлагаем темы для разбора и публикации! 📖
В комментариях к данному посту предлагайте вопросы, которые вы хотели бы увидеть максимально подробно разобранными в постах, а если будет интересно то и на видео.
Голосование будет проводиться всю неделю, а статья или видео - выходить по выходным.
Примерные правила:
🟢 темы, не выше уровня middle, чтоб был интерес общим.
🟢 Один человек - одна тема.
🟢 Тема должна быть отдельным теоретически-практическим вопросом. Готовый проект - это не тема!
Жду Ваших предложений!👏
В комментариях к данному посту предлагайте вопросы, которые вы хотели бы увидеть максимально подробно разобранными в постах, а если будет интересно то и на видео.
Голосование будет проводиться всю неделю, а статья или видео - выходить по выходным.
Примерные правила:
Жду Ваших предложений!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Выбираем темы для рассмотрения в следующие выходные! 🤨
Anonymous Poll
32%
OkHttps
14%
GraphQL
32%
NoSQL DB
21%
Nginx
👍3
А вы знали, что первый компьютерный "онлайн-опросник" был создан в 1995 году?
SurveyMonkey, запущенный в 1995 году, стал первым сервисом для создания онлайн-опросов. Он позволил бизнесам собирать данные от пользователей через интернет.
#facts
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
"Будущее компьютеров — в их способности решать задачи коллективно."
Михаил Карцев, разработчик суперкомпьютеров, сказал это в 1970-х годах в Институте точной механики.
Биография
#Citation #Biography
Please open Telegram to view this post
VIEW IN TELEGRAM
Wikipedia
Карцев, Михаил Александрович
Михаи́л Алекса́ндрович Ка́рцев (10 мая 1923, Киев — 23 апреля 1983, Москва) — советский учёный в области вычислительной техники, доктор технических наук, профессор.
👍3
Введение в Gradle и концептуальная архитектура
Что такое Gradle? Эволюция от Ant и Maven
Gradle — это инструмент автоматизации сборки с открытым исходным кодом, предназначенный для управления проектами на Java, Kotlin, Scala, C++ и других языках. Он сочетает декларативный подход Maven с гибкостью Ant, используя Groovy или Kotlin для описания сборки. Gradle был создан в 2007 году Хансом Доктером и Адамом Мердоком и с тех пор стал стандартом для многих современных проектов, включая Android и Spring Boot.
Эволюция
Ant (2000): Первый широко используемый инструмент сборки для Java. Ant применяет императивный подход, где разработчик вручную описывает задачи в XML-файле (build.xml). Он не предоставляет встроенного управления зависимостями или жизненного цикла, что делает его гибким, но сложным для крупных проектов.
Maven (2004): Ввел декларативный подход с жизненным циклом (clean, build, site) и управлением зависимостями через репозитории. Maven использует XML (POM.xml), что обеспечивает стандартизацию, но ограничивает гибкость для нестандартных сценариев.
Gradle (2007): Объединяет преимущества Ant и Maven, предлагая:
Гибкость: Возможность писать программную логику для задач с помощью Groovy или Kotlin.
Производительность: Инкрементальная сборка и кэширование задач.
Декларативность: Простое описание зависимостей и плагинов, аналогичное Maven.
Многопроектная поддержка: Эффективное управление многомодульными проектами.
Gradle стал популярным благодаря поддержке Android Studio, высокой производительности и активному сообществу.
В памяти: Gradle работает как Java-приложение, загружая конфигурационные файлы (build.gradle, settings.gradle), плагины и зависимости в оперативную память. В отличие от Maven, Gradle использует Groovy/Kotlin для парсинга скриптов, что увеличивает потребление памяти из-за динамической природы этих языков, но оптимизируется за счет кэширования и инкрементальности.
Архитектура Gradle
Архитектура Gradle построена вокруг концепции задач (tasks) и графа выполнения, что отличает его от жизненного цикла Maven. Рассмотрим ключевые аспекты.
Task-based Model vs Lifecycle-based (в Maven)
Task-based Model (Gradle):
Gradle использует модель, основанную на задачах, где каждая задача (task) — это атомарная единица работы (например, компиляция, тестирование, упаковка).
Задачи определяются в build.gradle и могут быть связаны через зависимости (например, задача build зависит от compileJava).
Разработчик может создавать кастомные задачи с программной логикой, что обеспечивает гибкость.
Пример:
Lifecycle-based Model (Maven):
Maven использует фиксированный жизненный цикл (clean, default, site) с фазами (compile, test, package), к которым привязаны плагины.
Ограниченная гибкость: задачи определяются через плагины, а не напрямую.
В памяти:
В Gradle каждая задача представлена как объект в памяти, содержащий конфигурацию и зависимости. Это увеличивает потребление памяти по сравнению с Maven, где фазы жизненного цикла имеют более жесткую структуру. Однако Gradle оптимизирует выполнение, пропуская неизмененные задачи (см. инкрементальность).
Directed Acyclic Graph (DAG) исполнения задач
Gradle строит Directed Acyclic Graph (DAG) для задач, где:
Узлы — это задачи.
Ребра — зависимости между задачами (например, build зависит от test, а test — от compileJava).
Gradle анализирует DAG, чтобы определить порядок выполнения задач и избежать циклов.
Процесс:
Gradle парсит build.gradle и создает объекты задач в памяти.
Формируется DAG на основе зависимостей, указанных в dependsOn или неявно через плагины.
Gradle выполняет задачи в порядке, определенном топологической сортировкой DAG, пропуская те, которые не требуются.
Пример:
#Java #middle #Gradle
Что такое Gradle? Эволюция от Ant и Maven
Gradle — это инструмент автоматизации сборки с открытым исходным кодом, предназначенный для управления проектами на Java, Kotlin, Scala, C++ и других языках. Он сочетает декларативный подход Maven с гибкостью Ant, используя Groovy или Kotlin для описания сборки. Gradle был создан в 2007 году Хансом Доктером и Адамом Мердоком и с тех пор стал стандартом для многих современных проектов, включая Android и Spring Boot.
Эволюция
Ant (2000): Первый широко используемый инструмент сборки для Java. Ant применяет императивный подход, где разработчик вручную описывает задачи в XML-файле (build.xml). Он не предоставляет встроенного управления зависимостями или жизненного цикла, что делает его гибким, но сложным для крупных проектов.
Maven (2004): Ввел декларативный подход с жизненным циклом (clean, build, site) и управлением зависимостями через репозитории. Maven использует XML (POM.xml), что обеспечивает стандартизацию, но ограничивает гибкость для нестандартных сценариев.
Gradle (2007): Объединяет преимущества Ant и Maven, предлагая:
Гибкость: Возможность писать программную логику для задач с помощью Groovy или Kotlin.
Производительность: Инкрементальная сборка и кэширование задач.
Декларативность: Простое описание зависимостей и плагинов, аналогичное Maven.
Многопроектная поддержка: Эффективное управление многомодульными проектами.
Gradle стал популярным благодаря поддержке Android Studio, высокой производительности и активному сообществу.
В памяти: Gradle работает как Java-приложение, загружая конфигурационные файлы (build.gradle, settings.gradle), плагины и зависимости в оперативную память. В отличие от Maven, Gradle использует Groovy/Kotlin для парсинга скриптов, что увеличивает потребление памяти из-за динамической природы этих языков, но оптимизируется за счет кэширования и инкрементальности.
Архитектура Gradle
Архитектура Gradle построена вокруг концепции задач (tasks) и графа выполнения, что отличает его от жизненного цикла Maven. Рассмотрим ключевые аспекты.
Task-based Model vs Lifecycle-based (в Maven)
Task-based Model (Gradle):
Gradle использует модель, основанную на задачах, где каждая задача (task) — это атомарная единица работы (например, компиляция, тестирование, упаковка).
Задачи определяются в build.gradle и могут быть связаны через зависимости (например, задача build зависит от compileJava).
Разработчик может создавать кастомные задачи с программной логикой, что обеспечивает гибкость.
Пример:
task hello {
doLast {
println 'Hello, Gradle!'
}
}
Lifecycle-based Model (Maven):
Maven использует фиксированный жизненный цикл (clean, default, site) с фазами (compile, test, package), к которым привязаны плагины.
Ограниченная гибкость: задачи определяются через плагины, а не напрямую.
В памяти:
В Gradle каждая задача представлена как объект в памяти, содержащий конфигурацию и зависимости. Это увеличивает потребление памяти по сравнению с Maven, где фазы жизненного цикла имеют более жесткую структуру. Однако Gradle оптимизирует выполнение, пропуская неизмененные задачи (см. инкрементальность).
Directed Acyclic Graph (DAG) исполнения задач
Gradle строит Directed Acyclic Graph (DAG) для задач, где:
Узлы — это задачи.
Ребра — зависимости между задачами (например, build зависит от test, а test — от compileJava).
Gradle анализирует DAG, чтобы определить порядок выполнения задач и избежать циклов.
Процесс:
Gradle парсит build.gradle и создает объекты задач в памяти.
Формируется DAG на основе зависимостей, указанных в dependsOn или неявно через плагины.
Gradle выполняет задачи в порядке, определенном топологической сортировкой DAG, пропуская те, которые не требуются.
Пример:
task compileJava {
doLast { println 'Compiling Java' }
}
task test(dependsOn: compileJava) {
doLast { println 'Running tests' }
}
task build(dependsOn: test) {
doLast { println 'Building artifact' }
}
#Java #middle #Gradle
👍3
Инкрементальность и кэширование
Gradle оптимизирует производительность за счет:
Инкрементальности: Gradle проверяет входные и выходные данные задач (например, исходные файлы, скомпилированные классы). Если они не изменились, задача пропускается.
Пример:
Задача compileJava проверяет хэши исходных файлов и пропускает компиляцию, если они не изменились.
Кэширование:
Локальный кэш: Gradle хранит результаты задач в ~/.gradle/caches, что позволяет повторно использовать артефакты между сборками.
Build Cache: Gradle может кэшировать результаты задач на удаленном сервере (например, в CI/CD), что ускоряет сборку на разных машинах.
Настройка в settings.gradle:
В памяти:
Инкрементальность требует хранения хэшей входных/выходных данных в памяти для сравнения, что добавляет overhead. Build Cache минимизирует повторные вычисления, но требует дополнительной памяти для управления метаданными кэша.
Сравнение Gradle vs Maven
Гибкость, декларативность, производительность
Гибкость:
Gradle: Позволяет писать программную логику в задачах, используя Groovy/Kotlin. Подходит для нестандартных сценариев (например, кастомные процессы сборки).
Maven: Ограничивает кастомизацию плагинами и XML, что менее гибко для сложных задач.
Декларативность:
Maven: Полностью декларативный подход через XML (POM.xml), что упрощает стандартизацию, но ограничивает выразительность.
Gradle: Сочетает декларативность (зависимости, плагины) с императивной логикой, что делает его более выразительным.
Производительность:
Gradle: Быстрее за счет инкрементальной сборки, кэширования и параллельного выполнения задач. Флаг --parallel ускоряет многомодульные проекты.
Maven: Медленнее из-за последовательного выполнения фаз и отсутствия встроенной инкрементальности. Флаг -T частично компенсирует это.
В памяти:
Gradle потребляет больше памяти из-за динамической природы Groovy/Kotlin и сложных DAG. Maven экономичнее, так как использует фиксированную структуру жизненного цикла, но менее эффективен по времени выполнения.
Groovy DSL vs XML (Maven)
Groovy DSL (Gradle):
Использует Groovy для описания сборки, что делает синтаксис компактным и выразительным.
Пример:
XML (Maven):
Использует XML (POM.xml), что делает конфигурацию строгой и стандартизированной.
Пример:
В памяти:
Парсинг Groovy DSL в Gradle требует загрузки Groovy-библиотек и динамической компиляции скриптов, что увеличивает потребление памяти по сравнению с XML-парсингом Maven, который использует более легковесные парсеры (например, StAX).
#Java #middle #Gradle
Gradle оптимизирует производительность за счет:
Инкрементальности: Gradle проверяет входные и выходные данные задач (например, исходные файлы, скомпилированные классы). Если они не изменились, задача пропускается.
Пример:
Задача compileJava проверяет хэши исходных файлов и пропускает компиляцию, если они не изменились.
Кэширование:
Локальный кэш: Gradle хранит результаты задач в ~/.gradle/caches, что позволяет повторно использовать артефакты между сборками.
Build Cache: Gradle может кэшировать результаты задач на удаленном сервере (например, в CI/CD), что ускоряет сборку на разных машинах.
Настройка в settings.gradle:
buildCache {
local {
enabled = true
}
remote(HttpBuildCache) {
url = 'https://cache.example.com/'
push = true
}
}
В памяти:
Инкрементальность требует хранения хэшей входных/выходных данных в памяти для сравнения, что добавляет overhead. Build Cache минимизирует повторные вычисления, но требует дополнительной памяти для управления метаданными кэша.
Сравнение Gradle vs Maven
Гибкость, декларативность, производительность
Гибкость:
Gradle: Позволяет писать программную логику в задачах, используя Groovy/Kotlin. Подходит для нестандартных сценариев (например, кастомные процессы сборки).
Maven: Ограничивает кастомизацию плагинами и XML, что менее гибко для сложных задач.
Декларативность:
Maven: Полностью декларативный подход через XML (POM.xml), что упрощает стандартизацию, но ограничивает выразительность.
Gradle: Сочетает декларативность (зависимости, плагины) с императивной логикой, что делает его более выразительным.
Производительность:
Gradle: Быстрее за счет инкрементальной сборки, кэширования и параллельного выполнения задач. Флаг --parallel ускоряет многомодульные проекты.
Maven: Медленнее из-за последовательного выполнения фаз и отсутствия встроенной инкрементальности. Флаг -T частично компенсирует это.
В памяти:
Gradle потребляет больше памяти из-за динамической природы Groovy/Kotlin и сложных DAG. Maven экономичнее, так как использует фиксированную структуру жизненного цикла, но менее эффективен по времени выполнения.
Groovy DSL vs XML (Maven)
Groovy DSL (Gradle):
Использует Groovy для описания сборки, что делает синтаксис компактным и выразительным.
Пример:
plugins {
id 'java'
}
dependencies {
implementation 'org.springframework:spring-core:5.3.20'
}
Преимущества: Легко читаемый код, поддержка программной логики, динамическая конфигурация.
Недостатки: Требует изучения Groovy, потенциальные ошибки из-за динамической типизации.
XML (Maven):
Использует XML (POM.xml), что делает конфигурацию строгой и стандартизированной.
Пример:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.3.20</version>
</dependency>
Преимущества: Простота для новичков, строгая структура, поддержка инструментами (IDE).
Недостатки: Многословность, ограниченная гибкость.
В памяти:
Парсинг Groovy DSL в Gradle требует загрузки Groovy-библиотек и динамической компиляции скриптов, что увеличивает потребление памяти по сравнению с XML-парсингом Maven, который использует более легковесные парсеры (например, StAX).
#Java #middle #Gradle
👍3
Поддержка Groovy DSL и Kotlin DSL
Gradle поддерживает два языка для написания скриптов сборки:
Groovy DSL:
Основной язык Gradle, используемый в build.gradle.
Динамическая типизация, лаконичный синтаксис.
Пример:
Kotlin DSL:
Введен для статической типизации и лучшей поддержки в IDE.
Используется в build.gradle.kts.
Пример:
Выбор:
Используйте Groovy для простоты и совместимости с существующими проектами.
Выберите Kotlin для новых проектов, особенно если команда знакома с Kotlin или требуется строгая типизация.
Build Scans — что это и зачем
Build Scans — это инструмент Gradle для анализа и отладки сборок.
Они представляют собой веб-отчеты, содержащие:
Детали выполнения задач (время, зависимости, пропущенные задачи).
Информацию о конфигурации (плагины, зависимости, свойства).
Логи ошибок и предупреждений.
Настройка:
Зачем:
Отладка: Выявление узких мест (например, медленных задач).
Оптимизация: Анализ пропущенных задач и кэширования.
Совместная работа: Делитесь Build Scans с командой для диагностики проблем.
CI/CD: Интеграция с Gradle Enterprise для хранения и анализа сборок.
В памяти: Build Scan собирает метаданные о сборке в памяти, включая DAG, время выполнения задач и конфигурацию. Это увеличивает потребление памяти, особенно для крупных проектов. Данные отправляются на сервер Gradle Enterprise, что требует сетевых операций.
#Java #middle #Gradle
Gradle поддерживает два языка для написания скриптов сборки:
Groovy DSL:
Основной язык Gradle, используемый в build.gradle.
Динамическая типизация, лаконичный синтаксис.
Пример:
plugins {
id 'java'
}
repositories {
mavenCentral()
}
Kotlin DSL:
Введен для статической типизации и лучшей поддержки в IDE.
Используется в build.gradle.kts.
Пример:
plugins {
java
}
repositories {
mavenCentral()
}
Преимущества: Статическая типизация, автодополнение в IDE, меньше ошибок на этапе выполнения.
Недостатки: Более строгий синтаксис, требует изучения Kotlin.
Выбор:
Используйте Groovy для простоты и совместимости с существующими проектами.
Выберите Kotlin для новых проектов, особенно если команда знакома с Kotlin или требуется строгая типизация.
Build Scans — что это и зачем
Build Scans — это инструмент Gradle для анализа и отладки сборок.
Они представляют собой веб-отчеты, содержащие:
Детали выполнения задач (время, зависимости, пропущенные задачи).
Информацию о конфигурации (плагины, зависимости, свойства).
Логи ошибок и предупреждений.
Настройка:
Добавьте плагин в build.gradle:
plugins {
id 'com.gradle.build-scan' version '3.17.4'
}
buildScan {
termsOfServiceUrl = 'https://gradle.com/terms-of-service'
termsOfServiceAgree = 'yes'
}
Запустите сборку:./gradlew build --scan
Получите ссылку на Build Scan в консоли.
Зачем:
Отладка: Выявление узких мест (например, медленных задач).
Оптимизация: Анализ пропущенных задач и кэширования.
Совместная работа: Делитесь Build Scans с командой для диагностики проблем.
CI/CD: Интеграция с Gradle Enterprise для хранения и анализа сборок.
В памяти: Build Scan собирает метаданные о сборке в памяти, включая DAG, время выполнения задач и конфигурацию. Это увеличивает потребление памяти, особенно для крупных проектов. Данные отправляются на сервер Gradle Enterprise, что требует сетевых операций.
#Java #middle #Gradle
👍3
Конфигурационные файлы: build.gradle, settings.gradle, gradle.properties
Gradle использует три основных файла конфигурации:
build.gradle:
Основной файл сборки, определяющий задачи, плагины и зависимости.
Пример:
settings.gradle:
Определяет структуру многомодульного проекта и настройки (например, корневое имя проекта, включенные модули).
Пример:
gradle.properties:
Хранит свойства для настройки Gradle и JVM.
Пример:
Нюансы:
Храните build.gradle и settings.gradle в корне проекта, а gradle.properties — в корне или ~/.gradle.
Используйте gradle.properties для чувствительных данных (например, ключи API) с осторожностью, предпочтительно шифруйте их.
В многомодульных проектах каждый модуль имеет свой build.gradle, но общий settings.gradle.
Нюансы и внутренние механизмы
Управление памятью:
Gradle загружает модель проекта, задачи и зависимости в JVM. Groovy/Kotlin DSL увеличивают overhead из-за динамической компиляции.
Инкрементальность и кэширование снижают повторные вычисления, но требуют памяти для хранения хэшей и метаданных.
Настройте org.gradle.jvmargs в gradle.properties для увеличения кучи: -Xmx2048m.
Кэширование:
Локальный кэш (~/.gradle/caches) хранит зависимости, плагины и результаты задач.
Build Cache (локальный или удаленный) минимизирует повторные сборки, но требует настройки и дискового пространства.
Очистка кэша: ./gradlew --stop и rm -rf ~/.gradle/caches.
Производительность:
Инкрементальная сборка и --parallel ускоряют выполнение, но увеличивают пиковое потребление памяти.
Используйте --no-daemon для одноразовых сборок, чтобы избежать постоянного процесса Gradle Daemon.
Отладка:
Флаг --info или --debug выводит подробные логи:./gradlew build --debug
Build Scans предоставляют визуальный анализ.
Используйте ./gradlew tasks для списка доступных задач.
Многомодульные проекты:
Gradle эффективно управляет модулями через settings.gradle, строя DAG для определения порядка сборки.
Используйте ./gradlew :module-name:task для выполнения задачи в конкретном модуле.
Совместимость:
Gradle требует JDK 8+ (рекомендуется 11+). Убедитесь, что JAVA_HOME указывает на правильный JDK.
Некоторые плагины Maven (например, maven-release-plugin) требуют адаптации для Gradle (например, nebula-release-plugin).
#Java #middle #Gradle
Gradle использует три основных файла конфигурации:
build.gradle:
Основной файл сборки, определяющий задачи, плагины и зависимости.
Пример:
plugins {
id 'java'
id 'org.springframework.boot' version '2.7.18'
}
repositories {
mavenCentral()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter'
testImplementation 'junit:junit:4.13.2'
}
В памяти: Парсится в объектную модель Gradle, включая задачи и зависимости. Динамическая компиляция Groovy/Kotlin увеличивает overhead.
settings.gradle:
Определяет структуру многомодульного проекта и настройки (например, корневое имя проекта, включенные модули).
Пример:
rootProject.name = 'my-project'
include 'module-api', 'module-core', 'module-web'
В памяти: Формирует модель проекта, включая граф модулей. Меньше по объему, чем build.gradle, но влияет на DAG.
gradle.properties:
Хранит свойства для настройки Gradle и JVM.
Пример:
org.gradle.jvmargs=-Xmx2048m
org.gradle.parallel=true
myVersion=1.0.0
В памяти: Свойства загружаются как часть конфигурации Gradle, минимально влияя на память.
Нюансы:
Храните build.gradle и settings.gradle в корне проекта, а gradle.properties — в корне или ~/.gradle.
Используйте gradle.properties для чувствительных данных (например, ключи API) с осторожностью, предпочтительно шифруйте их.
В многомодульных проектах каждый модуль имеет свой build.gradle, но общий settings.gradle.
Нюансы и внутренние механизмы
Управление памятью:
Gradle загружает модель проекта, задачи и зависимости в JVM. Groovy/Kotlin DSL увеличивают overhead из-за динамической компиляции.
Инкрементальность и кэширование снижают повторные вычисления, но требуют памяти для хранения хэшей и метаданных.
Настройте org.gradle.jvmargs в gradle.properties для увеличения кучи: -Xmx2048m.
Кэширование:
Локальный кэш (~/.gradle/caches) хранит зависимости, плагины и результаты задач.
Build Cache (локальный или удаленный) минимизирует повторные сборки, но требует настройки и дискового пространства.
Очистка кэша: ./gradlew --stop и rm -rf ~/.gradle/caches.
Производительность:
Инкрементальная сборка и --parallel ускоряют выполнение, но увеличивают пиковое потребление памяти.
Используйте --no-daemon для одноразовых сборок, чтобы избежать постоянного процесса Gradle Daemon.
Отладка:
Флаг --info или --debug выводит подробные логи:./gradlew build --debug
Build Scans предоставляют визуальный анализ.
Используйте ./gradlew tasks для списка доступных задач.
Многомодульные проекты:
Gradle эффективно управляет модулями через settings.gradle, строя DAG для определения порядка сборки.
Используйте ./gradlew :module-name:task для выполнения задачи в конкретном модуле.
Совместимость:
Gradle требует JDK 8+ (рекомендуется 11+). Убедитесь, что JAVA_HOME указывает на правильный JDK.
Некоторые плагины Maven (например, maven-release-plugin) требуют адаптации для Gradle (например, nebula-release-plugin).
#Java #middle #Gradle
👍3
Что выведет код?
#Tasks
public class Task210725 {
static int x = 5;
static {
x = 10;
}
public static void main(String[] args) {
System.out.println(x);
int x = 20;
System.out.println(x);
System.out.println(Task210725.x);
}
}
#Tasks
👍2
👍2
Что такое System.identityHashCode()? 🤓
Ответ:
Метод System.identityHashCode(Object) возвращает хэш-код объекта, основанный на его адресе в памяти, даже если метод hashCode() переопределен.
Пример:
String s1 = new String("test");
String s2 = new String("test");
System.out.println(s1.hashCode() == s2.hashCode()); // true
System.out.println(System.identityHashCode(s1) == System.identityHashCode(s2)); // false
Полезен для отладки или проверки уникальности объектов.
#собеседование
Ответ:
Пример:
String s1 = new String("test");
String s2 = new String("test");
System.out.println(s1.hashCode() == s2.hashCode()); // true
System.out.println(System.identityHashCode(s1) == System.identityHashCode(s2)); // false
Полезен для отладки или проверки уникальности объектов.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
А вы знали, что термин "дропдаун" в интерфейсах появился в 1984 году?
Слово "dropdown" (выпадающее меню) начали использовать с выпуском Macintosh, где такие меню стали стандартом для выбора опций. Это упростило взаимодействие с программами.
#facts
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2