ООП подход для игр плохо работает, смотрите в сторону компонентного подхода (ECS) и работ со структурами данных. Unity с каждой новой версией уходит от ООП.
Я только в kubernates встретил обозначение MiB, Gi и не мог понять чем она отличается от MB, GB. Погугли и удивился что mb, gb это 10 числа, а MiB и Gi двоичные, потом открыл свойства папки в windows и увидел привычное обозначение mb. И понял что их MiB это теже самые мегабайты, что я знаю, и не нужно их переводить в другую систему счисления.
У них есть jep с новым ключевым словом lazy, но это на будущее. Они выпустили обзор на канале java по разбору этой фичи, там более подробно объясняют и показывают примеры использования https://youtu.be/uMypEIx8qY8?si=KQn3d-Ad8_Dwt5_r
Про java 17 так же можно упомянуть, что JVM стал возвращать память обратно в операционную систему. Для cloud, где развёрнуто большое количество сервисов, это хорошее снижение затрат на простаивающие сервисы.
Лучше использовать 17 версию, так как в ней сделали так, чтобы java отдавала обратно в ОС неиспользуемую память. Траты на простаивающие приложения уменьшатся.
Язык Java это не только его синтаксис, а ещё виртуальная машина, делающая очень много вещей. То что JVM пишется на C++ это нормально, ведь на прямую работать с железом и поддерживать различные ОС требуется низкоуровневый язык. Синтаксис от этого никак не ограничивается, возьми тот же Kotlin или Scala. Крупные компании вообще могут иметь свой собственный JVM.
На языке Java написано очень много либ, фреймворков, систем. Когда вносятся какие-то улучшения в язык, то они должны не только удовлетворять потребности, но и чтобы при миграции на новую версию языка не возникало проблем, тут скорее идёт речь больше про патчи безопасности, то есть был сервис написанный на Java 7, а поддержка языка закончилась и патчи больше не выпускаются, поэтому компании нужно перейти на новую версию языка и чтобы в процессе когда они просто повысили версию языка ничего не сломалось, разрабы openjdk заботятся об этом и предоставляют максимально как могут обратную совместимость, чтобы при повышении версии не пришлось нигде переписывать код.
Зачем использовать аннотацию @ExtendWith(SpringExtension.class) если она и так есть в @SpringBootTest, так же видимо опечатка с аннотацией @TestcontainersTestcontainers . Помимо @DirtiesContext, чтобы контекст нигде дальше не перезапустился лучше сразу в базовом определить все @MockBean и @SpyBean. И покажи в конце что у вас в итоге получилось.
Вот именно, но из-за этой переработки теряются некоторые детали, например, на тех экранах видеонаблюдения некоторые просто нерабочие в оригинале же они показывают помещение и переключаются.
ООП подход для игр плохо работает, смотрите в сторону компонентного подхода (ECS) и работ со структурами данных. Unity с каждой новой версией уходит от ООП.
А как работает присвоение null таким value классам? Помню хотели от null отказаться, но проблема, что не понятно как инициализировать
Я только в kubernates встретил обозначение MiB, Gi и не мог понять чем она отличается от MB, GB. Погугли и удивился что mb, gb это 10 числа, а MiB и Gi двоичные, потом открыл свойства папки в windows и увидел привычное обозначение mb. И понял что их MiB это теже самые мегабайты, что я знаю, и не нужно их переводить в другую систему счисления.
У них есть jep с новым ключевым словом lazy, но это на будущее. Они выпустили обзор на канале java по разбору этой фичи, там более подробно объясняют и показывают примеры использования https://youtu.be/uMypEIx8qY8?si=KQn3d-Ad8_Dwt5_r
Теперь понятно над чем разработчики JVM Excelsior работали, когда перешли в Huawei
Про java 17 так же можно упомянуть, что JVM стал возвращать память обратно в операционную систему. Для cloud, где развёрнуто большое количество сервисов, это хорошее снижение затрат на простаивающие сервисы.
Лучше использовать 17 версию, так как в ней сделали так, чтобы java отдавала обратно в ОС неиспользуемую память. Траты на простаивающие приложения уменьшатся.
Язык Java это не только его синтаксис, а ещё виртуальная машина, делающая очень много вещей. То что JVM пишется на C++ это нормально, ведь на прямую работать с железом и поддерживать различные ОС требуется низкоуровневый язык. Синтаксис от этого никак не ограничивается, возьми тот же Kotlin или Scala. Крупные компании вообще могут иметь свой собственный JVM.
На языке Java написано очень много либ, фреймворков, систем. Когда вносятся какие-то улучшения в язык, то они должны не только удовлетворять потребности, но и чтобы при миграции на новую версию языка не возникало проблем, тут скорее идёт речь больше про патчи безопасности, то есть был сервис написанный на Java 7, а поддержка языка закончилась и патчи больше не выпускаются, поэтому компании нужно перейти на новую версию языка и чтобы в процессе когда они просто повысили версию языка ничего не сломалось, разрабы openjdk заботятся об этом и предоставляют максимально как могут обратную совместимость, чтобы при повышении версии не пришлось нигде переписывать код.
А что на Shenandoah GC уже забили?
Зачем использовать аннотацию @ExtendWith(SpringExtension.class) если она и так есть в @SpringBootTest, так же видимо опечатка с аннотацией
@TestcontainersTestcontainers. Помимо @DirtiesContext, чтобы контекст нигде дальше не перезапустился лучше сразу в базовом определить все @MockBean и @SpyBean. И покажи в конце что у вас в итоге получилось.А что не работает? Я использовал redisson-hibernate-6 всё работало, о его настройках можно в их репозитории на гитхабе прочитать.
В этом примере, если на методе стоит
synchronized, то и volatile, и immutable нам ведь уже не нужны.Вот именно, но из-за этой переработки теряются некоторые детали, например, на тех экранах видеонаблюдения некоторые просто нерабочие в оригинале же они показывают помещение и переключаются.