Developer Preview под Mac OS и альфа версия под Linux. Стабильная Linux версия ожидается в 2012.

странно, зачем это подтвердил ЛОР

Нет. В ведроиде этой штуки нет. А оракл на ведроид наезжает из-за другой штуковины: у Ларри как всегда желание урвать бабла халявно, вот и решил, что можно наехать.

А Moonlight не рипнуулся?

> почетное место в катафалке занимает Visage - мертвый наследник FXScript

fixed.

я имел ввиду что выглядит так что эту штуку можно развить в ведроид при достаточных амбициях.

> Оно жрет как трактор,и памяти и процессора

Ну между прочим некий товарищ Adam Bien утверждает, что «Because JavaFX's small footprint it is going to be used as base for embedded devices as well».

>Adam Bien утверждает, что «Because JavaFX's small footprint it is going to be used as base for embedded devices as well».

уже «Была продемонстрирована работа JavaFX на планшетах под управлением Windows, Android и iOS»
Java One — день второй

http://javafx.com/roadmap/#4

JavaFX will be officially tested and supported on Ubuntu — the most popular Linux distribution on desktop PCs — but is expected to run 'as is' with other Linux distributions. JavaFX for Linux is planned for release in the end of 2012.

Ура, бубунта, а то выкладывают джаву в рпм-ах, для кого спрашивается?

думаю не станет популярна...

>А разработчики могут и под windows писать, какая разница. Разница в том, что подовляющие большинство хороших разработчиков работают под linux.

>Разница в том, что подовляющие большинство хороших разработчиков работают под linux.

под маком, если уж на то пошло...

Хорошие разработчики используют подходящую систему, а не удобную им лично.

> Хорошие разработчики используют подходящую систему, а не удобную им лично.
Не путайте систему под которой будет работать разрабатываемое приложение и систему на которой идет разработка.

Во первых-пример старый,джаваскрипты нерабочие.
Во вторых javaFX обратно не совместим,т.е. рабочая программа на 1.2 не будет работать на 1.3 ,как и 1.3 на 2.0 (т.е. переписав программу в соответствии с новыми изменениями и скомпиляв ее-будет работать(код там есть))
В третих-все приложения javafx обязательно подписываются(с версии 1.3),там сертификат на пол года(максимум кажись),т.е. через пол года аплет перед запуском будет спрашивать-разрешить/нет запуск...но перед вызовом вопроса-аплет запускается,дает исключение(непомню как оно завется),потом идет вопрос(со своим исключанием),т.е. очевидно что 99% программ не отрабатывают исключение (что сертефикат истек),половина из них вывалится сразу,еще до вопроса,другая половина-проигнорирует исключение и будет пытаться работать дальше-что невозможно(исключения будут падать на этапе отрисовки элементов)...

>В третих-все приложения javafx обязательно подписываются(с версии 1.3),там сертификат на пол года(максимум кажись),т.е. через пол года аплет перед запуском будет спрашивать-разрешить/нет запуск...

пруф или не было

Не успеваешь скачать и поиграться с дико глючащими примерами, а здесь уже подходит к концу тематический срач... Лор - торт!

Какое отношение к Linux имеет версия, для Linux несуществующая?

Да ещё и оказывается, что даже старые версии — исключительно x32, а о x64 можно даже и не мечтать.

>базирующийся

Базируются военные, а технологии основываются.

> я правильно понял, что тебе больше нравится сказать 20 раз префикс svg, чем один раз сказать inlude_svg?

Мне нравится, когда есть и директива «include SVG», и возможность внедрения. Так сделано, например, в XHTML/HTML5. Можно сделать <img src=«image.svg»/>, а можно, за счет использования пространств имен, внедрить SVG прямо в HTML. Вы не догадываетесь, зачем это сделано, и какие преимущества имеет второй вариант? Подумайте. Пускай это станет вашим домашним заданием.

Вообще, удивляюсь и сочувствую, насколько у вас бедная фантазия как у разработчика. (Впрочем, надеюсь, что с фантазией у вас все в порядке, и дело лишь в скудости опыта.) Иначе вы бы сразу придумали десятки применений пространствам имен в XML. Например, вы можете задать сложную графическую картинку, в которой некоторые элементы должны быть активными, то есть отзываться на движения мыши. Или вообще жить своей жизнью. Вы вводите свой атрибут в приватном пространстве имен, при помощи которого и задаете все эти тонкости. При этом XML остается легитимным, валидным и соответствующим схеме (в данном случае - схемам). Вы можете использовать свой layout manager, и управлять его поведением при помощи кастомных атрибутов; такой механизм использует, например, MigPane. Итак, в самых общих словах: namespaces - это расширение семантики данных, при сохранении свойств well-formed и schema valid.

XPath

даааа, и для этого совершенно обязательно выдумывать новый язык!

навигацию по нему можно делать стандартными языковыми средствами

Скажите, почему же тогда возникают проекты типа JXPath, OGNL? Хорошо, пускай вы утверждаете следующее:

конечно, говноязыки типа явы не позволяют определять свои операторы

...но есть же Scala, где операторы можно определять. И вы предлагаете создать Scala DSL для навигации по XML DOM? При условии того, что уже давно существуют зрелые, стабильные реализации XPath?

internal DSL намного лучше, чем новый язык

Скажите, вам никто еще не говорил, что у вас DSL головного мозга?

я правильно понимаю, что ты хочешь нас заставить поддерживать отдельно от основной ООП-программы правила валидации? в то время как на порядки проще проводить валидацию уже имеющимся кодом

Я никого не хочу ничему заставлять. Валидация по схеме и валидация программная должны дополнять друг друга. Нет смысла программно валидировать структурные свойства, такие как mandatory element, или element multiplicity, или соответствие простым паттернам. С этим гораздо лучше справится парсер, имеющий в своем распоряжении XML-схему.

Вообще, батенька, каков смысл вашего этого махания кулаками и брызганья слюной? В чем тут сермяжная сущность - прийти в тему о JavaFX, прицепиться к упоминанию XML и произвести подрыв бочки с дерьмом?

XML - говно и не нужен!
Namespaces - не нужны, будем инклюдить все подряд!
XPath - не нужен, будем замусоривать язык костыльной, слабоспецифицированной, бажной, медленной реализацией половины XSLT!
DTD и XSD - не нужно, будем все валидировать программно!

Мне кажется, вы в пылу дискуссии забыли о ее предмете - JavaFX. XML не рассматривается здесь как самостоятельное явление (да, в абсолютном контексте он не лишен недостатков), но лишь, подчеркиваю, как механизм для декларативного задания пользовательских интерфейсов и векторной графики. В этом контексте вышеперечисленные механизмы имеют несомненные преимущества, как было показано выше. Вы заявляете, что есть механизмы более эффективные и изящные? Так озвучьте же их! Что вы предлагаете в качестве более правильной альтернативы FXML? Вы не стесняйтесь, выкладывайте.

А то, знаете ли, на пустобреха смахиваете.

> То есть Java сама по себе с этой задачей не справляется, из-за чего и приходится городить костыли?

Отчего же. Справляется, и очень неплохо. Но всегда есть возможность сделать еще лучше. К тому же, на дворе XXI век, и в Oracle понимают, что нужны новые технологии и новые подходы. Именно поэтому Java нисколько не рискует превратиться в Delphi своего времени.

Батенька, вы бы почаще заглядывали в ленту активности проекта Visage. Коммиты там происходят значительно чаще, чем вы думаете.

Все ждал, вдруг кто спросит, но не дождался. Kuka, а что вы преподаете? И где? (если где не секрет).

> В чем тут сермяжная сущность - прийти в тему о JavaFX, прицепиться к упоминанию XML и произвести подрыв бочки с дерьмом?

добро пожаловать на лор!

XML - говно и не нужен! Namespaces - не нужны, будем инклюдить все подряд! XPath - не нужен, будем замусоривать язык костыльной, слабоспецифицированной, бажной, медленной реализацией половины XSLT! DTD и XSD - не нужно, будем все валидировать программно!

я утверждал совсем не это; на будущее — не включай больше бредогенератор

Что вы предлагаете в качестве более правильной альтернативы FXML? Вы не стесняйтесь, выкладывайте. А то, знаете ли, на пустобреха смахиваете.

сюрприз!

чтобы не быть пустобрехом, мне вовсе не обязательно выкладывать какие-то альтернивы чему-то — мне достаточно находить пустые баззворды и несоответствия реальности в твоих постах

на самом деле, конечно, у меня есть мнения по всей линейке «язык программирования / язык разметки / система контроля версий / ide»

я их полностью выложу когда сочту нужным

а пока продолжим обсуждать твои заявления (тем более, что на мои идеи ты пока не высказал ничего более разумного, чем пустое «Скажите, вам никто еще не говорил, что у вас DSL головного мозга?»)

кстати, я не совсем Ъ и глянул-таки на спецификацию fxml

1. ты всерьез называешь декларативным язык, в который включены куски кода?

<Button text=«Click Me!» onAction=«java.lang.System.out.println('You clicked me!');»/>

2. ты всерьез ведешь разговор о xml-валидации fxml формата? как ты будешь валидировать вышеприведеный пример?

3. вот эта хрень:

<fx:define><ToggleGroup fx:id=«myToggleGroup»/></fx:define>

...

<RadioButton text=«A» toggleGroup=«$myToggleGroup»/>

из-за лишнего знака доллара не похожа на xml ref  — и ты рассказываешь тут про стандарты?

(я, конечно, мог пропустить соответствующий высер w3c в его общем поносе стандартизации, и если это все же xml ref, то исправления принимаю)

З.Ы. примеры брались из пдф-ки вот отсюда: http://fxexperience.com/2011/07/introducing-fxml/

> К тому же, на дворе XXI век, и в Oracle понимают, что нужны новые технологии и новые подходы.

это слова какого-то маркетоида, а вовсе не преподавателя

чувак, ты на оракл евангелистом работаешь?

З.Ы. мое мнение — для java fx из имеющегося говноспектра говноязыков выбрали не самое плохое, а возможно даже и самое хорошое под их условия; но тот (ненавистный мне) hype, который сопровождал сан и который, похоже, перешел по наследству ораклу, плюс твои подозрительно восторженные реплики явно требуют взывать все те бочки с говном, что производит мой заводик :-)

> Вообще, удивляюсь и сочувствую, насколько у вас бедная фантазия как у разработчика.

на весь этот твой пост тоже будет ответ

З.Ы. на всякий случай — я не лиспер

AdamBien Adam Bien
#JavaFX is going to be COMPLETELY open source and it will be proposed to the JCP.

>Свинг же хорош тем, что неплохо выглядит на винде, где и так разброд и шатание во внешнем виде приложений, а также худо-бедно выглядит на маках. При условии, что используется нативный look&feel. Выглядит похоже на нативные приложения.

А с Gtk LaF и на линуксе