Reprise du message précédent :

M'en parle pas. J'ai commencé DA:O, pour voir (en pas-acheté). 22:20, je me dis qu'il est pas tard je vais faire juste 2 ou 3 combats. 1h plus tard, il était... 1h30.
 

Mouais, mais vous avez du CGN, comme des pauvres tiers-mondistes. Moi, j'ai pas la fibre, mais j'ai au moins une IPV4 statique.

J'ai déjà ouvert 5 fois la page Steam.
Et je viens de me logguer....

 
rhô, les noms d'éléments. L'élément optional dans AttOblig1

 
GabeN te regarde  

TBH je suis plus intéressé par Medieval Engineers ( https://www.youtube.com/watch?v=GJBYsv3sGAI ) qui permettra (s'ils tiennent leurs promesses) de construire également le chateau avant de le détruire D

 
MAIS TAGGLE§§§§§§§ J'ai déjà watmille jeux que j'ai acheté et auxquels je n'ai jamais joué !!
 
Je vais demander à Steam de me payer un salaire tous les mois, comme ça j'arrête de bosser et je pourrai enfin profiter de mes jeux !

Acheté J'ai gardé la page de paiement ouverte pendant 1h.

@Alt : tu devrais lire ça : http://www.amazon.fr/Macroscope-Ve [...] 8&sr=&qid=

J'ai craqué Vous faites chier. Allez mourir.

Prenez Darkest Dungeon

Sinon moi je joue à Robocraft. C'est rigolo.

moi je joues pas, je bosse

N'empêche je suis un peu déçu par l'UMP : la semaine avait pourtant bien commencé, mais là en deuxième partie ça s'essouffle un peu...

Et n'oubliez pas de prendre Infinifactory

Bon ben Besiege: testé et approuvé

l'effet Civ

c'est une option les IP statiques ...c'est aussi un des trucs qui sera bien avec l'IPV6, c'est que cette notion disparaitra...enfin d'ici à ce que plus personne ne fasse d'IPV4, ce qui n'est pas pour tout de suite

Bon ben Besiege: testé et approuvé

public static Date stringToDate(final String data,final String pattern) {
 
        if (data == null || data.equals("" )){
            return null;
        }
 
        final SimpleDateFormat formatter = new SimpleDateFormat(pattern);
        Date res = null;
        try {
            res = formatter.parse(data);
        } catch (ParseException e) {
            log.error("Erreur lors de la convertion d'un String "+data+" en Date avec le pattern "+pattern+" :",e);
        }
        return res;
    }
 
    /**
     * Méthode permettant de convertir un String en Date
     *
     * @param data
     * @param pattern
     * @return Date
     */
    public static Date stringToDateOptimized(final String data) {
 
        if (StringsUtils.isEmpty(data)){
            return null;
        }
 
        Date res = null;
        try {
            res = DATE_FORMAT_FRENCH_DEFAUT_DATE_HEURE.parse(data);
        } catch (ParseException e) {
            log.error("Erreur lors de la convertion d'un String "+data+" en Date :",e);
        }
        return res;
    }

 
OPTIMIZED§ (mais pas thread safe hein)

Il leve pas des exceptions le constructeur de SimpleDateFormat, genre si tu lui passes un pattern pourri ?
A part ça je vois rien d'extraordinaire là dedans, et conversion ça s'écrit conversion
PS : je ne parle pas le java alors pour le côté "optimisé" je ne saurai rien te dire.

 
Le SimpleDateFormat n'est pas thread-safe. Si plusieurs appels à la méthode parse() de la même instance sont concurrents, tes résultats sont invalides.

le parse() change l'état interne du SimpleDateFormat.

C'est super ça
PS : c'est pas vraiment pour moi que tu disais ça hein ?

C'est pas vraiment la question, moi (en tant que mec qui ne bite rien au java et qui passe ici par accident) je me disais juste que l'appel au constructeur devait aussi certainement être dans le try/catch.
 
D'ailleurs Oracle est du même avis :  
http://docs.oracle.com/javase/7/do [...] ormat.html

C'est le problème pointé par le commentaire d'origine.

La seule raison de faire un truc pareil, c'est d'avoir le pattern sous contrôle d'un tiers, s'il est contrôlé par l'application (ce qui est généralement le cas) tu t'en tapes parce-que le pattern est toujours correct et ça va jamais thrower en production.

 
 
Non, IllegalArgumentException c'est une RuntimeException. Ici on est en face d'une méthode en interne avec un pattern fourni (ou assaini/validé) par le développeur.
On n'attend donc pas qu'elle soit catchée.

bof, moi je laisserai pisser, c'est souvent des trucs statiques, si tu merdes dans la config ça va pas démarrer et t'envoyer un message d'erreur long comme le bras.

Le plus étonnant, c'est de garder les deux méthodes dans le code, je trouve.

https://www.kickstarter.com/project [...] na-and-gps

Mais on est bien d'accord que la méthode optimisée n'optimise rien du tout, à part utiliser un pattern standard au lieu de celui fourni par l'utilisateur ?

 
Elle fait un new en moins, on peut donc supposer qu'elle est plus efficace en temps et ressources.

L'escape analysis devrait rendre le new insignifiant, par contre parser le pattern c'est un poil plus lourd.

S'il faut être thread-safe et que le parsing du pattern pose vraiment un pb de perf, ça peut valoir le coup
de cloner DATE_FORMAT_FRENCH_DEFAUT_DATE_HEURE puis de parser la date avec le clone.

( Ceci dit, si on voulait garder la flexibilité du pattern en paramètre mais ajouter un petit cache local,
ça vaut quoi les ThreadLocal de java niveau perfs ? )

c'est ce que j'utilisais dans traimoo

Elle évite d'allouer un SimpleDateFormat à chaque appel (donc allocation d'un Calendar et parsing du format)

'tain je viens de péter 2 fraises dans du plexiglass

Pas étonnant, c'est pas encore la saison  

 
C'est pratique par contre c'est source de leaks dans les applis web > http://stackoverflow.com/a/7791593/136698

Alternativement, tu utilises un pool en static sur ta classe.