Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Было бы очень интересно посмотреть сравнение с полноценной Java SE на Raspberry Pi: время старта, перфоманс на прогретом коде и т.п.
Точно, мне тоже интересно. Посмотрим.
Непонятно какой результат будет у теста. Что именно надо доказать/опровергнуть/проверить?
Насколько я себе представляю, реализация одинаковых функций будет одинакова и простейшие тесты без выделения и освобождения памяти (например считать hash строки) будут выполняться примерно одинаково.
А различие ME / SE настолько велико, что для более сложных тестов могут дать отклонения как в ту, так и в другую сторону.
Логика работы того же GC должна по идее очень сильно отличаться в разных java-машинах
Насколько я себе представляю, реализация одинаковых функций будет одинакова и простейшие тесты без выделения и освобождения памяти (например считать hash строки) будут выполняться примерно одинаково.
А различие ME / SE настолько велико, что для более сложных тестов могут дать отклонения как в ту, так и в другую сторону.
Логика работы того же GC должна по идее очень сильно отличаться в разных java-машинах
ты бы, кстати, про встречу JUG более явно написал в начале поста. Ну или в конце. А то я еле-еле нашёл анонс в середине.
Где-то в комментариях к прошлым постам писали что Jazelle не используется и сильно устарел.
У Оракла много разных JVM, так что лучше уточнять, о которой речь.
Про Jazelle писал: раз, два. JVM с JIT ее не используют, т.к. от нее только хуже.
В основе Java SE Embedded лежит Hotspot JVM. Выпускается в нескольких сборках — в зависимости от версии архитектуры (ARM v5, v6, v7) и поддержки VFP. Кроме того, JVM в рантайме определяет поддерживаемый набор инструкций для более оптимальной JIT-компиляции. В частности, версия, собранная под ARM v6, может генерировать код с использованием ARM v7 инструкций.
Полноценно поддерживаются многоядерные CPU. Навороченный JIT-компилятор с промежуточным представлением, глубоким инлайнингом, спекулятивной девиртуализацией и т.д.
В основе Java ME лежит CLDC HI JVM. Тоже выпускается в разных сборках для разных платформ. Прежде всего заточена на маленькие объемы памяти. Поэтому большинство фич включаются/выключаются на этапе сборки под конкретную платформу. Также имеет JIT компилятор, заточенный под ARM, хотя и гораздо проще (можно сказать, однопроходный). Более того, есть сборки и без JIT-компилятора вовсе. Подозреваю, что рекорды по занимаемому месту, достигнуты именно на такой сборке.
Про Jazelle писал: раз, два. JVM с JIT ее не используют, т.к. от нее только хуже.
В основе Java SE Embedded лежит Hotspot JVM. Выпускается в нескольких сборках — в зависимости от версии архитектуры (ARM v5, v6, v7) и поддержки VFP. Кроме того, JVM в рантайме определяет поддерживаемый набор инструкций для более оптимальной JIT-компиляции. В частности, версия, собранная под ARM v6, может генерировать код с использованием ARM v7 инструкций.
Полноценно поддерживаются многоядерные CPU. Навороченный JIT-компилятор с промежуточным представлением, глубоким инлайнингом, спекулятивной девиртуализацией и т.д.
В основе Java ME лежит CLDC HI JVM. Тоже выпускается в разных сборках для разных платформ. Прежде всего заточена на маленькие объемы памяти. Поэтому большинство фич включаются/выключаются на этапе сборки под конкретную платформу. Также имеет JIT компилятор, заточенный под ARM, хотя и гораздо проще (можно сказать, однопроходный). Более того, есть сборки и без JIT-компилятора вовсе. Подозреваю, что рекорды по занимаемому месту, достигнуты именно на такой сборке.
Добрый день!
А не могли бы вы объяснить различия между ME и SE в Raspberry Pi? Просто для неё есть обе JRE, а вот чем они различаются и какие у них преимущества по сравнению с друг другом я не знаю. Я так думаю, что для ME нужно меньше памяти, а SE зато позволят запускать любые Java-приложения. Но на этом мои знания ограничиваются.
На прошлом Java One, когда как раз активно демонстрировали возможности Raspberry Pi с Java SE и ME, этих различий не показали.
А то так для меня получается, что ME есть, но лучше использовать SE, т.к. на SE можно запускать все приложения.
А не могли бы вы объяснить различия между ME и SE в Raspberry Pi? Просто для неё есть обе JRE, а вот чем они различаются и какие у них преимущества по сравнению с друг другом я не знаю. Я так думаю, что для ME нужно меньше памяти, а SE зато позволят запускать любые Java-приложения. Но на этом мои знания ограничиваются.
На прошлом Java One, когда как раз активно демонстрировали возможности Raspberry Pi с Java SE и ME, этих различий не показали.
А то так для меня получается, что ME есть, но лучше использовать SE, т.к. на SE можно запускать все приложения.
Отвечаю как разработчик ME.
Необходимо понимать, что Raspberry не является целевой платформой Java ME. Java ME под Raspberry сделана исключительно ради того, чтобы многие смогли попробовать Java ME на реальном железе, а не только писать под эмулятор. Java ME работает на очень ограниченных устройствах(реальные релизы под 192 KB RAM и 1 MB ROM) и это её целевые платформы, где у вас выбора между Джавами и не останется, SE пока под них не выпускают.
Зачем нужны столь ограниченные устройства — это тема отдельного топика, но они весьма востребованы в связи с их стоимостью, энергопотреблением, размерами и прочими вкусными штуками.
На самом деле, на SE можно запускать очень и очень многое, но есть и вкусные штуки в ME, которые в SE не реализованы, а именно Device Access API. Также есть tooling, позволяющий при наличии коннекции удалённо деплоить, дебажить, профилировать приложения. При этом по SSH можно не подключаться, достаточно просто подключиться использую тулы ME. Также есть возможность установки/обновления приложения по HTTP, это также удобно. Причём одно приложение может останавливать, запускать и обновлять другие приложения без остановки JavaME runtime. Т.е. вся работы сводится к тому, чтобы правильно запустить JavaME(а на некоторых устройствах типа Keil MCBSTM32F200, Qualcomm IoE development platform или STM32F4Discovery она сама запускаться) и работать.
В общем каждый инструмент предназначен для своих нужд и Java SE и Java ME также имеют свои целевые назначения.
Необходимо понимать, что Raspberry не является целевой платформой Java ME. Java ME под Raspberry сделана исключительно ради того, чтобы многие смогли попробовать Java ME на реальном железе, а не только писать под эмулятор. Java ME работает на очень ограниченных устройствах(реальные релизы под 192 KB RAM и 1 MB ROM) и это её целевые платформы, где у вас выбора между Джавами и не останется, SE пока под них не выпускают.
Зачем нужны столь ограниченные устройства — это тема отдельного топика, но они весьма востребованы в связи с их стоимостью, энергопотреблением, размерами и прочими вкусными штуками.
На самом деле, на SE можно запускать очень и очень многое, но есть и вкусные штуки в ME, которые в SE не реализованы, а именно Device Access API. Также есть tooling, позволяющий при наличии коннекции удалённо деплоить, дебажить, профилировать приложения. При этом по SSH можно не подключаться, достаточно просто подключиться использую тулы ME. Также есть возможность установки/обновления приложения по HTTP, это также удобно. Причём одно приложение может останавливать, запускать и обновлять другие приложения без остановки JavaME runtime. Т.е. вся работы сводится к тому, чтобы правильно запустить JavaME(а на некоторых устройствах типа Keil MCBSTM32F200, Qualcomm IoE development platform или STM32F4Discovery она сама запускаться) и работать.
В общем каждый инструмент предназначен для своих нужд и Java SE и Java ME также имеют свои целевые назначения.
А что бы вы посоветовали для сабжевого харда? ME это слшиком как я понимаю, взрослая джава в реальном мире тоже очень быстро утомит расбери.
Всё зависит от задач.
Нужна графика и мультимедиа + огромный API, JNI и прочие «большие» штуки — SE
Нужен лёгкий способ доступа к периферии, крутой туллинг, множество приложений в одном Java рантайме и низкий футпринт с меньшим временем запуска — ME
Никто, кстати, не запрещает запускать их вместе :)
Нужна графика и мультимедиа + огромный API, JNI и прочие «большие» штуки — SE
Нужен лёгкий способ доступа к периферии, крутой туллинг, множество приложений в одном Java рантайме и низкий футпринт с меньшим временем запуска — ME
Никто, кстати, не запрещает запускать их вместе :)
Причём одно приложение может останавливать, запускать и обновлять другие приложения без остановки JavaME runtime.Это реализуется в рамках API CLDC или требует, например, OSGi? И какова ситуация с PermGen в этом случае (в смысле gc классов при выгрузке старой версии приложения)? На se эта проблема бывает очень актуальна.
Ещё вопрос, в догонку. Какова ситуация с лицензированием? То здесь www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javame-419430.html#J2MECLDC-1.1-WINUNIX-G-F незарегистрированным дают согласиться с лицензией, но не прочитать её ,)
1. Это реализуется внутренними механизмами JavaME и перешло ещё с мобильных телефоном, где запускался один Джава рантайм и приложения жили каждый в своём изолированном пространстве.
2. Это ссылка на скачивание Java ME Embedded. www.oracle.com/technetwork/java/embedded/downloads/javame/index.html
Лично у меня лицензия показывается при нажатии мышью. На крайний случай, зарегаться там не сложно :)
2. Это ссылка на скачивание Java ME Embedded. www.oracle.com/technetwork/java/embedded/downloads/javame/index.html
Лично у меня лицензия показывается при нажатии мышью. На крайний случай, зарегаться там не сложно :)
Это реализуется внутренними механизмами JavaME и перешло ещё с мобильных телефоном, где запускался один Джава рантайм и приложения жили каждый в своём изолированном пространстве.С одним класслоадером, как я понимаю. А изоляция за счёт кучи ограничений (типа отсутствия reflections, загрузки классов только из своего jar, невозможности иметь классы, пересекающиеся с системными пакетами). Тогда невозможно иметь два загруженных приложения с разными версиями одного класса. OSGi, очевидно, при таком подходе к загрузке классов работать не может (т. к. невозможно загрузить свой или подменить системный класслоадер).
Вопрос с permgen при выгрузке классов остается открытым. Можно, конечно, поговорить и на встрече jug, если будет время и желание =)
Отличный пост, у меня аж ностальгия… Хочется опять пописать под J2ME
Кстати а почему NetBeans?
Кстати а почему NetBeans?
Можно и в Eclipse. Тут есть плагины: www.oracle.com/technetwork/java/javame/javamobile/download/sdk/index.html
Малина — зачёт :)
А почему этой встречи JUG нет в событиях на хабре? Было бы полезно. Донецк, например, есть.
А вот такой глуповатый вопрос Java ME-программистам от простого юзера простого J2ME-телефона.
Есть Sony Ericsson Elm — одна из последних и лучших трубок на яве. Там есть Wi-Fi. Есть ли возможность с этого телефона, через j2me-программу, ползать по локальной сетке, к которой телефон подключён по Wi-Fi, с целью, например, качать/отгружать файлы или слушать на телефоне музыку, лежащую на одном из расшаренных дисков в сети? По сути аудио-видео плеер + файл-менеджер, умеющий лазить по локальной сети.
Я сколько ни искал — такой проги не нашёл, только невнятные костыли с необходимостью ставить на комп серверную часть…
Есть несколько похожая прога «JavaFTP», которая на телефоне, подключённому по Wi-Fi к роутеру, поднимает ftp-сервер, выводит адрес типа
Есть Sony Ericsson Elm — одна из последних и лучших трубок на яве. Там есть Wi-Fi. Есть ли возможность с этого телефона, через j2me-программу, ползать по локальной сетке, к которой телефон подключён по Wi-Fi, с целью, например, качать/отгружать файлы или слушать на телефоне музыку, лежащую на одном из расшаренных дисков в сети? По сути аудио-видео плеер + файл-менеджер, умеющий лазить по локальной сети.
Я сколько ни искал — такой проги не нашёл, только невнятные костыли с необходимостью ставить на комп серверную часть…
Есть несколько похожая прога «JavaFTP», которая на телефоне, подключённому по Wi-Fi к роутеру, поднимает ftp-сервер, выводит адрес типа
ftp://192.168.1.x и с компа в локалке можно зайти по этому адресу и работать с телефоном, копируя туда-сюда файлы. А вот бы наоборот.
Хорошая статья, есть что подчеркнуть подобное писал. Если интересно то могу поделиться, только у меня движущаяся платформа с управлением через сокет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java ME Embedded на Raspberry Pi