Почему в Java есть два класса Timer (один под javax.swing, один под java.util)?

Я действительно смущен этим. Java имеет два класса Timer, один под swing, а один под util... почему? Какой из них следует использовать, если я хочу просто запустить X каждые Y секунд? Означает ли это, что если я создаю графический интерфейс, я должен использовать версию качания для таймера?

спасибо!

ОТВЕТЫ

Ответ 1

Вот разница между javax.swing.Timer и java.util.Timer:

javax.swing.Timer
  • подходит для более простых случаев, используя небольшое количество таймеров (скажем, менее дюжины).
  • запускает объекты ActionListener в потоке отправки событий
  • может напрямую обновлять GUI, не используя EventQueue.invokeLater
  • если задача выполняется целиком в потоке отправки событий (то есть, если она не порождает рабочий поток), тогда графический интерфейс будет оставаться отзывчивым, только если задача не занимает очень много времени (скажем, до 300 миллисекунд)

java.util.Timer

  • более масштабируемый, чем javax.swing.Timer, и с дополнительными функциями планирования
  • запускает объекты TimerTask в частном потоке
  • необходимо использовать EventQueue.invokeLater для обновления GUI

Вы можете использовать таймеры Swing двумя способами:

  • Выполнение задачи один раз, после задержки. Например, диспетчер подсказок использует таймеры Swing, чтобы определить, когда показывать подсказку и когда ее скрывать.
  • Повторное выполнение задачи. Например, вы можете выполнить анимацию или обновить компонент, который отображает прогресс в достижении цели.

Ниже приведены источники информации выше http://www.javapractices.com/topic/TopicAction.do?Id=160 и http://docs.oracle.com/javase/tutorial/uiswing/misc/timer.html

Какой я должен использовать, если я хочу просто запустить X каждые Y секунд?

В зависимости от того, с чем вы взаимодействуете. Если вы взаимодействуете с графическим интерфейсом, используйте javax.swing.Timer, иначе используйте java.util.Timer.

Означает ли это, что если я создаю GUI, я должен использовать версию swing для таймера?

ДА

Ответ 2

Версия Swing предназначена для рендеринга компонентов качания. Если вам просто нужно время, используйте утилиту.

Ответ 3

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

Ответ 4

В версии 1.3 еще один класс Timer был добавлен на платформу Java: java.util.Timer. И он, и javax.swing.Timer предоставляют один и тот же базовый функциональности, но java.util.Timer является более общим и имеет больше функции. У javax.swing.Timer есть две функции, которые могут сделать это немного проще в использовании с графическими интерфейсами. Во-первых, метафорой обработки событий является знакомы с программистами GUI и могут поток передачи событий немного проще. Во-вторых, его автоматическая нить обмен означает, что вам не нужно предпринимать специальные шаги, чтобы избежать нереста слишком много потоков. Вместо этого ваш таймер использует тот же поток используется, чтобы заставить курсоры мигать, появляются подсказки инструментов и т.д.

Вы можете найти дополнительную документацию и несколько примеров использования таймеры, посетив раздел "Использование таймеров", раздел "Учебник по Java". Дополнительные примеры и помощь в выборе между этим типом и java.util.Timer, см. Использование таймеров в приложениях Swing, статья в Соединение Swing.

Из официальной документации .

Ответ 5

Если у вас есть простая, быстрая задача, которая должна взаимодействовать с каркасом swing, то проще использовать javax.swing.Timer

Для почти любого другого случая - даже приложения GUI вы должны использовать java.util.Timer Если у вас есть графический интерфейс, вам необходимо обрабатывать интеграцию с потоком отправки событий swing так же, как любая другая задача, используя EventQueue.invokeLater для обновления графического интерфейса, как указано выше.

Обычно, когда вы начинаете, первые несколько событий таймера могут показаться быстрыми и маловероятными для производительности, но по мере изменения требований они будут занимать больше времени и больше, и требования самого GUI будут расти. Лучше избегать переделки, просто выходя за пределы среды качания - иначе ваш графический интерфейс быстро появится "вялым" или "непригодным".