java.lang.VerifyError при издевательстве над статическими методами Swing - PullRequest
Новая
       21

java.lang.VerifyError при издевательстве над статическими методами Swing

4 голосов
/ 29 марта 2011

Я использую PowerMock для макетирования статических методов на JOptionPane, но JRE, похоже, не очень соответствует этому, потому что я получаю java.lang.VerifyError при инициализации, так как он проверяет целостность своих собственных пакетов и классы.

У меня есть несколько обходных путей, но я не очень доволен любым из них:

  • Напишите объектную оболочку для JOptionPane и предоставьте интерфейс для необходимых мне методов (showInputDialog и т. Д.), Чтобы я мог внедрить макет или заглушку для тестирования. Это просто перемещает проблему в другое место, поскольку мне все равно нужно было бы охватить мои методы-оболочки, но, по крайней мере, они будут изолированы от логики.

  • Используйте экземпляр JOptionPane вместо ссылки на класс, чтобы вызывать методы для него (я думаю, у меня не возникнет никаких проблем с насмешкой над экземпляром, так как класс не является окончательным). Недостатком является то, что я получу много предупреждений типа «вызов статического метода для переменной экземпляра», но это цена, которую нужно заплатить.

  • Не смеяться над JOptionPane и использовать Robot для запуска входных событий для его обработки. Это может быть очень громоздким и не очень надежным ... Кроме того, я использую внутренние диалоги, и это требует дополнительной работы для настройки JDesktopPane, JInternalFrame s и т. Д.

Любые другие идеи или предложения?

Спасибо!

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

1 Ответ

2 голосов
/ 29 марта 2011

  • Напишите оболочку для JOptionPane - это, безусловно, самый надежный вариант, который также позволяет вам писать удобные методы быстрого доступа для себя.Я бы выбрал этот.Если, как и я, и большинство других разработчиков, у вас уже есть некоторый класс помощника GUI где-то в вашем проекте, они могут пойти туда.

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

  • Используйте Robot для насмешки над входами - да, это звучит крайне хрупко для меня.В этот момент вы становитесь зависимыми от внутренней структуры и деталей реализации JOptionPane, что не является подходящим местом.Поведение и порядок кнопок JOptionPane s также могут различаться в зависимости от вида (например, «ОК», «Отмена» против «Отмена», «ОК»).Наконец, это не будет работать в автономной среде (хотя, если вы уже используете JOptionPane s в своих тестах и ​​планируете всегда тестировать на настольном компьютере, это не проблема).

...