Комментарии 43
По словам «jvm scala AOT» уже могу угадывать автора, пока-что работает безотказно :) Никита, спасибо за рассказ. А где будут материалы выкладывать? Я б послушал.
Последнее время весь десктоп, который я вижу сделан поверх Eclipse. Включая дорогущие проприетарные софтины.
Кстати, о разных JVMах. А есть ли среди них какой-нибудь оптимизирующий хвостовые вызовы? Я вынужден переходить с функциональных языков на JVMные и некоторые привычки меня сильно подводят. А моделью безопасности Java я все равно не пользуюсь, так как весь код могу контролировать.
Кстати, о разных JVMах. А есть ли среди них какой-нибудь оптимизирующий хвостовые вызовы? Я вынужден переходить с функциональных языков на JVMные и некоторые привычки меня сильно подводят. А моделью безопасности Java я все равно не пользуюсь, так как весь код могу контролировать.
Не только поверх Eclipse. Есть еще поверх Netbeans — platform.netbeans.org/screenshots.html. Android Studio сделана поверх IntelijJ IDEA Platform. Мелочь всякую пишут и на голых SWT/Swing/JOGL/JavaFX
Поверх Netbeans я видел только kojo.
Наша JVM — Excelsior JET — оптимизирует хвостовую рекурсию (если удается доказать, что не используется стек-трейс внутри). Scala оптимизируют хвостовую рекурсию на уровне scalac (можно причем форснуть это дело).
Только рекурсию или вообще хвостовые вызовы?
Scala это умеет не всегда, к сожалению.
Scala это умеет не всегда, к сожалению.
А что такое оптимизация хвостовых вызовов? Нерекурсивный хвостовой вызов может быть спокойно заинлайнен.
Или вы про такое?
Или вы про такое?
def even(n: Int) = (n == 0) || odd(n-1)
def odd(n: Int) = (n == 1) || even(n-1)
А если это вызов виртуального метода другого объекта? Или не виртуального, но из другого модуля компиляции? На уровне JVM это можно соптимизировать, на уровне языка сложнее.
Честно говоря опять не понял вопроса. Если вызов виртуальный, то понятно, что инлайнить можно только спекулятивно. А что такое модули компиляции и уровень JVM/языка я совсем не понял. Буду рад более развернуто услышать вопрос.
p.s. под виртуальным я понимаю такой invokevirtual, который нельзя девиртуализовать.
Если вызов виртуальный, можно последовательность команд invoke и return выполнить в другом порядке — сначала освободить фрейм вызывающего метода, а потом создать фрейм вызываемого. То есть инлайнить вообще не обязательно.
Пусть у нас функция x, описанная в файле x.scala, последним оператором вызывает вызывает функцию y, описанную в y.scala. Когда компилятор обрабатывает x.scala ему нужен только интерфейс y. Вытаскивание кода функции y, что бы ее заинлайнить в x, усложнит сборку.
Пусть у нас функция x, описанная в файле x.scala, последним оператором вызывает вызывает функцию y, описанную в y.scala. Когда компилятор обрабатывает x.scala ему нужен только интерфейс y. Вытаскивание кода функции y, что бы ее заинлайнить в x, усложнит сборку.
Я отстаивал прямо противоположную точку зрения: сложность задач в вебе стремительно растет (на клиентской стороне), и что через некоторое время текущими технологиями, основанными на HTML + JavaScript эти задачи будет решать слишком дорого, потому что в веб-технологиях есть встроенные от рождения проблемы, которые не решаются естественным путем.
Согласен про проблемы, но внятно сформулировать их меня затрудняет, возможно в силу небольшого опыта в rich web. Не могли бы вы их сформулировать?
Мое мнение здесь такое, если вкратце.
HTML, по своей природе провоцирует Browser Hell. Он не говорит, как рисовать, а говорит что рисовать. В результате, возможны разные интерпретации, какие мы и видим в разных браузерах. Таким образом, пока все не перейдут на один движок ренедеринга HTML мы будем иметь Browser HELL.
Есть и проблемы с JavaScript. Во первых, опять же разные браузеры, поддерживают его по разному. Во вторых, JavaScript создавался как простой язык, который придавал бы хоть какую-то динамичность, статическому интернет контенту. Никто не предполагал, что его будут использовать в таком объеме как сейчас. А спроектирован он на скору руку (в течении полугода) и довольно погано. В результате,
a) оптимизировать его (IMHO) так чтобы он был близок к производительности к С или Java практически не реально, хотя Google здесь и сделал прорыв. И я сильно сомневаюсь, что его скорость будет как-то расти кардинально в ближайшем будущем (по некоторым данным скорость его не растет последние 3 года). asm.js мог бы в принципе прийти на помощь — но его область ограничена оптимизацией одного конкретного метода. Если мы имеем нормальную OOP модель с виртуальными методами, где надо много инлайнить, что можно хорошо делать на основе типовой информации, то asm.js тоже не помощник. Причем, использование JavaScript как ассемблера, мне вообще кажется полным бредом: это же надо было догадаться транслировать эффективные языки в крайне неэффективный!
b) отсутствие нормальной поддержки мультитредности в мультиядерный век, это тоже тот ещё прикол. Упование на автоматическое распараллеливание — это тоже странно. В JavaScript весь state — mutable
c) Ну и проектировать большие системы в той объектной модели, что есть у JavaScript — это тоже крайне странно. Я думаю, что начиная с некоторой сложности, архитектура будет ломаться сама по себе с практически не реальной вероятностью что-либо отрефакторить.
Но это все моё IMHO. Время покажет.
HTML, по своей природе провоцирует Browser Hell. Он не говорит, как рисовать, а говорит что рисовать. В результате, возможны разные интерпретации, какие мы и видим в разных браузерах. Таким образом, пока все не перейдут на один движок ренедеринга HTML мы будем иметь Browser HELL.
Есть и проблемы с JavaScript. Во первых, опять же разные браузеры, поддерживают его по разному. Во вторых, JavaScript создавался как простой язык, который придавал бы хоть какую-то динамичность, статическому интернет контенту. Никто не предполагал, что его будут использовать в таком объеме как сейчас. А спроектирован он на скору руку (в течении полугода) и довольно погано. В результате,
a) оптимизировать его (IMHO) так чтобы он был близок к производительности к С или Java практически не реально, хотя Google здесь и сделал прорыв. И я сильно сомневаюсь, что его скорость будет как-то расти кардинально в ближайшем будущем (по некоторым данным скорость его не растет последние 3 года). asm.js мог бы в принципе прийти на помощь — но его область ограничена оптимизацией одного конкретного метода. Если мы имеем нормальную OOP модель с виртуальными методами, где надо много инлайнить, что можно хорошо делать на основе типовой информации, то asm.js тоже не помощник. Причем, использование JavaScript как ассемблера, мне вообще кажется полным бредом: это же надо было догадаться транслировать эффективные языки в крайне неэффективный!
b) отсутствие нормальной поддержки мультитредности в мультиядерный век, это тоже тот ещё прикол. Упование на автоматическое распараллеливание — это тоже странно. В JavaScript весь state — mutable
c) Ну и проектировать большие системы в той объектной модели, что есть у JavaScript — это тоже крайне странно. Я думаю, что начиная с некоторой сложности, архитектура будет ломаться сама по себе с практически не реальной вероятностью что-либо отрефакторить.
Но это все моё IMHO. Время покажет.
вот тебе и тема для статьи, кстати
Большое спасибо за развернутый ответ!
В моих задачах эффективности javascript обычно хватает. Но сам язык на столько громоздок и ужасен, что писать я на нем не могу.
А эффективные языки, типа Scala, Clojure или Haskell кроме того еще и удобны. И я готов смириться с потерей производительности, лишь бы не писать на js.
Правда, пока программирование клиента мне удавалось спихивать на других. Но что так будет всегда я не уверен и пытаюсь разобраться с альтернативами.
А эффективные языки, типа Scala, Clojure или Haskell кроме того еще и удобны. И я готов смириться с потерей производительности, лишь бы не писать на js.
Правда, пока программирование клиента мне удавалось спихивать на других. Но что так будет всегда я не уверен и пытаюсь разобраться с альтернативами.
В небольших задачах производительности конечно хватает. Все чем занимается JS сейчас — это месит HTML DOM, и в итоге HTML рендеринг (который написан как правило на C) мажорирует всё остальное. Но тут опять возникает вопрос правильно ли UI представлять с помощью HTML. Вообще есть более эффективные модели представления UI. HTML все-таки создавался для отображения текста!
Кроме того, если кроме манипуляции UI JS начнет что-то делать более умное (например считать разные геометрические модели), то тут-то он и приплывёт. А еще я считаю, что далеко не все что сейчас делается на сервере, правильно делать на сервере. Можно часть работы отдавать на клиент (всё-таки он довольно мощный сейчас), чтобы разгрузить сервера. И здесь опять JS только мешает.
Кроме того, если кроме манипуляции UI JS начнет что-то делать более умное (например считать разные геометрические модели), то тут-то он и приплывёт. А еще я считаю, что далеко не все что сейчас делается на сервере, правильно делать на сервере. Можно часть работы отдавать на клиент (всё-таки он довольно мощный сейчас), чтобы разгрузить сервера. И здесь опять JS только мешает.
Недавно услышал о CDF — он бы мог многое перенести на клиента.
Хотя лично я предпочел бы более многоуровневые архитектуры. Даже браузер разделил бы на части, по образу Opera mini. Значительную часть вычислений можно было бы выполнять на proxy.
Хотя лично я предпочел бы более многоуровневые архитектуры. Даже браузер разделил бы на части, по образу Opera mini. Значительную часть вычислений можно было бы выполнять на proxy.
Реальной проблемой является только b), хотя js развивается и в этом направлении.
Browser HELL сильно преувеличен. Никто не пишет RIA для старых IE. Ну и, в конце концов, можно в два клика завернуть веб-морду в нужную вам версию хрома и распространять такой бандл, который для юзера будет обычной программой, а не сайтом, а для программиста будет только 1 браузер.
Далее про а). JS ориентирован всё-таки на написание клиентов/гуев, а не приложений целиком. Делать на нём фотошоп целиком довольно странно. А вот сделать морду к облаку/ферме, на которой крутится низкоуровневый числодробильный сервер — вот это как раз таки тренд развития всей ИТ-отрасли. Какая разница, из какого именно языка вы дёргаете функцию «нарисовать кнопочку»? Всё равно этот вызов проходит через 20 либ разной степени низкоуровневости.
Про с) — не холивара ради, но проектировать, опять же, программы со сложными интерфейсами на прототипном наследовании сильно проще. Вместо того, чтобы дизайнить класс для какого-нибудь уникального диалога, а затем долго и муторно создавать единственный экземпляр этого класса, вы просто делаете этот диалог, получая сразу и диалог, и прототип таких диалогов, на случай, если оно вам понадобится в будущем. Кода почти в два раза меньше.
Ну и конечно MVVM это чит.
Browser HELL сильно преувеличен. Никто не пишет RIA для старых IE. Ну и, в конце концов, можно в два клика завернуть веб-морду в нужную вам версию хрома и распространять такой бандл, который для юзера будет обычной программой, а не сайтом, а для программиста будет только 1 браузер.
Далее про а). JS ориентирован всё-таки на написание клиентов/гуев, а не приложений целиком. Делать на нём фотошоп целиком довольно странно. А вот сделать морду к облаку/ферме, на которой крутится низкоуровневый числодробильный сервер — вот это как раз таки тренд развития всей ИТ-отрасли. Какая разница, из какого именно языка вы дёргаете функцию «нарисовать кнопочку»? Всё равно этот вызов проходит через 20 либ разной степени низкоуровневости.
Про с) — не холивара ради, но проектировать, опять же, программы со сложными интерфейсами на прототипном наследовании сильно проще. Вместо того, чтобы дизайнить класс для какого-нибудь уникального диалога, а затем долго и муторно создавать единственный экземпляр этого класса, вы просто делаете этот диалог, получая сразу и диалог, и прототип таких диалогов, на случай, если оно вам понадобится в будущем. Кода почти в два раза меньше.
Ну и конечно MVVM это чит.
>>завернуть веб-морду в нужную вам версию хрома и распространять такой бандл,
Ну это холиварная тема конечно. Единственной причиной, по моему мнению, почему RIA имеет смысл делать в вебе — это наличие у всех (какого-то) браузера. Никогда бы не стал делать на веб технологиях десктоп. Но если вам нравится — пожалуйста.
>> JS ориентирован всё-таки на написание клиентов/гуев, а не приложений целиком. Делать на нём фотошоп целиком довольно странно
>> А вот сделать морду к облаку/ферме, на которой крутится низкоуровневый числодробильный сервер —
>>вот это как раз таки тренд развития всей ИТ-отрасли
Толстые клиенты тоже никто не отменял. Но из-за того что, как вы говорите, область применения JS заканчивается на UI, а Java не умеет распространяться по частям (умеет конечно, но не из коробки), у нас нет возможности регулировать толщину клиента. Некоторые (а я бы сказал большинство) числодробильных действий сегодняшний клиент вполне способен делать (однажды один мой знакомый померил производительность своего телефона и завопил — «у меня же Cray в кармане!»). Какого фига мы загружаем сервера лишней работой?
И потом, лично мне не нравятся ни один RIA сервис в вебе — они тормозные (потому что в частности лезут за каждой хреновинкой в сеть) и не удобные (аналогичные десктопные клиенты как правило удобней — например Outlook удобеней GMail, Google Earth удобней Google Maps и т.д., а про клаудные IDE я вообще молчу).
И ещё про тренд: вы не обращали внимание на mobile, где каждый уважающий себя сервис делает нативные приложения, которые по сути являются толстыми клиентами? Если JS такой клёвый для гуев, что же всех там не устраивает (знаю что некоторые на самом деле завертки над JS, но и настоящих нативных клиентов довольно до фига)?
>>Ну и конечно MVVM это чит.
Что имеете в виду? Вообще наплодили вариаций от MVC, сам черт ногу сломит. Я считаю что GUI нужно рисовать (визуально дизайнеру), и программировать диалоги вообще не нужно. В вебе это не возможно из-за Browser Hell опять же. Но если бы так программы были построены, то их кустомизация на клиенте была бы доступна для всех (то есть для конечных пользователей). Прилетела тебе программа, видишь что тебе нафигачили миллион ненужных кнопок — взял (стандартный) редактор удалил все, что тебе не нужно. Или, наоборот, прикрутил, то что тебе не хватает в том же редакторе. И программисту ничего делать не надо, чтобы это поддержать
Ну это холиварная тема конечно. Единственной причиной, по моему мнению, почему RIA имеет смысл делать в вебе — это наличие у всех (какого-то) браузера. Никогда бы не стал делать на веб технологиях десктоп. Но если вам нравится — пожалуйста.
>> JS ориентирован всё-таки на написание клиентов/гуев, а не приложений целиком. Делать на нём фотошоп целиком довольно странно
>> А вот сделать морду к облаку/ферме, на которой крутится низкоуровневый числодробильный сервер —
>>вот это как раз таки тренд развития всей ИТ-отрасли
Толстые клиенты тоже никто не отменял. Но из-за того что, как вы говорите, область применения JS заканчивается на UI, а Java не умеет распространяться по частям (умеет конечно, но не из коробки), у нас нет возможности регулировать толщину клиента. Некоторые (а я бы сказал большинство) числодробильных действий сегодняшний клиент вполне способен делать (однажды один мой знакомый померил производительность своего телефона и завопил — «у меня же Cray в кармане!»). Какого фига мы загружаем сервера лишней работой?
И потом, лично мне не нравятся ни один RIA сервис в вебе — они тормозные (потому что в частности лезут за каждой хреновинкой в сеть) и не удобные (аналогичные десктопные клиенты как правило удобней — например Outlook удобеней GMail, Google Earth удобней Google Maps и т.д., а про клаудные IDE я вообще молчу).
И ещё про тренд: вы не обращали внимание на mobile, где каждый уважающий себя сервис делает нативные приложения, которые по сути являются толстыми клиентами? Если JS такой клёвый для гуев, что же всех там не устраивает (знаю что некоторые на самом деле завертки над JS, но и настоящих нативных клиентов довольно до фига)?
>>Ну и конечно MVVM это чит.
Что имеете в виду? Вообще наплодили вариаций от MVC, сам черт ногу сломит. Я считаю что GUI нужно рисовать (визуально дизайнеру), и программировать диалоги вообще не нужно. В вебе это не возможно из-за Browser Hell опять же. Но если бы так программы были построены, то их кустомизация на клиенте была бы доступна для всех (то есть для конечных пользователей). Прилетела тебе программа, видишь что тебе нафигачили миллион ненужных кнопок — взял (стандартный) редактор удалил все, что тебе не нужно. Или, наоборот, прикрутил, то что тебе не хватает в том же редакторе. И программисту ничего делать не надо, чтобы это поддержать
Что я имею в виду под MVVM? Откройте для себя knockout.js, например. Не говорю про ожиревший angular.
Вместо модели, контроллера и представления у вас есть модель, грязная модель представления и представление.
«Грязная» значит непроверенная и несохранённая.
Трюк в том, что грязная модель двунаправленно связана с представлением библиотекой, и вам вообще не нужно писать никакой код.
Юзер вбил данные в гуе? Они уже лежат в грязной модели, вам не нужно вешать события и потом париться, если UX-дизайнер заменит селект на радиобаттон.
И наоборот, вы просто присваиваете грязной модели нужное значение, и гуй автоматически его обновляет, потенциально даже по хитрой схеме.
Ну вот пример из продакшена:
Целый слой, называемый контроллером, становится не нужен.
Вместо модели, контроллера и представления у вас есть модель, грязная модель представления и представление.
«Грязная» значит непроверенная и несохранённая.
Трюк в том, что грязная модель двунаправленно связана с представлением библиотекой, и вам вообще не нужно писать никакой код.
Юзер вбил данные в гуе? Они уже лежат в грязной модели, вам не нужно вешать события и потом париться, если UX-дизайнер заменит селект на радиобаттон.
И наоборот, вы просто присваиваете грязной модели нужное значение, и гуй автоматически его обновляет, потенциально даже по хитрой схеме.
Ну вот пример из продакшена:
<!-- ko if: id -->
<h1>Запись #<span data-bind="text: id"></span></h1>
<!-- /ko -->
<!-- ko ifnot: id -->
<h1>Новая запись</h1>
<!-- /ko -->
Целый слой, называемый контроллером, становится не нужен.
>>Что я имею в виду под MVVM?
Нет я не понял контекста, в котором вы это употребили (то ли за что-то, то ли против чего-то).
>>Трюк в том, что грязная модель двунаправленно связана с представлением библиотекой, и вам вообще не нужно писать никакой код.
>>Юзер вбил данные в гуе? Они уже лежат в грязной модели, вам не нужно вешать события и потом париться,
>>если UX-дизайнер заменит селект на радиобаттон.
Так это же классика GUI! Так делали со времен его изобретения (Smaltalk, Xerox Cedar, Oberon System). То что это переизобрели спустя 30 лет в JavaScript не делает ему никакой чести. В простых сценариях, да можно без контроллера, и что?
Нет я не понял контекста, в котором вы это употребили (то ли за что-то, то ли против чего-то).
>>Трюк в том, что грязная модель двунаправленно связана с представлением библиотекой, и вам вообще не нужно писать никакой код.
>>Юзер вбил данные в гуе? Они уже лежат в грязной модели, вам не нужно вешать события и потом париться,
>>если UX-дизайнер заменит селект на радиобаттон.
Так это же классика GUI! Так делали со времен его изобретения (Smaltalk, Xerox Cedar, Oberon System). То что это переизобрели спустя 30 лет в JavaScript не делает ему никакой чести. В простых сценариях, да можно без контроллера, и что?
Я дико извиняюсь, но хочу спросить, а что за девушка на первой фотографии? Кажется очень знакомой.
Вот знать бы ещё, что afterparty было
Ну для этого надо быть спикером, к сожалению. Хотя на CodeFest ( codefest.ru ) в последний год сделали так, что на афтепати может попасть любой кто заплатит заранее деньги
> Прикол этой [SWT] библиотеки состоит в том, что приложения, написанные на SWT всегда выглядят как родные приложения целевой платформы, просто потому, что используют родные контролы для отрисовки UI. Что не так с дефолтным UI для Java – Swing, где UI целевой платформы эмулируется (и не всегда хорошо).
Не соглашусь. На FreeBSD проблем со Swing гораздо меньше, чем с SWT (хотя и то, и это работает). Сложность состоит в том, что SWT нужно собирать под целевую платформу из исходников, а Swing — часть JRE. Сборка SWT же сопряжена с рядом условий, которые не касаются JRE, но касаются клиентского окружения.
И, да, использование SWT не всегда автоматически соответствует требованиям нативного HIG — для этого нужно писать дополнительный код.
> Я хочу добавить в Java-платформу еще одну модель распространения приложений, в которой приложение прилетает из сети по частям и по запросу, и первым прилетает из сети представление (пользовательский интерфейс). То есть я хочу устроить распространение клиентских Java приложений по типу Web приложений. Но это не Java WebStart (и не апплеты), где приложение загружается из сети целиком.
Распространение Web-приложения в виде .class-файлов вместо архива .jar для апплетов давно ли не работает?
С самого начала (с 1995 года) всё задумывалось работать «по запросу». Апплеты изначально начинали работать ДО того, как весь относящийся к ним код загружался в пользовательскую JVM. Это потом придумали упаковку всего кода апплета в ZIP и в JAR, чтобы не тратить время на установление нового соединения по HTTP 1.0 на загрузку очередного востребованного .class-файла. Но сейчас же наступают Web-сокеты, где накладные расходы на установку нового соединения минимальны, загрузка каждого следующего востребованного .class-файла почти ничего не стоит.
Не соглашусь. На FreeBSD проблем со Swing гораздо меньше, чем с SWT (хотя и то, и это работает). Сложность состоит в том, что SWT нужно собирать под целевую платформу из исходников, а Swing — часть JRE. Сборка SWT же сопряжена с рядом условий, которые не касаются JRE, но касаются клиентского окружения.
И, да, использование SWT не всегда автоматически соответствует требованиям нативного HIG — для этого нужно писать дополнительный код.
> Я хочу добавить в Java-платформу еще одну модель распространения приложений, в которой приложение прилетает из сети по частям и по запросу, и первым прилетает из сети представление (пользовательский интерфейс). То есть я хочу устроить распространение клиентских Java приложений по типу Web приложений. Но это не Java WebStart (и не апплеты), где приложение загружается из сети целиком.
Распространение Web-приложения в виде .class-файлов вместо архива .jar для апплетов давно ли не работает?
С самого начала (с 1995 года) всё задумывалось работать «по запросу». Апплеты изначально начинали работать ДО того, как весь относящийся к ним код загружался в пользовательскую JVM. Это потом придумали упаковку всего кода апплета в ZIP и в JAR, чтобы не тратить время на установление нового соединения по HTTP 1.0 на загрузку очередного востребованного .class-файла. Но сейчас же наступают Web-сокеты, где накладные расходы на установку нового соединения минимальны, загрузка каждого следующего востребованного .class-файла почти ничего не стоит.
>>Распространение Web-приложения в виде .class-файлов вместо архива .jar для апплетов давно ли не работает?
Апплетами давно никто не занимался (наверно с 1995 года) и эта технология поросла мхом. И я да, не видел распространения апплетов в виде класс-файлов. Если у вас более-менее серьезное приложение, с большими зависимостями от библиотек, то держать все это дело в виде рассыпухи классов на сервере — это через чур. Здесь нужна поддержка от сервера и я не видел стандартных серверных решений для этого дела и пишу сейчас свой (генеральная идея — это запустить IDEA или Netbeans по кускам из сети). Кроме того сервер может оптимизировать отдачу классов, отпрофилировав, какие классы реально нужны, и потом в нужном порядке отсылать их на клиент в виде хорошо упакованного стрима. Трафик будет меньше раз в пять по сравнению с передачей приложения целиком.
Апплетами давно никто не занимался (наверно с 1995 года) и эта технология поросла мхом. И я да, не видел распространения апплетов в виде класс-файлов. Если у вас более-менее серьезное приложение, с большими зависимостями от библиотек, то держать все это дело в виде рассыпухи классов на сервере — это через чур. Здесь нужна поддержка от сервера и я не видел стандартных серверных решений для этого дела и пишу сейчас свой (генеральная идея — это запустить IDEA или Netbeans по кускам из сети). Кроме того сервер может оптимизировать отдачу классов, отпрофилировав, какие классы реально нужны, и потом в нужном порядке отсылать их на клиент в виде хорошо упакованного стрима. Трафик будет меньше раз в пять по сравнению с передачей приложения целиком.
Кроме того, для того чтобы приложения прилетали действительно мгновенно, представление (UI) должно быть отделено от логики (как в вебе) и представление должно прилетать первым, а логика должна прилетать, когда пользователь начнет реально что-то делать с приложением (тыкать в кнопки). В Swing/SWT — представление как правило перемешано с логикой — по зависимостям классов (это кстати причина медленного старта Java приложений). На JavaFX и FXML так приложения уже можно писать, но пацаны-то не знают.
а кто-нибудь знает, когда будет видео с Joker конференции? там снимали все доклады, и к сожалению параллельно проходило много разных интересных докладов, и хотелось бы посмотреть их.
Они уже смонтированы, на самом деле. Сейчас отсматриваем, косяки выискиваем. Выложим в декабре.
habrahabr.ru/company/codefreeze/blog/202804/#comment_7013682
habrahabr.ru/company/codefreeze/blog/202804/#comment_7013682
Спасибо за отличную статью, Никита! Очень хочется увидеть видео докладов!
А чем Питер лучше чем Вашингтон, например?)
Да, был. В Вашингтоне есть одна очень клёвая фишка — это все государственные музеи бесплатны для всех!
Спасибо, Никита! Отличная статья! А я еще до Вашингтона так и не добрался.
Вышло видео с нашим выступлением на JUG.ru: Обзор возможностей Excelsior JET, Внутренняя архитектура Excelsior JET
Ссылки сверху случайно протухли, вот новые ссылки: Обзор возможностей Excelsior JET, Внутренняя архитектура Excelsior JET
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О чём молчит Joker. Рассказ-история о конференции