Salut,
Comme beaucoup ici : 1.4 au boulot, 1.5 pour les projets personnels.
Version imprimable
Salut,
Comme beaucoup ici : 1.4 au boulot, 1.5 pour les projets personnels.
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.
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.
Bonjour,
Pour moi, je bosse en 5.0 et pour mes développements perso c'est en 6.0 !
A plus,
Mathieu
Mes développements professionnels comme mes développements persos sont faits avec java SE 6.
Oh le veinard !Citation:
Envoyé par sironimo
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
java 1.5 + j2se1.4 (ou 1.3 selon le client ....) au boulot
A la maison , je programme pas !
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)Citation:
Envoyé par zais_ethael
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 .... :aie: )
Tu prends un très mauvais exemple :D
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.
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 :D)Citation:
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).
En fait il n'y a aucune différence... ou presque !!!Citation:
Envoyé par joho
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. :arrow: le fonctionnement est tout à fait identique.
Tu peux vérifier cela en affichant toutes les méthode compareTo() de BigInteger :
Ce qui donne :Code:
2
3
4
5
La seule différence c'est que tu ne peux plus appeler directement compareTo(Object) :Code:
2
Par contre tu peux l'appeler lorsque tu utilises ton objet BigInteger en tant que "Comparable" :Code:
2
3
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à...Code:
2
3
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++
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.Citation:
Envoyé par zais_ethael
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.
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 ...
Attention car @Suppresswarning doit être utiliser avec parcimonie !Citation:
Envoyé par benwit
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++
Ou alors ceux qui n'utilisent pas d'Enumeration, mais des Iterator :)Citation:
Envoyé par zekey
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...
Je suis entièrement d'accord avec toi et je crois sincèrement les utiliser à bon escient lorsque je suis sûr du contenu.Citation:
Envoyé par adiGuba
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 :
context.getInitParameterNames() retourne une énumération sans <Type>Code:
2
3
4
5
6
7
8
9
10
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 :
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.Code:
2
3
4
5
6
7@SuppressWarnings("unchecked") @Override public Map<String, Object> getActionParameters() { return request.getParameterMap(); }
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...Citation:
Envoyé par benwit
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 :
Cela te permet de caster sans warning (et sans utiliser @SuppressWarning) :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Cela génère un ClassCastException à l'exécution si les types sont incompatibles :Code:
2
3
Tout en ayant une vérification minimum des types à la compilation selon la déclaration du paramètre :Code:
2
3
Code:
2
3
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++
Merci :king:
Et comme ça, pour savoir, comment tu l'as appelé ta classe qui comporte cette méthode statique ? et quels autres petits trésors as tu mis dedans :roll:
:mrgreen:
JDK SE 7, maintenant ça existe?
https://jdk7.dev.java.net/
Et depuis décembre dernier
https://openjdk.dev.java.net/