Здравствуйте, Steamus, Вы писали:

S>PS: Когда я говорю — не слабее флеша, я имею в виду визуальные эффекты. Ибо всё остальное это совсем другой мир. А что касается ...красочного web... c этим пока непонятно. Понятно что оно не встраивается как флеш. В планах вроде было превращение визуальной части в векторную графику для WEB. Но, разумеется, пока это немножко мутно и фантастично. Посему, на сегодняшний день, это очень мощная библиотека создания стандалон-клиентов.
А шрифты уже исправили? Смотрел несколько версий — все шрифты размытые как в Java 1.4/Java 5.

А>Я думаю что у явы нет будущего на десктопе.

А>Ниша Явы это нагруженные сервера, бэкэнды, энтерпрайз и т.д.

Дай затянуться, братиш. Я тоже хочу туда улететь, где ты. Где нет явы на десктопе, где виндовз полностью переписана на C#, где Дельфи и Кларион забыты как страшные сны

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Steamus, Вы писали:

S>>PS: Когда я говорю — не слабее флеша, я имею в виду визуальные эффекты. Ибо всё остальное это совсем другой мир. А что касается ...красочного web... c этим пока непонятно. Понятно что оно не встраивается как флеш. В планах вроде было превращение визуальной части в векторную графику для WEB. Но, разумеется, пока это немножко мутно и фантастично. Посему, на сегодняшний день, это очень мощная библиотека создания стандалон-клиентов.
B>А шрифты уже исправили? Смотрел несколько версий — все шрифты размытые как в Java 1.4/Java 5.

В версии 2.1 сделали родное сглаживание. Где-то там в январе. Они вообще довольно быстро шуршат и на всё реагируют. Есть активный форум где можно всё спросить и пожаловаться.

https://forums.oracle.com/forums/forum.jspa?forumID=1385

Здравствуйте, Steamus, Вы писали:



S>Ява уже довольно давно превосходно работает на десктопе. Причём на своём родном "встроенном" Swing. Сомневающие могут запустить IntelliJ IDEA. И много корпоративных приложений так написано. Другое дело, что Sun ближе к своему закату уже совсем "лыко не вязала". Они только к версии 1.6 стали прочухивать, что графику нужно чуть дооптимизировать, Look and feel новый сделать и показывать это, показывать! Ото все их примеры клиентов выглядели корчеобразно. Аляповатый бордюр, первый попавшийся шрифт, простоватые иконки. В итоге, внушили всем, что клиент на джаве это мрак. И это при том, что свинг может быть очень красив и быстр. Даже пошустрее чем WinForms. Затем они зачём-то начали JavaFX с неким скриптовым языком. Который не сильно продвигали и в итоге ни то ни сё.

Хм. А мне тот скрипт показался даже симпатичен. Уж всяко получше xml.
Но первый FX был настолько сырым, что использовать его было невозможно вообще никак.

Здравствуйте, Steamus, Вы писали:



S>Да он то может и классный, но вот тут действительно никто не понял — зачем? Декларативность обеспечивает XML. Ну вот он и остался. А динамическая часть на джава. Там где нет декларативности. Ну вродеж это разумно? Не?

Увы, xml все-таки проигрывает в читабельности — очень много мусора.

А с JTable другая проблема. Он сложный для освоения формоклепателем среднего уровня.

Здравствуйте, Blazkowicz, Вы писали:

B>Я не приувеличиваю. Я хорошо знаю Swing и уже заманался оптимизировать и бороться с отрисовкой красивостей, которые хотят дизайнер и заказчик.
Ну, мне сложно судить. Мне вообще сложно представить корпоративного заказчика, который бы тщательно домогался от интерфейса неких таких мистичесеских возможностей которые Свинг с легкостью не предоставит. Разве что вы разрабатываете игры на Свинге.

S>>Поверю наслово, у вас, вероятно, инсайдерская информация. Хочу только заметить что ни JBuilder ни NetBeans не смотря на таких же дисциплинированых разработчиков, подобных достижений в Swing GUI не имеют.
Никакого инсайда. Банально — опыт. В двух словах, на пальцах. Глянем на два известных продукта одного класса: Хром и Файерфокс. Два браузера. Там нет джавы.

Хром: можно спорить о юзабилити, но все диалоги спроектированы единообразно и элегантно: нормальные отступы, красивые бордюры, одинаковые кнопки, спланированное использование пространства.

Лиса: грубые бордюры, разного размера кнопки (две рядом стоящие кнопки имеют разный размер), маленькая дистанция между надписью и краем кнопки, аляповатое распределение пространтсва в диалогах...

Щё раз — там нет джавы. Это просто квалификация менеджера проекта. Как итог, визуально, внутри, Фокс выглядит как студенческая поделка. Но ведь вроде же сильный и популярный инструмент? А такие ляпы. И терпят. Не жужжат.

B>Что-нибудь с биндингом на объекты или таблицы, постраничной позагрузкой (а не построчной). Ибо каждый раз приходится изобретать заново.
Нда, хотелось бы. Навскиду и сам не понимаю — почему бы таки и не сделать некий мляцко мощный грид что бы все утёрлись. Ну всем же, халера, нужен. Козлы в общем. Тут — да.

B>Возможно. Но зачем оракл позиционирует его как решение для web в первую очередь?
Вроде как бы не так что бы и позиционирует. Но конкретно упоминает. Ну, что поделать с веб-цунами? Подростки и манагеры спускают от Веба по нескольку раз за раз. Ну нельзя не воткнуть Веб как тарджет для анонса. Нельзя! Партия в целом и генсек в частности не пропустят. Это серъёзная беда. Я согласен.

B>Нет MDI. Какие-то сложности с модальными диалогами. Что-то ещё было, сразу не вспомню.
Ай, ну кому нужен MDI в 21 веке? Обойдутся без расстановки окон черепицей.

S>>>Поверю наслово, у вас, вероятно, инсайдерская информация. Хочу только заметить что ни JBuilder ни NetBeans не смотря на таких же дисциплинированых разработчиков, подобных достижений в Swing GUI не имеют.
S>Никакого инсайда. Банально — опыт. В двух словах, на пальцах. Глянем на два известных продукта одного класса: Хром и Файерфокс. Два браузера. Там нет джавы.

Хм. А вот у меня как-раз инсайдерская информация есть. И по ней — UI в Idea сделан весьма сложно и с кучей трудозатрат.
Там куча всего переписано, куча внутренних сложных хаков, куча издевательств над деревом обработки событий, некоторое количество мест вида "боимся заглядывать" и т.п. Впрочем, исходные коды есть — так что можно самому посмотреть, насколько там все "просто".

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>В Swing не хватает готового каркаса. Т.е. готового проекта приложения со всеми фенечками, от dockingа до управления actions и автоматическим обновлением. Я уж не говорю про биндинг. Это есть в RCP, но у SWT плохо с корпоративными компонентами, да и вообще тяжеловат в разработке.
ДФ>Все это можно набрать через отдельные продукты третьих фирм, но для этого уже надо быть очень неплохим специалистом.

Ну вы сами по сути на всё и ответили. Была идея сделать каркас-поддержку стандартного проекта — проект назывался Swing Application Framework. Глуповатое название, ибо влёт не понятно чем отличается от Swing Framework. Ну, в Сане реально дауны в маркетинге сидели. Но, не пошёл. Обещали включить в SDK позже. Не уверен что включат. Но смысл простой — джава SDK не может охватить абсолютно всё. Как бы это кому-то и не хотелось. Рантайм будет просто абсурдного размера. И ребятам постоянно приходится делать выбор что и где сечь. Ну а продвинутые корпоративщики всегда могут цеплять платформу RCP-Эклипс руками.

Steamus //

Здравствуйте, Дельгядо Филипп, Вы писали:


S>>>>Поверю наслово, у вас, вероятно, инсайдерская информация. Хочу только заметить что ни JBuilder ни NetBeans не смотря на таких же дисциплинированых разработчиков, подобных достижений в Swing GUI не имеют.
S>>Никакого инсайда. Банально — опыт. В двух словах, на пальцах. Глянем на два известных продукта одного класса: Хром и Файерфокс. Два браузера. Там нет джавы.

ДФ>Хм. А вот у меня как-раз инсайдерская информация есть. И по ней — UI в Idea сделан весьма сложно и с кучей трудозатрат.
ДФ>Там куча всего переписано, куча внутренних сложных хаков, куча издевательств над деревом обработки событий, некоторое количество мест вида "боимся заглядывать" и т.п. Впрочем, исходные коды есть — так что можно самому посмотреть, насколько там все "просто".

Там продукт очень сложный и мощный. "Простым" не окажется ни один UI, на чём бы он не был реализован. Будь то Qt, SWT, MFC... Visual Studio также часто тормозит. Вот это я и хотел сказать.

Здравствуйте, e.thrash, Вы писали:

ET>Спрос огромный на ява программеров.
ET>а что пишут нового на яве?

ET>желательно примеры известных продуктов, сайтов.

ET>зы. А сайты вообще пишут на яве сейчас, кроме одноклассников?

IBM/Rational. У нас тут почти все на Java пишут.

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, Дельгядо Филипп, Вы писали:

S>Там продукт очень сложный и мощный. "Простым" не окажется ни один UI, на чём бы он не был реализован. Будь то Qt, SWT, MFC... Visual Studio также часто тормозит. Вот это я и хотел сказать.

Хм, а что там такого концептуально сложного? Почему вообще такой UI должен быть сложным? Actions (недоделанные), Docking (плохой), несколько достаточно простых Master-Detail, несколько своих компонент (зачастую сомнительных)? Т.е. да, на чистом Swing (Qt, MFC etc) делать крайне сложно, но это скорее проблема инструментов, нежели сложность собственно UI.

На том же RCP сделать что-то подобное на порядок проще (впрочем, это вообще одна из печалей индустрии — почему IntelliJ все еще держатся за свою платформу вместо разработки надстройки над Eclipse. Хотя, гм, понятно почему... ).

Собственно, одна из причин, по которой Java мало на десктопе — отсутствие законченных и стандартных каркасов уровня приложения. RCP и Netbeans Framework завязаны на IDE (и у обоих куча своих проблем), аналогичный проект от Spring пока затих, JCP на каркас тоже так и не доведен до окончательной стадии. В fx тоже начали с примочек для дизайнеров, а не с каркаса приложения для корпоративных приложений.
В общем, ужас-ужас-ужас...

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>На том же RCP сделать что-то подобное на порядок проще (впрочем, это вообще одна из печалей индустрии — почему IntelliJ все еще держатся за свою платформу вместо разработки надстройки над Eclipse. Хотя, гм, понятно почему... ).
Ну да. Инжинеры из IntelliJ посмотрели внутри Eclipse, ужаснулись и сказали "закопайте обратно".

ДФ>Собственно, одна из причин, по которой Java мало на десктопе — отсутствие законченных и стандартных каркасов уровня приложения. RCP и Netbeans Framework завязаны на IDE (и у обоих куча своих проблем), аналогичный проект от Spring пока затих, JCP на каркас тоже так и не доведен до окончательной стадии. В fx тоже начали с примочек для дизайнеров, а не с каркаса приложения для корпоративных приложений.
На Java нет вменяемых GUI-фреймворков. Точнее, есть — Android UI.

ДФ>На том же RCP сделать что-то подобное на порядок проще (впрочем, это вообще одна из печалей индустрии — почему IntelliJ все еще держатся за свою платформу вместо разработки надстройки над Eclipse. Хотя, гм, понятно почему... ).

Потому что SWT некроссплатформенно, еле-еле есть порт на Windows и Linux, под тем же MacOS X не работает, под ту же Win x64 только недавно порт сделали, не прошло и 10 лет с появления x64 в 2003 году

ДФ>Собственно, одна из причин, по которой Java мало на десктопе — отсутствие законченных и стандартных каркасов уровня приложения.

Собственно главная причина не в этом, а в том что запуская новое приложение пользователь запускает новую жавамашину, если приложений 5 то половина памяти съедена только JVM. На сервере проще, там один сервер — один инстанс JVM, который крутит jboss или GF. а приложения на десктопе не умеют шарить одну общую JVM

Здравствуйте, Аноним, Вы писали:

А>Потому что SWT некроссплатформенно, еле-еле есть порт на Windows и Linux, под тем же MacOS X не работает, под ту же Win x64 только недавно порт сделали, не прошло и 10 лет с появления x64 в 2003 году
Странно. Вроде недавно кто-то хвастался что даже под маком оно работает. Но неудобное для программирования страшно.

А>Собственно главная причина не в этом, а в том что запуская новое приложение пользователь запускает новую жавамашину, если приложений 5 то половина памяти съедена только JVM. На сервере проще, там один сервер — один инстанс JVM, который крутит jboss или GF. а приложения на десктопе не умеют шарить одну общую JVM
Полностью согласен. Только в Java 5 гуёй хоть немного озаботились. Время запуска оптимизируют и всё такое. Но, в целом, всё ещё косяков хватает. Теже оптипизации скорости загрузки могут не работать, если вместо полноценной JRE на клиенте будет JRE встроеная в приложение. GC может иногда доставлять.

Здравствуйте, Аноним, Вы писали:


А>Собственно главная причина не в этом, а в том что запуская новое приложение пользователь запускает новую жавамашину, если приложений 5 то половина памяти съедена только JVM. На сервере проще, там один сервер — один инстанс JVM, который крутит jboss или GF. а приложения на десктопе не умеют шарить одну общую JVM.

Если бы умели, то это был бы полный трындец. Одно кривое приложение, и во всех остальных OutOfMemory. При этом, даже если у всех разные класслоадеры(что логично), все равно можно легко добраться до данных другого приложения. На сервере это не проблема, ибо список задеплоенных приложений заранее задан, и админ о нем знает(и там нет вероятности встретиться со зловредом извне), на десктопе же это стрем.

Здравствуйте, Blazkowicz, Вы писали:


B>Полностью согласен. Только в Java 5 гуёй хоть немного озаботились. Время запуска оптимизируют и всё такое. Но, в целом, всё ещё косяков хватает. Теже оптипизации скорости загрузки могут не работать, если вместо полноценной JRE на клиенте будет JRE встроеная в приложение. GC может иногда доставлять.

GC вообще не очень хорош как идея для десктопных приложений. Ибо со свопом он не дружит, заставляя во время прохода по дереву объектов вытаскивать кучу страниц из него, что вызывает сильные тормоза при нехватке памяти на машине.

Здравствуйте, Eugeny__, Вы писали:

А>>Собственно главная причина не в этом, а в том что запуская новое приложение пользователь запускает новую жавамашину, если приложений 5 то половина памяти съедена только JVM. На сервере проще, там один сервер — один инстанс JVM, который крутит jboss или GF. а приложения на десктопе не умеют шарить одну общую JVM.

E__>Если бы умели, то это был бы полный трындец. Одно кривое приложение, и во всех остальных OutOfMemory. При этом, даже если у всех разные класслоадеры(что логично), все равно можно легко добраться до данных другого приложения. На сервере это не проблема, ибо список задеплоенных приложений заранее задан, и админ о нем знает(и там нет вероятности встретиться со зловредом извне), на десктопе же это стрем.

На JavaOne говорили, что в оптимизация работы нескольких JVM на одной машине в роадмапе есть, где то в 9 или даже позже.

Здравствуйте, GarryIV, Вы писали:

GIV>На JavaOne говорили, что в оптимизация работы нескольких JVM на одной машине в роадмапе есть, где то в 9 или даже позже.
Это звучит как "года через четыре у нас появится очередная заплатка, которая, может быть, уберет пару проблем в работе десктопных приложений". И что нам делать эти 4 года. 8)
JavaFX анонсировали в 2007, выпустили в 2008 и до сих пор его никто не торопиться использовать. Такими темпами железо реально догонит JVM, что её и не нужно будет оптимизировать.
Графика, интегрированая в CPU, SSD и вуаля, Java на клиенте не такая уж и тормозная.

Здравствуйте, Blazkowicz, Вы писали:

А>>Потому что SWT некроссплатформенно, еле-еле есть порт на Windows и Linux, под тем же MacOS X не работает, под ту же Win x64 только недавно порт сделали, не прошло и 10 лет с появления x64 в 2003 году
B>Странно. Вроде недавно кто-то хвастался что даже под маком оно работает. Но неудобное для программирования страшно.

Да, работает. Но там в нашем проекте оно особо пока не проверяется. Запустилось, что-то отрисовалось — и ладно.