Открыть список
Как стать автором
Обновить

Комментарии 39

НЛО прилетело и опубликовало эту надпись здесь
а куда КАТ? вроде один есть
НЛО прилетело и опубликовало эту надпись здесь
странненько, непонятненько :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Было бы очень интересно посмотреть сравнение с полноценной Java SE на Raspberry Pi: время старта, перфоманс на прогретом коде и т.п.
Точно, мне тоже интересно. Посмотрим.
Непонятно какой результат будет у теста. Что именно надо доказать/опровергнуть/проверить?
Насколько я себе представляю, реализация одинаковых функций будет одинакова и простейшие тесты без выделения и освобождения памяти (например считать hash строки) будут выполняться примерно одинаково.
А различие ME / SE настолько велико, что для более сложных тестов могут дать отклонения как в ту, так и в другую сторону.
Логика работы того же GC должна по идее очень сильно отличаться в разных java-машинах
Да там даже код тестов может отличаться. Тут дело далеко не только в JIT. Сравнение не корректно.
Это смотря что и как сравнивать. Не вижу никаких проблем в сравнении. Пишешь бенчмарки и гоняешь.
" Пишешь бенчмарки и гоняешь."
О! Клева, хочу послушать доклад об этом. ;))))
… пишет Java SE Performance Engineer :)
потому и пишу, что не бывает «пишешь и гоняешь»
т.е. бывает, но не всегда, или не так как хотелось или вообще не то ;)
ты бы, кстати, про встречу JUG более явно написал в начале поста. Ну или в конце. А то я еле-еле нашёл анонс в середине.
Всегда хотел спросить, а то в голове небольшая мешанина.

Вот в процессоре Raspberry есть Jazelle (позже ARM-овцы от нее отказались, если я не ошибаюсь). Использует ли Oracle JVM этот набор инструкций, или обычный JIT эффективнее? Использует ли JIT некий «общий подсет» инструкций ARM, или получающийся бинарный код оптимизирован под набор инструкций конкретного процессора? (например, в каких-то армах есть NEON, в распберри есть VFP2 и так далее). Или это не приносит выигрыша в производительности? Вот здесь и здесь говорится о преимуществе Oracle JVM над другими ARM-реализациями JVM. Это связано с глубокой оптимизацией под ARM или просто в принципе JIT оракла лучше?
Где-то в комментариях к прошлым постам писали что 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-компилятора вовсе. Подозреваю, что рекорды по занимаемому месту, достигнуты именно на такой сборке.
Я готов очень подробно рассказать как достигнуты рекорды на отдельной встрече :) В частности на Московском JUG.
Выложите потом видео, пожалуйста! Или хотя бы слайды.
Добрый день!
А не могли бы вы объяснить различия между 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 также имеют свои целевые назначения.
А что бы вы посоветовали для сабжевого харда? 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
Лично у меня лицензия показывается при нажатии мышью. На крайний случай, зарегаться там не сложно :)
Это реализуется внутренними механизмами JavaME и перешло ещё с мобильных телефоном, где запускался один Джава рантайм и приложения жили каждый в своём изолированном пространстве.
С одним класслоадером, как я понимаю. А изоляция за счёт кучи ограничений (типа отсутствия reflections, загрузки классов только из своего jar, невозможности иметь классы, пересекающиеся с системными пакетами). Тогда невозможно иметь два загруженных приложения с разными версиями одного класса. OSGi, очевидно, при таком подходе к загрузке классов работать не может (т. к. невозможно загрузить свой или подменить системный класслоадер).

Вопрос с permgen при выгрузке классов остается открытым. Можно, конечно, поговорить и на встрече jug, если будет время и желание =)
Отличный пост, у меня аж ностальгия… Хочется опять пописать под J2ME
Кстати а почему NetBeans?
НЛО прилетело и опубликовало эту надпись здесь
Немного не так.

Имеется ввиду, что потенциально можно портировать Java ME-E на широкий класс устройств, если есть такая потребность. От кого идут потребности — вопрос, касающийся каждой платформы в частности.
А почему этой встречи JUG нет в событиях на хабре? Было бы полезно. Донецк, например, есть.
А вот такой глуповатый вопрос Java ME-программистам от простого юзера простого J2ME-телефона.
Есть Sony Ericsson Elm — одна из последних и лучших трубок на яве. Там есть Wi-Fi. Есть ли возможность с этого телефона, через j2me-программу, ползать по локальной сетке, к которой телефон подключён по Wi-Fi, с целью, например, качать/отгружать файлы или слушать на телефоне музыку, лежащую на одном из расшаренных дисков в сети? По сути аудио-видео плеер + файл-менеджер, умеющий лазить по локальной сети.

Я сколько ни искал — такой проги не нашёл, только невнятные костыли с необходимостью ставить на комп серверную часть…

Есть несколько похожая прога «JavaFTP», которая на телефоне, подключённому по Wi-Fi к роутеру, поднимает ftp-сервер, выводит адрес типа ftp://192.168.1.x и с компа в локалке можно зайти по этому адресу и работать с телефоном, копируя туда-сюда файлы. А вот бы наоборот.
К сожаление не знаю scope API на вашем телефоне. Для вашей задачи необходимо:
1. CLDC 1.1+
2. MIDP 2+
3. JSR135
4. Опционально можно JSR234, там есть крутые темы эквалайзера и т.п… Фактически дополняет JSR135
Хорошая статья, есть что подчеркнуть подобное писал. Если интересно то могу поделиться, только у меня движущаяся платформа с управлением через сокет.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.