GWT: глюк

I can think of a few:

• Everything is asynchronous. Well, anything service-oriented at any rate. While Swing sometimes acts like this via SwingWorkers and the like, Swing is fundamentally synchronous via the EDT (event dispatching thread). It can take a bit of getting used to;
• You're in for a world of hurt known as CSS and cross-browser compatibility. While GWT does mask many of the differences between browsers, it certainly doesn't mask them all and you can spend hours looking for the source of a line of pixels in GWT just as you can in a normal Web Site;
• There are far fewer resources for Swing than GWT;
• You can only use certain classes on the client-side. The one that used to always cause me issues was BigDecimal;
• Your choices of widgets is far more limited. Whatever you do avoid ExtGWT like the plague. Daryls is like the Jeffrey Dahmer of Generics;
• Make sure you use GWT 1.6;
• The compile-time on GWT is just horrific;
• If you're just making client changes (ie you're not changing any service interfaces), you don't need to rebuild to see those changes. Just refresh in the hosted browser;
• For changes to serverside code that doesn't change the interfaces, make sure you have an Ant or Maven task to rebuild and redeploy your classes without doing a GWT rebuild;
• You can point the hosted browser at something other than the hosted server and debug using it; and
• Make sure your machine has lots of RAM. My IDE on some apps would get out of memory errors if less than about a gig of RAM was allocated to it and these weren't huge apps. I would really recommend 2gigs system RAM absolute minimum, preferably 3 or more.

Без использования GIN и Guice . Внедрение зависимостей очень и очень полезно. GIN (Guice для GWT) не очень хорошо документирован, но стоит потраченного времени, чтобы заставить его работать.

Чтобы расширить то, что Клетус сказал об «определенных классах», у вас нет полной JRE на стороне клиента GWT. (Помните, что код клиента Java GWT транслируется в JavaScript.) Это означает, что сторонние API-интерфейсы Java часто не работают на стороне клиента. Их нужно портировать на GWT. Так много, чтобы написать один раз, бегать везде. См. здесь для получения дополнительной информации об этом ограничении.

Различные браузеры имеют совершенно разные характеристики производительности, поэтому вам придется тестировать их с разными браузерами, даже если GWT генерирует обходные пути Javascript для различий между браузерами.

Создание элементов DOM может быть очень медленным в некоторых браузерах. Если у вас есть большие таблицы (десятки строк), которые часто меняются, браузер может перестать отвечать, если вы просто удалите все строки и создадите их заново. Нам пришлось написать алгоритм сравнения для эффективного обновления таблиц при получении нового содержимого с сервера.

Большинство из них по-прежнему на 100% актуальны для того, что вы хотите сделать:

Крупнейшие подводные камни GWT?

Чтобы конкретно решить проблему перехода Swing -> GWT, есть одно простое правило:

• GWT - это не Swing, и чтобы создать хорошее приложение, вы всегда должны знать на каком-то уровне, какой HTML-код будут создавать создаваемые вами виджеты, и время от времени вам придется спускаться, испачкать и изменить некоторые из поведение или даже закодировать некоторые пользовательские части в javascript или HTML.

Одна важная проблема, о которой следует помнить, - это тестирование. Тестирование Swing-приложения с помощью junit в основном несложно, но для того, чтобы получить такой уровень охвата в приложении gwt, вам необходимо расширить свой арсенал.

1. Straight junit - подходит для классов / утилит моделей, которые не не ссылаюсь ни на одну из сред выполнения gwt. Просто напишите и запустите свои тесты как обычный junit, просто убедитесь, что gwt не пытается скомпилировать ваш тестовый код в ваш модуль. Вы не всегда можете учитывать свои классы, чтобы получить такое покрытие, но когда вы можете, это будет здорово и быстро.
2. GWTTestCase / junit - это специальный подкласс TestCase (в стиле junit3), который загрузит некоторую среду выполнения gwt для тестовый забег. По моему опыту, это слишком сложно получить хорошее освещение и слишком медленно, чтобы быть полезным. Прочтите это для получения дополнительной информации по этой теме.
3. Selenium - Это обеспечит вам охват в браузере (и это лично мой любимый подход). Если вы используете java selenium-rc и объединяете его с причалом для обслуживания тестируемого приложения, вы даже можете имитировать вызовы rpc, чтобы полностью протестировать свой пользовательский интерфейс. У вас также есть возможность запускать тесты во всех основных браузерах.

I ran into an issue where trying to populate tables through nested collection didn't work, presumably because the compiler didn't understand it (issue @ GWT list). Note that this was about a year ago, so it may no longer be the case.

Second issue (again, a year ago, so may no longer be the case) was that compiling on a 64-bit box with a 64-bit JVM wasn't supported, so I ended up needing a separate 32 bit jvm and wrapping an ant task that specifically referenced that for the GWT compile setup.

Даже с 4 гигабайтами ОЗУ у вас могут возникнуть проблемы с компиляцией приложения ( на GWT 1.6 и ранее). Я не могу скомпилировать наше (довольно большое) приложение на работе, используя Maven / что угодно. Размещенный режим работает нормально, но никакие настройки (увеличение ограничений виртуальной памяти до 2 гигабайт и т. Д.), Похоже, не решают эту проблему.