Discussion :

[kpouer]

Ceci dit je viens de tomber sur un post ou certaines personnes ont tenté de cross compiler firefox sur ARM

http://markmail.org/message/kj7sen5lrwpgxkzc

Ca a l'air d'être tout une odyssée

[jabbounet]

Ca a l'air d'être tout une odyssée

il n'a pas eu de souci pour générer l'executable, simplement il est un peu gros

I've just read a subject on this newsgroup about cross compile of firefox 1.5.0.3 for ARM platform. I am actually trying to do the same and I managed to cross compile firefox without problems. But I have an other problem, the installed version of firefox is 189 Mo big

probable que tous les link se soit fait en statique et ont été incorporé a l'executable.

[jabbounet]

gcc peut être croisé oui surement mais ca reste très théorique tout ca à part si on fait un petit projet console sans dépendances.
Exemple : prend les sources de VLC, met toi sous Windows et build moi un VLC pour Mac OS X ou pour Linux.
Si tu sais faire j'ai hate d'avoir le tutorial

J'ai trouvé l'inverse tu cross compile depuis linux pour des cibles windows, ça te va?

http://mailman.videolan.org/pipermai...ch/002788.html


http://wiki.bebits.com/page/CrosscompilingFirefox
http://techbase.kde.org/Getting_Star...ross-Compiling
http://live.gnome.org/Cross%20compil...%20for%20Win32
http://developer.pidgin.im/wiki/BuildingWinPidgin (pour celui là faut aller en bas en cherchant cross)

et la un how to pour faire de la cross compilation de ce que tu veux depuis sparc si j'ai bien lu
http://linux.bytesex.org/cross-compiler.html
de windows -> linux
http://metamod-p.sourceforge.net/cro...for.linux.html

mais finalement la compilation croisé n'est pas si anecdotique même pour des applis desktop voir pour les desktop.

je n'ai pas été chercher les méthode pour mac os mais la démarche est tres certainement equivalente.

[Jedai]

Ca a l'air d'être tout une odyssée

Ca l'est : il faut pas mal de connaissance du domaine pour bien configurer un environnement de cross-compilation. Néanmoins certains acteurs du domaine essaient de faire un effort pour automatiser un peu la tâche : par exemple j'ai eu des échos que le projet Mingw Fedora bien que loin d'être parfait fonctionnait déjà pas mal pour cross-compiler de Linux vers Windows pour un effort relativement minime.

--
Jedaï

[jabbounet]

Ca l'est : il faut pas mal de connaissance du domaine pour bien configurer un environnement de cross-compilation. Néanmoins certains acteurs du domaine essaient de faire un effort pour automatiser un peu la tâche : par exemple j'ai eu des échos que le projet Mingw Fedora bien que loin d'être parfait fonctionnait déjà pas mal pour cross-compiler de Linux vers Windows pour un effort relativement minime.

--
Jedaï

Ce n'est pas si compliqué que cela, la compilation reste classique a part le fait que le compilateur te fournit un binaire au format de ta cible. ce qui est plus compliqué c'est l'édition des lien ou là tu dois avoir dans ton environnement les librairies au format de ta cible (ou alors avoir de quoi recompiler aussi ces librairies)

mais la technique n'est pas très éloignée d'une compilation classique.

et vu que quelques application desktop C++ indique la marche a suivre....



par contre j'aimerai revenir sur java et sa portabilité.

Cas numéro 1

Concernant la portabilité, il y'a un point qui m'embête au niveau du concept "compile once, run anywhere".

si je compile n'importe quelle appli du monde qui ont été conçu avec le jdk 1.4 de sun (ce qui retire toutes les applis au dessus 1.5 1.6 par exemple) avec le jdk 1.4 (je suis gentil je prend le jdk concu pour ces application )

y'aura t'il parmi nos java-istes confirmés qui lise ce post quelqu'un capable de me garantir (en mettant un main ou tout autre partie de son corps a couper) que les jar que j'ai produit avec ce jdk marcheront sans aucun soucis
avec les jvm 1.4 suivantes:

http://edocs.bea.com/jrockit/geninfo...utjrockit.html
http://docs.hp.com/en/JAVACOREDOCS/version_history.html
http://www.aonix.com/pdf/PercDatasheet.pdf
....

je conçois que la portabilité de java entre différents os ne soit pas trop compliqué (sous condition de garder la même jvm) la question est qu'en est il si je dois prendre une autre jvm que celle de sun?


Autrement Cas numéro 2. (rien a voir avec le premier)

j'ai un super périphérique tout nouveau tout beau qui se branche sur un emplacement pci express d'une carte mère.

Je souhaite que ce périphérique puisse être utilisé sous tous les OS majeur du monde grand public (utilisateur lambda) , pour cela j'ai fais la conception d'une super application desktop haut niveau en java pour utiliser ce périphérique et le configurer. simplement il me manque pour l'instant la couche driver.
Est il possible de faire ce driver en java?

Cas numéro 3 la compatibilité ascendante:

la jvm est un soft comme un autre, même si sun "garantie" une compatibilité ascendante entre 2 version, on peu trouver des gens qui ne la trouve pas excellente. ainsi qu'une liste d'incompatibilités entre chaque version.

http://www.javaworld.com/javaworld/j...-overcome.html

http://java.sun.com/j2se/1.3/compatibility.html
http://java.sun.com/j2se/1.4.2/compatibility.html
http://java.sun.com/javase/6/webnote...atibility.html
http://java.sun.com/javase/6/webnote...ompatibilities


Une question que je me pose qu'en sera t'il de la compatibilité ascendante quand java 3.0 sortira?, certains se posent déjà des questions sur son contenu et font déjà des propositions.
http://onjava.com/lpt/a/2524

[Tommy31]

Est il possible de faire ce driver en java?

Un driver non. Mais si le driver existe, il est possible de s'interfacer avec (jni).

Une question que je me pose qu'en sera t'il de la compatibilité ascendante quand java 3.0 sortira?

La prochaine version c'est la 7.0

[Luc Hermitte]

par contre j'aimerai revenir sur java et sa portabilité.

Cas numéro 1

Concernant la portabilité, il y'a un point qui m'embête au niveau du concept "compile once, run anywhere".

si je compile n'importe quelle appli du monde qui ont été conçu avec le jdk 1.4 de sun (ce qui retire toutes les applis au dessus 1.5 1.6 par exemple) avec le jdk 1.4 (je suis gentil je prend le jdk concu pour ces application )

y'aura t'il parmi nos java-istes confirmés qui lise ce post quelqu'un capable de me garantir (en mettant un main ou tout autre partie de son corps a couper) que les jar que j'ai produit avec ce jdk marcheront sans aucun soucis
avec les jvm 1.4 suivantes:

(je ne suis pas un javaiste.)
Non, il y a parfois des regressions d'une JVM à l'autre et qui sont corrigées dans la suivante.
Comme tu l'as très bien dit toi même la JVM est un soft comme un autre.

je conçois que la portabilité de java entre différents os ne soit pas trop compliqué (sous condition de garder la même jvm) la question est qu'en est il si je dois prendre une autre jvm que celle de sun?

Détrompes-toi. Va porter une application java3D vers une distribution linux où les drivers d'une carte graphique particulière ne sont pas encore disponibles ....
Attention, ce n'est pas la faute à Java!
Reste que le portage de l'application n'est pas trivial.


Et pour ta question ben ... ce sont des softs, on ne change pas de JVM impunément. Je ne saurais pas relativiser le coup d'un portage inter-JVM p/r à celui d'un portage entre compilos. Je ne suis pas sûr qu'il y ait beaucoup de monde à porter des applis d'une JVM à l'autre. Pour le C++, les sous-ensembles standard et portable sont assez bien connus vu que c'est un besoin un petit peu plus fréquent.

[millie]

y'aura t'il parmi nos java-istes confirmés qui lise ce post quelqu'un capable de me garantir (en mettant un main ou tout autre partie de son corps a couper) que les jar que j'ai produit avec ce jdk marcheront sans aucun soucis
avec les jvm 1.4 suivantes:

http://edocs.bea.com/jrockit/geninfo...utjrockit.html
http://docs.hp.com/en/JAVACOREDOCS/version_history.html
http://www.aonix.com/pdf/PercDatasheet.pdf
....

Il y a des spécifications du JRE que l'on peut trouver sur le site de Sun.
Plusieurs societés ont développés leur propre JRE avec leur propre bibliothèque standard (ou JDK).
Les plus connus sont Sun, IBM, HP. IBM a repris d'ailleurs les sources de Sun pour ensuite y faire des modifications.

Les societés ne garantissent le bon fonctionnement sur les différentes plateformes que pour leur JDK (évidemment, Sun ne va pas garantir qu'une source fonctionnant sur un JRE de Sun sous Windows va fonctionner sur le JRE d'IBM sous AIX).

On peut s'attendre à ce qu'il y ait des bugs dans les implémentations des spécifications, donc forcement, il peut y avoir des différences.
En cas de changement de type de JRE (Sun à IBM par exemple), il vaut mieux retester systématiquement toute l'application.

Ceci est le même problème avec :
- les serveurs d'applications (une méthode peut avoir un comportement différent sous Websphere ou sous Glassfish à cause d'un bug).
- le passage de gcc vers le compilateur de microsoft etc. (bibliothèque standard différement implementée)

La bibliothèque standard de Java étant très importante, il y a malheureusement plus de risque qu'il y ait une différence entre 2 implémentations.

[hugo123]

Qu'il y ait des problèmes "potentiels" c'est possible, n'empêche que pour le développeur lambda qui ne fait pas de système embarqué ca reste simple.
Perso je bosse sur windows et mon appli tourne sur 4 OS différents (AIX,SUNos,Linux,Windows) avec deux JVMs différentes (IBM et SUN) et nos clients utilisent des JRE de versions 1.4 jusque 6 sur les postes clients.

C'est quand même ce que j'appelle du "compile once, run everywhere", on pourra broutiller sur ce qu'on veut.

Ah par contre, quand j'ai bossé en C++ sur SunOs (il y a maintenant 4 ans) et qu'on a voulu faire un portage sur AIX, c'est pas passé comme une lettre à la poste. L'effort n'a pas été démentiel non plus mais il n'a été négligeable quand même.

[jabbounet]

Un driver non. Mais si le driver existe, il est possible de s'interfacer avec (jni).

===> Ok donc tu pers la portabilité dans ce cas, et tout l'intérêt de java.....

La prochaine version c'est la 7.0

je vois a plus long terme désolé.... un jour il y'aura un java troisième édition.

[jabbounet]

(je ne suis pas un javaiste.)
Non, il y a parfois des regressions d'une JVM à l'autre et qui sont corrigées dans la suivante.
Comme tu l'as très bien dit toi même la JVM est un soft comme un autre.



Détrompes-toi. Va porter une application java3D vers une distribution linux où les drivers d'une carte graphique particulière ne sont pas encore disponibles ....
Attention, ce n'est pas la faute à Java!
Reste que le portage de l'application n'est pas trivial.


Et pour ta question ben ... ce sont des softs, on ne change pas de JVM impunément. Je ne saurais pas relativiser le coup d'un portage inter-JVM p/r à celui d'un portage entre compilos. Je ne suis pas sûr qu'il y ait beaucoup de monde à porter des applis d'une JVM à l'autre. Pour le C++, les sous-ensembles standard et portable sont assez bien connus vu que c'est un besoin un petit peu plus fréquent.

Ah donc tant que l'on reste dans le standard on est portable c'est ça?

c'est comme le C/c++ alors si ton programme respecte les norme c ansi et que tu as le même compilateur sur toutes tes plate forme cible ça marchera par exemple.


tout ce bazar pour dire qu'il faut aussi respecter un certain nombre de contraintes pour être portable en java.

[jabbounet]

Qu'il y ait des problèmes "potentiels" c'est possible, n'empêche que pour le développeur lambda qui ne fait pas de système embarqué ca reste simple.
Perso je bosse sur windows et mon appli tourne sur 4 OS différents (AIX,SUNos,Linux,Windows) avec deux JVMs différentes (IBM et SUN) et nos clients utilisent des JRE de versions 1.4 jusque 6 sur les postes clients.

C'est quand même ce que j'appelle du "compile once, run everywhere", on pourra broutiller sur ce qu'on veut.

Ah par contre, quand j'ai bossé en C++ sur SunOs (il y a maintenant 4 ans) et qu'on a voulu faire un portage sur AIX, c'est pas passé comme une lettre à la poste. L'effort n'a pas été démentiel non plus mais il n'a été négligeable quand même.

ok on peux quitter l'embarqué si tu veux, je travaille actuellement sur un protocole définit par une RFC (définie par l'IETF Internet Engineering Task Force) bref un standard internet (un truc que java aime bien en gros), ce protocole définit comme obligatoire de pouvoir communiquer via TCP (la aucun problème) et via SCTP. Ma question est : Comment je fais pour faire la partie SCTP sans passer par une couche JNI ou une partie C/C++ avec le jdk 1.6 ?

[hugo123]

De prime abord j'en sais rien.
Tu veux que je te fasse une analyse de faisabilité ?
Attention mes prix de consulting sont assez élevé

(sinon t'as le forum java un peu en dessous de celui la pour poser la question ^^)

edit : première recherche sur google :

http://i1.dk/JavaSCTP/ => une solution jni effectivement
http://www.openjdk.org/projects/sctp...e-summary.html => une solution qui semble lié a une implémentation de jdk
http://sourceforge.net/projects/jsctp/ => encore du jni

ah et puis :
http://bugs.sun.com/bugdatabase/view...bug_id=4927640

effectivement sun ne semble pas encore le supporter. Je ne saisis pas bien si c'est pour des raisons économiques (pas assez d'adopteur) ou pour des raisons techniques (pas de support sur tout les OS). Quoi qu'il en soit c'est bien dommage pour toi tout du moins si tu ne veux absolument pas faire de JNI.
(le jni n'est pas forcément "sale")

a+

Edit bis : apparemment prévu en JDK 7 : http://mail.openjdk.java.net/piperma...st/000076.html
too bad

[jabbounet]

[url]http://www.openjdk.org/projects/sctp/javadoc/b09/com/sun/nio

si je ne me plante pas openjdk est tout un paquet d'évolution java non standard qui doivent a plus ou moins long terme être intégrée a java.

mais ce n'est pas du standard (pas encore), oui mais cette rfc a déjà quelques années et si on avais du attendre que sun veuille bien l'inclure dans le standard on aurais perdu des clients.

(le jni n'est pas forcément "sale")

non il te limite juste dans ta portabilité ce qui es le point fort de java....

et quand tu vend des librairies en java et que tu annonce que tu as une couche jni, tu fais peur a tes clients car il se demandent si tu supportera toutes les plateformes sur lesquels il veulent/peuvent déployer.



Bref tout ça pour dire que parfois avec java je me sens un peu limité dans ce que je peu faire, et que malgré toutes ses qualités je me sens un peu bridé quand je dois faire du java.

[hugo123]

Et oui, des fois il y a des plans qui ne se passent pas sans accroc ^^ En même temps c'est un peu notre métier que de faire du rapiécage de temps en temps, non ?

Quand au jni, ben, on est d'accord, la limitation porte sur des problèmes de portabilité de la couche inférieure... en C ou C++

A force de débattre sans fin sur ces deux languages, je prononcerais bien le marriage forcé par jni moi ^^

[jabbounet]

Et oui, des fois il y a des plans qui ne se passent pas sans accroc ^^ En même temps c'est un peu notre métier que de faire du rapiécage de temps en temps, non ?

Quand au jni, ben, on est d'accord, la limitation porte sur des problèmes de portabilité de la couche inférieure... en C ou C++

A force de débattre sans fin sur ces deux languages, je prononcerais bien le marriage forcé par jni moi ^^

C'est pour cela que java est "portable" en fait il ne veulent pas se mouiller en allant chatouiller des trucs un peu compliqué qui nécessite d'aller taper dans le matériel. ça limite son utilisation malheureusement....

[Tommy31]

===> Ok donc tu pers la portabilité dans ce cas, et tout l'intérêt de java.....

ou comment jeter le bébé avec l'eau du bain.

je vois a plus long terme désolé.... un jour il y'aura un java troisième édition.

Ton lien datait de 2002.
C'est quoi java troisième édition ?

[jabbounet]

ou comment jeter le bébé avec l'eau du bain.



Ton lien datait de 2002.
C'est quoi java troisième édition ?

un jour peu être, actuellement java en est à la seconde édition on peu supposer qu'un jour il y'aura un troisième....

jamais 2 sans trois

en tout cas les spec semblent déjà avoir été entamées
http://java.sun.com/docs/books/jls/t...tml/j3TOC.html

ne me dites pas que vous êtes pas au courant de ce qui va venir dans votre langage préféré?

il y'aura des unchecked conversion (ça va commencer a ressembler a du C )



Cependant j'aurais un autre question.....

s'il n'y a pas de pointeur en java (d'après ce que me disent certains amis java-istes), comment se fait t'il qu'il y'ai des NullPointerException?

ou alors sun a fait comme avec les enfant qui ne veulent pas manger d'épinard et leur a fait croire que c'était des choux de bruxelles ?

[adiGuba]

y'aura t'il parmi nos java-istes confirmés qui lise ce post quelqu'un capable de me garantir (en mettant un main ou tout autre partie de son corps a couper) que les jar que j'ai produit avec ce jdk marcheront sans aucun soucis
avec les jvm 1.4 suivantes:

http://edocs.bea.com/jrockit/geninfo...utjrockit.html
http://docs.hp.com/en/JAVACOREDOCS/version_history.html
http://www.aonix.com/pdf/PercDatasheet.pdf
....


je conçois que la portabilité de java entre différents os ne soit pas trop compliqué (sous condition de garder la même jvm) la question est qu'en est il si je dois prendre une autre jvm que celle de sun?

En théorie oui. Bien sûr tu peux rencontrer des bugs qui te poseront problèmes, mais c'est généralement assez rare. Pour faire le parallèle tu peux avoir le même genre de problème lorsque tu compiles du code C/C++ avec deux compilateurs différents...

Le second point problématique peut venir d'un bugs ou d'un comportement différent dans les APIs standard... mais encore une fois tu peux retrouver ceci dans les librairies d'un langage natif !


En règle général ces problèmes sont extrêmement rare...
Donc la réponse serait plutôt : OUI ca marche, mis à part quelques cas particulier vraiment rare...

Et je dirais même plus ton appli compilé avec un JDK 1.4 fonctionnera aussi sur une JVM 1.5, 6.0 et même sur le futur Java 7


Enfin, petit rappel. La compatibilité en Java se base sur deux niveaux :

• La compatibilité binaire, qui indique qu'un programme compilé avec un ancien JDK fonctionnera à l'identique sur une nouvelle JVM. C'est le niveau où la compatibilité est le plus fort, et qui permet de continuer à utiliser ses anciens programmes sans avoir à les retoucher.
• La compatibilité des source, qui indique qu'un programme conçus pour un ancien JDK pourra être recompilé sans erreur sur un JDK plus récents.

Est il possible de faire ce driver en java?

Non. La programmation système n'est pas ciblé par Java.
Par contre rien ne t'empêche de développer ton driver en natif et de packagé les diverses implémentations avec ton application Java...

la jvm est un soft comme un autre, même si sun "garantie" une compatibilité ascendante entre 2 version, on peu trouver des gens qui ne la trouve pas excellente. ainsi qu'une liste d'incompatibilités entre chaque version.

http://www.javaworld.com/javaworld/j...-overcome.html

http://java.sun.com/j2se/1.3/compatibility.html
http://java.sun.com/j2se/1.4.2/compatibility.html
http://java.sun.com/javase/6/webnote...atibility.html
http://java.sun.com/javase/6/webnote...ompatibilities

Toutes évolutions aussi minime qu'elle soit peut entrainer une incompatibilité...
Par contre elle sont quand même relativement limité. Si tu prend la temps de lire ces listes tu verras que la plupart du temps il s'agit de points ultra-spécifique...

Une question que je me pose qu'en sera t'il de la compatibilité ascendante quand java 3.0 sortira?, certains se posent déjà des questions sur son contenu et font déjà des propositions.
http://onjava.com/lpt/a/2524

Ici tu parles de supposition sur une version qui casserait justement toute la compatibilité ascendante.

C'est comme si je te disais : on supprime toutes les fonctions/classes litigieuses des librairies standard du C/C++ pour les réécrire en mieux !!! Normal que les anciennes applications ne marche plus !

Ton article (qui date quand même de 2002 ) n'est que pure spéculation !
7 ans plus tard cette "troisième édition" n'est toujours pas là mais Java a subit de grosse évolution tant au niveau du langage que des APIs...

De plus le terme "seconde édition" est plus un coup de pub bien pourri qu'autre chose : la compatibilité n'a pas été cassé du tout ! Par contre on s'est trainé des titres doublement numéroté du style "Java 2 Standard Edition 1.3"...

===> Ok donc tu pers la portabilité dans ce cas, et tout l'intérêt de java.....

Non : il est possible de développer des applications natifs tout en restant portable.
Si si je t'assure

Ah donc tant que l'on reste dans le standard on est portable c'est ça?

c'est comme le C/c++ alors si ton programme respecte les norme c ansi et que tu as le même compilateur sur toutes tes plate forme cible ça marchera par exemple.


tout ce bazar pour dire qu'il faut aussi respecter un certain nombre de contraintes pour être portable en java.

Je ne pense pas qu'on puisse comparer le C ANSI et l'API standard de Java...

si je ne me plante pas openjdk est tout un paquet d'évolution java non standard qui doivent a plus ou moins long terme être intégrée a java.

Non : openJDK est le projet de Sun suite à l'ouverture du code en GPL.
On y retrouve le JDK6 mais également les travaux sur le futur JDK 7...

mais ce n'est pas du standard (pas encore), oui mais cette rfc a déjà quelques années et si on avais du attendre que sun veuille bien l'inclure dans le standard on aurais perdu des clients.

Il y a des milliers de RFC, et tout ne peux pas être inclut en standard...

non il te limite juste dans ta portabilité ce qui es le point fort de java....

Tu peux tout à fait faire du JNI en restant portable !
Je te rappelle quand même que quelques lignes plus tôt tu assurait les qualité de portabilité du C++. Pourquoi d'un coup cela ne serait plus possible ???

et quand tu vend des librairies en java et que tu annonce que tu as une couche jni, tu fais peur a tes clients car il se demandent si tu supportera toutes les plateformes sur lesquels il veulent/peuvent déployer.

Il suffit d'indiquer les plateformes supportées.
Tu es en train de casser toi-même tes arguments sur la portabilité du C/C++ !!!

C'est pour cela que java est "portable" en fait il ne veulent pas se mouiller en allant chatouiller des trucs un peu compliqué qui nécessite d'aller taper dans le matériel. ça limite son utilisation malheureusement....

Dès le début Java N'EST PAS FAIT POUR CELA !!!

A partir du moment où tu touches au matériel tu fais du code ultra-spécifique qui devra être adapté à la cible, et je ne vois pas le problème qu'il y a à utiliser JNI et du code natif ?!


a++

[jabbounet]

En théorie oui. Bien sûr tu peux rencontrer des bugs qui te poseront problèmes, mais c'est généralement assez rare. Pour faire le parallèle tu peux avoir le même genre de problème lorsque tu compiles du code C/C++ avec deux compilateurs différents...

Le second point problématique peut venir d'un bugs ou d'un comportement différent dans les APIs standard... mais encore une fois tu peux retrouver ceci dans les librairies d'un langage natif !


En règle général ces problèmes sont extrêmement rare...
Donc la réponse serait plutôt : OUI ca marche, mis à part quelques cas particulier vraiment rare...

Et je dirais même plus ton appli compilé avec un JDK 1.4 fonctionnera aussi sur une JVM 1.5, 6.0 et même sur le futur Java 7

A condition de ne pas tapper dans les package non standard (type sun.*)

Autrement les différentes jvm cités etant developpé par des hommes ayant lu la spécification java et ayant fait un interprétation personnelle de cette norme je ne vois pas comment on peux garantir que tous les binaires compilé avec le jdk 1.4 marcheraient sur jrockit sans avoir au moins essayé par exemple.

Enfin, petit rappel. La compatibilité en Java se base sur deux niveaux :

• La compatibilité binaire, qui indique qu'un programme compilé avec un ancien JDK fonctionnera à l'identique sur une nouvelle JVM. C'est le niveau où la compatibilité est le plus fort, et qui permet de continuer à utiliser ses anciens programmes sans avoir à les retoucher.
• La compatibilité des source, qui indique qu'un programme conçus pour un ancien JDK pourra être recompilé sans erreur sur un JDK plus récents.

ok sous reserve de ne pas tomber dans un des éléments de l'incompatibilité.

Non. La programmation système n'est pas ciblé par Java.
Par contre rien ne t'empêche de développer ton driver en natif et de packagé les diverses implémentations avec ton application Java...


Toutes évolutions aussi minime qu'elle soit peut entrainer une incompatibilité...
Par contre elle sont quand même relativement limité. Si tu prend la temps de lire ces listes tu verras que la plupart du temps il s'agit de points ultra-spécifique...

mais je suis certains que si ces point existait c'est qu'ils ont été utilisé quelque part...

Ici tu parles de supposition sur une version qui casserait justement toute la compatibilité ascendante.

oui je suppose.

Ton article (qui date quand même de 2002 ) n'est que pure spéculation !
7 ans plus tard cette "troisième édition" n'est toujours pas là mais Java a subit de grosse évolution tant au niveau du langage que des APIs...

j'ai trouvé plus récent sur le site de sun, je n'ai pas regarder les compatibility considérations.

De plus le terme "seconde édition" est plus un coup de pub bien pourri qu'autre chose : la compatibilité n'a pas été cassé du tout ! Par contre on s'est trainé des titres doublement numéroté du style "Java 2 Standard Edition 1.3"...

C'est vrai qu'avec tous les acronymes qu'il y'a dans le monde java ça finis par devenir lourd non de rajouter un seconde numéro dans une liste?

Non : il est possible de développer des applications natifs tout en restant portable.
Si si je t'assure

je suis d'accord sur ce point mais c'etait pour chatouiller les javaistes.
plein de gens sur le topic reprochent a C/C++ de ne pas être portable.
je ne vois pas pourquoi sous prétexte qu'il serais utilisé avec jni il deviendrait portable comme par magie. c'est parcequ'il y a le mot java dans la phrase?

Je ne pense pas qu'on puisse comparer le C ANSI et l'API standard de Java...

posix stlv2, cela te va mieux?

Non : openJDK est le projet de Sun suite à l'ouverture du code en GPL.
On y retrouve le JDK6 mais également les travaux sur le futur JDK 7...

je suis tres limité en java donc je peux dire des conneries sur le sujet

Il y a des milliers de RFC, et tout ne peux pas être inclut en standard...

Oui, mais si on est obligé d'attendre que cela soit inclu en standard on prend du retard.

Tu peux tout à fait faire du JNI en restant portable !
Je te rappelle quand même que quelques lignes plus tôt tu assurait les qualité de portabilité du C++. Pourquoi d'un coup cela ne serait plus possible ???

ici je prenais la casquette des javaiste qui disaient le contraire, que c'était compliqué, maintenant si on met un peu de magie et que l'on ajoute java dans la phrase cela deviens portable ....

Il suffit d'indiquer les plateformes supportées.
Tu es en train de casser toi-même tes arguments sur la portabilité du C/C++ !!!

comme en C/C++

Dès le début Java N'EST PAS FAIT POUR CELA !!!

A partir du moment où tu touches au matériel tu fais du code ultra-spécifique qui devra être adapté à la cible, et je ne vois pas le problème qu'il y a à utiliser JNI et du code natif ?!

a++

je ne le vois pas non plus simplement, tu réduis le nombre de plate forme supporté tu ne fais plus de "compile once run anywhere" pour ton application vu que tu es au moins obligé de fournir les lib que tu as développé en dessous de jni pour toutes les plate formes supporté. donc tu perd le "compile once" pour ton appli ainsi que le "run anywhere"