janvier
2007
Un article de adiGuba
C’est bien connu, à chacune de ses nouvelles versions, la plateforme Java prône la compatibilité ascendante : depuis toujours Java semble lui vouer un culte qui frise la déification.
Petit rappel pour ceux qui ne suivrait pas ! On pourrait brièvement décrire la compatibilité ascendante par la phrase suivante : « Le nouveau système sait faire marcher les logiciels de l’ancien, mais l’inverse n’est pas vrai« .
La compatibilité constitue d’ailleurs un des 6 grands thèmes de Java SE 6
Compatibility As the platform has matured, yet continued to evolve, many community members have naturally come to expect that their investments in Java-based systems, whether large or small, will be preserved. Any program running on a previous release of the platform must also run—unchanged—on an implementation of Java SE 6. (There are exceptions to this general rule but they are exceedingly rare, and they typically involve serious issues such as security.)
Concrètement, cela signifie qu’un programme conçu pour un JRE plus ancien continuera à fonctionner de la même manière avec un JRE plus récent, sans nécessiter de re-compilation ou de modification du code source (à quelques exceptions près plutôt rare).
Donc votre application développée pour Java 1.2 fonctionnera avec le tout dernier Java SE 6, mais l’inverse n’est logiquement pas vrai.
Toutefois, si cela a grandement contribué à l’adoption du langage, c’est également à l’origine de plusieurs frein à son l’évolution et même à la correction de bugs…
En effet, toute modification dans le langage ou dans l’API peut logiquement avoir un impact sur les programmes existants, et peut donc potentiellement nuire au bon déroulement de ces programmes, ce qui reviendrait à casser la compatibilité.
Ainsi, afin qu’une modification puisse être intégré dans le langage, elle ne doit avoir aucun impact sur les programmes existants, et ce n’est pas forcément toujours évident… un grand nombre de bugs ne peuvent donc pas être corrigé sans nuire à la compatibilité ascendante, et reste présent de version en version. Pire encore : les JVMs alternative (c’est à dire non distribué par Sun) reproduise les mêmes bugs de la JVM de Sun afin d’être totalement compatible (on parle alors de JVM « bug-for-bug » compatible).
Le problème est tout simple, et si vous suivez un peu les liens « en vrac » du blog Java, vous avez sans doute jeter un coup d’oeil à la proposition d’API de compatibilité sur Javalobby, qui tente d’apporter une solution à ce problème.
Sa proposition est plutôt simple (et doit surement être amélioré), et permettrait de donner la possibilité de proposer plusieurs implémentations selon une « version de compatibilité ».
Ainsi une application « Java 7″ pourrait se passer de bugs présent dans des JVM plus anciennes, ou encore utiliser de nouvelle fonctionnalité incompatible avec les précédentes APIs. C’est particulièrement intéressant lorsqu’on conserve une main-mise sur les machine cible, ou que l’on a des restrictions vis à vis de la JVM à utiliser.
Bien sûr cela resterait au développeur de choisir la version avec laquelle il veut rester compatible. Cela permettrait ainsi une gestion plus souple de cette compatibilité ascendante : les anciens programmes fonctionnerait toujours, mais on pourrait également choisir une « autre implémentation » pour les programmes plus récents qui n’ont pas besoin de rester compatible avec d’anciennes JVMs…
Décidément, Java 7 fait déjà beaucoup parlé de lui : est-ce un effet du passage en open-source ?
31 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- Difference de performances Unix/Windows d'un programme?
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- [ fuite ] memoire
- Possibilité d'accéder au type générique en runtime
- Recuperation du nom des parametres
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- Définition exacte de @Override
- Classes, méthodes private
- jre 1.5, tomcat 6.0 et multi processeurs
J’avoue que ce sur quoi j’ai travaillé était des binaires, donc pas de DLL..
Il est effectivement possible qu’avec des DLL cela crée un problème..
Avec des binaires il n’y a absolument aucun problème, puisque les librairies servant à fabriquer les binaires sont incluses.. et donc le code est auto-suffisant.
Par contre, et d’ailleurs c’est à mon avis le point faible de toutes ces technos Windows et Web (eh oui !! je viens d’un monde plûtot mini, donc VMS ou Unix/Linux)
à force de vouloir une souplesse dynamique, on oublie la continuité dans le temps…
Car en effet si une routine en appelle une autre faisant partie d’un DLL, mais que soit ce DLL n’existe plus, soit la routine a été modifiée (par exemple dans ces paramètres d’appel) 2 versions risquent d’avoir du mal à coexister…
Hum, l’idée est bonne mais il y a peut etre des pièges. Par exemple pour l’usage de librairies prévues pour une autre version, ou attendant une classe dans une version autre que celle correspondante à la JVM courante.
J’avoue être novice dans ce genre de problèmes mais je suspecte que si solution simple il y avait elle serait déjà appliquée de partout. Même .Net n’a pas intégré une telle chose, malgré sa jeunesse, il doit donc y avoir anguille sous roche
Règle importante : si quelque chose de réfléchi parait stupide, se demander si on a bien compris la chose
lol
++
Bonjour
Je ne suis pas (pour l’instant) utilisateur de Java.
Par contre j’ai utilisé (et même développé) une solution équivalente à ce qui est mentionné dans le pointeur du premier poste, et cela marche parfaitement et même dans les 2 sens :
si chaque nouelle version garde l’ancien code, mais rajoute le code débuggé ou modifié accessible uniquement à partir de telle version, ça marche parfaitement et on peut gérer simultanément plusieurs versions différentes.. Je ne comprend pas que personne chez Sun n’ai déjà mis ça en place, moi je l’ai fait il y a plus de 10 ans pour une grosse application critique et les dernières versions peuvent toujours interagir avec les versions 1….
Et c’est FACILE à implanter, puisqu’il suffit de vérifier à quelle version on parle puis de faire des « if »… Et cela peut être la même chose même si ce ne sont pas des corrections de bugs mais des paramètres en plus, ou de significations différentes…
Donc je dirais OUI sans hésitation à la modif proposée, mais cela ne provoquerais aucune rupture :
il suffit que la première version à faire cela inclue toutes les autres (enfin les différences)….
>> Et bien en faite, vu que ce qu’ils enseignent ne marcherait plus, il seraient bien obligé d’évoluer je pense.
Ils utiliseront simplement un JDK plus ancien…
>> Et en ce qui concerne les différents API/framework, je pense que la plupart sont quand même assez à jour. Non ? Un exemple ?
Jakarta Commons Collections est compatible avec le JDK 1.2 !
Elle serait donc probablement impacté par une rupture dans l’API Java (par exemple car elle utilise
qui a été « remplacé » par
).
Remarque d’ailleurs que cette API n’a pas été upgradé pour profiter des avantages des Generics contrairement à l’API de Collections standard (en réalité il y a un portage sur sourceforge mais indépendant de Jakarta).
>> Quand je dis « assez à jour », je veux dire qu’ils sont écrits au minimum avec la version 1.4 de java.
La plupart des autres APIs du projet Jakarta sont également compatible JDK 1.2…
>> Il me semble que les méthodes dépréciées sont valables pour 3 versions de la jdk par exemple.
Non. Enfin il ne me semble pas…
Mis à part quelques rares occasions, les méthodes dépréciés sont conservées. Il est juste indiqué qu’elles « pourraient » disparaitre dans une version future…
a++
Il me semble que les méthodes dépréciées sont valables pour 3 versions de la jdk par exemple.
En gros, si c’était bon en 1.2 puis déprécié en 1.3, cela sera encore bon en 1.6 mais plus en 1.7.
Ce qui devrait laisser de la marge.
« faire une rupture ne changera pas grand chose au niveau de l’enseignement »
Et bien en faite, vu que ce qu’ils enseignent ne marcherait plus, il seraient bien obligé d’évoluer je pense.
Et en ce qui concerne les différents API/framework, je pense que la plupart sont quand même assez à jour. Non ? Un exemple ?
Quand je dis « assez à jour », je veux dire qu’ils sont écrits au minimum avec la version 1.4 de java.
Il ne faudrait peut être pas faire une rupture avec toutes les versions passées, mais plutôt avec les versions inférieurs à la 1.4 (non inclue). Et quand la 8 sortira, et bien on « oublie » la 1.4.
nicØB >> Il s’agit plutôt d’un problème du coté de l’enseignement qui n’évolue pas aussi vite.
Lorsque j’étais étudiant j’avais également remarqué cela pour le langage C…
Mais le fait de faire une rupture ne changera pas grand chose au niveau de l’enseignement, mais pourrait faire peur aux entreprises…
ZedroS >> Lorsqu’il y a des incompatibilités entre deux versions de la JVM, elles sont détaillés dans la documentation, par exemple pour Java 6 : http://java.sun.com/javase/6/webnotes/compatibility.html
Mais elles sont généralement assez limitées dans leurs impacts. Le principal problème que je voulais soulever c’est que dans certains cas les incompatibilités seraient telles que la correction/modification n’est tout simplement pas prise en compte.
Quand aux migrations, il faut avouer qu’elles ne sont pas si complexe que cela (et justement grâce à la compatibilité ascendante).
Pour info nous avons presque fait la même migration que toi, c’est à dire une application web Java1.4/J2EE 1.4 vers Java SE 5.0/Java EE 5.0, et nous n’avons vraiment eux qu’un problème concernant la méthode
dont les spécifications n’était pas précise sur le comportement exacte, et dont la version de Tomcat que nous utilisions était incorrecte…
Mais l’application migré étant assez ancienne, j’imagine mal ce qui se serait passé s’il y aurait eu une rupture dans la compatibilité…
a++
Allez, juste pour illustrer la force de la chose : nous avons récemment passé une application web 1.4 en 1.6. Aucune modification à faire, tout a compilé et pas de bug à l’usage. Par contre, côté perf, que du bonheur. Il y avait justement un soucis sur un point spécifique et la simple montée de version a tout résolue. Bref, client et développeurs 200% satisfaits !
Après, je ne suis pas au courant des subtilités du genre ‘bug laissé en état car risquerait de casser des applis’. Je trouve ce point là très dommageable et il gagnerait à être modifié en disant clairement que suite aux remontées de bug les corrections nécessaires seront réalisées (et d’ailleurs cela devrait encourager à remonter des patchs et/ou à prévoir des solutions de contournements susceptibles de fonctionner aussi une fois le bug corrigé).
Quand à la gestion des deprecated, je trouve que laisser ce genre de classes/méthodes dispos sur 3 générations de JDK est une bonne chose. Ainsi on limite le nombre de mises à jour importantes à faire et on peut faire profiter aisément de montée de version pour des applications au gout du jour. Une bonne chose je trouve donc. Sans parler du fait que des EDI de type Eclipse (gratuit !) signalent d’emblée ce genre de choses…
Personnellement, je pense que ça serait une bonne idée de faire une rupture.
Quand on veut s’initier à Java, on se retrouve devant un ensemble de classes/interfaces & cie assez … impressionnant. Enlever ce qui est obsolète, ça serait une bonne chose car moins de risque de se trompé. Par exemple les classes Vector, HashTable, etc.
De plus, cela obligerait peut être les enseignants à se remettre au goût du jour. Dans mon école on nous apprend java en version … 1.2. Quand j’étais en DUT c’était pareil. Vu que j’utilise la version 6 ça m’a quelque peu surpris.
Au programme, on voit les Vector, HashTable, enfin bref tout ce qui est dépassé et sans entendre parler des classes qui les remplacent, comme ArrayList, HashMap.
Le prof dans tout ça n’a d’ailleurs aucunes notions là dessus puisque je viens de lui apprendre en TP que cela existait. Du coup, en installant la dernière JVM, il se serait bien rendu compte de lui même qu’il n’était pas à la page (bien que ça soit à lui de se renseigner … dans un monde parfait).
Le résultat ? On apprend des choses inutiles et on participe, sans le savoir et le vouloir, à la « non évolution » des programmes écrits en Java.
Etant étudiant c’est tout ce que je peux dire.
> c’est pas ce que vincent semble dire et je crois qu’on en a tous plus
L’outil utilisait une méthode disponible uniquement dans le JDK 1.5. Donc, fonctionnait pas si on exécutait le programme sous JDK 1.4.
> ou moins fait l’experience dans la rédac avec un outils … donc j’ai
> des doutes quand même
Le problème avec l’outil, c’était un problème de compatibilité descendante et non ascendante
C’est comme si vous vouliez faire tourner du .NET 3 sous .NET 2. Sûr que cela ne marchera pas.
P.S. T’installe toujours Windows 98 sur ta machine toi pour faire tourner de vieux programmes ? Ou bien t’es content que MS essaye de faire que les Windows aient une compatibilité ascendante, même si marche pas dans 100% des cas ? Personnellement, je n’ai que JDK 6 sur mon PC. Et la majorité de mes programmes Java fonctionnent encore.
>> Les entreprises qui restent actuellement en 1.3 continueront à utiliser 1.3, qu’on supprime ou non la compatibilité ascendante…
Si les entreprises ne changent pas de version c’est avant tout qu’elles n’ont pas ce besoin. Elles préfèrent donc adopter une attitude passive plutôt que de tenter une migration pas forcément simple malgré la compatibilité ascendante…
Mais si on rentre dans une rupture, la migration n’en deviendrait que plus complexe et donc plus couteuse… et cela retarderait encore plus la migration : on se retrouverait avec une différence encore plus marqué !
Il n’y a pas trop d’info là dessus…
Tu peux te faire une idée avec les sondages du forum :
Mais je crains qu’ils ne représentent pas forcément le monde de l’entreprise…
a++
ya t’il quelqu’un qui aurait des chiffres sur le nombre d’entreprise qui utiliseraient des version du JDK ou JRE inferieure à 1.4 ou à 1.3
« ®om >> On est d’accord sur le fait que la compatibilité ascendante est du « best effort » et pas du 100% (et cela ne pourra jamais l’être).
Mais tu dis toi même qu’un grand nombres d’entreprise utilisent encore des vieux JDK ! Qu’en serait-il si la compatibilité serait cassé ??? »
Justement, je pense que la compatibilité ascendante n’est pas (si) utilisée (que ça) dans les entreprises, et donc qu’on s’impose des contraintes pour rien… Les entreprises qui restent actuellement en 1.3 continueront à utiliser 1.3, qu’on supprime ou non la compatibilité ascendante… Donc autant la supprimer.
Certes, c’est un peu caricatural, mais c’est l’idée…
En tout cas le sujet passionne les foules ! Et c’est bien
subzero82 >> Le problème vient surtout pour des méthodes/fonctionnalités existantes non deprecated.
Deprecated est justement une solution à ce problème : en déclarant deprecated des méthodes, on propose généralement une solution alternative qui utilise une implémentation différente. Cela permet une compatibilité ascendante car les anciens programmes continueront à utiliser les méthodes deprecated avec l’ancien code…
Toutefois ce n’est pas toujours une solution… notamment lorsqu’on doit respecter une interface…
®om >> On est d’accord sur le fait que la compatibilité ascendante est du « best effort » et pas du 100% (et cela ne pourra jamais l’être).
Mais tu dis toi même qu’un grand nombres d’entreprise utilisent encore des vieux JDK ! Qu’en serait-il si la compatibilité serait cassé ???
De plus bien généralement le passage ne se fait pas de manière préventive (c’est à dire qu’il ignore complètement s’ils auront des problèmes de sécurité et remettent simplement le passage à plus tard).
De plus en cas de rupture, cela voudrait dire qu’une grande partie des API externes existantes ne seraient plus utilisables à moins d’effectuer le portage… et tu penses que dans de tels conditions les entreprises se précipiteraient pour migrer leurs applications ??? Ce serait pire car cela obligerait à maintenir plusieurs versions selon le JDK cible…
Olivier >> Pourtant, même si elle n’est pas prôné pour .NET, il y a également des efforts pour assurer la compatibilité ascendante.
Ce n’est pas nouveau ni limité à Java, mais bien commun à tous les langages. Le nouveau problème étant que les langages s’accompagnent désormais d’une API bien plus conséquente. .NET est moins frappé par le problème, entre autre du fait de sa jeunesse… mais il n’en sera pas toujours ainsi.
Pour finir je vais prendre un exemple en C : ce n’est pas pour rien si la fonction gets() si dangereuse n’a jamais été supprimée : un grand nombre de programme n’aurait tout simplement plus fonctionné ! Cela aurait pourtant été fort utile !
a++
>> Penses-tu vraiment qu’il soit logique pour un utilisateur de télécharger et installer le runtime 2.0 s’il a déjà le 3.0 ???
nan, pasque le 3.0 est une surcouche du 2.0 :mouarf:
nan sérieux, je la compatibilité ascendante … je trouve ca absurde … tout simplement que je plaind le pauvre dev de la JVM, puisqu’il est bien question de la JVM au départ … qui doit s’amuser à jongler avec les versions … et dedans ca doit être, pardonnez moi l’expression, un beau bordel.
imagine si le dev de java dure encore 50 ans … donc on va dire une bonne 20aines de versions … s’il faut gérer 50 ans de versions successives pour avoir un code compatible meme avec la première version de la JVM … c’est uthopique … et la dessus je rejoint en partie subzero82. c’est pas possible … ou alors ta jvm fait 2Go
subzero82, je suis totalement d’accord avec toi, une rupture s’imposerait (pas à chaque version, mais là ça serait utile), même si elle n’aura jamais lieu…
Déjà tout Swing qui utilise des Vector (paye le prix de la synchronisation à chaque get), et toute l’ancienne api des collections (qui fait double emploi, et qui n’est plus à utiliser – Hashtable, Vector, Stack…).
Mais, au-delà des anciennes api, il y a même des éléments syntaxiques incorrects : synchronized.
En effet, depuis java 5.0 il y a l’introduction de java.util.concurrent et de son interface Lock / sa classe ReentrantLock, qui permet de combler le problème de synchronized.
La synchronisation sur un moniteur Object ne permet de n’utiliser qu’une seule variable condition, ce qui est totalement stupide. Du coup on se retrouve à mélanger des synchronized utilisés pour l’exclusion mutuelle et les Locks pour pouvoir utiliser plusieurs conditions.
Et le pire, c’est que comme forcément, comme tout objet, Lock hérite de objet, il contient des méthodes wait() et notify(), mais il faut utiliser await() et signal()… (ça fait office de double moniteur).
Tout ça pour dire qu’à terme (et on est peut-être déjà au terme), cela peut nuire au langage…
Surtout que la compatibilité ascendante, c’est du « best effort », mais c’est pas du 100%… et si ça n’est pas du 100%, ça n’atteint pas son but : les entreprises utilisent encore des jre 1.3 ou 1.4 pour faire tourner leurs anciens programmes, alors qu’ils pourraient installer 6.0 si la compatibilité était 100% ok…
Et comme pour des pbs de compatibilité ils utilisent 1.3, les nouveaux programmes se trouvent aussi écrits en 1.3… et ça n’évolue pas…
Donc autant faire une rupture…
ça améliorerait les performances, les phases d’apprentissage pour les débutants, et corrigerait des bugs…
apparement je n’arrive pas à serné le problème de manière clair. par les methodes obselète dans mon message precedent, je désigné un exemple mais l’outils doit faire plus.
je n’arrive pas à localiser le problème mise à part les méthodes depricated; ou se situe le vrais problème ??? au niveau des interface graphique ????? dans l’interpretation du byte code ???
ya bien un endroit ou sa bloque vraiment non ????
>> Par l’assitance, j’opterais pour un soft capable d’analyser un code source et d’identifier les methodes devenue obselète et proposer une alternative. ainsi, le coût de la remise à niveau de l’application serait reduit.
Le problème c’est que cela ne concerne pas seulement les méthodes obsolètes (deprecated). Ce n’est que la partie visible du problème, et il est d’ailleurs facile de les détecter et remplacer avec le compilateur et l’API.
Prenons un exemple : je pense qu’on est tous d’accord pour dire que le LookAndFeel par défaut de Java (metal) est assez « moche », et ce malgré le nouveau style qu’il a reçu pour Java 5.0.
Il existe pourtant un grand nombre de LookAndFeel pour Java très réussi, qui auraient pu avantageusement le remplacer…
Seulement cela aurait provoqué des incompatibilités certaines avec des applications qui se basent sur ce LookAndFeel en particulier, par exemple en placant et dimensionnant les composants « à la main » sans utiliser de LayoutManager…
Alors que le nouveau style apporté par Java 5.0 est 100% compatible car il conserve les mêmes proportions au pixel près, ce qui n’est pas le cas lorsqu’on utilise un autre LookAndFeel…
Avec une API de compatibilité, un nouveau LnF pourrait être intégré, et utiliser directement par défaut pour toutes les nouvelles applications, alors que les anciennes applications continueraient à utiliser l’ancien LnF…
a++
Slt tout le monde,
cette discussion est vraiment passionante.
pour am part, je croix qu’une rupture est inévitable pour le bien de JAVA. la JDK ne peut pas porté indéfiniment le poid des bugs identifié dans ces version precedente.
Au risque de paraitre un radicale, je pense qu’une rupture doit ce faire, mais en apportant assistance au à ceux qui maintiennent des applications tournant sur des JVM plus ancienne.
Par l’assitance, j’opterais pour un soft capable d’analyser un code source et d’identifier les methodes devenue obselète et proposer une alternative. ainsi, le coût de la remise à niveau de l’application serait reduit.
qu’on dite vous ??,
>> c’est pas ce que vincent semble dire et je crois qu’on en a tous plus ou moins fait l’experience dans la rédac avec un outils … donc j’ai des doutes quand même
Oui c’est sur que cela ne pourra jamais être parfait, mais cela pourrait permettre d’améliorer cette compatibilité
Grosso modo cela permettrait à chaque nouvelle version d’incorporer les différences avec les précédentes. Au lieu d’avoir 4 frameworks tu n’en aurais plus qu’un seul complété du code des différences avec les versions précédentes…
>> pi si je distribue l’appli en ligne, l’installeur te donne le lien du runtime s’il est pas sur la machine de toutes façons :mouarf:
Penses-tu vraiment qu’il soit logique pour un utilisateur de télécharger et installer le runtime 2.0 s’il a déjà le 3.0 ???
a++
>> Justement cela ne fonctionnera pas de manière imprévue, puisque tu pourrais choisir l’implémentation selon tes besoins (ancienne version pour cibler plus large, ou version récente pour profiter de fonctionnalité qui casse la compatibilité).
c’est pas ce que vincent semble dire et je crois qu’on en a tous plus ou moins fait l’experience dans la rédac avec un outils … donc j’ai des doutes quand même
>> Cela dépend du type d’application que tu distribues. Tu ne peux pas forcément déployer toutes les versions du framework et te les trainer derrière toi. Qu’en est-il si tu distribue l’application en ligne ? Qu’en sera-t-il dans quelques années ? Tu vas continuer à installer le premier framework juste pour quelques applications ? Sans oublier qu’au bout d’un moment ils ne seront plus supportés…
Une API de management pourrait être tout à fait transparente pour le developpeur, et permettrait simplement d’indiquer à la machine virtuelle quel « version » du code utilisé. Il n’est pas question de manager le code
nan, certes, mais je pense qu’avec 4 versions du framework (1.0, 1.1, 2.0 et 3.0) … j’ai pas énormémént de travail … et qui plus est, j’essaie de faire en sorte d’écrire mes applis pour le dernier framework … en 1.1 j’ai plus grand chose.
pi si je distribue l’appli en ligne, l’installeur te donne le lien du runtime s’il est pas sur la machine de toutes façons :mouarf:
>> ben je préfère un code qui marchera de façons prévue que de façon imprévue …
Justement cela ne fonctionnera pas de manière imprévue, puisque tu pourrais choisir l’implémentation selon tes besoins (ancienne version pour cibler plus large, ou version récente pour profiter de fonctionnalité qui casse la compatibilité).
>> donc limite je m’en fiche un peu de la compatibilité ascendante et le client aussi.
Cela dépend du type d’application que tu distribues. Tu ne peux pas forcément déployer toutes les versions du framework et te les trainer derrière toi. Qu’en est-il si tu distribue l’application en ligne ? Qu’en sera-t-il dans quelques années ? Tu vas continuer à installer le premier framework juste pour quelques applications ? Sans oublier qu’au bout d’un moment ils ne seront plus supportés…
Une API de management pourrait être tout à fait transparente pour le developpeur, et permettrait simplement d’indiquer à la machine virtuelle quel « version » du code utilisé. Il n’est pas question de manager le code.
a++
>>>> Au moins avec la méthode dotnet on est sur à 100% que l’application tournera de la même manière quelque soit les futures versions de .NET installées sur la machinne.
>>Ceci est également possible en java, mais comme je l’ai dit ce n’est pas de la compatibilité ascendante.
ben je préfère un code qui marchera de façons prévue que de façon imprévue … donc limite je m’en fiche un peu de la compatibilité ascendante et le client aussi. comme je l’ai dit plus haut … je préfère occuper mon disque avec 30 … allez 50megas de plus par version du runtime (java ou .net) mais être sur du résultat
>> Par contre utiliser une API de compatibilité dans ces cas là pourrait être intéressant…
je suis pas sur … pour allourdir encore le processus de développement, déploiment et au final l’éxécution
sinon c’est plus du managé ton code … si tu dois manager celui qui manage … on est pas sortis
>> ça c’est la théorie, mais il semble qu’en pratique ça soit pas aussi simple d’aprés les différents retours.
En pratique la compatibilité n’est jamais simple !
Toutefois avec Java il y a une volonté pour la préserver au maximum.
>> Au moins avec la méthode dotnet on est sur à 100% que l’application tournera de la même manière quelque soit les futures versions de .NET installées sur la machinne.
Ceci est également possible en java, mais comme je l’ai dit ce n’est pas de la compatibilité ascendante.
Pour moi ce n’est pas forcément une meilleure solution (ni une plus mauvaise d’ailleurs). Chacune aillant ses avantages et ses défauts.
Par contre utiliser une API de compatibilité dans ces cas là pourrait être intéressant…
« La méthode java, permet a une application ancienne de bénéficier des améliorations des nouvelles versions, sans même avoir a compiler. »
ça c’est la théorie, mais il semble qu’en pratique ça soit pas aussi simple d’aprés les différents retours. Au moins avec la méthode dotnet on est sur à 100% que l’application tournera de la même manière quelque soit les futures versions de .NET installées sur la machinne.
Je dois vous avouer que la notion de compatibilité ascendante m’a toujours assez fait rigoler.
Il suffit de voir le nombre de personnes qui ont eu des soucis avec leur application lorsque l’implémentation du parseur SAX ou DOM a changé entre le JDK 1.3 et JDK 1.4. Du coup, c’était plus trop le même résultat.
Aussi, essayez de faire tourner un netBeans 3.2 (prévu pour JDK 1.3) sous le JDK 1.6. Beaucoup de chance que ca marche pas.
Pire encore: une méthode marquée deprecated et qui, si mes souvenirs sont bons, lève maintenant une exception si on l’appelle.
Dernier problème en date: Driver JDBC d’Oracle, compilé avec JDK 1.4, qui lorsqu’il tourne sous JDK 1.5 ne stocke pas correctement les BigDecimal dans la Database. Tout cela parce que depuis le JDK 1.5 la méthode toString() de BigDecimal ne fonctionne plus comme auparavant. Et que pour avoir le même comportement qu’auparavant, il faudrait utiliser la version toPlainString().
Je reviendrai plus tard sur ce sujet dans mon blog.
La méthode java, permet a une application ancienne de bénéficier des améliorations des nouvelles versions, sans même avoir a compiler.
vi, c’est sur, mais je trouve pas ca très « propre » de tout mettre dans le même et comme tu le dis ca freine l’évolution
puis une JVM doit peser à peu pres autant qu’un framework .Net … donc je pense que vu la taille des durs actuel ce soit un grand soucis de place … donc autant tout séparrer proprement
thesmall : Je n’ai pas d’info sur le sujet… J’ai oublié de dire que cela devrait être vrai en théorie, mais que la pratique n’est pas toujours aussi simple
Essaye d’ajouter un FocusListener pour forcer le « Select All »…
Olivier : On ne parle pas de la même chose !
En Java aussi il est possible d’utiliser plusieurs JVMs sur la même machine et de choisir celle qu’on veut utiliser (que ce soit avec JavaWebStart sans le fichier de déploiement, ou avec l’option -version:1.5 par exemple). Mais il ne s’agit pas de compatibilité ascendante puisque les applications fonctionnent sur la plateforme pour laquelle ils ont été conçus.
La compatibilité ascendante permet (normalement) d’utiliser un ancien programme sur une plateforme plus récente sans avoir à le modifier (et donc d’éviter de multiplier les versions).
S’inspirer de MS ne serait pour une fois pas une mauvaise idée …
.Net supporte plusieurs versions installé sur la même plate-forme … et la bonne version est choisie a l’éxécution de l’application. Il est meme possible de spécifier l’utilisation d’une version précise via le fichier de configuration de l’application
Bonjour,
J’aimerais préciser qu’en entreprise, nous avons développé nos application java en 1.2 et que tout récemment nous avons du la faire tourner avec un jre 1.6 !
Tout fonctionne presque parfaitement sauf un gros soucis… les grab focus ! En effet lors de l’exécution avec la jre 1.2, lors que la fonction grab focus est appelée, le contenu du composant focused (dsl pour le terme) est sélectionné (en subrillance – permet de le modifier). Et lorsque l’application tourne sur la dernière plateforme, le curseur se positionne à la fin du champ !
Assez embêtant pour les utilisateurs !
Savez-vous si c’est de l’imcompatibilité pour la fonction grab focus ?
TheSmall