Какие недостатки есть у Java Swing GUI Framework? [закрыто]

11

Я использовал Java Swing для некоторых настольных приложений. Но я не так часто использовал другие GUI-структуры, поэтому не могу их сравнить.

Определенно есть некоторые вещи, которые мне нравятся в Swing, и некоторые, которые мне не нравятся, но это ситуация практически со всем.

Каковы самые большие недостатки в среде Java Swing GUI?

frameworks gui swing Jonas
источник
2
Вопрос интересный. Мне тоже интересно, каковы сильные и слабые стороны Swing по сравнению с QT, GTK, SWT, Winforms, Cocoa и тому подобное. Может быть, вам следует перефразировать заголовок, чтобы просить о сравнении , а не о недостатках (которые, как правило, приводят к недостаточно обоснованным ответам)
barjak

Ответы:

3

  1. Вы должны установить Java где-нибудь. Это верно для всех структур GUI, конечно, но у Java есть восприятие 2-тонной гориллы. Это стало намного лучше, но в те ранние дни Java-апплетов многие люди были потрясены. Если вам нужно только запустить одно приложение, вам нужно много времени, чтобы поддерживать его в актуальном состоянии с помощью исправлений безопасности и тому подобного. У всех должен быть Flash для YouTube. Платформа .Net устанавливается за кулисами, и у каждого в браузере включена поддержка JavaScript. Java - это обычно дополнительная вещь.

  2. Несмотря на то, что это что-то вроде однократной записи, запускается где угодно, вы все равно обнаруживаете, что в Mac OSX нет этой новомодной вещи, которую вы хотите использовать, или один клиент отказывается обновить свой linux-мандрагор после JRE 1.4.

  3. Как разработчик, вы должны думать о потоках. И это сложно, так как многопоточность возможна, но Swing делает вид, что все однопоточные. Но тогда половина библиотек, в которых вы работаете, имеют некоторую степень многопоточности и предполагают, что вы знаете о EDT invokeLater, и это навязывает много уроков трудным путем.

  4. Опыт Swing не легко переносится на другие виды разработки пользовательского интерфейса. Например, если вы мастер в таблицах в .css, вы будете полностью захвачены Jtables, рендерами, редакторами и т. Д.

В общем, основная проблема с Swing заключается в том, что он не соответствует тому, как он продавался. Это совершенно адекватная технология для многих случаев использования, но те первые 5 или 6 лет были полны ужасных реализаций и ужасных апплетов. И теперь это старая технология - на Web 3.0 или что-то еще.

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

Стив Джексон
источник
1
Я нахожусь в той же ситуации, что и ОП: я знаю Swing и мне интересно сравнивать его с другими графическими интерфейсами. Для меня пункты 1, 2 и 4 не имеют отношения к вопросу. Итак, я бы хотел отреагировать на пункт 3: не могли бы вы привести несколько примеров многопоточных инструментариев GUI, пожалуйста? Спасибо.
Барджак
2
@barjak: многопоточный графический интерфейс является ошибкой. Единственный, кого я знаю, это старый Java AWT. Но они учились на ошибках, когда разрабатывали Swing, который является однопоточным, как и все современные графические фреймворки.
Йонас
@Jonas Заставить разработчика задуматься о многопоточности часто бывает ошибкой, но вы не можете запускать анимации, выполнять вызовы RMI или выполнять интенсивные вычисления (помните, что это толстый клиентский инструментарий) без некоторой степени многопоточности.
Стив Джексон
3
@ Стив: Это правда. Но вы не должны делать RMI-вызовы и интенсивные вычисления в GUI-потоке. Такого рода вещи должны выполняться в фоновом потоке, как в Swing и WPF.
Джонас
@barjak - формы Windows, MFC, SWT, pyQT, Juce .... Мне сложнее думать о тех, которые не являются многопоточными. Обычно применяются те же правила, вы не можете касаться компонентов GUI, кроме как в потоке, который их создал.
Стив Джексон
2

Jonas,

Swing обобщает вашу базовую архитектуру, чтобы предоставить вам независимый от платформы пользовательский опыт. Единственным тяжеловесным компонентом (предоставляемым ОС) является контейнер JFrame, а остальное в значительной степени обрабатывается Takeit Swing. AWT, с другой стороны, просит ОС нарисовать все свои компоненты пользовательского интерфейса, что означает, что он быстрее во многих отношениях, чем использование собственных компонентов пользовательского интерфейса, специфичных для данной ОС. SWT пытается достичь среднего уровня, для различных стандартных компонентов, таких как кнопки и метки (которые доступны в большинстве ОС), он позволяет ОС справиться с этими и для других специализированных компонентов, SWT будет обрабатывать создание для вас.

При этом я могу обрисовать недостатки.

(1) Поскольку инструментарий создает и отображает компоненты для вас, а не запрашивает ОС, вы не получаете преимущества от скорости встроенных компонентов, предоставляемых ОС.

(2) Пользовательский интерфейс не является особенно атрибутивным, поскольку он выглядит чуждым большинству платформ ОС в отношении того, как вы выглядите и чувствуете.

(3) Некоторые из менеджеров компоновки, например, GridBadLayout и т. Д., Могут быть упрощены. Я потерял счет из числа проектов, над которыми я работал, где люди обернули GridBagLayout в какой-то специальный код, чтобы получить более простой способ его использования.

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

Пустынная планета
источник
4
Swing ускоряется с помощью графического процессора , что не является частой платформой, поэтому я считаю, что Swing работает быстрее. Это также стратегия, которую имеет WPF в Windows, но не WinForms (только в некоторых версиях Windows). Как может «[некрасиво] ... в отношении того, какой внешний вид и стиль вы используете» быть правдой, если это очень настраиваемо или вы можете использовать собственные платформы LaF? Я согласен, что менеджеры по раскладке действительно плохие.
Джонас
Джонас, это «настраиваемый» аспект свинга, который делает его сложным по сравнению с другими фреймворками. Если вы попытаетесь абстрагироваться от функций, которые дает вам ОС, вы потеряете многие из преимуществ, которые она предлагает. Самая первая версия Swing была кошмаром, что привело к созданию SWT. Позже Swing был улучшен, чтобы быть намного быстрее, и у вас есть классы, такие как SwingUtilities, которые предлагают лучшую поддержку потоков для GUI.
Пустынная планета
Гадкий может быть неправильное слово; иностранец может быть лучшим словом, так как внешний вид и внешний вид не совсем совпадают с внешним видом и интерфейсом родного пользовательского интерфейса, насколько я помню, у вас есть Java, мотив, металл и некоторые другие, но в целом они не таковы. все это красиво.
Пустынная планета,
Следующее, на что нужно обратить внимание при сравнении, - это усилия, приложенные при разработке пользовательского интерфейса. Я бы не сказал, что менеджеры по раскладке действительно плохие, там лучше, чем вообще без компоновки (с которыми мне приходится иметь дело при работе на мобильном устройстве), но они не прилагают никаких усилий для упрощения модели.
Пустынная планета
Я думаю, основываясь на том, что вы сказали, вы использовали более свежую версию Swing, но когда она только появилась, люди сильно ее не любили и тем более, когда пытались предоставить апплеты на основе Swing. Существует множество историй для UI-фреймворков, разработанных на Java, и это интересно прочитать, если вы посмотрите на это.
Пустынная планета
-2

Swing медленный (плохая производительность), жесткий / неуклюжий в использовании (по сравнению со многими другими) и на некоторых платформах выглядит не очень хорошо, на самом деле очень плохо.

Анто
источник
5
Я нахожу это быстрым (ускорение с помощью графического процессора по сравнению со многими родными графическими интерфейсами), поэтому я не могу согласиться с производительностью или у вас есть примеры? Как это сложно и неуклюже по сравнению с другими фреймворками? Я согласен, что он не выглядит хорошо, но его можно настроить так, чтобы он выглядел как родные приложения или использовал пользовательский LaF.
Джонас
Это выглядит более или менее всегда не родной на GTK. Что я слышал, так это то, что поскольку рисование виджетов основывается на Java 2D, это происходит медленно, но мне нечем это доказать. И Qt, и GTK кажутся мне менее неуклюжими, но вкусы разные.
Anto
Ах, это может работать хуже на некоторых платформах. Я использовал его только на Windows, где он ускорен и очень быстр.
Джонас
6
Люди все еще жалуются на то, что что-то не выглядит нативно, при использовании все большего количества браузерных вещей (например: stackexchange), где каждая страница выглядит по-разному? А скорость? Большую часть времени пользователь ждет интерактивная программа с графическим интерфейсом.
пользователь неизвестен
2
Большинство «модных» программ больше не выглядят нативно. В этом отношении свинг заканчивается не лучше и не хуже. Производительность нашего 50kloc Swing-приложения (толстый клиент) кажется хорошей. Гораздо проще получить качели до точки не сбоев, чем у «родных» приложений.
Тим Уиллискрофт