Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
А мне было скучно. Понравилось всего пару выступлений. Нового в ЕЕ почти ничего, JMS 2.0 вообще странная спецификация. Можно было пропустить в этом году.
Ну не так уж и мало. Если считать тупо по количеству JRS'ов, то в Java EE 6 добавилось 30 JSR'ов, а в Java EE 7 — 23.
Зря вы так. Конференция однозначно удалась — и содержание, и организация были очень даже.
Я бы с вами согласился если не был на прошлой конференции. Интересных изменений крайне мало. Ну по крайней мере для меня.
Могу рассказать про все это более подробно здесь на хабре, кому-нибудь интересно?
Да, очень хотелось бы. Смотрел вашу презентацию на slideshare, но из-за отсутствия звукового сопровождения, к сожалению, понятно было не всё.
Меня писал коллега на iPad, попробую выложить видео скоро. Статью может тоже напишу, но позже.
Мы наконец-то опубликовали видео моего выступления — www.youtube.com/watch?v=CKWlp8UQQb4
А почему Java-приложения для iOS могут быть быстрее нативных на ObjC, разве Java не выступает «дополнительной прослойкой»?
Java для iOS в ее «хорошем» исполнении компилируется в нативный ARM-код, который может быть быстрее или медленнее скомпилированной ObjC программы в зависимости от множество факторов – в этом случае никаких прослоек нет.
Вы возможно думаете о трансляции Java -> ObjC с последующей компиляцией. В этом случае действительно есть прослойка, но и сам способ не претендует на идеальное решение.
Вы возможно думаете о трансляции Java -> ObjC с последующей компиляцией. В этом случае действительно есть прослойка, но и сам способ не претендует на идеальное решение.
Не дополнительной прослойкой, а альтернативной. Пока JavaFX не опенсорснули, сложно говорить как эта библиотека реализована на iOS, но я практически уверен, что JavaFX реализовали не поверх Cocoa, а непосредственно на железе, используя в том числе, графические ускорители напрямую (как они это делают на десктопах сейчас). Что же касается Java vs ObjC вообще, то эту тему уже попытались пробенчмаркировать. Но бенчмаркам конечно верить нельзя, но как компиляторщик могу сказать следующее. Объектная модель ObjC пришла из SmallTalk, то есть вызов метода, осуществляется поиском метода во время исполнения, в Java — объектная модель основана на таблице виртуальных методов, то есть вызов метода — это в худшем случае косвенный вызов. Но так как Java, кроме всего прочего еще и статически типизированный язык, то большинство виртуальных вызовов можно с помощью статического типового анализа или анализа иерархии классов заменить на прямые с последующей открытой подстановкой и специализацией. Что крайне важно для производительности программ, написанных в хорошем объектно-ориентированном стиле (с тотальной инкапсуляцией и обилием очень маленьких методов). В ObjC же из-за его объектной модели, крайне сложно девиртуализовать вызовы методов, если вообще возможно. А так как на iOS запрещена динамическая компиляция в машинный код, то динамически оптимизировать ObjC с помощью inline caches, как это делают. например, в JavaScript V8, тоже нельзя.
А почему выступления не писались на видео? Это было запрещено устроителями конференции?
Мне тоже понравились доклады TheShade, из первого дня они были самыми зачетными — выступление очень живое. На второй день попасть не было возможности, хотелось пообщаться с ребятами из jetbrains про котлин, скалу.
Отсутствие указателей малость убило — рядом была конференция зубников их там еще на выходе из метро встречали, а у javaone не было даже на входе в павильон вывески, только зайдя внутрь можно было заметить в глубине холла слева плакат.
Отсутствие указателей малость убило — рядом была конференция зубников их там еще на выходе из метро встречали, а у javaone не было даже на входе в павильон вывески, только зайдя внутрь можно было заметить в глубине холла слева плакат.
pjBooms, а можете рассказать с примерами про вашу: Excelsior JET?
Просто так рассказывать можно долго, да и сообществом будет воспринято как реклама. Может у вас есть какие-то вопросы?
Правильно ли я понял, что фишка это jvm в компиляции java кода (именно не байт кода, или все таки его — но тогда ведь есть проекты для запуска байт кода на llvm)? Если все таки это весчь работает с байткодом, приминима ли она к альтернативным языкам (scala)?
На входе принимается именно байткод (который получается обычным javac или scalac). После этого уже *.class + *.jar скармливаются компилятору. Мы сами даже внутри компании используем Scala и компилируем ее нашим же компилятором. :)
И на выходе исполняемый файл. На сайте написано, сейчас поддерживается x86, и только под windows — есть планы на x86_64 (да я знаю, что 32 битные приложения работают на 64 битной машине) и linux? А очень долго происходит компиляция (для примера стандартное play приложение)? То есть сейчас сначала мы ждем .java, .scala -> .class и потом .class -> .exe. Звучит не быстро…
Есть бенчмарки улучшения производительности и потребления памяти? Я нашел только пару красивых маркетинговых графиков.
А что стало со сборщиком мусора? Он также может вызвать stop the world? Или у вас что то хитрое типа azul c4?
Есть бенчмарки улучшения производительности и потребления памяти? Я нашел только пару красивых маркетинговых графиков.
А что стало со сборщиком мусора? Он также может вызвать stop the world? Или у вас что то хитрое типа azul c4?
Проясню насчет поддерживаемых архитектур: Windows x86 + amd64, Linux x86 only. В скором времени появится и Linux amd64, это точно. А затем есть еще много разных ОС и архитектур. :)
Насчет скорости компиляции: к сожалению не очень знаком с Play, но, например, Eclipse 4.2 (40k классов) может компилироваться ~50 минут. Это очень сильно зависит от приложения, но сам JET предлагается скорее как финальный этап сборки программы, нежели инструмент для непрерывной разработки.
GC работает в среднем по-лучше, но это опять же индивидуально. И вот насчет бенчмарков я не подскажу. Завтра может появятся более просвещенные люди.
Насчет скорости компиляции: к сожалению не очень знаком с Play, но, например, Eclipse 4.2 (40k классов) может компилироваться ~50 минут. Это очень сильно зависит от приложения, но сам JET предлагается скорее как финальный этап сборки программы, нежели инструмент для непрерывной разработки.
GC работает в среднем по-лучше, но это опять же индивидуально. И вот насчет бенчмарков я не подскажу. Завтра может появятся более просвещенные люди.
Про бенчмарки: что-то хуже, что-то лучше (то что мы их давно не публиковали — не есть хорошо). Но к стандартным бенчмаркам надо относится осторожно: известно, что все производители компиляторов специально разгоняют бенчмарки. То есть, если у какого-то производителя какой-то бенчмарк лучше, чем у других — это чаще всего означает, что над этим бенчмарком хорошо поработали. Проверять же лучше на своих приложениях.
Для ознакомления можно посмотреть вот эти наши выступления: история одной JVM в картинках (рекомендую вопросную часть — это такой mini FAQ) и JIT vs. AOT.
Просто рассказ про Excelsior JET действительно может быть расценен как реклама, но наверно можно сделать серию технических статей про статическую компиляцию Java или особенность реализации GC и прочих особенностей нашей JVM.
Просто рассказ про Excelsior JET действительно может быть расценен как реклама, но наверно можно сделать серию технических статей про статическую компиляцию Java или особенность реализации GC и прочих особенностей нашей JVM.
Посмотрел доклад. Там не особо много технических подробностей, а половина вопросов было задано в некотором роде капитанских.
Про статьи — можно ведь писать технические статьи и не спускаться дл рекламы одного продукта. Теория, практика и сравнения на примерах (да много чего можно придумать, чтобы статью не считали рекламой).
Лично мне было интересно узнать про реализицию GC,
Про статьи — можно ведь писать технические статьи и не спускаться дл рекламы одного продукта. Теория, практика и сравнения на примерах (да много чего можно придумать, чтобы статью не считали рекламой).
Лично мне было интересно узнать про реализицию GC,
на JUG к нам давай
Для ознакомления можно посмотреть вот эти наши выступления: история одной JVM в картинках (рекомендую вопросную часть — это такой mini FAQ) и JIT vs. AOTOfftopic: Зачем все ролики на канале Эксельсиора скрытые?
Про статическую компиляцию, GC и прочее было бы интересно почитать.
JVM на Андроиде вроде уже года с 2009 есть — с тех самых пор, как NDK появился. Была какая-то контора в Швейцарии, которая свою виртуальную машину с Windows Mobile на Android перенесли. У них был JIT еще до того, как сделали JIT в Дальвике, и оно так заметно быстрее Java-код выполняло.
А можно ссылку на эту JVM?
Было это в 2009 году, так что имя вендора не помню. Вроде как нагуглил вот этих ребят, но до конца не уверен: www.myriadgroup.com/
В любом случае, JVM не была доступна для широкой публики, а только для «заинтересованных» партнеров.
В любом случае, JVM не была доступна для широкой публики, а только для «заинтересованных» партнеров.
Ну этих ребят я знаю. У них есть Java ME реализация JVM для set-top boxes, и альтернативная Дальвику — Alien Dalvik, которая как бы позволяет Android приложения запускать на Meego. Но это все не то.
Я же говорю о Java SE совместимой реализации, которая бы позволила получить настоящий WORA: чтобы клиентские Java SE приложения работали одинаково на всех декстопах и планшетах. И быстро. Такой реализации, на сколько мне известно, пока нет.
Я же говорю о Java SE совместимой реализации, которая бы позволила получить настоящий WORA: чтобы клиентские Java SE приложения работали одинаково на всех декстопах и планшетах. И быстро. Такой реализации, на сколько мне известно, пока нет.
«Знаете, нас JVM разработчиков в мире-то не очень много, а в России и того меньше: в Питере четверо, да у нас в Новосибирске десять.»
В Питере десятка полтора-два найдется, но порядок цифры верный.
В Питере десятка полтора-два найдется, но порядок цифры верный.
Именно JVM разработчиков? Не QA/QE и Java SE API?
В команде HotSpot в Питере было в лучшие времена 6 человек, и эта команда сдалала довольно заметные вещи. типа написала большую часть G1, сделала linux arm, linux sparc порты, compressed oops, dtrace support и т.п. Я был среди тех 6. Никого из них больше нету в Оракле, но знания и интерес остались. Кроме того не стоит недооценивать SQE, которые не только фиксят баги в релизнутых jdk, но и активно развивают servicebility, для чего тоже нужна квалификация вм-щика. Кроме того в Интеле было немало людей, которые занимальсь Harmony, да и потом, в переписках, всплывало немало руммких фамилий, но где они — не знаю, вероятно Леша и Сергей знают лучше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JavaOne Russia или бенефис Куксенко с Шипилёвым. Отчет о конференции