Discussion :

[welcome_59]

Java 6 au boulot.

Pour les projets persos, c'est plutôt Java 7.

[gexian]

Comme beaucoup Java 6 majoritairement au boulot avec tout de même la configuration suivante :
- java 5 pour les anciens projets qu'on a encore
- java 6 pour les projets en cours (ie commencés avant la sortie de java 7 qui sont aujourd'hui majoritaires)
- java 7 pour les nouveaux projets

Pour du personnel c'est java 7.

Mais comme l'a dit rmaker plus haut, l'important était de passer au java 5 (ha les vieux projets en 1.4 sans génériques et en 1.3 sans typage de collections ). Il m'arrive beaucoup moins maintenant de dire "ha si j'étais en java x je pourrai faire ça mieux".

[kalina]

Bonjour,
java 6 par habitude! mais je compte bien utiliser la 7 prochainement.

[Digicode]

Java 1.4 ... Je suis le seul de la boite à me taper les applis codées dans cette version
Et quand on me sort de là c'est pour du 1.5
Et dans mon ancienne boite c'était du 1.6

[nu_tango]

Java 1.4 ... Je suis le seul de la boite à me taper les applis codées dans cette version
Et quand on me sort de là c'est pour du 1.5
Et dans mon ancienne boite c'était du 1.6

Change de boite

[_skip]

La 1.6, depuis que la 7 a posé des problèmes avec lucene que nous utilisons pas mal. Même si ces problèmes sont à priori résolus, nous n'avons pas ressenti le besoin de nous mettre à jour car à part un ou 2 nice-to-have comme les ARM il y a assez peu de choses qui nous apporteraient réellement un plus par rapport à la 6.

[Digicode]

Change de boite

C'est que je l'aime bien ma boite

[zolive]

java 6 de Sun car j'ai souvent des soucis avec OpenJDK

[alex_vino]

Je suis loin d'etre expert, j'utilise de temps a autre Java7 pour des tests ou ne pas perdre la main.

J'ai une question:
Est-il si difficile en Java de migrer d'une version a une version ultérieure?

Merci de me donner des précisions.

[leminipouce]

Pourquoi se limiter à Java SE ?

Au boulot on est sur JEE6.

[nlegriel]

Au boulot nous commençons à porter notre existant Java 5 sur le JRE 6... mais avec interdiction d'utiliser les éléments nouveaux du Java 6 (jusqu'à nouvel ordre ).

Nous avons un gros ensemble de frameworks dont la partie commune à tous les projets est utilisée par une équipe qui a temporairement renoncé à porter en Java 6 :

• son application
• son IDE
• son environnement d'exécution

(changement de priorité ). Le code doit rester compilable par un JDK 5.

(A cause de ça j'ai dû voter Java 5)

Sinon pour mes réalisations perso : Java 7.

[drieu13]

Pour les projets perso java 7 et j'ai regardé un peu Java 8 par curiosité.
Sinon au travail, c'est java 6 qui est utilisé.

[thewayiam]

Java 6. Pas de migration envisagée : le java 7 ne sera que pour les nouveaux projets à priori.

[salve34]

Salut à tous,
perso je suis loin d'être un expert en java, mais je ne comprends pas trop la question. En fait ce que je veux dire c'est pourquoi la dernière version (stable bien-sûr) n'est pas utiliser systématiquement ? A part de nouvelles fonctionnalités, elle inclue aussi des maj de sécurité, des optimisations de code, etc.. non?
Autant je comprends qu'une boite ne passe pas aux versions récentes quand ce sont des soft payants mais là on est dans le gratuit (je sais que Oracle a racheté Sun mais pour l'instant c'est encore gratuit il me semble) comme linux, php, mysql etc... Je me vois mal coder en php3 (même si je suis obliger de maintenir des applis en php3) ou en mysql4 sous apache 1 et une Débian Woody. Si qqu'un pouvait éclairer ma lanterne, je l'en remercie par avance.

[adiGuba]

Tu réponds toi même à ta question :

Je me vois mal coder en php3 (même si je suis obliger de maintenir des applis en php3)

C'est l'existant qui pose problème !

Bien sûr si on n'a que des nouveaux projets à faire, sans aucune contrainte, il est préférable d'utiliser la dernière version !


Maintenant lorsque tu as une application qui tourne, le moindre changement peut avoir un impact. Malgré le fait que Java est rétrocompatible, les évolutions peuvent entrainer des incompatibilités, que ce soit au niveau des sources (ton code existant ne compile plus), soit au niveau du binaire (ton programme existant ne fonctionne plus de la même manière).

Tout ceci sans compter les bugs et autres.


Bref la migration implique des tests, afin de vérifier que tout fonctionne correctement. Et plus ton projet est gros, plus il a de dépendance, et plus tu as de chance d'avoir un problème

Bref tout ceci coûte cher (en temps !), et n'apporte pas grand chose de visible (aucun changement ni nouvelle fonctionnalité pour l'utilisateur).


a++

[salve34]

Merci pour ta réponse, mais comme tu le dis

Java est rétrocompatible,

donc il ne devrait pas y avoir de problème non? (sauf à "sauter des versions ie: java 1.4 => java 1.7 peut-être, ce qui me fait dire que l'on a tout intérêt à toujours faire les "upgrade")
@+

[UMLTECH]

Pour ma part, j'utilise essentiellement la JVM de Sun. v7 quand c'est possible (sur Eclipse). Sinon la v6 (indispensable par exemple avec certains produits Oracle car j'ai rencontré des problèmes de compatibilité avec la v7, notamment autour de produits connexes à Oracle Fusion Middleware).

Sinon, à mon sens, la question intéressante aurait plutôt été quelle JVM utilise t'on (IBM, Oracle JRootKit, Sun JavaSE ...) et quelles différences entre ces JVM ?

Sinon, bravo à ceux qui ont répondu Java SE v8 ... produit qui n'existe pas encore !

[salim.elakoui]

Java 6 encore et toujours, enfin jusqu'à ce qu'il y ait un vraie raison, performance ?? Du coté des devs, rien de bien révolutionnaire.

[Fricky]

Java 6 : Framework "maison" développé pour Java 6 et version déployée chez la plupart des clients.

donc il ne devrait pas y avoir de PB non?

Pour une SSII, c'est pas évident de vendre un projet technique de montée de version java : "Bonjour, on va bricoler et tester vos applications qui marchent, ça ne change rien pour vous, vous ne verrez aucune différence si ce n'est des risques de nouveaux bugs et on vous envoie la facture...".

Globalement, les entreprises ont un existant, éprouvé et connu par leurs équipes, et un tel projet de montée de version doit venir d'un problème identifié (exemple : incompatibilité de la nouvelle version de la gestion commerciale ou de la paie avec le JDK actuel). La raison "ça corrige des failles de sécurité (mais je ne sais pas si vous y êtes vulnérable) et ça améliore les perfs (mais vous êtes satisfait de vos perfs actuelles)" est rarement suffisante

[nounouuuuu201186]

Java 6 car il est installé par défaut sur ma machine