Tout d'abord, super Blog :).
Merci pour tous les tips et les aperiquiz.

Un nouveau lien dans mes marque-pages prioritaire.

Hahaha ! Quand tu arrive à 255 paramètres dans une méthode, tu peux commencer à te poser des questions de conceptions je crois :P

Makkhdyn: On avait convenu ensemble qu'il devait tester sur Eclipse et poster le résultat ici :-)

Autre point : par défaut, NetBeans propose aussi cette fonctionnalité sur les différents scopes.

Martin > C'est une fonctionnalité NetBeans :-°

Pour le Folding sous Eclipse il y a un fonctionnement de base sur les differents scopes. Pour quelque chose de plus personnalisé, il y a des plugins :
http://www.realjenius.com/platform_support

Ca n'a pas l'air de marcher sous Eclipse (sous la perspective Java et JBoss en tout cas)...

Le type chaîne en C# n'est pas un type valeur mais bien un type référence.
En C#/.NET, on peut distinguer les types comme cela :
- types de base vs types définies par le développeur
- types valeurs vs types références
Ces critères sont tous compatibles, quelques exemples :
type "base" "valeur" : bool
type "base" "reference" : string
type "personnalisé" "valeur" : MyStructure
type "personnalisé" "référence" : MyClass

Non, je n'ai fais plus de PHP depuis quelques années maintenant, donc je ne sais pas ce que ça donne.

Cependant, à ce que j'ai entendu dire, il est plutôt bien fait et tourne plutôt bien :)

As tu testé le développement php sous ce nouveau Netbeans ?
Il faudra que je trouve le temps de tester tout ça pour comparer avec le cdt d'Eclipse dont je suis fan !

Hello vivien,

Je souhaite moi aussi te remercier pour ta presence durant la formation au Training Center, ca a vraiment permis d'apporter une petite touche differente a la formation et cote ouverture d'esprit c'etait niquel.

Pense a me faire parvenir ton rapport quand tu l'aura fini.

A bientot

Beedoo

Très sympa ce billet, vivement la suite !

la differene est simple. En java tu travaillera avec des gens qui on des gros problèmes sur leurs grosses apllis toutes lourdes sous UNix. Alors que avec .Net tu pourra travailler avec des gens qui on des gros problèmes sur leurs grosses apllis toutes lourdes sous windows.

Sujet intéressant !
C'est tout de même dommage que 3 ans après la sortie du jdk 5, ce genre de pratique ne reste que très peu utilisée. Pire il reste sous les tirs croisés des deux clans : les antis et les pro-énumerations

Pour allez plus loin sur le sujet, je me permets de vous partager un article que je viens de publier sur le blog de Xebia, vous pourrez y découvrir, comment on passe d'une simple énumération à 3 éléments au 'strategy enum pattern'.

Le résultat est normale,

On ne peut pas hériter d'une énumération donc, si une méthode d'une énumération est abstraite elle ne sera jamais implémentée donc inutile. Une interfaces abstraite pourrait être comparée à une classe abstraite dont toutes les méthodes seraient abstraites donc cela ne change en rien sont comportement. Par contre pour les interfaces final je cherche encore, peut-être parce que le but d'une Interface est d' être implémentée/héritée.

L'inconvénient que certains trouvent à cette approche est la création de classes anonymes en plus de l'énumération en elle même.

Dans le cas d'une énumération comportant n cas, le nombre de classes (énumération + classes anonymes) après compilation est de n+1, ce qui peut rapidement devenir un problème lorsqu'on augmente le nombre de champs dans l'énumération.

Mais il est vrai que ce genre de syntaxe reste couramment utilisé :)

en général on préfère ce genre de syntaxe sans variable intermediaire
enum Sex {
MALE {
@Override
public String toString() {
return "Male";
}
},

FEMALE {
@Override
public String toString() {
return "Female";
}
};

}

Merci pour ce tutorial très complet, néamoins, serait il possible d'avoir de plus amples informations concernant la configuration http? telles que la cipher suite selectionnée, le contenu des champs network adress, le server name, etc...

Merci encore!

Bonjour Florent,

Cette approche n'a pas pour but d'être mise en application. La raison principale est qu'une telle demande d'objets n'est rencontrée que durant des benchmarks.

Le but principal était de mettre en avant le concept de réutilisation des objets, mais je ne pense pas que ce concept soit réellement réutilisable, sauf dans des cas très particuliers.

Cependant, les désavantages que tu présentes sont très intéressants, et méritent d'être considérés. J'essayerais de relancer le même benchmark sur une machine à plusieurs processeurs si j'arrive à en trouver une.

Bonne journée,
Vivien

Bonjour,

C'est une approche qui n'a plus vraiment de sens avec les jvm modernes.
Dans le micro-benchmark que tu présentes il me semble que la gestion des erreurs est omise par exemple, cette technique a donc un désavantage indéniable: la gestion de la mémoire est à réaliser par le développeur.
Autre problème avec cette approche: le code utilisant ton pool va aller de moins en moins vite plus tu auras de processor.
Pour plus d'infos sur cette problématique je vous conseilles 2 références:

http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
http://blogs.azulsystems.com/cliff/

bonne journée,
Florent

très sympa oui !