Графический интерфейс на Java. Есть ли в них смысл ?

Вот смотрю что люди на форме где то 40 процентов вопросов
задают по вопросам разработки графического дизайна на
яве. Уже работаю не первый год и работал не только на
винде но видел очень мало удачных примеров реализации
явоского графического интерфейся. Я не имею ввиду
веб-прилажения где ява работает прекрасно. Не хочется
возвращаться к этой теме но уже много раз обсуждали
то что Java IDE все немного тормознутые. А ведь их
пишут лучшие из лучших програмистов. Я не хочу
что бы меня упрекнули в том что я ругаю яву. Наоборот
я её очень люблю но server side которая работает
на Application Server. А вот насчёт графического
интерфейса. Есть ли в нём смысл и есть ли у него
будующее ?

0

а на чем же еще java программисту писат графический интерфейс

0

Я вот пишу GUI на свинге. Проблемы конечно есть, но отсутствие смысла среди них вроде не числится ;-) Конечно, невозможно написать гуй на Swing так, чтобы он конкурировал по производительности с писанным на VC, но я, к счастью, разрабатываю не среды разработки, а АРМ, а в них бОльшая часть работы (читай, большая часть задержек) делается на сервере.

0

Точку в этом деле ставить по-моему рано. Ее можно было бы поставить, если бы HTML формы совместно с браузерами закрывали вопрос о клиентском приложении, однако это не так. Если для внешних клиентов HTML формы вполне достаточно (так как, по определению, эти клиенты мало что могут), то построить 'АРМ' для Интранет и сотрудников фирмы выполняющих сложные действия с помощью HTML форм кажется невозможным. Если Вы это все-же сумеете сделать, возникает вопрос контроля ввода пользователей (как минимум). В случае HTML формы Вы можете либо проверять ввод с помощью Java Script, либо выполнять проверки на сервере приложений. Во втором варианте, когда пользователи в массовых количествах вводят сложные данные это решается с повышением нагрузки на сервер приложений и повышением сетевого трафика.

Что касается фразы 'А ведь их пишут лучшие из лучших програмистов.' Я как-то, по нужде, попытался посмотреть коды Oracle Enterprise Manager. Почему-то они мне не понравились. Они пишутся не одним человеком, а командами. Пишутся так, чтобы быть reusable в чистом виде. Такое впечатлеие, что основная забота не об эффективности, а о повышении скорости разработки и повторном использовании. Не всегда разумно используется наследование.

В том то и дело, что вопрос - каким должен быть клиент Интранет, в отличие от задач сервера приложений и сервера базы данных, остается открытым. Если нам web приложение нужно только для работы с внешними клиентами, то можно ограничится HTML формами. Однако очень заманчиво построить всю работу организации однородным образом. И тут мы натыкаемся на ограничения HTML форм.
Так что вопрос этот рано сдавать в архив.

0

Ну, раз уж пошла речь о 'сдаче в архив' вопроса о GUI, то тут нужно сказать, что он будет 'сдан в архив' только вместе с HTML и JavaScript. Обе эти технологии для программирования слабо пригодны. Все GUI с более или менее серьезной функциональностью, которые мне приходилось наблюдать, либо сразу были сделаны на апплетах/Swing&JNLP, либо начинались как HTML&JS приложения, а потом были переведены на Swing тем или иным способом.

Очевидно, что Swing - далеко не идеальное решение для сетевых приложений, но лучшие технологии (например, X-win) сейчас не популярны.

0

Свинг тормозной. Вообще скорость всего что касается графического интерфейса на яве лично меня не устраивает. А насчёт АРМ через веб приложение. То тут как в анекдоте про кошек 'Вы не любите кошек ? вы просто не умеете их годовить'. В основном весь ввод данных это заполнение форм. А генерация отчётов через веб приложения работает прекрасно. Едиснтвенное с чем я согласен это валидация данных. Частично её решает стратс через java-script или server-side код. Но в принципе в плане загрузки сервера это не такая уж большая проблема. Железо нынче дешёвое и купить пару неплохих серверов, объеденить их в кластер стоит того что бы не мучить конечного юзера жуткими(именно жуткими) задержками при работе с Java GUI (не web based). Конечно если у пользователя P4-2800 MultiThreading то ему уже наверно без разницы. Но если это обычные бухгалтер и у нег PII-400 (по советским меркам ещё очень приличный компьютер да и по американским такие же стоят у большинства клерков) - так вот для такого компьюетра Swing или AWТ это смерть.

0

Про смерть, это сильно. У нас AWT аплет нормально работает. Свинг действительно тормозит (по слухам). Мне кажется, впечатление о 'чудовищных' тормозах возникает потому, что многие используют готовые универсальные пакеты (тот же свинг). И если на серверной стороне готовые решения работают нормально (типовые задачи, хорошо отлажено и можно увеличить скорость за счет железа), то клиентские приложения всегда более индивидуальны. Поэтому универсальные пакеты в GUI труднее применять. Я могу предположить, что GUI чаще чем сервер программируют с 'чудовищными' ошибками.

0

To simplepilot:
Отвечаю по пунктам:
1. Не согласен, что GUI - это только заполнение форм. Существует немало задач, где гуй должен вразумительным (и незамедлительным) образом реагировать на значения, вводимые в какие-то поля. Эта реакция может заключаться не только в валидации, но и, например, в изменении внешнего вида формы. Вспомните хотя бы property panes. Широкое распространение wizards в последнее время вызвано как раз тем, что в HTML/JS все это сделать малореально. Но wizard далеко не всегда удобен.
2. Валидация данных через JS код - это принципиально неверный подход, поскольку JavaScript - принципиально неверный язык. Хотя бы из-за отсутствия контроля типов. Опять же, хотя бы из-за невозможности хоть как-то протестировать код до выполнения (вы где-нибудь видели unit tests для JS кода?). С другой стороны, валидация на сервере - обязательная вещь, но недостаточная. Основная причина в том, что верх изуверства - заставлять оператора набить целую форму, послать ее на сервер, и только после этого объявлять, что самое первое поле было заполнено неверно и из-за этого все нужно переделать.
3. На самом деле говорить о том, что мощный сервер дешевле умеренно толстых клиентов (всегда ?) неправомерно. Когда пользователей много, и сервер выполняет интенсивные вычисления (не такая уж редкая ситуация), покупка гранд-серверов становится накладной. Кластер многопроцессорных RISCов старших моделей от любого вендора легко потянет на миллион баксов. Скольким бухгалтерам можно сделать upgrade рабочих станций за эти деньги? Не даром ведь никак не желает умирать концепция распределенных вычислений, несмотря на все присущие ей проблемы.
4. GUI на Swing действительно получается довольно неторопливый, и этому есть две основные причины:
4.1. Архитектура Swing. Она обладает большой избыточностью, и это ведет к тормозам. Если уж совсем невмоготу, можно этот вопрос решить принципиально: Swing - не единственная GUI библиотека для Java. Для апплетов можно на худой конец пользовать AWT, для приложений есть Eclipse. Рискну предположить, что существует и еще что-нибудь.
4.2. Стиль прогрммирования. Java вообще провоцирует неаккуратное программирование. Это вызвано тем, что есть garbage collector, collection framework, и другие универсальные, удобные, но неэффективные фишки. В результате народ часто создает объекты там, где можно было бы обойтись простыми типами, memory allocation становится самой частой операцией в программе, приведение типов - вообще чуть ли не в каждой строке. Немалые иерархии классов создаются на всякий случай, совершенно без реальной необходимости. And on, and on... Я мог бы здесь привести примеры кода, которые можно было бы посчитать приколом, если бы они не работали в production. К сожалению, таких примеров полно.

Резюме: Вы не любите кошек? Вы просто не умеете их готовить!

0

Маленький личный опыт имею по созданию GUI со Swing.
Состряпал небольшую универсальную форму для запроса из базы даных, при этом описание расстановки полей формы хранится в базе данных. В этом же прилижении имеется самописаный графический редактор, в котором рисуются квадратики и полилинии, а коррдинаты точек 'просовываются' в базу. На машине с P-IV и 512 памяти запускаются одновременно : база данных Oracle, JDeveloper (а эта штука совсем не хилая по объемам), а также запускаю приложение и выполняю редактирование объектов - Drag & Drop и т.п. Никаких тормозов не заметил. Правда я принципиально не использую монстров верхнего уровня типа JTable и переписал кое-какие классы моделей документов, а также Layout Manager'ов, но это непринципиально.

0

На rsdn.ru как-то прозвучал крик души - у людей была таблица на AWT и она летала. Потом поступила команда перейти на свинг, знаменитый JTable. Все стало умирать, особенно при большом количестве строк. Однако большинство учебников раздел GUI начинают так: вот есть устаревший 'тяжеловесный' AWT, а мы сейчас подробненько рассмотрим современный 'легковесный' Swing.

0

Ну тут как я понимаю дело не в том что Свинг легковесный а в том что свинг имеет больше стандартных графических элементов (widget). AWT как изветсно ограничена набором графических элемнтов которые могут быть отображены самой простой поддерживающей Java операционной системе. Я когда то работал с AWT написал игру Lines в виде аплета и мне понравилось. Простенько но быстренько. А Swing я никогда не трогал но слышал что там могут быть тысячи (!) слушателей (listener) различных событий и все они требуют для себя память.

0

Извините по-поводу Listener'ов.
Если генерить их в GUI'вой графике, то Вам накидают кучу анонимных классов так, что мало не покажетя. А я ручками (один раз) прослушивателем сделал один объект (контроллер) и регистрирую его у всех порождающих события, а кто порождает события определяю по коду команды. Если аккуратно и со смыслом, то и Swing'и сгодятся.
Когда года три назад у меня на курсе по Oracle Александр Цибал флегматично сказал слушателям : поставьте 256 на клиента и Java будет нормально работать, все слушатели 'заржали' - тогда 256 на клиента было смешно. Завтра и 512 на клиенте будет не смешно, тогда может и JTable сгодится.

0

Кстати немного офтопик. А этот Oracle JDeveloper. Как он вообще ? а то они в последнее время активно его продвигают. Интересно услышать мнение людей которые с ним работали.

0

to simplepilot:
На самом деле проблема не в том, что каждый listener требует память, а в том, что каждое событие является объектом и требует память. Если учесть, с какой частотой они генерируются, например в том же JTable, получается действительно безобразие. И самое интересное, что это реально не нужно: асинхронная обработка событий (что-нибудь типа message system) в Swing отсутствует.

0

to simplepilot
Файл jdev905preview.zip (это последняя версия JDeveloper), который Вы можете скачать с www.oracle.com имеет вес в 250 Mб.
При развертывании никой инсталляции, настроек и переменных окружающей среды не требуется. При деинсталляции надо просто вытереть его из директории. Изначально он был построн по образу и подобию JBuilder, потому на него и похож. В его состав входит сервер приложений OC4J, прообразом которого явился сервер Orion. Так, что Вы можете смело стряпать в нем сервлеты и EJB. Масса 'Мастеров' - на каждый чих. Мне нравится простота создания разных архивов и доставка их на сервера приложений. Графическое редактирование не идеально, но редактор текстов и трассировщик неплохие. Имеются подсказки (например ошибок) уже на этапе набора текста, если кого-то это раздражает можно отменить. Легко встраиваются новые библиотеки. 'Мастера' также обеспечивают развертывание приложений на серверах приложений (не на всех, естественно). В последние версии встроена поддержка Ant и UML диаграмм - красота неописуемая ! Имеется еще целая куча 'прибамбасов', до которых у меня руки не доходят.
Я читаю курсы на этом инструменте и поэтому вынужден его использовать. Однако полагаю, что несмотря на то, что он 'тяжеловат' - во всем остальном очень неплох.

0

Вдогон по поводу медленности. Попробовал наш AWT апплет в браузере при включенном джава плагине. Скорость просто открытия всяких фреймов заметно упала по сравнению с режимом без плагина. Можно было бы советовать клиентам отключать плагин, да не у всех уже есть встроенная джава.

0

Согласен, Java 2D работает медленно, сам писал лабы по маш графика на ней - видно оптимизация под win API не особо крутая. Но я не соглашусь, что Swing будет медленный для приложений уровня предприятия (ERP). Как показатель - Oracle Forms Developer 9i создает приложения как Java апплеты, а Forms Developer позиционируется как средство поддержки Oracle Application.

0

Вот когда Oracle Application будет написан на .NET, тогда я поверю, что Java бесперспективна.

0

Вот пример полного комплекса написанного полностью на Java (за исключением драйверов оборудования). У них есть демо версия которую можно посмотреть (если не жалко трафика).
http://www.aamsystems.com/production/programms/lyrix/
Я запускал клиента на Celeron 1300 256Мб и никаких тормозов не наблюдал (если быть честным то подтормаживали графические планы с большим количеством объектов, но тут виноват и сервер т.к. он запускаля на значительно более слабой машине), а по нынешним меркам это весьма слабая машинка.

0

Обнаружил удивительную для себя вещь. AWT фреймы в апплете быстро открываются в браузере с явой 1.1 и в десятки раз медленнее с 1.4 Оказалось, что на этапе инициации тормозит операция add, которая добавляет панели в видимый фрейм. Решение проблемы оказалось простым - создаем фрейм и делаем его setVisible(false), потом добавляем все компоненты (которые тоже невидимы). Только после этого делаем фрейм и все его компоненты видимыми. Теперь все летает. Если сначала открытие фрейма занимало 3-5 сек, то теперь 100-200 мсек.

0