Когда говорят о междвездных перелетах, всегда ограничиваются фантазиями в рамках релятивистской теории как наиболее близкой к реальности. Дабы исправить положение добавлю от нексолько более фантастических вариантов.
1. Квантовая телепортация. Обширная тема для фантазии. Перенос информации о структуре в другую точку пространства и воссоздание оной в новом месте. Теория относительности ограничивает скоростью света лишь перемещение энергии и материальных носителей, тогда как в квантовой теории информация распространяется мгновенно (или существует вне пространства-времени — тут можно долго философствовать). Ни КМ ни ТО не накладывает ограничений на мгновенное перемещение нематериальных сущностей, коей является информация.
2. Структура пространства Вселенной в некоторых моделях быть очень необычной и не ограниченной тремя измерениями + временем. Когда путь по «традиционным» направлениям исчисляется световыми годами, окольными дорогами он может занять величину, сравнимую с планковской длиной.
3. Как ни странно, пространство представляет собой лишь удобную сущность для множества моделей. Однако существуют модели, где пространство является вторичной сущностью, порождаемое самой материей как совокупность ее собственных степеней свободы. Примером может служить любая компьютерная 3D-игра. Игровая сцена состоит из множества объектов, каждый из которых имеет собственные атрибуты координат. При этом память компьютера не содержит трехмерного пространства как такового ни в каком виде. Иллюзию простратства создают алгоритмы рендеринга и симуляции физики движения. Понятно что в таком мире, найдя способ поменять координаты объекта в обход алгоритма механики, объекты можно легко телепортировать.
4. Эзотерический вариант, но для полноты приведу. Обнаружится, что сознание не является продуктом мозга, а существует вне его как некая нематериальная субстанция, способная воспринимать информацию мгновенно и на любом расстоянии. Пока эта тема является сильно «желтой», однако проводимые научные исследования по изучению экстрасенсорных способностей дали определенные результаты.
Jboss 7 радикально отличается от предыдущих версий и, надо сказать, не всегда в лучшую сторону. Было необходимо настроить вызов ejb remote — это сплошной гемор. Клиент попросту не работает — отваливается через раз. К тому же требует спецнастроек на стороне клиента. Вызов ejb из другого сервера я так и не смог настроить — плюнул и сделал все на вебсервисах.
Я юзаю serviio на ubuntu. Один недостаток: убунта уже давно не обновляет версию ффмпег в своих реозиториях. Поэтому для нормальной работы приходится делать собственную сборку.
Интересно, я до этого Atmosphere использовал. Во множестве подобных фреймворков почему-то отсутствуют нормальные средства отлавливания событий life-cycle для коннекшна. То есть такую простую вещь как обновляемый список онлайн пользователей приходится реализовывать через одно место. Дело усложняется, если необходимо добавить прозрачный реконнект.
Все-равно кое-что остается за кадром. Хорошо, была операционная оболочка Windows 3.x, OS/2 не тянула на тот момент по системным требованиям. Однако массовый старт Windows как операционной системы начался только с версии Win95 (не придирайтесь к деталям — по крайней мере она так позиционировалась). К тому моменту у чикаги системные требования были практически такими же, как и у OS/2, да и среднепользовательские компьютеры уже были в состоянии их удовлетворить. OS/2 3.0 Warp 3.0 вышла на год раньше Win95, была продвинутей по всем парамерам, стабильнее, запускала программы Windows 3.x. Тем не менее это не помешало Microsoft выпустить монстра Win95 и пересадить на него всех пользователей.
P.S. у меня на компе стояла OS/2 3.0 Warp, а в последствии OS/2 4.0 Merlin почти до 98 года. Пришлось снести, т.к. в универе перешли на Office 95, а Word 6.0 не понимал его формата. Так что основная заслуга Microsoft не винда, а именно пресловутый офис. Люди не используют операционную систему, люди используют программы.
Дело в том, что цикл обновления коммерческих серверов апликаций жутко медленный. До сих пор еще ни один из моих клиентов не использует сервер с JEE6: везде это либо WAS 7, WL 10 или JBoss 5. И мигрировать на новый профайл никто особо не собирается. Так что пока еще JEE7 увидит свет, пока на него мигрируют продукты и компоненты, пока это все смогут задвинуть клиенту — пройдут годы.
По поводу упрощения не согласен. JEE — это изначально неправильная и неудобоваримая вещь, далекая от реальных нужд и задач. Переход на аннотации отодвинули его смерть. То, куда стоит двигать JEE — это в сторону embedded runtime с программной конфигурацией, так, чтобы он больше смахивал на фреймворк, нежели на сервер. А шлифование API — это дело десятое.
Пройдет еще лет этак 5-7, прежде чем это появится в коммерческих серверах приложений у клиентов. Один вопрос остается непонятным — неужели существуют реальные задачи, где была бы острая необходимость в новом API, и которые не могут быть решены с уже существующим? Я не усмотрел никаких радикальных нововведений, кроме некой удобоваримости. Но уж коле пишете по jee, забудьте про эстетику.
Этот случай как раз я и имел ввиду, например реализация ORM при помощи делегатов. Или более сложный кейс, когда есть одна модель, и требуется динамически менять ее поведение в зависимости от контекста: на сервере замепить в DB, на транспортном уровне мепить в XML, а на клиенте добавить возможность отслеживать изменения (PropertyChangeListeners). На данный момент это решается достаточно сложно при помощи магии фреймворков, AOP, проксирования, code enhancement, etc… Если добавить базовые возможности AOP в язык, такие как interceptor-ы для свойств, было бы на порядок проще реализовывать подобные решения.
Думаю, в подавляющем большинстве случаев все свойства класса будут использовать один и тот же делегат. Поэтому было бы удобно указывать его один раз на уровне описания класса. Как вариант: если класс имплементирует интерфейс делегата, то он сам является делегатом для своих свойств, а также для свойств всех его потомков. Концепт делегата в этом случае играет роль интерсептора для свойств. Таким образом, мы можем создать целую domain model с заданным функционалом, описав делегат только для базового класса.
Смотрел я это видео раньше. Антон призывает использовать средства адекватные задаче. В большинстве случаев действительно хватает простых средств, предоставляемых Java, фреймворком и парой open-source библиотек. Но, «мужики-то не знают», и по инерции выбирают сложную архитектуру для решения любой задачи. На работе меня неоднократно спрашивали: «а какой сервер приложений вы используете в проекте»? Людям было непросто объяснить, что приложение было standalone и пускалось из командной строки (Apache Camel+ActiveMQ).
Я много работал с J2EE, и могу с уверенностью сказать, что это сложная, медленная, неудобоваримая и в 95% случаев абсолютно бесполезная куча соглашений с перманентно глючной имплементацией. При том, что в J2EE продумана и описана архитектура, в ней совершенно за кадром остается методология разработки. Цикл по типу Insert trace-compile-package-deploy-test-see logs-undeploy мне напоминает прошлый век. Arquillian и JRebel — это извращения, призванные на борьбу с ветряными мельницами. Поэтому, я выдвину тезис: любую задачу, которую вы решаете с помощью J2EE я решу без нее в 10 раз быстрее, дешевле, проще и надежнее. Практически ВСЕ технологии J2EE, которые Вы используете либо не нужны для решения задачи, либо имеют более простую альтернативу.
> Мое мнение: пакетная обработка графики и веб плохо уживаются. Гонять туда-сюда гигабайты файлов: терять время и дорого платить за трафик.
Я не совсем про это. Сервер запускать именно локально а ГУИ рисовать в браузере. При желании все это можно сделать в один клик по иконке: запускается сервер и встроенный в окно браузер без URLя, вкладок и меню. Количество библиотек с виджетами для веба зашкаливает. Взять хотя бы SmartClient или ExtJS. Для любителей Java есть врапперы для GWT. Кроме того, битмапы и императивную графику можно рисовать на Canvas.
> Может вам такие приложения попадались? Например, отзывчивость интерфейса не была приоритетом при разработке?
Нет, это общее впечатление многих пользователей от любого свинг-интерфейса. Netbeans/Idea ощутимо лагают, интерфейс Eclipse более тормозной, но ощущения лагания нет. Еще тормознутость многих апликаций хорошо заметна, когда меняешь лейаут, например тащя JSplitPane. Лейаут в свинге пересчитывается крайне долго, и еще дольше, если количество объектов достаточно большое.
> Нативный L&F в JDK 6 был просто замечательный
Я пришел из тех времен, когда LAF был Metal и Basic. С грехом пополам сделали мимикрию под XP. Потом под Висту с опозданием на год. Последним запилили Nimbus, который ужасен. Сторонние LaF были еще ничего (Alloy, Plastic). В последние годы высказывались идеи по поводу адаптивных лейаутов: это когда например Label выравнивается по font baseline с текстом в следующем TextField, или когда автоматически отключаются бордеры внутри других контейнеров с бордерами. В Substance LaF были потуги на этот счет. Но массово все это так и не было доведено до ума.
> Например, на дерево объектов очень плохо ложатся интерфейсы с огромным количеством записей.
Согласен. С деревом MVC реализовывать неудобно. Но можно. Html, Windows, SWT живут как-то с обычными таблицами, не MVC. Строки для huge-таблицы можно генерить динамически при скроллинге даже в модели с деревом.
> И даже со всеми ухищрениями не получается достичь производительности императивной отрисовки.
А вот здесь не согласен. Умный рендерер может эффективно отсекать невидимые узлы дерева, плюс автоматически делать оптимизации рендеринга: статичное поддерево может быть прозрачно закешировано в виде битмапа. Плюс такие плюшки как декларативная анимация, лееры, эффекты, аффинные преобразования, фильтры, etc… Кроме того, декларативный рендерер позволяет использовать композитные возможности низлежащей платформы (OpenGL, DirectX): лееры и Z-order компонентов могут управляються нативно, тогда как в Swing их каждый раз всех приходится перерисовывать в правильном порядке на канве Graphics2D. Ну и самое главное — асинхронный рендеринг отдельно от Event Dispatch.
> Не понял этого высказывания. Приведете пример?
Рисуя что-то ручками в Graphics2D постоянно приходилось профилировать и думать как это лучше оптимизировать. Большинство оптимизаций сводилось к банальному битмап-кешированию сложных отрисовок, что декларативный рендерер делает автоматически. Другая рекомендуемая оптимизация — брать из Graphics2D clip-регион и не рендерить объекты, которые находятся за его пределами. И еще over 9000 рекомендаций. И все ручками.
Один вопрос — какова цель использовать именно платформу osgi? Уверен, что RAP/RWT существует не только ввиде бандла, но и как обычная библиотека. Просто мне интересно на каких реальных задачах целесообразно использовать osgi? Как мне кажется, когда у нас есть жуткий компот из различных модулей и все это должно ворочаться вместе, не мешая друг другу, например как в Eclipse. Для того, чтобы пустить Jetty + EclipseLink + RAP/RWT достаточно простенького maven-проекта.
Программирую на свинге с 96 года (swing-1.1.1, когда еще не был включен в JRE). На мой взгляд, плохая реализация сомнительной идеи (мимикрировать под нативные ОС). Свинг полностью изжил себя лет 7 назад, когда из Сана ушла вся swing-команда: Chet Haase, Romain Guy, Alex Potochkin, Kirill Grouchnikov, Amy Fowler, и др. Java полностью потеряла позиции на рынке десктопов, даже JavaFX теперь уже не спасет. Императивная отрисовка графики, разработанная в 80-х кодах, изжила себя лет 10 назад и во всех системах была заменена декларативным описанием дерева объектов как JavaFX, SVG, HTML. Кроме того, основным недостатком свинга являлись:
— скудный набор компонентов.
— любой шаг влево связан с жуткими сложностями. Я задолбался в сотый раз писать TableCellRenderer для нормального отображения данных в таблице.
— нет нормального Layout-а. GridBagLayout создавался для IDE tools, но никак не для человека. Точку поставил только MigLayout.
— нет нормального LAF. Мимикрия под системные просто ужасна. Был интересный LAF — Substance.
— общая тормознутость интерфейса. Я не знаю почему так получается, но свинговый интерфейс любой апликации лагает. С SWT такой проблемы нет.
Один вопрос: а почему Вы не выбрали архитектуру веб клиента? Например Embedded Jetty + GWT/SmartGWT или Vaadin?
Ниже прокомментирую некоторые ваши высказывания:
> На сегодняшний день в QML и JavaFX исправлены описанные проблемы. Поэтому, если вы готовы работать со сценическим графом, то вам стоит взять их на тест-драйв.
Интерфейс на JavaFX лагает как слайдшоу на моей рабочей тачке, даже банальный скроллинг. Не ведитесь на удочку Oracle, обещающей светлое будущее JavaFX. Поезд ушел 7 лет назад. Все разговоры о портировании JFX на мобильные завораживают, но, пардон, где Java под iOS/Android? Теперь у нас есть HTML5/Canvas/CSS3/SVG.
> Очень много библиотек.
80% из них уже давно не поддерживается.
> Вся отрисовка hardware-accelerated. Любое Swing-приложение отрисовывается на GPU, от разработчика ничего не требуется.
Это не так. Акселерировано толька отрисовка примитивов и опции с растрами. Поскольку разработчик сам пишет код отрисовки компонентов, то он ответственен за то, чтобы акселерация использовалась по-максимому. Известен такой хак как двойная буферизация. У меня есть книга Swing Hacks по всем подобным хакам свинга, которая занимает 300 страниц.
> Swing – только hardware accelerated.
Это тоже не верно. Swing лежит на AWT, который в свою очередь использует Toolkit, который использует graphics pipeline. Последний по возможности использует ресурсы машины. Так что swing работает и на машинах без акселерации, и на remote desktop, только отрисовка долгая, поскольку транслируется весь растр окна.
> Не все объекты BufferedImage используют аппаратное ускорение.
BufferedImage вообще не accelerated. Это просто растр в памяти. ТруЪ accelerated — это VolatileImage и CompatibleImage. При рендеринге BufferedImage по возможности внутренне создается VolatileImage (или CompatibleImage), данные которого лежат на видеокарте. Битность BufferedImage имеет значение только при переводе в VolatileImage: если она у них совпадает, перевод делается на порядок быстрее. Битность VolatileImage зависит от девайса: например X Window не поддерживала альфа канал (не знаю как в JDK7 с ее новой rendering pipeline)
> При доступе к данным растра BufferedImage, картинка перестает рисоваться через GPU.
Не при доступе, а при изменении данных связанный VolatileImage перестает быть валидным до тех пор, пока BufferedImage не отрисуется заново. Поэтому, если растр часто меняется, лучше сразу пользоваться VolatileImage. Единственная деталь — VolatileImage не гарантирует сохранность данных и в любой момент может быть очищет видеокартой.
> Нет встроенной анимации и полу-прозрачности.
Есть (был) проект SwingX, который расширял компоненты, добавляя дополнительные возможности по отрисовке (Painter).
Идея модели в целом правильная, но предположение не совсем точное. Любое т.н. «путешествие во времени» генерирует возмущение модели. Это возмущение имеет характер затухающей моды. Однако частота и амплитуда моды могут сильно варьироваться в зависимости от того, сколько бифуркативных точек было затронуто. Иногда возмущение бывает слишком «сильным» для данного объема модели, и тогда вместо затухания мы получаем расхождение и совершенно альтернативную реальность. Извините за пространные рассуждения, но, думаю, идея понятна. Имеется четкий математический аппарат, способный оценить устойчивость мат. модели к возмущениям.
В квантовой механике повсеместно используется принцип Эверетта об альтернативных реальностях. Но это лишь классическое приближение, чтобы было понятно большинству. Гораздо сложнее осознать, что никакой фиксированной реальности нет, кроме наблюдаемой нами непосредственно или косвенно. Реальность не линия, а облако с максимальной плотностью в точке наблюдателя, где все ненаблюдаемые исходы событий существуют и реализуются одновременно «здесь» и «сейчас». С этой точки зрения большинство возмущений (путешествий во времени) останутся незаметными и не затронут «облако реальности» наблюдателя.
У нас в доме был случай. Женщина на улице дала поздатыльник или вроде того своему ребенку за то, что тот не слушался. Нашлись добрые соседи и позвонили в полицию. В итоге ребенка у нее забрали.
Достаточно одного звонка ребенка в службу, обидевшегося, что ему не подарили планшетник, чтобы у родителей начались серьезные проблемы. Нагрянет армия соцработников с единственной целью — найти хоть что-нибудь, до чего можно было бы докопаться. Но, благо, пока в Испании нет такого п-ца как в Штатах.
Есть такой принцип «не усложняй!». Если геттер-сеттер выполняет тривиальную задачу, что вы тестируете в этом случае? Поведение платформы (.NET)? Мою IDE, сгенерировавшую к полям геттеры-сеттеры (JAVA)? Вот когда у вас появится необходимость нетривиальной реализации свойства, тогда и пишите к нему тест. Его наличие как раз и будет указывать, что свойство делает еще что-то, кроме простой операции с полем.
А теперь просто факты для размышления.
1. В генной инженерии для модификации используются плазмиды и вирусы. ГМО, созданные таким спопобом несут остаточную генетическую информацию — фрагменты этих вирусов и плазмид, которая может проявится позже. Очистить геном на 100% от «следов инженерии» пока не представляется возможным.
2. ГМО, распространяясь в естественной среде, постепенно вытесняют оригинальные организмы. Хорошо это или плохо — тема для спора. Основной аргумент: ГМО может отличаться серией параметров, которые не имеют значения в использовании продукта человеком, но могут быть критичны для соблюдения баланса экосистем в естественной среде.
3. Контроль и производители. Пока производство ГМО не приняло массовый характер (многие производители, отсутствие монополий), все-таки стоит опасаться появления на рынке некачественых или потенциально опаных ГМО. На данный момент ГМО — достаточно узкая область, где возможен сговор между производителем и контролирующими структурами (все знают неприятную историю с Монсанто и американскими фермерами, вынужденными закупать каждый год на посев).
4. Все-таки эффект недостаточно исследован. Дело не в том, что ВСЕ ГМО потенциально опасны, ибо ненатуральны, а в том, что за последнее время появляется огромное количество методов и технологий получения ГМО. И есть вероятность, что очередная технологическая новинка создаст негативный эффект. А негативный эффект стратегически важных продуктов, как злаковые, проявившийся через несколько поколений (скажем, 10 лет) может полностью уничтожить пищевую промышленность и смежные отрасли, спровоцировав массовый голод. Не даром некоторые отмечают, что ГМО может оказаться бомбой замедленного действия.
Java — это не только и не столько язык, сколько платформа: JVM, библиотеки, фреймворки, сборщики, продукты, etc. И это дерьмо постоянно растет, но нисколько не совершенствуется. И проблема в том, что сейчас на голой джаве уже практиески никто не пишет. Все современные архитектурные шаблоны на java ведут к наворачиванию технологий распуханию аппликации. Вот пример для простой вебапликации: JBoss+SpringMVC+EJB+JPA+JSP+Maven+Arquillian. И это не предел. Естественно что разработка со всем этим дерьмом будет еле ворочаться. Но тем не менее, сама компиляция в Java очень быстрая.
P.S. Хочется писать лаконичнее — возьмите к примеру Groovy, XTend или Kotlin.
Скорей всего эта реализация была взята из JRockit-а, ибо Оракл давно собиралась перенести в JVM «лучшие черты JRockit».
А вот чисто теоретиццки, возникала ли когда-нибудь идея сделать native имплементацию части классов rt.jar? Всякие байткод компиляторы типа excelcior не в счет. Именно ручками на сях.
1. Квантовая телепортация. Обширная тема для фантазии. Перенос информации о структуре в другую точку пространства и воссоздание оной в новом месте. Теория относительности ограничивает скоростью света лишь перемещение энергии и материальных носителей, тогда как в квантовой теории информация распространяется мгновенно (или существует вне пространства-времени — тут можно долго философствовать). Ни КМ ни ТО не накладывает ограничений на мгновенное перемещение нематериальных сущностей, коей является информация.
2. Структура пространства Вселенной в некоторых моделях быть очень необычной и не ограниченной тремя измерениями + временем. Когда путь по «традиционным» направлениям исчисляется световыми годами, окольными дорогами он может занять величину, сравнимую с планковской длиной.
3. Как ни странно, пространство представляет собой лишь удобную сущность для множества моделей. Однако существуют модели, где пространство является вторичной сущностью, порождаемое самой материей как совокупность ее собственных степеней свободы. Примером может служить любая компьютерная 3D-игра. Игровая сцена состоит из множества объектов, каждый из которых имеет собственные атрибуты координат. При этом память компьютера не содержит трехмерного пространства как такового ни в каком виде. Иллюзию простратства создают алгоритмы рендеринга и симуляции физики движения. Понятно что в таком мире, найдя способ поменять координаты объекта в обход алгоритма механики, объекты можно легко телепортировать.
4. Эзотерический вариант, но для полноты приведу. Обнаружится, что сознание не является продуктом мозга, а существует вне его как некая нематериальная субстанция, способная воспринимать информацию мгновенно и на любом расстоянии. Пока эта тема является сильно «желтой», однако проводимые научные исследования по изучению экстрасенсорных способностей дали определенные результаты.
P.S. у меня на компе стояла OS/2 3.0 Warp, а в последствии OS/2 4.0 Merlin почти до 98 года. Пришлось снести, т.к. в универе перешли на Office 95, а Word 6.0 не понимал его формата. Так что основная заслуга Microsoft не винда, а именно пресловутый офис. Люди не используют операционную систему, люди используют программы.
По поводу упрощения не согласен. JEE — это изначально неправильная и неудобоваримая вещь, далекая от реальных нужд и задач. Переход на аннотации отодвинули его смерть. То, куда стоит двигать JEE — это в сторону embedded runtime с программной конфигурацией, так, чтобы он больше смахивал на фреймворк, нежели на сервер. А шлифование API — это дело десятое.
Я много работал с J2EE, и могу с уверенностью сказать, что это сложная, медленная, неудобоваримая и в 95% случаев абсолютно бесполезная куча соглашений с перманентно глючной имплементацией. При том, что в J2EE продумана и описана архитектура, в ней совершенно за кадром остается методология разработки. Цикл по типу Insert trace-compile-package-deploy-test-see logs-undeploy мне напоминает прошлый век. Arquillian и JRebel — это извращения, призванные на борьбу с ветряными мельницами. Поэтому, я выдвину тезис: любую задачу, которую вы решаете с помощью J2EE я решу без нее в 10 раз быстрее, дешевле, проще и надежнее. Практически ВСЕ технологии J2EE, которые Вы используете либо не нужны для решения задачи, либо имеют более простую альтернативу.
Я не совсем про это. Сервер запускать именно локально а ГУИ рисовать в браузере. При желании все это можно сделать в один клик по иконке: запускается сервер и встроенный в окно браузер без URLя, вкладок и меню. Количество библиотек с виджетами для веба зашкаливает. Взять хотя бы SmartClient или ExtJS. Для любителей Java есть врапперы для GWT. Кроме того, битмапы и императивную графику можно рисовать на Canvas.
> Может вам такие приложения попадались? Например, отзывчивость интерфейса не была приоритетом при разработке?
Нет, это общее впечатление многих пользователей от любого свинг-интерфейса. Netbeans/Idea ощутимо лагают, интерфейс Eclipse более тормозной, но ощущения лагания нет. Еще тормознутость многих апликаций хорошо заметна, когда меняешь лейаут, например тащя JSplitPane. Лейаут в свинге пересчитывается крайне долго, и еще дольше, если количество объектов достаточно большое.
> Нативный L&F в JDK 6 был просто замечательный
Я пришел из тех времен, когда LAF был Metal и Basic. С грехом пополам сделали мимикрию под XP. Потом под Висту с опозданием на год. Последним запилили Nimbus, который ужасен. Сторонние LaF были еще ничего (Alloy, Plastic). В последние годы высказывались идеи по поводу адаптивных лейаутов: это когда например Label выравнивается по font baseline с текстом в следующем TextField, или когда автоматически отключаются бордеры внутри других контейнеров с бордерами. В Substance LaF были потуги на этот счет. Но массово все это так и не было доведено до ума.
> Например, на дерево объектов очень плохо ложатся интерфейсы с огромным количеством записей.
Согласен. С деревом MVC реализовывать неудобно. Но можно. Html, Windows, SWT живут как-то с обычными таблицами, не MVC. Строки для huge-таблицы можно генерить динамически при скроллинге даже в модели с деревом.
> И даже со всеми ухищрениями не получается достичь производительности императивной отрисовки.
А вот здесь не согласен. Умный рендерер может эффективно отсекать невидимые узлы дерева, плюс автоматически делать оптимизации рендеринга: статичное поддерево может быть прозрачно закешировано в виде битмапа. Плюс такие плюшки как декларативная анимация, лееры, эффекты, аффинные преобразования, фильтры, etc… Кроме того, декларативный рендерер позволяет использовать композитные возможности низлежащей платформы (OpenGL, DirectX): лееры и Z-order компонентов могут управляються нативно, тогда как в Swing их каждый раз всех приходится перерисовывать в правильном порядке на канве Graphics2D. Ну и самое главное — асинхронный рендеринг отдельно от Event Dispatch.
> Не понял этого высказывания. Приведете пример?
Рисуя что-то ручками в Graphics2D постоянно приходилось профилировать и думать как это лучше оптимизировать. Большинство оптимизаций сводилось к банальному битмап-кешированию сложных отрисовок, что декларативный рендерер делает автоматически. Другая рекомендуемая оптимизация — брать из Graphics2D clip-регион и не рендерить объекты, которые находятся за его пределами. И еще over 9000 рекомендаций. И все ручками.
— скудный набор компонентов.
— любой шаг влево связан с жуткими сложностями. Я задолбался в сотый раз писать TableCellRenderer для нормального отображения данных в таблице.
— нет нормального Layout-а. GridBagLayout создавался для IDE tools, но никак не для человека. Точку поставил только MigLayout.
— нет нормального LAF. Мимикрия под системные просто ужасна. Был интересный LAF — Substance.
— общая тормознутость интерфейса. Я не знаю почему так получается, но свинговый интерфейс любой апликации лагает. С SWT такой проблемы нет.
Один вопрос: а почему Вы не выбрали архитектуру веб клиента? Например Embedded Jetty + GWT/SmartGWT или Vaadin?
Ниже прокомментирую некоторые ваши высказывания:
> На сегодняшний день в QML и JavaFX исправлены описанные проблемы. Поэтому, если вы готовы работать со сценическим графом, то вам стоит взять их на тест-драйв.
Интерфейс на JavaFX лагает как слайдшоу на моей рабочей тачке, даже банальный скроллинг. Не ведитесь на удочку Oracle, обещающей светлое будущее JavaFX. Поезд ушел 7 лет назад. Все разговоры о портировании JFX на мобильные завораживают, но, пардон, где Java под iOS/Android? Теперь у нас есть HTML5/Canvas/CSS3/SVG.
> Очень много библиотек.
80% из них уже давно не поддерживается.
> Вся отрисовка hardware-accelerated. Любое Swing-приложение отрисовывается на GPU, от разработчика ничего не требуется.
Это не так. Акселерировано толька отрисовка примитивов и опции с растрами. Поскольку разработчик сам пишет код отрисовки компонентов, то он ответственен за то, чтобы акселерация использовалась по-максимому. Известен такой хак как двойная буферизация. У меня есть книга Swing Hacks по всем подобным хакам свинга, которая занимает 300 страниц.
> Swing – только hardware accelerated.
Это тоже не верно. Swing лежит на AWT, который в свою очередь использует Toolkit, который использует graphics pipeline. Последний по возможности использует ресурсы машины. Так что swing работает и на машинах без акселерации, и на remote desktop, только отрисовка долгая, поскольку транслируется весь растр окна.
> Не все объекты BufferedImage используют аппаратное ускорение.
BufferedImage вообще не accelerated. Это просто растр в памяти. ТруЪ accelerated — это VolatileImage и CompatibleImage. При рендеринге BufferedImage по возможности внутренне создается VolatileImage (или CompatibleImage), данные которого лежат на видеокарте. Битность BufferedImage имеет значение только при переводе в VolatileImage: если она у них совпадает, перевод делается на порядок быстрее. Битность VolatileImage зависит от девайса: например X Window не поддерживала альфа канал (не знаю как в JDK7 с ее новой rendering pipeline)
> При доступе к данным растра BufferedImage, картинка перестает рисоваться через GPU.
Не при доступе, а при изменении данных связанный VolatileImage перестает быть валидным до тех пор, пока BufferedImage не отрисуется заново. Поэтому, если растр часто меняется, лучше сразу пользоваться VolatileImage. Единственная деталь — VolatileImage не гарантирует сохранность данных и в любой момент может быть очищет видеокартой.
> Нет встроенной анимации и полу-прозрачности.
Есть (был) проект SwingX, который расширял компоненты, добавляя дополнительные возможности по отрисовке (Painter).
В квантовой механике повсеместно используется принцип Эверетта об альтернативных реальностях. Но это лишь классическое приближение, чтобы было понятно большинству. Гораздо сложнее осознать, что никакой фиксированной реальности нет, кроме наблюдаемой нами непосредственно или косвенно. Реальность не линия, а облако с максимальной плотностью в точке наблюдателя, где все ненаблюдаемые исходы событий существуют и реализуются одновременно «здесь» и «сейчас». С этой точки зрения большинство возмущений (путешествий во времени) останутся незаметными и не затронут «облако реальности» наблюдателя.
Достаточно одного звонка ребенка в службу, обидевшегося, что ему не подарили планшетник, чтобы у родителей начались серьезные проблемы. Нагрянет армия соцработников с единственной целью — найти хоть что-нибудь, до чего можно было бы докопаться. Но, благо, пока в Испании нет такого п-ца как в Штатах.
1. В генной инженерии для модификации используются плазмиды и вирусы. ГМО, созданные таким спопобом несут остаточную генетическую информацию — фрагменты этих вирусов и плазмид, которая может проявится позже. Очистить геном на 100% от «следов инженерии» пока не представляется возможным.
2. ГМО, распространяясь в естественной среде, постепенно вытесняют оригинальные организмы. Хорошо это или плохо — тема для спора. Основной аргумент: ГМО может отличаться серией параметров, которые не имеют значения в использовании продукта человеком, но могут быть критичны для соблюдения баланса экосистем в естественной среде.
3. Контроль и производители. Пока производство ГМО не приняло массовый характер (многие производители, отсутствие монополий), все-таки стоит опасаться появления на рынке некачественых или потенциально опаных ГМО. На данный момент ГМО — достаточно узкая область, где возможен сговор между производителем и контролирующими структурами (все знают неприятную историю с Монсанто и американскими фермерами, вынужденными закупать каждый год на посев).
4. Все-таки эффект недостаточно исследован. Дело не в том, что ВСЕ ГМО потенциально опасны, ибо ненатуральны, а в том, что за последнее время появляется огромное количество методов и технологий получения ГМО. И есть вероятность, что очередная технологическая новинка создаст негативный эффект. А негативный эффект стратегически важных продуктов, как злаковые, проявившийся через несколько поколений (скажем, 10 лет) может полностью уничтожить пищевую промышленность и смежные отрасли, спровоцировав массовый голод. Не даром некоторые отмечают, что ГМО может оказаться бомбой замедленного действия.
P.S. Хочется писать лаконичнее — возьмите к примеру Groovy, XTend или Kotlin.
А вот чисто теоретиццки, возникала ли когда-нибудь идея сделать native имплементацию части классов rt.jar? Всякие байткод компиляторы типа excelcior не в счет. Именно ручками на сях.