mayton2019

Он скорее всего работает. Просто консоль так быстро появляетя и исчезает что ты не успеваешь разглядеть.
Там сразу после печати Hello идет return.

Добавь туда cin >> для того чтоб было какое-то ожидание от пользователя.

Надо сменить тип данных с TEXT на NUMBER. Тогда суммирование будет точнее. По крайней мере я проверил вот так.

sqlite> create table test(n number(2,3))
   ...> ;
sqlite> insert into test values(16.30);
sqlite>
sqlite> select typeof(n) from test;
real
sqlite>
sqlite> insert into test values(19.11);
sqlite>
sqlite> select total(n) from test;
35.41
sqlite> select sum(n) from test;
35.41

С точки зрения 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% бинарная совместимость всех структур. Вот библиотеки Протобуф и Авро
как раз для этого создавались.

Вот из википедии. Как из положительного сделать отрицательное в формате ДК (дополнительный код).

int twos_compl_abs(int a) {
    if (a < 0) a = (~a) + 1;
    return a;
}

Инвертируем и добавляем единичку.

Для числа -100. Берем сначала по модулю. 100 - это 64 + 32 + 4

0110 0100

Инвертируем

1001 1011

И прибавляем 1

1001 1100

В хекс-системе тоже число будет

9C

Делаешь такой шаблон

SELECT * FROM `wp_s3cu_authorization_logs` WHERE 1=0

а потом к нему добавляешь строки. Если был активирован флажок windows - то добавляешь строку
OR os_id = 'windows10'

Эта строка просто не работает.

$where .= " AND {$table_prefix}`{$this->search_by}` LIKE '%{$this->search}%'";

Несмотря на то что java/c++ формально являются ООП языками, многие вещи
с перегрузкой у них реализованы по разному. В случае с методом sound в Java
скорее всего будет создано просто 2 метода (разные сигнатуры).