Quelle version de Java utilisez vous principalement (2007) ? [Archives]

**davidly** · 05/01/2007, 15h47

Salut,

Comme beaucoup ici : 1.4 au boulot, 1.5 pour les projets personnels.

**Tommy31** · 05/01/2007, 16h39

J'ai travaillé sur la version 1.5 dès qu'elle fut sortie. Et depuis je traine des pieds pour retravailler sur d'ancienne version, tant les améliorations apportées dans cette mouture sont indispensables.

**dstauret** · 07/01/2007, 06h26

Moi c'est java 5.
J'ai essayé java 6 (refactoring et tout) sur mon projet du moment, mais l' application était qqs peu buggué en 6.
Dès que j'ai fini mon projet (des mise à jour seront déjà dispo), je travaille la compatibilité avec java6; car la version 6 offre beaucoup d'avantages niveau performance. Et en plus est beaucoup plus légere.

**M@th** · 14/02/2007, 08h04

Bonjour,

Pour moi, je bosse en 5.0 et pour mes développements perso c'est en 6.0 !

A plus,
Mathieu

**sironimo** · 14/02/2007, 08h29

Mes développements professionnels comme mes développements persos sont faits avec java SE 6.

**Syrion** · 14/02/2007, 17h45

Envoyé par sironimo

Mes développements professionnels comme mes développements persos sont faits avec java SE 6.

Oh le veinard !

Dev persos en j2SE 6, dev professionnels en J2EE 1.4 et J2SE 5 (oui on migre à Java 5 et on exécute du code compilé Java 5 et 1.4 avec une JVM 1.4.2 en prod... halala les stupides contraintes d'éditeurs). Je vous rassure, les classloaders 1.4 n'ont pas accès aux classes 5.0

**willoi** · 14/02/2007, 18h08

java 1.5 + j2se1.4 (ou 1.3 selon le client ....) au boulot

A la maison , je programme pas !

**zais_ethael** · 16/02/2007, 15h51

Petite question.
En quoi cela consiste-il un si énorme problème de demander poliment au client de mettre à jour sa jvm? C'est vrai quoi, si on le faisait tous les mois je dis pas mais une fois tous les deux ou trois ans c'est pas un drame. Ca fait un an que le java 5 est sorti, beaucoup s'accordent pour dire qu'il est quasi indispensable (j'en fait partie), il serait peut-être temps de lancer une petite vague de migration (surtout pour ceux qui utilisent le 1.3)?

**joho** · 16/02/2007, 16h04

Envoyé par zais_ethael

Petite question.
En quoi cela consiste-il un si énorme problème de demander poliment au client de mettre à jour sa jvm? C'est vrai quoi, si on le faisait tous les mois je dis pas mais une fois tous les deux ou trois ans c'est pas un drame. Ca fait un an que le java 5 est sorti, beaucoup s'accordent pour dire qu'il est quasi indispensable (j'en fait partie), il serait peut-être temps de lancer une petite vague de migration (surtout pour ceux qui utilisent le 1.3)?

Perso j'ai un gros problème avec la compatibilité ascendante de java (que je ne conteste pas étant plus javatiste que DotNETMan)
Pendant mes études (fraichement terminée) j'ai observé quelque chose qui je penses pourra répondre a ta question.
Il y a une différence entre :
http://java.sun.com/j2se/1.5.0/docs/...igInteger.html et
http://java.sun.com/j2se/1.4.2/docs/...igInteger.html
Il y a effectivement des différences (scandaleuse ?) entre ces deux versions de la classe BigInteger (en tout cas dans la doc) Pour éviter de vous faire chercher, il semble qu'avec java 5 on ne puisse plus faire de compareTo avec des object , on ne peut en faire qu'avec des BigInteger contrairement a la version 1.4
imagine une appli critique qui tourne sur des postes et qui utilise cette méthode [compareTo(Object)] (et encore, je n'ai vu que celle la) , tu changes la version de la jre et hop ... ca pète (théoriquement ... je n'ai pas testé dites moi si je me trompes)
(D'ailleurs ca me pose un problème philosophique de compatibilité ascendante tout ca ....

)

**zais_ethael** · 16/02/2007, 16h28

Tu prends un très mauvais exemple

Quelle est la première chose qu'on fait dans les méthodes compareTo en Java 1.4? Un casting.
Ce qui signifie qu'en java 1.4 compareTo renvoie une exception, ce qui est impossible en java 5 vu que le compilateur refusera de compiler.
Ce sera exactement le même "problème" avec tous les generics, le programmeur inatentif qui ira mettre un String dans une liste ou il aura décidé de ne mettre que des Integer aura fatalement un problème, mais en Java 5 ça ne compilera pas.

compareTo

public int compareTo(Object o)

Compares this BigInteger with the specified Object. If the Object is a BigInteger, this method behaves like compareTo(BigInteger). Otherwise, it throws a ClassCastException (as BigIntegers are comparable only to other BigIntegers).

Pour ce qui est de faire tourner un code compilé en 1.4 sur une jvm 5, cet exemple devrait fonctionner quand même, parceque même les generics sont rétrocompatibles. Mais dans le problème qui nous préoccupe, je ne vois de toutes façons pas l'interet de faire ça (ben oui, si tu demandes à tes clients de passer en 5, c'est pas pour continuer de faire du 1.4

)

**adiGuba** · 16/02/2007, 16h47

Envoyé par joho

Il y a une différence entre :
http://java.sun.com/j2se/1.5.0/docs/...igInteger.html et
http://java.sun.com/j2se/1.4.2/docs/...igInteger.html
Il y a effectivement des différences (scandaleuse ?) entre ces deux versions de la classe BigInteger (en tout cas dans la doc) Pour éviter de vous faire chercher, il semble qu'avec java 5 on ne puisse plus faire de compareTo avec des object , on ne peut en faire qu'avec des BigInteger contrairement a la version 1.4

En fait il n'y a aucune différence... ou presque !!!

Je m'explique : avec Java 1.4.2 tu avait deux méthodes compareTo() :

compareTo(BigInteger) qui permet de comparer simplement deux instances BigInteger.
compareTo(Object), afin de respecter l'interface Comparable,
qui fonctionne comme la précédente si l'objet passé en paramètre est un BigInteger, et qui renvoi une ClassCastException si ce n'est pas le cas...

La version 1.5 est différentes dans le sens où elle utilise désormais les generics, et qu'elle implémente Comparable<BigInteger>. Ainsi la méthode à implémenter n'est plus compareTo(Object) mais compareTo(BigInteger). Par contre une méthode implicite compareTo(Object) est bien généré par le compilateur, qui se contentent d'appeler la précédente après un cast.

le fonctionnement est tout à fait identique.

Tu peux vérifier cela en affichant toutes les méthode compareTo() de BigInteger :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	for (Method m : BigInteger.class.getMethods()) {
		if (m.getName().equals("compareTo")) {
			System.out.println(m);
		}
	}

Ce qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public volatile int java.math.BigInteger.compareTo(java.lang.Object)
public int java.math.BigInteger.compareTo(java.math.BigInteger)

La seule différence c'est que tu ne peux plus appeler directement compareTo(Object) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
	Object object = ...;
	BigInteger bi = new BigInteger("0");
	bi.compareTo(object); // provoque une erreur

Par contre tu peux l'appeler lorsque tu utilises ton objet BigInteger en tant que "Comparable" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
	Object object = ...;
	Comparable c = new BigInteger("0");
	c.compareTo(object); // provoque un warning "raw type"

Mais quoi qu'il arrive une application compilé avec du Java 1.4.2 fonctionnera de la même manière dans ce cas là...

Il faut bien comprendre que la compatibilité ascendante est à deux niveaux :

Au niveau binaire, c'est à dire du bytecode : un code compilé avec un vieux JDK devrait fonctionner de la même manière sur une JVM plus récente. C'est ici que le respect de la compatibilité est le plus fort. Dans le cas de [b]BigInteger.compareTo(Object)(/b] cela ne pose aucun problème.
Au niveau du source Java. C'est à dire qu'un code compilé avec un vieux JDK devrait être compilé avec un JDK plus récent. Ici c'est déjà plus compliqué car il peut y avoir un grand nombre de cas où la compilation échoue entre deux versions...

Concernant la mise à jours de la JVM, ce n'est pas vraiment un problème pour les particuliers mais pour les entreprises. A partir du moment où tu as toutes une suite d'applications au coeur du métier de l'entreprise, tu dois être sûr que ces applications puissent continuer à fonctionner et à évoluer avec la nouvelle version...

Ainsi de nombreuse entreprises sont frileuses et conservent de vieille JVM... même si leurs craintes sont parfois exagéré.

Perso on a fait une migration d'une application web Tomcat Java 1.4 sous Windows vers du 5.0 sous Linux, le tout sans problème majeur ou bloquant. Mais il faut avouer que cela demande quand même un certain travail dont l'intérêt n'est pas forcément immédiatement évident (tout cela pour faire tourner la même application).

a++

**Syrion** · 17/02/2007, 18h54

Envoyé par zais_ethael

Petite question.
En quoi cela consiste-il un si énorme problème de demander poliment au client de mettre à jour sa jvm? C'est vrai quoi, si on le faisait tous les mois je dis pas mais une fois tous les deux ou trois ans c'est pas un drame. Ca fait un an que le java 5 est sorti, beaucoup s'accordent pour dire qu'il est quasi indispensable (j'en fait partie), il serait peut-être temps de lancer une petite vague de migration (surtout pour ceux qui utilisent le 1.3)?

Si tu parles de JVM sur poste client, c vrai qu'après une courte phase pour s'assurer qu'il n'y a pas de nouveau bug évident qui pourrait être évité par une simple période d'observation, OK.
Par contre, le vrai problème, ce sont les boîtes qui comme la mienne sont liés à une version de produitd éditeur, qui ne veut pas assurer de support pour une autre JVM que celle qu'il a certifiée. Exemple : si vous tenter de faire tourener WAS 6 sur une JVM 1.5, vous allez vous sentir seul. Très seul.

Bon ok on a contourné le problème : un classloader personnalisé avec retrotranslator, qui permet de se mettre au Java 5 avec une JVM 1.4.2.
Parcequ'un jour il est prévu soit une montée de version sur le produit propriétaire, soit un passage sur une base open source. Parceque support ou pas, la foule de bugs qu'on déniche dans le propriétaire et pas dans l'open, ça ralentit les devs et ça augmente la maintenance (quand on a 2ème effet kiss-kool en prod).

Mais pour le grand public, oui, la mise à jour devrait être systématique; même si je déteste en tant que dev de voir un "jusched" dans la table des process, pour M. Tartempion ou pour les utilisateurs de chez Martin&Cie ça ne devrait pas poser de pb.

**benwit** · 18/02/2007, 22h30

Jusqu'à l'année dernière, je développai principalement en 1.4 (la force des habitudes)

Et puis j'ai fait le saut 1.5 et je ne le regrette pas :

J'aime les templates qui évitent les cast (même si certains warning sont pénibles, je les désactive avec l'annotation suppresswarning)

J'adore les boucles simplifiées, l'autoboxing et les paramètres variables ...

**adiGuba** · 19/02/2007, 09h02

Envoyé par benwit

J'aime les templates qui évitent les cast (même si certains warning sont pénibles, je les désactive avec l'annotation suppresswarning)

Attention car @Suppresswarning doit être utiliser avec parcimonie !
En effet un warning signifie un problème potentiel et il vaut mieux tenter de le résoudre plutôt que de le cacher...

a++

**®om** · 19/02/2007, 09h04

Envoyé par zekey

d'un autre coté je préfère bosser avec celui la, plutôt qu'avec celui qui appelle ses enum toto et tata

Ou alors ceux qui n'utilisent pas d'Enumeration, mais des Iterator

Sinon, moi j'utilise Java SE 6, et là pour un projet Java EE pour les cours j'utilise Java EE 5, donc avec Java SE 5...

**benwit** · 19/02/2007, 19h42

Envoyé par adiGuba

Attention car @Suppresswarning doit être utiliser avec parcimonie !
En effet un warning signifie un problème potentiel et il vaut mieux tenter de le résoudre plutôt que de le cacher...

a++

Je suis entièrement d'accord avec toi et je crois sincèrement les utiliser à bon escient lorsque je suis sûr du contenu.

Il faut reconnaître que l'interaction avec les anciennes API n'est pas terrible. Je vais quand même pas recopier tous les éléments de mon tableau parce que le type parait suspect au compilo ?

Exemples avec l'API des servlets :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
    @SuppressWarnings("unchecked")
    public void contextInitialized(ServletContextEvent sce)
    {
        ServletContext context = sce.getServletContext();
 
        Enumeration<String> names = context.getInitParameterNames();
        while (names.hasMoreElements())
        {
            String name = names.nextElement();
            String value = context.getInitParameter(name)

context.getInitParameterNames() retourne une énumération sans <Type>
donc si j'ôte l'annotation, il me met un warning "unchecked" que je fasse un cast (Enumeration<String>) ou non !

Dans ce cas là, je me le permet car si l'API est bien çoncue, c'est logique puisque getInitParameter(String param) prend une String en parametre.

Autre cas ou le type de contenu est connu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
    @SuppressWarnings("unchecked")
    @Override
    public Map<String, Object> getActionParameters()
    {
        return request.getParameterMap();
    }

Tu remarqueras avec ces exemples que je passe d'une API (avant 1.5) à mon code 1.5. C'est parce que je n'ai pas accès aux sources qui pouraient être modifiés que je fais cela. Le pattern Adapter qui permettrait de modifier le code d'un source auquel je n'aurais pas accès n'est pour moi pas intéressant dans ce cas.

Qu'en penses tu et comment ferais tu sinon ?

**adiGuba** · 19/02/2007, 20h23

Envoyé par benwit

Qu'en penses tu et comment ferais tu sinon ?

Je suis globalement d'accord avec toi : c'est une des principales raisons de l'utilité de @SuppressWarning...

Toutefois je te conseillerais d'éviter de placer @SuppressWarnings sur l'ensemble d'une méthode. Il est préférable de limiter son action à la portion de code la plus petite afin d'être sûr qu'il ne cache pas un autre warning involontaire...
Le mieux pour cela est de créer une méthode contenant seulement le code générant un warning légitime...

Perso je me suis fait une méthode qui permet de faire cela de manière totalement générique, et qui fonctionne quasiment comme un cast standard :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
	/**
         * Cast non sécurisé.<br/>
         * Cette méthode permet de caster des types non-paramétré en
         * type paramétré.<br/>
         * Exemple :
         * {@code List<String> list = uncheckedCast( maListeNonParamétré ); }
         * <br/>
         * <b>Attention :</b> cela peut avoir des effets de bords
         * indésirables si la référence en paramètre ne respectent
         * pas le type paramétré !
         * 
         * @param <P> Type du paramètre de la méthode.
         * @param <R> Type de la valeur de retour.
         * @param p Paramètre à "caster".
         * @return La référence 'p', castée dans le type de R.
         * @throws ClassCastException en cas de type incompatible.
         */
	@SuppressWarnings("unchecked")
	public static <P,R extends P> R uncheckedCast(P p) throws ClassCastException {
		return (R) p;
	}

Cela te permet de caster sans warning (et sans utiliser @SuppressWarning) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    Map ref = new HashMap();
    Map<String,String> map = uncheckedCast(ref);
    // --> Compile sans warning

Cela génère un ClassCastException à l'exécution si les types sont incompatibles :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    Object ref = new ArrayList();
    Map<String,String> map = uncheckedCast(ref);
    // --> Compile sans warning, mais ClassCastException à l'exécution

Tout en ayant une vérification minimum des types à la compilation selon la déclaration du paramètre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    ArrayList ref = new ArrayList();
    Map<String,String> map = uncheckedCast(ref);
    // --> Erreur de compilation "not applicable"

Par contre, et c'est la raison de l'existence du warning, si l'objet ne respectent pas le type paramétré (par exemple si la Map ne comporte pas que des <String,String>), tu te retrouvera avec des ClassCastException "incohérent" (c'est à dire non pas au moment du cast, mais plus loin dans ton code).

a++