Комментарии 28
В Java ведь так и нету unsigned типов? Сильно ли это мешало?
Исключительно при написании драйверов под чипы. Например в BMP280 в datasheet вся "математика" на побитовых сдвигах. Сначала свернул не туда, потом поменял на умножение/деление.
При написании bridge java-posix даже этого не заметил.
Вопрос - как производительность и системные требования Java на одноплатниках выглядят в сравнении с, допустим Python.
По моему это от задачи скорее зависит и сколько вы Xms and Xmx для JVM выделите под эти задачи.
Но на Raspberry Pi Zero W и Orange Pi Zero особых проблем не испытывал с примерами с гитхаба.
Обратите внимание, современный одноплатник на борту имеет CPU/Memory больше чем сервера 10-15 лет назад, где java прекрасно работала(и продолжает работать) в enterprise на том же WebLogic с 4-8GB на ноду, по этому я бы с ходу этим вопросом не заморачивался с самого начала.
Если говорить про GraalVM native-image, то ядро занимает около 10МБ на диске. В памяти на 64mb я свои тестовые примеры в native запускал без проблем.
Обратите внимание, современный одноплатник на борту имеет CPU/Memory больше чем сервера 10-15 лет назад, где java прекрасно работала(и продолжает работать) в enterprise на том же WebLogic с 4-8GB на ноду,
8 gb на ноду это прямо даже много было 15 лет назад.
В памяти на 64mb я свои тестовые примеры в native запускал без проблем.
Я без грааля смотрел на одноплатнике дешевом лет 5 назад на JAVA 8, у меня получилось примерно так(смотрел по хmx, выделенная память, реально потребеление будет чуть выше):
вроде бы 2 mb RAM было минимум(это с небольшими приседаниями)
8мб уже можно было использовать для коносльных приложений, простого-веб-сервиса или веб-морды. Но надо смотреть на используемые бибилотеки.
64 мб вполне успешно крутился томкат с веб-сервисом и мордой на JSP, каких-. По сути уже можно использвоать для всего подряд. Спринг правда тяжеловат, его бы не рекомендовал брать в таком конфиге.
По логике с новой джавой и новыми GC(zgc, shenandoah) потребление памяти должно было бы упасть. С граалем соотвственно еще меньше.
Спасибо за комментарий. Полностью согласен и подтверждает мои размышления.
А с учётом будущего выхода из incubator Project Panama все станет ещё интереснее.
К тому же Graal все же разрабатывается как платформа для многих языков. Что сделает более тесную интеграцию кода.
То есть имхо будущее у данного направления есть.
Мне кажется к вопросам производителности скорее стоит вальгаллы ждать-после нее в теории уйту обертки над примитивами, что в теории должно положительно сказаться на памяти и производительности в целом.
А вот от панамы честно говоря много не жду в этом плане-мне кажется она больше даст буста в больших проектах, например веб-серваера с тысячами соединений, а для мелких проектов многопточность в большинсвте случаев не очень важна(хотя конечно зависит от проекта).
Так Панама - это так же замена JNI и отсутствие необходимости писать враперы на сях для доступа в натив.
Надеюсь только ее Оракл с Graal-Native подружит(запросы на гитхабе уже есть) чтобы не пришлось два различных пути делать.
Говоря про производительность - это возвращаясь к разговору о серверах. Уже лучше одноплатники чем 10 лет назад большое железо. Улучшения же в jave давно ждем.
Есть еще библиотека DeviceIO (https://wiki.openjdk.java.net/display/dio) от того же оракла, поддерживает все linux платы (теоретически, т.к. не использует ничего вендорспецифичного). GPIO работает поверх sysfs
Приветствую, спасибо, когда то на нее смотрел, но забыл.
Как я писал в статье, это еще один пример от которого хотелось уйти - масса сишного кода (то есть вся работа в си, java - враппер). Sysfs - depricated с 4.8 и требует дополнительных действий для того чтобы его включить-выключить.
Но еще раз спасибо за ссылку, посмотрю в исходники на тему может я что-то "продолбал"
В DIO нативный код был не от хорошей жизни, библиотека писалась для JavaME c ее ограничениями (каждый класс давал +500байт в бинарник). Поэтому и сложная система взаимодействия нативного и жава кода (все жавовые нитки там зеленые).
Кстати, сама библиотека довольно широко разошлась, Eclipse Kura ее использует. Было бы неплохо ее переписать чисто на жавке с сохранением АПИ
Update: судя по исходникам, SPI/I2C/GPIO - действительно ничего вендорспецифичного.
Однако mmio.c прибит гвоздями:
#define BLOCK_LEN 0x01000000
#define BASE_ADDR 0x20000000
//#define VIRT_ADDR 0x7e000000
К BCM2835 - https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf (то есть RPi A(+)/B(+)/Zero. На другом железе (включая RPi4) это работать не будет.
и опять же в сишном коде. Я от direct memory access пока отказался в верхоуровневом API (кейса не нашел), но это так же возможно - https://github.com/java-embedded-framework/jef/blob/master/linux-core/src/main/java/ru/iothub/jef/linux/core/Mmap.java
Пусть и вендорспецифик, но это можно использовать.
Ещё раз подтверждается моё (возможно не только) наблюдение о том, что Java имеет наименьшую популярность при выборе языка для пет-прожектов. Если вдруг кровавый энтерпрайз её разлюбит, то джава и вся её богатая экосистема будет забыта разработчиками, как страшный сон.
Или может время еще не пришло?
Инжектор был придуман в 1864 году, однако когда он начал появляться в ДВС автомобилей?
Просто "железо" сначала дозрело до RTOS, потом дозрело до Linux и продолжает дальше зреть. Замечу, 3 моих соседа рулят отделами разработки в Siemens, Qualcomm, Broadcomm и пишут.... на golang. Это не штучные люди, а направление миграции "железячных компаний" от си-с++ в сторону go. Ваш комментарий, 5 лет назад звучал бы для golang точно так же, как сейчас для Java. Однако...
Java имеет огромную экосистему и придя на embedded, она в том числе сократит стоимость разработки и time to market для будущих систем. А возможно и нет. Время покажет.
Я немного не о том: любительские проекты на Java без поддержки корпораций не выживают, так как сил сообщества оказывается недостаточно (не находится достаточно энтузиастов). Хотя, казалось бы, один из популярнейших языков. Тот же golang вполне имеет своих фанатов, которые пишут на нём "для души", на Python чуть ли не половина пишут только пет-проекты.
То есть, люди пишут на Java, так как за неё хорошо платят корпорации, но дома, "для души", избегают.
(да, я не люблю Java, но ещё я не люблю C++, но вот у него в этом плане порядок - кто на нём пишет, тот его любит)
Apache Foundation и Eclipse Foundation с вами не согласятся. :)
Дык. Там большинство Java проектов, это побочный инструментарий какой-либо корпорации, отданный на опенсорс за ради удешевления разработки. И, соответственно, разрабатываются эти проекты при спонсорской поддержке всё тех же корпораций. Не нужна корпорациям Java на одноплатниках - соответственно, нет её в перечне проектов этих фондов. И энтузиастам она, оказывается, тоже там не нужна - хотя, казалось бы, множества Java-разработчиков и любителей одноплатных DIY должны хорошо так пересекаться.
Про инжекторы и развитие в целом - я согласен, как и про приход ЯВУ в embedded. Но курьез в том, что многие железки уже поддерживают MicroPython "из коробки" - а Java, изначально придуманная для embedded - потеряла рынок приложений для телефонов (что там с SIM-приложениями - я не знаю), и вряд ли вернется в одноплатные компьютеры.
А можно подробнее, что значит:
MicroPython "из коробки"
Название железа, плат и т.д. То про, что вы говорите, это работа на микроконтроллерах похоже. Ниша которых в ближайшем будущем - работа от батарейки (энергоэффективность) и RT системы. Больше - они нигде будут не нужны скорее всего.
Современная "плата" 2021го года это Linux 4.8+, с DDR4 и ARM64(в процессе перехода). Вы на ней, спокойно разворачиваете и Java и Golang (да вон на ней докер легко бегает), и работаете ну как минимум не хуже чем на PC 5 лет назад.
А с учетом, что я написал в комментариях, что Samsung/Broadcom/Qualcomm уже переходят на Golang, то какой микропитон тут уж. Жить ему где то на STM32/ESP32 (вроде там он и живет ныне) и всяких 8ми битных ардуинах.
MicroPython "из коробки" - значит что подключаясь к плате, вы попадаете в консоль Python, а исходник с определенным именем автоматически запускается при подаче питания/рестарте.
"Современные платы" с Linux - это совсем другой класс (одноплатные компьютеры), да и от батарейки с потреблением в 15 Вт как у "малины" - вы их работать долго не заставите. А реальный "embedded" действительно живет на STM32 и ему подобных.
В качестве примера платы - могу порекомендовать MAIX Bit. Разумеется, MicroPython там можно не загружать и писать на С/С++ - как и в ESP32. Но в качестве средства для прототипирования и отладки алгоритмов - MicroPython очень удобен.
Приветствую, спасибо.
все ровно как я написал выше и про батарейку и кто там останется вскоре и про «640 КБ должно хватить всем» (с). К сожалению это вымирающий вид. Нет он не вымрет, но ниша будет сокращаться. Как у Amtel 8 бит, или STM32 убивший своего младшего брата STM8.
Если у вас есть розетка, то проще взять тот же Allwinner F100S или V3S (а они стоят практически тех же денег, что и STM, а иногда и дешевле) и получить готовый линукс со всеми вкусностями и плюшками, которые возможны на операционной системы.
Посмотрите на ту плату, которую я упомянул - или пресловутый ESP32. Линукс там ни для чего не нужен в 99.99% применений. Можно еще упомянуть эпичную историю с раутерами Linкsys - выкинув оттуда Линукс, удалось сократить вдвое количество памяти на плате при одновременном добавлении новых возможностей.
"Если у вас есть розетка" - а что, если нет? И радиатор с вентилятором некуда ставить - а без него включится тепловой троттлинг и производительность упадет...
Java на одноплатниках: легко и просто