Romain Guy a écrit 196 commentaires

Ce n'est pas vrai. Tu peux utiliser la plateforme Java en Python, en Ruby, en Prolog, en LISP, en BASIC, en SmallTalk, en Eiffel, etc. Voici une belle liste regroupant tous les langages connus pour fonctionner sur la plateforme Java : http://www.robert-tolksdorf.de/vmlanguages.html(...) Il s'agit soit d'interpréteurs, soit de compilateurs. Bref ne confondons pas le langage Java avec la plateforme Java :)

N'oublions pas deux nouveautés assez sympa (surtout la seconde) :
- la possibilité d'écrire des flottants sous forme hexa
- la possibilité de changer le type de retour d'une méthode surchargée si le nouveau type est un descendant de celui d'origine. En clair une classe Voiture pourra enfin avoir une méthode clone() retournant une Voiture et non plus un Object. Pratique pour éviter d'autres transtypages fastidieux :)

Je me suis laissé emporter, pardon. Ceci dit Sun aura du mal à trouver de bonnes raisons pour refuser la participation de quiconque :)

Malheureusement je dois avouer que je n'ai jamais essayé car la VM de Sun m'a toujours suffit. Je sais par contre que des utilisateurs s'en servent sous NetWare par exemple, et je ne pense pas que Sun fournisse une telle JVM. D'autres s'en servent sous MacOSX... ce n'est pas Sun qui s'occupe de cette VM (même si ils ont aidé), etc. Soyons honnête, c'est surtout la VM de Sun qui est utilisée mais ce n'est pas impossible de s'en passer, juste chiant ^^

Mea culpa, je me repends derechef pour cette grossière erreur. A trop ouvrir sa bouche on finit par dire des conneries ^^

Non c'est faux. Le commité exécutif est composé de 15 sièges, dont un réservé à Sun. Ce commité est élu régulièrement (chaque année jusqu'à 5 sièges sont élus). Si tous votent contre Sun crois bien que la décision sera appliquée. Tu devrais lire les différents documents présentant le JCP sur le site officiel.

Oui je suis d'accord pour la question de fiabilité avec la vérification à la compilation. En fait ce problème est rarement abordé dans tous les documents que j'ai pu lire car, et mon expérience me l'a prouvé, il est finalement assez rare de se tromper de type dans une liste. Bien évidemment ça arrive et c'est mieux de le voir à la compilation :) Mais tu le dis toi-même, ce sont principalement les transtypages qui disparaissent, rendant le code bien plus clair.

Malheureusement les generics, sous une apparente simplicité, cachent de nombreuses subtilités qui ne seront pas forcément toutes aisément assimilables par les débutants (le fameux joker ?).

La plupart des nouveautés proviennent des JSR émises au sein du JCP. Lorsque j'avais interviewé James Gosling, l'un des pères de Java, au sujet de Java 5 il m'avait bien précisé qu'il n'aimait pas du tout l'autoboxing ou les generics.

Ces nouveautés sont donc la volonté de la communauté et non de Sun, qui se doit malgré tout de communiquer positivement à ce sujet, quel que soit leur avis.

Il y a deux choses que j'aimerais mettre au clair après lecture de la news et des commentaires.

Premièrement les generics ne correspondent pas aux templates du C++ même si leur syntaxe y fait penser. Renseignez-vous sur ce sujet, notamment en lisant les critiques formulées par Bruce Eckel, et vous constaterez que les generics servent principalement à l'autoboxing et pas à grand chose d'autre.

Ensuite concernant le paquet java.util.concurrent il ne s'agit pas d'une initiative de Sun, mais de Doug Lea qui a proposé cette extension en créant une JSR au sein du Java Community Process (voir http://www.jcp.org(...)). Puisque la communauté l'a soutenu, car il est vrai que le modèle d'accès concurrents n'était pas terrible malgré le synchronized, on retrouve ça dans le SDK.

Java 5 n'est pas révolutionnaire car on y trouve surtout des raccourcis syntaxiques. Le problème vient du fait que beaucoup essayent d'y voir une révolution, comme les fameux generics, quand il ne s'agit que d'améliorations censées accélérer un peu le développement sans pour autant le bouleverser. La seule chose réellement novatrice que l'on retrouve dans Java 5 est, à mon avis, le concept des metadata, bien qu'il ne soit pas du tout spécifique à Java. D'ailleurs Python 2.4 propose la même chose :-)

C'est compréhensible mais avoue que l'on pouvait difficilement faire l'impasse sur JavaOne 2004 et PHP5 qui étaient deux gros événements :-)

Très instructif : http://www.sunsource.net/(...)

Ce n'est pas si étonnant, Apple et Sun s'aiment bien. Lors de JavaOne 2004 il y a eu un match de hockey entre Sun et Apple (la Word Wide Developer Conference d'Apple se tenait à environ 70m de JavaOne :-). Et de plus en plus de développeurs Java semblent se tourner vers MacOS X.

Pour Mono, ça se passe avec iKvm.

[quote]Kwé ? D'un autre côté, Sun demande la suppression de tous les API Sun (J2SE, J2EE et J2ME) du site jdocs. Dommage ![/quote]

On trouve ça tous dommage mais ce que faisait JDocs.com avec la doc de J2SE allait à l'encontre de la licence que tu acceptes lors du téléchargement de cette doc. Rick Ross et Matt Schmidt modifiait ainsi le contenu de la documentation sans permission. Heureusement il y a aujourd'hui une parade : la doc est affichée dans une frame en haut et les notes en bas. C'est moins pratique que pour les autres APIs mais c'est mieux que rien. Et ils continuent à faire pression sur Sun :)

Ca tombe bien, ce n'est pas du tout le rôle de ANT ^^ Make ne sait pas plus synchroniser des textes gratuits que je sache. Pour y remédier il faudrait utiliser des outils de diff XML je pense.

A qui as-tu écrit ? A Pilgrim ou au responsable de la version française ? J'y avais participé à l'époque et ça se passait très bien donc à moins qu'il n'ait changé d'adresse mail je vois peu de raisons pour un tel silence. Tu peux toujours télécharger les sources de Dive Into Python sur le CVS du projet SourceForge. En attendant une éventuelle réponse tu pourras déjà te familiariser avec le système de compilation, basé sur ANT, Docbook XML et Saxon (enfin du moins, était :-).

Cela va certainement relancer leur adoption mais les specs telles que présentées par le draft actuel me semblent encore un peu compliquées par rapport aux critiques que les développeurs formulent à l'encontre des EJB. Beaucoup de ces critiques sont dirigées contre les EJB persistants avec les annotations contenant du code SQL ou l'utilisation de @Inject. Ceci dit, ils n'ont qu'à participer au JCP au lieu de râler ^^

N'oublions pas les JSF (Java Server Faces) qui sont vraiment très très très intéressants, notamment avec des outils comme Java Studio Creator. Ils se rapprochent de l'ASP.NET pour ses composants côté serveur.

J'ai interviewé Marc Fleury à JavaOne et il m'a clairement affirmé leur volonté de soutenir EJB 3.0 et Hibernate. Pour eux JDO est un jouet sans intérêt. Les gens de chez Sun (notamment James Gosling) ont des propos plus modérés et disent que les deux peuvent parfaitement cohabiter. Le fait est qu'on peut très bien utiliser JDO dans une application non-J2EE et que cela apporte pas mal d'avantages.

J'avoue que je ne connaissais pas cette ruse. Ceci dit je me souviens de tellement de prises de têtes avec les "secteurs" dans Build que je ne sais pas si j'aurais tenté de l'utiliser même en la connaissant. Cela me rappelle le coup des miroirs qui nécessitait une pièce plus grande que celle à réfléchir de l'autre côté du miroir.

Pour avoir beaucoup utilisé Build, l'éditeur de niveaux de Duke Nukem 3D, je tiens à préciser que des "passages" les uns au dessus des autres étaient impossibles. L'ergonomie même de l'éditeur empêchait de le faire mais le moteur en était en outre incapable. Pour créer par exemple un étage dans une maison il fallait créer un escalier avec un beau virage empêchant au joueur d'en voir la fin. Dans ce virage tu pouvais alors placer un téléporteur sans effet graphique et déplacer le joueur sur une autre partie de la map sur laquelle tu construisais le soit-disant étage. Il va sans dire que réaliser une maison et sa cour, visible du rez de chaussée et de l'étage, demandait des gros copier coller :)

Ca tombe bien parce qu'à JavaOne 2004 Sun a annoncé qu'ils allaient s'orienter vers un système d'abonnement et donner les logiciels et le matériel "gratuitement". Comme les opérateurs téléphoniques et les téléphones. Ils ont déjà commencé avec deux offres d'abonnement à Sun Developer Network Standard, 99$ avec Java Studio Creator, et SDN Enterprise, 1500$ avec une station Sun Opteron ou un serveur Sun Fire V20z.

Eh bien à l'occasion si tu lis un numéro récent, n'hésite pas.

Ca tombe bien je passe dans le coin :-) Concernant le problème des photos hors sujet (ça faisait longtemps tiens ;-) je peux t'assurer qu'on y a remédié. Par contre, pourrais-tu préciser un peu plus ta remarque sur le côté "criard" de Login: ?

Oui enfin comme bien souvent, tendez la main, on vous bouffe le bras. Sun fournit le code source de l'API et même de la JVM il me semble. Sans compter les spécifications complètes et le JCP qui, quoi qu'on en dise, réunit un paquet de monde et marche plutôt bien.

Le libre c'est bien, mais en vouloir de partout à tout prix...

www.sunsource.net

Et cette manie de vouloir libérer Java à tout prix gnigignnii #@!