Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Недоповторили Silverlight. И кому теперь это нужно?
Интсрументы разработки для Linux аж зимой.И это печально.
В JFX 1.0 был же декларативный JSON-подобный синтаксис. Его убрали? Если да, то зачем?
Как бы я их понимаю, эту штука на Java, и в первую очередь хорошо бы было иметь возможность писать реализацию на Java, не все хотят или просто не могут себе позволить осваивать еще какой-то скрипт. Для гиков или просто интересующихся, ведется работа над возможностью работать с JavaFX с использованием скриптовых языков — JavaOne 2011: JavaFX 2.0 with Alternative Languages. Существуют мнения что наиболее удобной может быть связка JavaFX + Scala.
Мне кажется, основной причиной стала масса проблем, порожденных тем, что программировать можно на двух языках сразу. Сейчас поясню мысль:
1. Вопрос первичности. Запуск Java из JavaFX и запуск JavaFX из Java — это два разных запутанных подхода, каждый из которых напоминает конструкцию костылей. Когда все написано только на JFX script (не помню, если честно, как назывался этот декларативный язык, и фигурировало ли его название хоть где-то), таких проблем не возникает, но написать на нем что-то посложнее красивой демки, идущей в архиве с примерами, не так уж и просто.
2. Вопрос многопоточности и управления потоками. Весь код на JFX script выполнялся в одном потоке. Если же мы пытались что-то сделать из другого потока (например, обновить progressbar на JFX из отдельного потока, запущенного из Java-кода), то в зависимости от положения звезд и планет, а также погоды, у нас либо все успешно обновлялось, либо приложение вешалось намертво. Конечно, спасал javafx.lang.FX.deferAction(), но далеко не в 100% случаев. К тому же, мало охотников писать на каждый необходимый метод соответствующую обертку. Нормальную поддержку многопоточности и взаимодействия с Java-кодом, вероятно, так и не получилось сделать. А если судить по фидбэку, который в свое время был на uservoice, этот вопрос стал вопросом жизни и смерти для декларативного языка JFX.
3. Вопрос мнимой силы биндинга. По-моему, сила биндинга переменных превратилась в слабость, т.к. постоянно нужно держать в уме, что куда биндится, и две схемы биндинга (прямую и обратную). Это создавало массу дополнительной бесплатной головной боли.
4. Вопрос эффективности JavaFX API в целом и генерируемого байткода в частности. Если декомпилировать класс, скомпилированный из JFX-кода, можно увидеть, что даже самый простой код приводит к генерации статического класса с цепочкой вызовов, идущих глубоко в недра API JavaFX script, через многочисленные классы-обертки, классы-контроллеры и т.д. Производительности при таком раскладе ожидать не приходится. Gоневоле задумываешься, когда на незамысловатой демке одно ядро не самого старого двухъядерного процессора (JavaFX 1.1 — 2009, Core2Duo T7100 — 2007) целиком отдается под нужды этой самой демки.
Именно поэтому переход на Java логичен, и его нужно только приветствовать. Жаль, конечно, что он произошел слишком поздно.
Естественно, все вышеперечисленное является всего лишь моим ИМХО.
1. Вопрос первичности. Запуск Java из JavaFX и запуск JavaFX из Java — это два разных запутанных подхода, каждый из которых напоминает конструкцию костылей. Когда все написано только на JFX script (не помню, если честно, как назывался этот декларативный язык, и фигурировало ли его название хоть где-то), таких проблем не возникает, но написать на нем что-то посложнее красивой демки, идущей в архиве с примерами, не так уж и просто.
2. Вопрос многопоточности и управления потоками. Весь код на JFX script выполнялся в одном потоке. Если же мы пытались что-то сделать из другого потока (например, обновить progressbar на JFX из отдельного потока, запущенного из Java-кода), то в зависимости от положения звезд и планет, а также погоды, у нас либо все успешно обновлялось, либо приложение вешалось намертво. Конечно, спасал javafx.lang.FX.deferAction(), но далеко не в 100% случаев. К тому же, мало охотников писать на каждый необходимый метод соответствующую обертку. Нормальную поддержку многопоточности и взаимодействия с Java-кодом, вероятно, так и не получилось сделать. А если судить по фидбэку, который в свое время был на uservoice, этот вопрос стал вопросом жизни и смерти для декларативного языка JFX.
3. Вопрос мнимой силы биндинга. По-моему, сила биндинга переменных превратилась в слабость, т.к. постоянно нужно держать в уме, что куда биндится, и две схемы биндинга (прямую и обратную). Это создавало массу дополнительной бесплатной головной боли.
4. Вопрос эффективности JavaFX API в целом и генерируемого байткода в частности. Если декомпилировать класс, скомпилированный из JFX-кода, можно увидеть, что даже самый простой код приводит к генерации статического класса с цепочкой вызовов, идущих глубоко в недра API JavaFX script, через многочисленные классы-обертки, классы-контроллеры и т.д. Производительности при таком раскладе ожидать не приходится. Gоневоле задумываешься, когда на незамысловатой демке одно ядро не самого старого двухъядерного процессора (JavaFX 1.1 — 2009, Core2Duo T7100 — 2007) целиком отдается под нужды этой самой демки.
Именно поэтому переход на Java логичен, и его нужно только приветствовать. Жаль, конечно, что он произошел слишком поздно.
Естественно, все вышеперечисленное является всего лишь моим ИМХО.
Спасибо, все разложили по полочкам. Соглашусь со всем. Разве что многопоточность, это проблема не только javaFX а всех GUI-фреймворков в целом
всё несколько проще и в то же время сложнее. Я работал с JavaFX когда она ещё называлась F3.
Главная проблема это команда JavaFX. Они занимаются не тем чем надо. Например, у них в команде нет художника (вот так, рисуют скины и кнопки без художника, понятно какой будет результат).
Главная проблема это команда JavaFX. Они занимаются не тем чем надо. Например, у них в команде нет художника (вот так, рисуют скины и кнопки без художника, понятно какой будет результат).
Когда же наступит день, когда под джава появится нормальный функциональный красивый и быстрый UI framework. Я сам люблю джаву и наверное единственное, что мне в ней не нравится- это проблема с интерфейсом. Сам после заявления на JavaOne скачал это приложение с компонентами (Ensemble), но после того, как скролл рваными движениями отозвался на мышку я понял, что праздника не будет, по крайней мере в этот раз. Очень надеюсь, что JFX доведут до ума. Это будет здорово…
если красивый — как измерить красоту интерфейса? нужна ли красота энтерпрайзу? про скорость — думаю не стоит, все таки есть примеры удобных и качественных десктоп приложений написанных на java.
Энтрепрайз — он такой, красота может и понадобиться, особенно когда желательно поразить заказчика красивыми финтифлюшками.
увы порой да. но лучше избегать таких требований.
заказчика лучше приятно удивлять другими вещами:
1. исполнительность
2. качество
3. сроки
4. прозрачность
blahblah
заказчика лучше приятно удивлять другими вещами:
1. исполнительность
2. качество
3. сроки
4. прозрачность
blahblah
Apple доказал что красивый интерфейс можно очень дорого продать
и много корпораций гигантов полностью перешли на продукцию Apple? shell, exxon, toyota, gm — кто? дизайнерские отделы возможно :)
Сейчас RIA это очередной тренд. Большинство производителей ПО не просто клепают софт а нанимают дизайнеров чтоб софт был вебдваноль«ным, как это в простонародье обозначают.
Даже, например, такой унылый монстр как SAP R3 озаботился красивым внешним видом, что уж говорить про прикладной софт расчитанный на широкий круг пользователей.
Даже, например, такой унылый монстр как SAP R3 озаботился красивым внешним видом, что уж говорить про прикладной софт расчитанный на широкий круг пользователей.
Это все будет, но после выигрыша тендера =)
Хорошая анимация – это уже большой плюс к юзабилити, делает понятным, откуда что и куда приходит.
К сожалению, этого тут пока нет. В отличие от Adobe Flex, например.
К сожалению, этого тут пока нет. В отличие от Adobe Flex, например.
> 4. прозрачность
Ну или полупрозрачность, на крайний случай :)
Ну или полупрозрачность, на крайний случай :)
Чем плох Jambi, например?
Сдается мне, что суть javafx не в том чтобы сделать красивый UI из коробки, а дать возможность программисту работать параллельно и независимо с дизайнером, подобно тому как это происходит в веб программировании. Использование css на это намекает. А использование fxml значит, что обязательно будут визуальные редакторы для верстки стилей и дизайна. Шаблоны и стили оформления от сообщества скоро появятся, если эта технология будет востребована. В свинге этот принцип уже пытались использовать. Но создание новых скинов в свинге просто физически не по силам простым дизайнерам. И наверное, создать новый фреймворк с нуля проще, чем вносить в свинг такие кардинальные изменения. Да и свинг по своему уже целостен, лаконичен и закончен как проект. Свинг, как и AWT, это часть ядра и будут поддерживаться до скончания веков. А JavaFX это новый виток эволюции. Но насколько он будет успешен, будем посмотреть. Теоретически JavaFX должна вернуть Java в интернет, как в старые добрые временна java applets.
Можно ли назвать это релизом, если Java FX SDK нельзя скачать без регистрации?
JavaFX надо было делать 10 лет назад. Все, паровоз уехал. Сейчас идет повсеместный отказ от плагинной архитектуры и шаг в сторону мобильных. Куда они будут его ставить — совершенно непонятно. Что плохо:
— Где полноценный мигратор с 1.3 на 2.0? На разрекламированном в свое времяJavaFX script сделаны реальные проекты. И что теперь с ними делать?
— Помимо JRE еще просят установить еще один плагин. Количество пользователей (клиентов => бабла), имеющих терпение что-то там устанавливать, чтобы посмотреть демку уменьшится раз в 5.
— Обещали апаратное ускорение в prism. Незаметно.
— Версии под «все платформы» (а это десктопный Win/Mac/Lin) появятся только к концу 2012 года (если не произойдет ничего странного, например Apple выпилит Java)
И вообще, JavaFX может быть адекватно заменен Html5 + SVG.
— Где полноценный мигратор с 1.3 на 2.0? На разрекламированном в свое времяJavaFX script сделаны реальные проекты. И что теперь с ними делать?
— Помимо JRE еще просят установить еще один плагин. Количество пользователей (клиентов => бабла), имеющих терпение что-то там устанавливать, чтобы посмотреть демку уменьшится раз в 5.
— Обещали апаратное ускорение в prism. Незаметно.
— Версии под «все платформы» (а это десктопный Win/Mac/Lin) появятся только к концу 2012 года (если не произойдет ничего странного, например Apple выпилит Java)
И вообще, JavaFX может быть адекватно заменен Html5 + SVG.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JavaFX изнутри