Было бы интересно посмотреть для сравнения, сколько было бы потребление памяти при использовании полноценной Java.
Мне кажется, RPi должен спокойно тянуть по объему памяти Java SE с БД и прочими удовольствиями.
А какой смысл в экономии памяти, коей на актуальной распберри гигабайт? Гоняем на ней клиентскую часть под оракловой java 8, данные лежат в MySQL (~150k записей в самой жирной таблице), поверх него натянут EclipseLink (лол, но это работает). В пике потребления (распаковка архива при импорте) получается ~400 Мб, в работе — 150-200Мб, остальное отдано под кэш превьюшек. Не скажу, что всё это очень шустро бегает, но тормоза отрисовки UI неизмеримо больше, чем работы с данными.
Для данного проекта web ui должен занимать как можно меньше ресурсов, потому что это не основная фича приложения.
Так что с Ioc и базой? Никак?
А то я сегодня удивился, что Spring Boot Web на хелловорлде только 73 МБ оперативы занял.
А что такое loc?
IoC фреймворк
Да, проще стримить данные куда то вовне и уже там делать join и aggregation если нужно.

А маленького IoC который бы мог хотя бы делать PostConstruct/PreDestroy я не нашел.
Всегда хотел, чтобы для Java и JVM-языков были средства для создания легковесных приложений. Дело даже не в ограничениях железа, а в том, что с такими программами проще. Легковесное приложение можно поставить на любую машину (не важно, сколько сервисов на ней уже крутится), можно порекомендовать любому человеку. Если это основное приложение на компьютере, то да, плевать, сколько оно там памяти потребляет. А от сервиса, который используется раз в день, хочется экономного расходования ресурсов.

Пример — Subsonic (self-hosted аналог сервисов типа Google Music и ему подобных). Обычно я пользуюсь облачным службами для стриминга музыки, но редкие вещи продолжаю хранить у себя и ради этого настроил Subsonic. Проблема в том, что он съедает 200-300 мегабайт памяти и время от времени грузит процессор. А ещё требует проприетарную JRE (я не доверяю Oracle). Всё это ради того, чтобы раз в день послушать песенку? В итоге я удалил его и поставил более легковесный аналог.

В этом плане очень хорош Go. Достаточно высокоуровневый язык, статические бинарики на выходе, довольно экономный с точки зрения памяти. И если вдруг понадобится разработать какой-нибудь сервис, я выберу именно его. Но писать приятнее всё-таки на Java/Kotlin.

Пробовал Avian в качестве альтернативной JRE, но проекту ещё расти и расти для более-менее серьёзного применения. Java Embedded — сложности с библиотеками, не буду повторять автора. Было бы очень хорошо, если бы сформировалось коммьюнити Java Embedded, которое бы готовило урезанные версии библиотек (либо писало их аналоги, если урезать не получается). Но слишком мала вероятность, что такое произойдет.
Всё это ради того, чтобы раз в день послушать песенку? В итоге я удалил его и поставил более легковесный аналог
а какой именно?
Всегда хотел, чтобы для Java и JVM-языков были средства для создания легковесных приложений.


Так уже все есть. Просто мало кому это надо на самом деле.
— Например, в яве есть свой HttpServer. Не нужно добавлять никаких внешних tomcat, jetty, netty и прочих.
— IoC — а так ли это надо? Я прекрасно уже 3 года обхожусь без и доволен. Непонятная хотелка привнесенная из энтерпрайз мира.
— nginx — совершенно не нужен. Если у Вас tomcat, netty, jetty — у них уже из коробки есть нативные биндинги на опенССЛ, точно такие же как и у енджинкса. А у нетти, например, даже к более быстрому форку опенССЛ — boringSSL. Опять же, старый костыль перекочевавший из прошлого, когда еще не было биндингов на яве.
— шаблонизаторы? Уже вроде как 2017-й…
  1. HttpServer лежит в com.sun, которого вроде нет в compact1.
  2. IoC иногда полезно чтобы код был более читаемый. Но пока действительно без него приходится
  3. nginx — нужен для SSL termination и отдаче статики. В простых http серверах нет поддержки openssl. Потом опять же есть неплохая интеграция nginx и letsencrypt. Я не смотрел на netty. Может быть он и может работать в compact1. Статику прогружать через heap тоже не хотелось бы, так как это будет влиять на gc и основные бэкэнд фичи
  4. Выбор шаблонизаторов скорее был не из-за технологий, а из-за требований к стабильности. Например, основные javascript технологии очень быстро меняются и не обратно совместимы. И каждый год появляется какая то новая модная технология. Задача же проекта не в создании модного web ui, а в backend декодировании сигналов.


Конечно, если какой-нибудь angular/reactjs разработчик присоединиться и будет пилить web ui, то никто не будет против :)
Потом опять же есть неплохая интеграция nginx и letsencrypt.


В нетти тоже. За другие серверы не скажу. Мне даже не надо стопать нетти, чтобы обновить сертификаты. В отличии от енджинкса.

Статику прогружать через heap тоже не хотелось бы


Опять же, в нетти не через хип. Уверен, что в других серверах так же. Хотя, да — для статики енджинкс наверное самое лучшее решение. Я отдаю файлы через нетти. Пока проблем не было. Лоад приличный.
Мне даже не надо стопать нетти, чтобы обновить сертификаты. В отличии от енджинкса.

справедливости ради, для обновления сертификатов в nginx достаточно сделать
service nginx reload
и это будет абсолютно незаметно для клиентов.
и это будет абсолютно незаметно для клиентов.


Для большинства приложений — да. Но если пользователи висят на keep-alive соединениях — то это будет заметно.
Естественно keep-alive, ведь речь о сертификатах, и соответственно HTTPS. Только что страшного произойдет, если клиент будет вынужден переустановить соединение?
Спасибо! Гляну нетти. 6мб может удастся съэкономить. Все таки подразумевается, что пользователь будет раз в год заходить на этот вэб ui, поэтому можно разочек и отдать файлы через jvm
Еще учтите, что если вы отдаете статику, то она прекрасно будет кешироватся в браузере (поэтому темплейты — фу-фу-фу :)). + если это система где один и тот же пользователь пользуется ею, то проблемы как бы и нету.

Не уверен по поводу compact1 и нетти. Но вы уж гляньте и отпишитесь.
В этом плане очень хорош Go. Достаточно высокоуровневый язык, статические бинарики на выходе, довольно экономный с точки зрения памяти. И если вдруг понадобится разработать какой-нибудь сервис, я выберу именно его. Но писать приятнее всё-таки на Java/Kotlin.

А за писать приятнее, к сожалению, нужно платить.


А ещё требует проприетарную JRE (я не доверяю Oracle).
Оно почти на 100% с открытым исходным кодом.
А ещё требует проприетарную JRE (я не доверяю Oracle)

Насколько я понимаю, очень зря, поскольку Oracle внедряет дополнительные оптимизации в свою версию JRE. Не самые свежие, но пруфы по Raspberry:

Вот странная штука. Шипелёв же говорил, что Оракл берёт OpenJDK и просто его билдит и всё.

Занудства ради: А можно цитату, где он говорит про «просто билдит»?

Я где-то слышал, где не помню. Но на занудство можно ответить только ещё большим занудством. Я отсмотрел нонстоп около пяти часов Шипилёва и нашёл. Вот он этот вопрос. Если вдруг ссылка с временем не работает — начинать смотреть ровно на 47 (сорок седьмой) минуте.

Благодарю!
А ещё требует проприетарную JRE (я не доверяю Oracle).

Используйте сборки openjdk. Для RPi есть хорошая сборка azul zulu с поддержкой armhf.
gson. Зависимость на java.sql (!!!)

Неудивительно, сериализуют java.sql типы. В теории можно раскидать по разным артифактам (+ конечно же иметь сводный, как обычно, для 99.999% юзеров).

angular, reactjs — на ровном месте привносят десяток короткоживущих технологий.

Текущий vue.js minified — 79.7кб
https://github.com/vuejs/vue/blob/dev/dist/vue.min.js
Можно затащить библиотеку по старинке, без всяких npm и вебпаков.

Спасибо автору, было интересно.

Можно и в сторону preact глянуть, если есть ограничение по размерам библиотек.

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