(message pas trolleux, mais on pourrait le croire)
 
depusi toujours on me prends la tête "Java, code once, run everywhere" et des "t'en a pas marre de coder que ça marche pas partout"
 
et là je tombe la dessus
 
http://www.sun.com/smi/Press/sunfl [...] 805.9.html
 
 

 
 
l'article n'est pas clair mais ça pue...
 
le C fonctionne partout de la même façon depuis 20ans, des derniers ordinateurs à votre programmeur de machine à laver...

en JAVA, un int c'est toujours 32bits et un long c'est toujours 64bits. Si la JVM tourne sur une machine 32bits (comme nos PC), elle doit "émuler" les long grâce à plusieurs int. Sur une machine 64bits (comme l'Opteron), les long sont gérés nativement par le CPU. L'autre différence est évidement le support de plus de 4Go. En java, les changements se trouvent dans la JVM, normalement tout programme doit tourner correctement sur une machine 32 ou 64bits.
 
 
En C, la taille des int et long dépend de l'architecture, par exemple, sur nos PC, un int est en 32bits, mais un long est aussi 32bits, pour avoir de plus grands chiffres, il faut utiliser des librairies spéciales. Les pointeurs sont aussi en 32bits.
 
Lors du passage en 64bits, les pointeurs passent en 64bits et les int restent en 32bits, donc partout où on avait fait des conversions int<->pointeurs, ca devient foireux. Pour ce qui est des long, ça dépend, sous Windows avec VisualStudio, il me semble que les long restent 32bits, mais il y a des long long qui sont en 64bits. Sous Linux, il me semble que les long passent en 64bits.
 
C'est à cause de ces changements qu'en C(++) le passage d'une architecture 32bits à 64bits demande plus que de juste recompiler.
 
Et je ne te parle même pas des 286, sur lesquels les int devaient sans doute être 16bits...

pourtant cette article dit clairement le contraire !

C clair que c'est chelou ce truc... Normalement, l'utilisation de la bonne VM devrait suffir
 
Peut-être par contre parlent-il au niveau de l'optimisation ? (et encore, normalement la VM doit être capable de prendre les bonnes décisions toute seule...)
 
En Java, y'a des pointeurs avec une gestion à chier comme en C ou pas ? (parceque si oui, c'est très certainement à ce niveau que ça part en sucette, mais ça apprendra aux développeur à coder proprement)

 
Si tu lis bien, tu verras qu'il est dit qu'en s'associant avec AMD pour développer une JVM 64 bits pour windows et linux, Sun permet aux entreprises de faire tourner leurs applis java sur les plateformes 64 bit AMD... C'est bien la JVM qui change, pas les applis.

Non, ils parlent bien dans la phrase quotée du code de l'appli, pas de la JVM.

Oui mais il disent bien "avec peu ou pas de changements au code". Evidemment, c'est le "peu" qui est suspect, mais je pense que c'est surtout une formule de prudence pour ne pas se faire reprocher les quelques cas tres particuliers qui pourraient nécessiter une modif du code.

ben oui, mais ça veut bien dire ce que ça veut dire. je suis désolé, la plus part des appli 32bits à peu ou pas de changements touneront aussi sur des architectures 64bits.

En C/C++ tu veux dire ? Ben ouais, à condition de pas avoir fait nimp avec les pointeurs comme disait deltaden. Et puis il faudra les recompiler   En java, sauf cas très particulier, ca reste "compile once, run everywhere"

ben le cas particulier devrait pas exister. ce que tu reproches au C/C++, ben Java a apparemment exactement le même problème. donc en java aussi faudra recompiler.

De toute façon, le C# c'est encore mieu y'a pas besoin de modifier une ligne
 
Et on peut choisir si on veut des int16, int32 ou int64... Que demande le peuple ?

et c'est le premir langage portable qui marche que sur une seule plateforme  

en tout cas, moi qui déjà avait du mal avec Java, là je crois que c'est ce qui va faire pencher la balance...

Mais nan, y'a des framework pour x-like depuis le temps. Ils sont pas forcément finalisés, mais déjà exploitable
 
M$ l'a indiqué depuis le départ : ils ont écrit le langage et ses spécifications dans l'optique du multiplateforme, mais n'assurent les développement que sous Windows. Après, si personne n'a envie d'écrire un framework pour tel ou tel OS, bah M$ n'y peut pas forcément grand chose : ils ont posé les règles dès le départ.

et on tout breveté à fond, engagé des centaines d'avocats pour chercher des poux à Monon.Net ... enfin bon, là n'est pas le sujet.

Bah ils ont breveté pour s'assuer, comme Sun l'a fait avec Java, que personne ne va décider "tiens, cette fonction elle serait mieu comme ça, et pis tiens, je vais rajouter celle là, et maintenant c'est plus portable".
Pourquoi M$ a perdu son procès contre Sun quand ils ont fait ce genre de bidouilles avec VJ++, c'est tout simplement parceque Sun a lui aussi déposé un brevet pour chaque ligne de spec.

tout ça puxor
 
perl et python sont libres, sur VM et n'ont pas tout ce genre de problème à la con

Il ne faudra PAS recompiler, les changements sont uniquement présents dans la JVM!
Quand tu compile ton prog java, il va utiliser des entiers 32 ou 64bits, ensuite, c'est lorsque la JVM compile le bytecode en langage machine qu'elle agit différement pour les long, ce n'est absolument pas le problème du prog java. Même chose pour les pointeurs, le bytecode, il sait même pas ce que c'est des pointeurs, c'est enore une fois le problème de la JVM.
 
Tous les programmes sont sensés marché directement, sans recompilation, d'ailleurs, c'est déjà le cas quand on fait tourner des progs java sur des machines 64bits actuelles (Sparc sous Solaris,...).
Comme l'a dis R3g, le "peu" est juste une formule de prudence, car il peut y avoir des cas spécifiques (comme l'utilisation de JNI mais ce n'est plus de la faute de Java...)
 
Pour ce qui est du C(++), il faudra recompiler, et il peut y avoir des problèmes si ce n'a pas été codé correctement.

je pense pas qu'on parle de JNI là

peut-être pas, mais de toute façon, je suis sûr qu'il s'agit du formule de prudence, on ne sait jamais ce qui peut arriver.

ben je croyais que le coup de la VM, c'était justement de prévoir ce jamais. si y a des implémentations de la VM qui suivent pas les critères de la VM...

he bien considère que ça prévoir ce jamais, il s'agit d'une annonce du département marketing, pas d'une interview d'un ingénieur qui s'y connait...
 
Je te signale que en C(++), il faut aussi attendre que les libs utilisées soient également portées, débuggées, validées, ensuite on peut seulement suivre le même cheminement pour ses propres programmes...

dans le cas du passage du 64 bits au 32 bits y a quand même des petites différence.
 
exemple :  

sur une plateforme 64 bits, l'affectation est atomique. Sur une plateforme 32 bits, il faut entourer cette opération d'un bloc sycnhronized car elle ne l'est pas ...
 
Pour ce cas là, le passage de 32 à 64 ne pose pas de problème (dans l'autre sens ca en poserait bcp, ou par exemple passage de 32-> 16 ), mais c'est peutr être pour ce genre de cas qi'il peux y avoir des trucs foireux

euh on a pas du suivre le meme cours sur l'atomicité...
 
en tout cas, ça n'entraine pas de changement dans ton code

Mmm.. tu es sur de ça ? j'aurais pensé que ce genre de chose était géré par la jvm justement ; que du point de vue de ton programme, une telle affectation était toujours atomique, quelque soit le type concerné.

ouais ouais je suis sûr ... 2 sec, je cherche la référence ...
on a déjà eu tout un débat la dessus au boulot !
 
edit : http://java.sun.com/docs/books/jls [...] html#28733

qu'est ce que tu veux dire ?

en java, je sais pas, mais c'est loin d'être atomique niveau processeur

une écriture d'une valeur de 32 bits ? pkoi ce serait pas atomique ?
 
je te parle pas de l'affectation en elle même (parce qu'il y a aussi la partie lecture), mais juste de l'écriture...
 
je disais que c'était atomique parce que tu risque pas ed te retrouver avec une valeur foireurse (genre moitié d'un int au début et moitié d'un autre int à la fin).
 
pareil pour l'affectation d'objet : si l'affectation (je parle juste de la copie des adresse mémoires là) n'était pas atomique, ca voudrais dire qu'on pourrais se retrouver avec des adresses foireuses ... ce qui ne peux pas arrivé sur ne archi 32 bits puisque l'écriture d'un bloc de 32 bits se fait en 1 fois.

ben oui mais y a pas que ça! c'est pas que l'ecriture, y a toutes les opérations avec les registres et la mémoire...  
 
enfin bon, fini la digression

donc toi tu me dis que quand tu fais o1 = o2, dans une apli multithreadé, tu peux te retrouver avec une un peu n'importe quoi dans o1 si on était en train de faire o1 = o3 au même moment dans un autre thread.
(sachant que o1 et o2 sont des objets)
 
pour moi, on aura o1 vaudra soit o2, soit o3 ... c'est ca que je voulais dire par atomicité de l'affectation ... tu crois que c'est pas le cas ?

peut etre pas n'importe quoi mais en tout cas je pense que c'est n'est pas prévisible lequel ça sera. sinon ça serait trop facile

 
Faut vraiment etre credule pour croire Microsoft de si bon coeur et que .NET est un framework multiplateforme puisque ca tourne que sous Windows.
Je te rappelle que Microsoft ne file pas les sources donc tu es oblige de tout redevelopper gratos pour ta plateforme et d'etre a la botte de MS puisque c'est eux qui decident comment les API evoluent (que l'on ne me parle pas de la pseudo standardisation). Etre a la botte de MS j'en connais pas beaucoup que ca fait juir...
 
Depuis le depart ils savent qu'il n'y aura pas d'implementation a la hauteur, c'est tres bien ca permet de concerver le monopole et en plus ca permet de convertir quelques personnes qui pensent que c'est un framework ouvert et multiplateforme.
 
edit - j'avais pas lu ce monument:

Assurer quoi ? c'est pour mieux niker ceux qui deviendraient trop genants tout simplement
Je suis curieux de savoir quels brevets Sun a utiliser lors du proces contre Microsoft. Apparemment tu as l'air vachement renseigne et tu vas nous sortir les liens de ce que tu avances.

  merci, je le note.

que ce soit pas prévisible ca ok, c'est pas bien grave. Ce qui est important c'est que ca n'écrive pas la moitié des deux. C'est ca que je veux dire quand je dis que l'écriture n'est pas atomique.
 
Pour un long, par example, c'est pas garntit !

ouais c'est très peu connu et pourtant c'est vachement important !!
 
ca doit être la cause de pas mal de bug ! imagine : à chaque fois que tu fais une copie de long ou de double dans une appli multithreadée et que tu oublies de synchronizer cette copie, potentiellement, ca peut complétement foirer sa valeur !!

oui mais bon, en mutli-thread, le moindre oubli de synchronisation est dramatique.

bha oui bien sûr ...
 
c'est pour ca que comme ce truc est très peu connu, à mon avis ca doit pas être rare de faire des bigs là dessus : c'est loin d'être évident qu'il faut synchronizer une ligne du style a=b;
 
mais c'est marrant ta remarque : on dirait que les applis multi-threadées te font très peur ... en Java ca se fait assez facilement...

ta mère t'as jamais appris manipulation varaible partagée -> mutex ?  

ton père t'as jamais dis que c'était pas nécessaire si l'opération était atomique ?