Commentaires sur : Problème de concurrence avec SimpleDateFormat https://java-freelance.fr/java/concurrence-simpledateformat Du java et du freelance Mon, 09 Aug 2010 09:49:55 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Par : Jerome Baumgarten https://java-freelance.fr/java/concurrence-simpledateformat/comment-page-1#comment-163 Jerome Baumgarten Wed, 31 Mar 2010 17:41:06 +0000 https://java-freelance.fr/?p=455#comment-163 Comme David, je conseille fortement JodaTime, d'autant plus que JodaTime a servi de base a la JSR 310 (http://jcp.org/en/jsr/detail?id=310) dont l'un des specs leaders n'est autre que Stephen Colebourne, le createur de JodaTime. Avec JodaTime on n'a pas de probleme de concurrence : DateTimeFormat is thread-safe and immutable, and the formatters it returns are as well. De plus DateTimeFormat utilise un cache en interne pour ne pas avoir a construire un DateTimeFormatter a chaque demande. Comme David, je conseille fortement JodaTime, d’autant plus que JodaTime a servi de base a la JSR 310 (http://jcp.org/en/jsr/detail?id=310) dont l’un des specs leaders n’est autre que Stephen Colebourne, le createur de JodaTime. Avec JodaTime on n’a pas de probleme de concurrence : DateTimeFormat is thread-safe and immutable, and the formatters it returns are as well. De plus DateTimeFormat utilise un cache en interne pour ne pas avoir a construire un DateTimeFormatter a chaque demande.

]]>
Par : David Gageot https://java-freelance.fr/java/concurrence-simpledateformat/comment-page-1#comment-160 David Gageot Sun, 28 Mar 2010 00:49:17 +0000 https://java-freelance.fr/?p=455#comment-160 La création d'un DateFormat à chaque formatage de date est un dans le top 10 des problèmes de performance les plus courants. C'est incroyable de voir que la plupart des développeurs n'ont aucune idée du coût de ce type d'opération. Du code faisant plusieurs transformations/formatage de dates peut vite devenir extrêmement lent. Pour moi, un DateFormat threadsafe en variable statique est la meilleure solution. Clair, rapide, sûr. Seulement, il faut chercher ailleurs que dans le JDK. Par exemple dans la librairie JodaTime. La création d’un DateFormat à chaque formatage de date est un dans le top 10 des problèmes de performance les plus courants. C’est incroyable de voir que la plupart des développeurs n’ont aucune idée du coût de ce type d’opération. Du code faisant plusieurs transformations/formatage de dates peut vite devenir extrêmement lent.

Pour moi, un DateFormat threadsafe en variable statique est la meilleure solution. Clair, rapide, sûr. Seulement, il faut chercher ailleurs que dans le JDK. Par exemple dans la librairie JodaTime.

]]>
Par : Mathilde https://java-freelance.fr/java/concurrence-simpledateformat/comment-page-1#comment-155 Mathilde Mon, 22 Mar 2010 16:19:07 +0000 https://java-freelance.fr/?p=455#comment-155 C'est un peu couteux, du justement au calendar. Mais je pense également que dans la plupart des cas c'est effectivement prématuré ! Il y a énormément de code sur Internet avec le date format en static :( C’est un peu couteux, du justement au calendar.

Mais je pense également que dans la plupart des cas c’est effectivement prématuré !

Il y a énormément de code sur Internet avec le date format en static :(

]]>
Par : Sylvain V. https://java-freelance.fr/java/concurrence-simpledateformat/comment-page-1#comment-132 Sylvain V. Wed, 17 Mar 2010 15:41:45 +0000 https://java-freelance.fr/?p=455#comment-132 Effectivement, il faut parfois se méfier des classes du frameworks... A cause (ou grace) aux serveurs d'application, les développeur oublient facilement qu'ils sont de facto dans un environnement multithreadé. Note : sur http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html il est bien indiqué : « Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally. » …la question étant plutôt : quel est le coût de création d’un SimpleDateFormat et est-il appelé très régulièrement ? Il me semble que le précalculer en static « par défaut » rentre dans la « Premature optimization ». Qu'en pensez-vous ? Effectivement, il faut parfois se méfier des classes du frameworks… A cause (ou grace) aux serveurs d’application, les développeur oublient facilement qu’ils sont de facto dans un environnement multithreadé.

Note : sur http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html

il est bien indiqué :

« Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally. »

…la question étant plutôt : quel est le coût de création d’un SimpleDateFormat et est-il appelé très régulièrement ?

Il me semble que le précalculer en static « par défaut » rentre dans la « Premature optimization ». Qu’en pensez-vous ?

]]>
Par : Francois MAROT https://java-freelance.fr/java/concurrence-simpledateformat/comment-page-1#comment-129 Francois MAROT Tue, 16 Mar 2010 21:17:54 +0000 https://java-freelance.fr/?p=455#comment-129 Excellent, je me suis posé la même question aujourd'hui à propos des SimpleDateFormat ! Mais pris par le temps, j'ai opté pour la solution la plus simple :/ Merci pour les infos ! Excellent, je me suis posé la même question aujourd’hui à propos des SimpleDateFormat ! Mais pris par le temps, j’ai opté pour la solution la plus simple :/
Merci pour les infos !

]]>
Par : Jérôme Ruillier https://java-freelance.fr/java/concurrence-simpledateformat/comment-page-1#comment-128 Jérôme Ruillier Tue, 16 Mar 2010 16:43:41 +0000 https://java-freelance.fr/?p=455#comment-128 Merci pour cet article ! Grâce a vous je découvre ThreadLocal qui me sera probablement bien utile à l'avenir ! Merci pour cet article !

Grâce a vous je découvre ThreadLocal qui me sera probablement bien utile à l’avenir !

]]>