Ars

Уважаемый mayton2019 дал в общем-то почти исчерпывающий ответ. Но раз вы задали этот вопрос "из возникшего интереса", то есть шанс, что и другим ответы данной темы будут интересы, потому попробую еще чуть-чуть дополнить упомянутый ответ.

Возможно многие и не слышали, но тем не менее существуют т.н. In-memory database (по-русски это, кажется, называется "Резидентная база данных", но я не уверен). Применяются такие системы как правило в высоконагруженных приложениях - в системах провайдеров телекоммуникационных услуг, когда-то читал - что в системах он-лайн биржевой торговли и пр. Там где данных очень много и доступ к ним нужен очень быстро. И главное - владелец таких данных оччччеееень богатенький, что-бы позволить себе приобрести оборудование с объемом оперативной памяти сопоставимым с объемом внешней памяти для "обычных" серверов баз данных. И вот тогда, для таких задач все данные СУБД, включая все индексы и другой служебно-вспомогательной информации, загоняются в оперативную память, обеспечивая и нужную скорость доступа и удобство доступа, которое обычно присуще СУБД.
Главнейшая проблема, которую решают разработчики таких систем - как обеспечить целостности базы данных при внезапной перезагрузке систем. Это влияет на производительность In-memory database, заставляя тратить часть вычислительных ресурсов на синхронизацию данных в ОП и резервных копий на внешней памяти.
Список таких систем можно, кстати, найти даже в Википедии:
https://en.wikipedia.org/wiki/List_of_in-memory_da...

Если же "спуститься" с небес на землю и учесть финансовые возможности "нормального" пользователя, то например, в языке программирования Python есть такой модуль - Pandas. По сути он дает удобство доступа к данным, почти такое-же (а может и еще большее) как SQL, сохраняя таблицы в ОП. А скорость обработки - сопоставимую с реализацией на "голых" массивах, а для сложных поисковых запросов - и еще большую. Естественно, что объем таблиц (DataFrame в терминологии Pandas) не может быть слишком большим. И не смотря на то, что есть прямой шлюз для перехода от DataFrame к SQL-структурам СУБД и обратно, скорость работы "в памяти" на много выше, чем скорость работы с теми-же данными, выгруженными в БД. Поэтом программист может комбинировать работу DataFrame для скорости обработки и СУБД для долговременно энергонезависимого хранения, найдя приемлемый для своего приложения компромисс.

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.

С точки зрения Java language, аннотации ничего не делают. Они - как каменты в коде. Но они могут быть подсказками для фреймворков которые в compile time, classloader или runtime могут что-то выполнить над кодом. 99%
это какие-то ORM/JSon подказки которые разъясняют фреймворку что делать. Например @Table(name="emp")
подсказка JPA то класс относится к таблице emp.

Ваш вопрос про либы Java/Kotlin слишком общий. Ничего конкретного нельзя сказать. Но по отношению к
Serializable, можно предположить что это гарантия что класс можно сериализовать во внешнюю память
(оперативная или диск) и это не нарушит никакой бизнес логики. Например это DTO которая полностью
самодостаточная. Не все сущности вообще реально сохранить. Некоторые сущности - как орграф опутывают
всю память Java и сохранять их накладно. Как корневой объект хипа. Дешевле дампнуть всю память чем
сохранять такие объекты поштучно. Некоторые - имеют связи с внешними ресурсами Files/Sockets и вне контекста они не имеют смысла. Есть ключевые слова языка (transient) которые запрещают сериализацию для полей.
Есть также проблема версионности для Serializable. Сохраненная структура не трекает ваши изменения
по коду уже после того как вы что-то сохранили. Грубо говоря это не JSON. Если вставили новое поле - можете
старый файл и не прочитать. В качестве маркера проблемы там заводят специальное поле типа versionId или
что-то такое. Просто для детектирования.

Если вы хотите иметь тотальный контроль над сохранением - то определяйте Externalizable и там будут 2
метода в которых вы контролируете Output/Input streams и сами пишете что сохранять и читать. А еще
лучше брать библиотеки Kryo/Protobuf/Avro e.t.c. У них еще и есть оптимизации по скорости и по сжатию.
Вы к этому придете эволюционным путем если будете писать систему где сохранение во вне - важно.

Сериализация во внешнюю память это огромная проблема когда мы пытаемся подружить разные
технологии (32-64 бит целые числа или разный порядок байт в машинном слове). Даже простое
сохранение даты или строки может быть ошибочным если вы сохранили в Java а пытаетесь читать в C++.
Нужна 100% бинарная совместимость всех структур. Вот библиотеки Протобуф и Авро
как раз для этого создавались.

Давайте по порядку.

Что такое аннотация? Аннотация - это некоторые произвольные метаданные, которые программист может присоединить к некоторому объекту. И только. Данные, ничего кроме. Никакого поведения сама по себе аннотация не добавляет.

То есть аннотация ничего не делает? Да, именно так. Сама по себе аннотация ничего не делает.

Тогда зачем она вообще нужна? Для того чтобы аннотация оказала какое-то влияние на программу нужен процессор аннотаций. Процессор аннотаций бывает двух видов: первый работает во время компиляции программы. И аннотации оказывают влияние именно на процесс компиляции. Это может повлиять на итоговой код программы, либо изменить логику работы компилятора, например, добавить какие-то дополнительные проверки.

Второй вид процессоров аннотаций работает во время выполнения программы. Через механизм рефлексии он анализирует аннотации, которые добавил программист, и выполняет логику в соответствии с аннотации и содержащимися в них даннми. Так, например, работает Spring, который в соответствии с аннотациями @Service, @Scope, @Autowired, @Controller и т.п. инициализирует компоненты приложения и запускает его в нужной конфигурации.

У Эккеля написано неточно (либо это неточный перевод, такое тоже часто бывает). Переменные никакого значения не получают, получает значение поле в аннотации (аннотация в Java - это тоже объект и тоже имеет поля). А затем уже процессор аннотаций значение этого поля как-то использует (в приведенном примере - устанавливает соответствие с колонкой в таблице базы данных соответствующего типа и, при необходимости, создает её).

У Шилдта написано корректнее - сами по себе аннотации никак семантику программы не затрагивают, для того чтобы они заработали требуется дополнительный код.

1. Перевести проект на gradle. Для этого сначала ставим этот самый градл, потом создаем папку, переходим туда в консоли и пишем
gradle init
Будет что-то такое.

Starting a Gradle Daemon (subsequent builds will be faster)

Select type of project to generate:
  1: basic
  2: application
  3: library
  4: Gradle plugin
Enter selection (default: basic) [1..4] 2

Select implementation language:
  1: C++
  2: Groovy
  3: Java
  4: Kotlin
  5: Swift
Enter selection (default: Java) [1..5] 4

Select build script DSL:
  1: Groovy
  2: Kotlin
Enter selection (default: Kotlin) [1..2] 2

Project name (default: rm_me): moy_proekt

Это сгенерирует дефолтный проект gradle для kotlin

2. Далее мы можем подключать любые зависимости, какие захотим. Для этого в сгенерированном проекте открываем файл build.gradle.kts и в секцию dependencies добавляем

dependencies {
  implementation("io.ktor:ktor-server-netty:1.3.2")
}

тут более подробно, но используется gradle синтаксис, а не kts
https://ktor.io/quickstart/quickstart/gradle.html

и почти всё тоже самое, но чуть чуть подробнее тут https://github.com/jershell/kotlin_slow_start
В общем сама цель перевести сначала проект на gradle, поскольку у котлина зависимости почти все через него и подключаются.

нельзя поменять.
надо создавать новый акк

У code review должна быть цель. В моей практике обычно проекты небольшие и там нет отдельных тестировщиков. Получается, что code review отвечает на три вопроса:

1. Соответствует ли функционал ТЗ?
   
2. Создает ли код проблемы команде?
   
3. Есть ли тут какой-то специфичный для проекта опыт, который лучше задокументировать, пока мы еще в контексте?
   

Получается что-то такое:

• До выполнения задачи: проводится анализ задачи, формулируется ТЗ. Бывает, что нужно подключиться и помочь с требованиями, с контекстом, в котором все делается. Чем более подробный анализ мы делаем и чем лучше мы понимаем контекст на этом этапе, тем больше вероятность, что потом весь процесс выполнения задачи пойдет как по маслу и code review будет чистой формальностью в конце.
  
• До ревью: линтеры проверяют код на соответствие стилю, на отсутствие синтаксического бреда.
  
• Дальше - проверка на соответствие функционала ТЗ. Это защита от глупых ошибок в продакшене, которые коснутся пользователей.
  
• Потом - на сответствие принятым соглашениям по коду, если они есть в проекте. Обычно это архитектурные паттерны и что-то про зависимости, смотрим не создает ли код проблем окружающим, а то разные глупости порой случаются. Особенно это важно в коде, который не сам в себе, а затрагивает много чего вокруг. Иногда возникает конфликт интересов, когда что-то явно устарело, и соглашения дополняются чем-то. Чем лучше был анализ в начале, тем меньше вероятность, что тут будет, что обсуждать.
  
• Дальше уточняющие вопросы по странным местам, если они есть. Это больше с целью узнать контекст задачи, почему приняты те или иные решения. Происходит передача специфичных для проекта знаний в сторону команды. Возможно там же будут какие-то рекомендации по поводу практик, на что стоит обратить внимание в следующий раз. Это будет передача опыта от команды.
  

А кто там будет, джун или синьер-помидор - не важно. Все люди ошибаются, и всем нужен контекст происходящего для эффективной работы.

1. Найти работу до достижения 18-и лет почти нереально.
   
2. Найти первую работу разработчиком очень тяжело.
   
3. Найти работу в геймдеве, не имея опыта разработчика, почти нереально.
   
4. Найти работу с GameMaker почти нереально.
   

В вашем случае наложение всех этих факторов многократно умножает сложность задачи.

Гарантированных методов нет, самое простое решение - периодически дергать Service (можно сказать пинговать), при отсутствии запросов определенное время (скажем, пропущено десять запросов) - Service закрывать, считая, что приложение закрыли.

Немного неожиданно, но BluetoothDevice implements Parcelable. Так что просто putParcelable.