java.util.Timer: ¿está en desuso?

Leí en un comentario al this answer y en muchas otras preguntas sobre la programación (lo siento, no hay referencias) que java.util.Timer está en desuso. Realmente espero que no, ya que lo estoy usando como la manera más fácil de programar cosas en Java (y funciona muy bien). Pero si está obsoleto, buscaré en otro lado. Sin embargo, un vistazo rápido al API docs for 1.6 no dice nada sobre que esté en desuso. Ni siquiera se menciona en Sun Deprecated List.java.util.Timer: ¿está en desuso?

¿Está oficialmente obsoleto ^* y, en caso afirmativo, qué debo usar en su lugar?

^* Por otro lado, si no está obsoleta, podían dejar de hablar mal de las personas inocentes y brillantemente esta implementadas-set-o-clases?

Fuente

2010-02-06 Dan Rosenstark

'java.util.Timer' está lejos de estar escrito brillantemente. Es inflexible y difícil escribir código comprobable. 'ScheduledExecutorService' es mejor en todos los sentidos. – skaffman

@skaffman, eso puede ser correcto. Mi única pregunta es si 'ScheduledExecutorService' es tan liviano como' Timer'. Es solo una envoltura delgada en 'Object.wait (long)' ... ¿qué pasa con Scheduled ...? –

El código fuente está ahí, échale un vistazo. Lo que puedo decir es que las cosas 'java.util.concurrent' (incluyendo' ScheduledExecutorService') han sido diseñadas para un rendimiento extremadamente alto, que 'Timer' nunca fue. – skaffman

Hay [JDK-8154799] deprecate Timer and TimerTask de seguimiento de errores del JDK y, a mediados de 2016 JEP 277 declaró que java.util.Timer (y TimerTask) sería obsoleto en JDK 9.

varias API Java SE tendrán una anotación de @Deprecated agregado, actualizado o eliminado. Algunos ejemplos de tales cambios se enumeran a continuación.

[...]

complemento @deprecated a java.util.Timer y TimerTask

Sin embargo, en la versión del JDK 9, esas clases no están en desuso (clases desaprobadas se pueden encontrar en el Deprecated List)

Fuente

2016-08-03 16:33:54 Martin

Gracias. Los lectores deberían ver la respuesta previamente aceptada aquí: http://stackoverflow.com/a/2213146/8047 –

@Martin: no vi ninguna referencia a que TimerTask o Timer quedara obsoleto, a partir de hoy (26/6/2017) . Tal vez fueron eliminados de la lista. – FractalBob

@FractalBob De hecho, estas clases no aparecen en la [JDK9 Deprecated List] (http://download.java.net/java/jdk9/docs/api/deprecated-list.html#class). Encontré [este informe de error] (https://bugs.openjdk.java.net/browse/JDK-8154799): parece que todavía no se ha decidido si van a dejar de estar disponibles (ver el cambio en 2016-10-04 21: 40 en Actividad → Todos). – Martin

En jdk1.6_10 no está en desuso, por lo que no hay necesidad de una alternativa.

Fuente

2010-02-06 12:48:03 stacker

'java.util.Date' tampoco está en desuso, pero se necesita una alternativa. – skaffman

Lo mismo vale para Observer/Observable. – Adamski

@skaffman ¿qué usas en lugar de 'java.util.Date'? Y si no desprecian estas cosas, ¿cómo se supone que debo saber para no usarlas? –

No, no todo. Es posible que desee utilizar otros mecanismos como Quartz para los requisitos del temporizador más complejos, pero el temporizador funciona perfectamente y no va a ninguna parte.

Fuente

2010-02-06 12:48:09

Gracias por eso. Veré también a Quartz. –

Sí, Quartz es excelente, aunque el API no es tan bueno. Sin embargo, las envolturas de Quartz provistas con Spring lo hacen mucho más usable/flexible. – Adamski

Creo que esto es un malentendido. El JavaDoc de la clase Timer menciona ScheduledThreadPoolExecutor y notas, que esta clase es efectivamente un reemplazo más versátil para la combinación Timer/TimerTask. Nada más. El temporizador no está en desuso.

Otra cita de JavaDoc, ScheduledThreadPoolExecutor este tiempo:

A ThreadPoolExecutor que, además, puede comandos de programación para ejecutar después de un retardo dado, o para ejecutar periódicamente. Esta clase es preferible a Timer cuando se necesitan múltiples subprocesos de trabajo, o cuando se requieren flexibilidad o capacidades adicionales de ThreadPoolExecutor (que se extiende esta clase).

Fuente

2010-02-06 12:56:41

Gracias por eso. Entonces, ¿cree que, en términos de peso de implementación, velocidad, uso de memoria, uso de CPU, el temporizador es la opción más liviana? –

El temporizador es "liviano" ya que solo tiene un hilo de fondo único. Tenga en cuenta que tanto Timer como ScheduledExecutorService usan una matriz internamente para mantener tareas programadas. Por lo tanto, programar 10,000,000 de tareas y luego cancelarlas dejará el tamaño de la matriz en 10,000,000. En realidad esto raramente sería un problema. – Adamski

Honestamente, no sé y no me importa el rendimiento en la mayoría de los casos. Si tuviera un problema de rendimiento, el intercambio de Timer.sleep() por ScheduledThreadPoolExecuter sería una de las últimas cosas que miré ... –

No, no está en desuso. Además de Sun Deprecated List, también verá una nota en JavaDoc para una clase que ha quedado obsoleta. Por ejemplo, la nota para StringBufferInputStream dice:

Obsoleto. Esta clase no convierte correctamente los caracteres en bytes. A partir de JDK 1.1, la forma preferida de crear una secuencia a partir de una cadena es a través de la clase StringReader.

Fuente

2010-02-06 12:58:47

Gracias Bill, la lista obsoleta se mencionó en la pregunta. Me preguntaba si había algún conocimiento interno que permitiera a las personas saber que Timer está obsoleto (o algo así). –

@yar: Oh, sí, no me di cuenta de que la palabra "aquí" estaba vinculada.El JavaDoc para la clase 'Timer' en sí tendrá una nota que le permitirá saber si alguna vez está en desuso. –

Gracias Bill, admito que vincular la palabra 'aquí' no es la mejor práctica para el texto de anclaje :) –

Como otros han mencionado, No, no es obsoleta, pero yo personalmente siempre uso ScheduledExecutorService lugar, ya que ofrece una API más rica y más flexibilidad:

ScheduledExecutorService le permite especificar el número de hilos, mientras que Timer siempre usa un solo hilo.
ScheduledExecutorService se puede construir con un ThreadFactory que permite el control sobre aspectos del hilo que no sean el estado del nombre/daemon (por ejemplo, prioridad, ThreadGroup, UncaughtExceptionHandler).
ScheduledExecutorService permite programar las tareas con un retraso fijo, así como a una tasa fija.
ScheduledExecutorService acepta Callable/Runnable ya que es una unidad de trabajo, lo que significa que no necesita la subclase TimerTask específicamente para usarla; es decir, podría enviar la misma implementación de Callable a un ExecutorService normal o ScheduledExecutorService.

Fuente

2010-02-06 12:59:29 Adamski

El último beneficio podría ser interesante para mí. Pero aparte de eso, me preocupa que ScheduledEx ... pueda ser "más pesado". ¿Pensamientos? –

Suponiendo que crea un ScheduledExecutorService con un solo hilo, es muy poco probable que vea una diferencia en el rendimiento (a pesar de que el temporizador contiene su propia implementación de cola de prioridad). – Adamski

java.util.Timer: ¿está en desuso?

Respuesta

Cuestiones relacionadas