Java Virtual Machine 1.4.2 beta

Posté par  . Modéré par Xavier Antoviaque.
Étiquettes : aucune
0
7
avr.
2003
Java
C'est encore chaud, une mise à jour de la Virtual Machine est disponible en version beta.

En plus d'une flopée de corrections de bogues, on notera principalement un souci de meilleure intégration (visuelle et au niveau de l'installation) pour Linux, ainsi que des performances accrues

A tester avec vos applications, pour faire travailler le bugparade et améliorer la stabilité sous Linux ! Pour Linux, au niveau des changements, on note :

- Support de ALSA (ouf!),
- Meilleur support du mode 24bits (RGBA),
- Amélioration du support de webstart (gestion des VM installées par RPM et des VM "montées"),

Et surtout des performances coté client qui montent (bienvenu pour les outils de développement ou les gros logiciels) !

Bien sur, la version 1.5 (J3SE ?) continue de mûrir dans les cartons de Sun, avec son lot de révolutions (VM partagé, etc.). Mais la 1.4.2 permet de patienter en disposant de quelque chose de professionnel.

Bien sur, on rapellera que la spécification Java n'est pas libre, car Sun garde le controle sur la validation.

Mais depuis l'accord à couteau tiré avec l'Apache Group, et la signature du JSPA, les implémentations libres sont donc possibles sans autre limitation que de devoir être une association et de valider ses machines virtuelles avec le toolkit gratuit de certification (le TCK).

Petit à petit l'oiseau fait son nid...

Aller plus loin

  • # Il manque un appeau à troll dans la news...

    Posté par  . Évalué à 10.

    Il n'est pas précisé que l'intégration visuelle se fait en imitant le thème gtk+ (et peut etre aussi le thème metacity, je me souviens plus très bien).
    Un petit lien qui explique comment faire marcher ce look and feel natif http://gnomedesktop.org/article.php?sid=1034&mode=thread&or(...)

  • # Re: Java Virtual Machine 1.4.2 beta

    Posté par  (site web personnel) . Évalué à 10.

    juste une ch'tite question pour les spécialistes de la chose : est-ce que c'est important/dangereux/inquiétant que le C# soit normalisé et pas Java ?

    ça change quoi sur le plan de la liberté ?

    ça change quoi sur le plan de la diffusion ?

    merci de vos réponses.

    • [^] # Re: Java Virtual Machine 1.4.2 beta

      Posté par  . Évalué à 10.

      Microsoft n'a pas récemment fait breveter son API .NET ou un truc comme ça ? Toujours est-il que Sun garde peut être le contrôle de Java, mais on oublie bien trop souvent le JCP (Java Community Process). Tout un chacun peut y participer pour proposer de nouvelles APIs ou modifications (langage, plate-forme, VM...). De nombreuses entreprises y sont représentées (BEA, IBM, Oracle, etc.) et Sun est loin d'être derrière tout ce qui s'y trame. Par exemple, lors de mon interview de James Gosling, j'ai pu apprendre que l'ajout des "templates" dans Java n'est pas une décision de Sun, ils étaient contre, mais du JCP. Ce n'est pas libre, certes, mais c'est très loin d'être fermé. Et devons nous rappeler que le code de la JVM AINSI que de l'API (à quelques paquetages cachés près) sont disponibles ?

      • [^] # Re: Java Virtual Machine 1.4.2 beta

        Posté par  . Évalué à 1.

        En même temps je comprend pourquoi ils etaient contre

        • [^] # Re: Java Virtual Machine 1.4.2 beta

          Posté par  (site web personnel) . Évalué à 3.

          Ah oui, et pourquoi?

          • [^] # Re: Java Virtual Machine 1.4.2 beta

            Posté par  . Évalué à -5.

            un indice : les classes virtuelles. Si tu sais a quoi ca sert, les templates ne te servent a rien ...

            • [^] # Re: Java Virtual Machine 1.4.2 beta

              Posté par  . Évalué à 8.

              Heiin????

              Les templates sont un moyen de générer du code typesafe facilement,je ne vois pas en quoi une classe virtuelle change qqch...

              Comment tu fais en java un vector ne contenant que tel ou tel type d'objet? Pour l'instant, soit tu réécris une classe à la main (avec tous ce qui vient avec, soit: un truc long et chiant), soit tu te retrouves avec un vector d'object et rien ne te limite, tu peux en faire un vector homogène ou hétérogène... le prob apparaitra lorsque tu utiliseras le contenu du vector, pas lors de l'ajout!

              Ca permet aussi d'avoir un code plus propre sans cast... tu feras:

              MimeEntry e=mimeVector.get(0);

              et non

              MimeEntry e=(MimeEntry)mimeVector.get(0);

              Ca me fait penser qu'un autre truc qui m'a toujours manqué dans java, c'est la surcharge des opérateurs...

              Enfin...


              ps: les templates ont bien d'autre utilisation que les containers, mais en général c'est la première application à laquelle on pense.

              • [^] # 100% D'accord ... sauf ;)

                Posté par  . Évalué à 6.

                pour les opérateurs !

                Je comprend l'interet de définir une synthaxe plus courte. Et j'en ait moi même fait l'utilisation pendant longtemps en C++.

                Mais à quoi cela sert-il si on en comprend pas la semantique sous-jacente ? ou si cette semantique n'est pas constante ?

                Quelle semantique assiger à << ou [] ? sur une liste, cela est facile, mais sur des objets plus métiers, cela reste plus "obscur" :(

                C'est un peu la même règle qui à mené Borland et Sun à définit la spec JavaBean et qui vise à ne pas cacher une semantique sous des attraits "sexy".

                Bien sur, on aime avoir des expression simple, mais à l'heure ou l'on a des outils qui font de la complétion une règle, pourquoi souhaiter abbréger à tout prix.

                Il faut penser qu'en java la notion d'opérateur existe, puisque par exemple on peut faire la chose suivante :

                String a = "test";
                String str = "un "+a;

                Mais ceci reste l'exception qui confirme la règle ;-)

                • [^] # Re: 100% D'accord ... sauf ;)

                  Posté par  . Évalué à 9.

                  Pas d'accord, il s'agit d'un hack immonde du compilo qui par derriere va aller te chercher un StringBuffer ...
                  Bref, du grand n'importe quoi ...

                  Il ne s'agit pas d'etre sexy ou quoique ce soit, il suffit d'utiliser a bon escient les outils dont on dispose.
                  Un operateur + sur un entier se comprend.
                  Un operateur + sur un velo ne se comprend pas.

                  De la meme maniere

                  Une methode changeDeVitesse sur un velo se comprend
                  Une methode changeDeVistesse sur un entier ne se comprend pas

                  Alors evidemment, on pourrait s'amuser a faire des methodes explicites sur les entiers.
                  Une methode add, une methode mul, ... Mais pourquoi se compliquer la vie alors qu'on peut faire des choses simples ... ?
                  Il ne s'agit pas d'etre sexy, mais d'etre efficace ...

                  • [^] # Pas si simple ...

                    Posté par  . Évalué à 5.

                    Bien sur, en Java ceci est comme indiqué une exception. Mais je te ferais remarquer au passage, que la façon de compiler en assembleur le resultat n'est pas vraiment définit avec précision dans les 1eres specs. Ainsi, bcp l'on deja noté, entre javac (v6) et jikes (par exemple), il y a un légere différence. Pour en avoir le coeur net, decompile ton bytecode (en ayant prit soit de ne pas l'avoir obscurcit). Lorsque je parlais de semantique cachée, je voulais dire que voir : client << product + qte; n'est pas forcement trés clair, et que lorsque tu as à voir bcp de code en revue (qui n'est generalement pas ton code), si tu dois avant de tenter de comporendre et maitriser la semantique des opérateurs sela ne simplifie ni ne rend rapide la compréhensio du code. client.order(product,qte); Dans le premier cas, non seulement se pose le PB de la semantique de '<<' et '+' mais également la question d'objet traditionel, à qui celà s'applique ! Pour quelqu'un qui s'est mit à l'objet sur le tard, cela semble bizzare, car il a vecu avec la notion de précédence omniprésente pour lire des choses du style : (int *) f[] (CHAR *href ...) Mais, est-ce que de telles choses sont vraiment si indispensable que cela ? Si tu fais des claculs sientifiques toutes la journée, alors oui peut-être ... mais pour la majorité d'entre nous qui fait plutot de l'algorithmique, je n'en suis pas vraiment sur. Enfin, je te rassures si tu veux faire de de la surcharge d'opérator va sur http://minilien.com/?jF4qfYTgy8 et fait ton choix ;-) Je te propose de joindre le debat sur la JCP, et de proposer tes idées. On sais jamais peut-etre feras-tu.penser la balance ...

                    • [^] # Re: Pas si simple ...

                      Posté par  . Évalué à 1.

                      Merci, mais je suis deja occupe avec mon projet de nouveau langage !! :-) (et non, ce n'est pas une blague, va voir http://nosica.ng-market.net)

                      • [^] # ça à l'air pas mal ...

                        Posté par  . Évalué à 2.

                        Un langage alternatif intérésant... mais il manque les Categories ;-)

                        http://minilien.com/?B2FTxO7FG1(...)

                        Ca c'est du concept genial que j'ai retrouvé nelle part.

                        L'idée d'une categorie est de rajouter des fonctionalités supplémentaires à une classe sans qu'elle entrent en compétition avec une classe (donc pas d'heritage necessaire, pais pas de surcharge authorisé pour la categorie)

                        Cela permet par exemple d'ajouter un comportement de persistence ou d'affichage, totalement indépendant du code métier.

                        En some un précurseur de la prog orienté aspect ;-)

                        D'apres ce que j'ai comprit, ton compilo est en Java mais l'assembleur généré n'est pas 100% bytecode, pourquoi ne pas utiliser la VM à 100% pour le runtime ?

                        Car l'avantage que tu met en avant pour le compilo : la portabilité, se retrouverais aussi pour l'execution ;-)

                        Excuses moi par avance si j'ai mal comprit le principe de nosica.

                        • [^] # Re: ça à l'air pas mal ...

                          Posté par  . Évalué à 1.

                          > Ca c'est du concept genial que j'ai retrouvé nelle part.

                          L'Objective-C propose les categories... et effectivement c'est assez utile.

                        • [^] # Re: ça à l'air pas mal ...

                          Posté par  . Évalué à 1.

                          Le compilo est ecrit en Java ... En attendant de pouvoir s'auto compiler ...
                          Le compilo Nosica produit ensuite un source en C qui est compile pour obtenir l'executable ... C'est a dire que le C nous sert de macro assembleur portable ...
                          Pourquoi ne pas utiliser la JVM ? Tout simplement parce que on veut des performances (on veut pouvoir rivaliser avec le C en terme de temps d'execution). Maintenant comme pour SmartEiffel rien n'empeche de construire un back end qui produit du code Java ou du bytecode ...
                          La portabilite n'est pas l'Argument que l'on met en avant, c'est un des arguments. L'argument que l'on met le plus en avant c'est l'analyse globale du code.

                          L'idee des categories (aspect) me semble interressante, cependant je n'ai jamais vu de vrai code l'utilisant. Je sais qu'il est actuellement tres difficile d'implementer la programmation aspect car ca necessite un ensemble d'outil assez lourd a mettre en place au runtime ...

                          Tu as d'autres infos la dessus ?

                          (sinon, je t'invite a venir poser tes questions sur le forum du site (http://nosica.ng-market.net/forum(...) )

                    • [^] # Re: Pas si simple ...

                      Posté par  (Mastodon) . Évalué à 1.

                      Bien vu.
                      J'ai retenu de la programmation Objet que les interactions entre objets se font par envois de messages. Il me semble donc que l'envoi du message "prendre une commande" à l'objet Client est plus lisible sous la forme 
                          client.order(product,qte);
                      que sous la forme
                          client << product + qte;

                  • [^] # Re: 100% D'accord ... sauf ;)

                    Posté par  . Évalué à 2.

                    Y'a le C# qui en abuse avec leur += sur les gestionnaires d'événements :)

                    • [^] # Tout à fait, ...

                      Posté par  . Évalué à 0.

                      Et c'est plutot ridicule, d'ailleur le choix du +=, on aurrait pu imaginer le << qui aurait été peut être plus "logique".... enfin, qu'importe car il y a pire comme syntaxe...

                      Au hazard, les attributs personalisés et leur passage de parametre ... ;-)

                      • [^] # Re: Tout à fait, ...

                        Posté par  . Évalué à 1.

                        Je trouve au contraire que c'est un choix logique. Il s'agit de l'ajout d'un élément à un ensemble et je pense que cet opérateur représente bien cette opération. Ca me semble en tout cas largement plus logique que <<.

                  • [^] # Re: 100% D'accord ... sauf ;)

                    Posté par  (site web personnel) . Évalué à 2.

                    Je pense que tu fais erreur, le compilo ne crée pas un StringBuffer mais fait simplement appelle à la methode concat(String str): String:
                    String a = "test";
                    String str = "un "+a;

                    Dans cet exemple la, un compilateur intelligent creera un String str initialisé a "un test" à la compilation.
                    Sinon, s'il se peut qu'il y ai une operation sur a visant à le modifier avant de creer str, alors l'operation se resume a creer un tableau de char de longueur a.length()+str.length(), y copier les caracteres de chaque chaines et de retourner une nouvelle chaine à partir du tableau de caracteres.

                    Bref, pas de StringBuffer dans tous les cas.

                    PS: Voir methode concat dans le code source de java/lang/String.

                    • [^] # Re: 100% D'accord ... sauf ;)

                      Posté par  . Évalué à 1.

                      Ca dépend de ce que l'on concatène et surtout des versions des compilateurs. Avec les compilos des JDK 1.2.x on se retrouvait avec plein de append() sur des StringBuffer.

                • [^] # Re: 100% D'accord ... sauf ;)

                  Posté par  . Évalué à 7.

                  En fait concernant les opérateurs, je peux comprendre qu'ils ne les aient pas mis... Cependant, avis perso, je ne crois pas que cela pose tellement plus de problème: que ce soit "+" qui soit flou ou "add" qui soit flou change grand chose....

                  En fait, c'est surtout à l'utilisation (je passe d'un langage à l'autre pour le moment), ce qui m'embête le plus c'est:

                  string str1="coucou";
                  string str2="pas coucou";
                  if(str1==str2) // compile mais buggé, faut utiliser equals...

                  Vector v=new Vector();
                  v.add("test");
                  string t=(string)v[0]; // et non! v.get(0).

                  Etc... je pense que ce sont typiquement les cas ou surchargé un opérateur aurait été pratique... (pareil pour hashtable, etc...), ça aurait en plus permis à string d'être vraiment une classe comme les autres...

                  Par contre c'est vrai que le "<<" et ">>" peut amener plus de confusions... (de base il n'ont pas une sémantique clair sur autre chose que des données binaires) et qu'il ne faut amha pas surcharger à tour de bras... ceci dit, le langage nous permettre d'utiliser des noms idiots pour les méthodes, ça ne veut pas dire qu'il faut le faire!

                  Amha, ce n'est pas uniquement pour abbréger le code, mais le rendre plus clair, typiquement un vector et un tableau dynamique, pouvoir l'indexé comme un tableau rend les choses plus simple! un hashtable est une association key->item, pouvoir utiliser un indexer pour ça me semble plus rapide et logique... parce que là, tu vois le get, tu ne sais pas toujours très bien de quoi il s'agit!

                  Enfin bref, les arguments contre (confusion, simplicité, etc....) sont aussi valable, perso, j'aurais aimer les avoir... mais bon ;-)

                  • [^] # Re: 100% D'accord ... sauf ;)

                    Posté par  . Évalué à 2.

                    > ça aurait en plus permis à string d'être vraiment une classe comme les autres

                    Euh String c'est une classe comme les autres justement (l'operateur == sur les classes s'applique aux references et n'est pas synonyme de o1.equals(o2)).
                    Par contre ce qui est chiant c'est que les types primitifs genre int, long, float ne sont pas des classes justement (et donc obliges d'etre encapsules dans des classes pour etre utilisables reellement).

                    • [^] # Tout à fait et on peut même preciser ...

                      Posté par  . Évalué à 4.

                      Que si la chaine est définie implicitement, style "test" dans : String a ="test"; String b ="test"; if(a==b){ // oui :o) } Alors cette chaine sera membre du pool de constante, et l'on pourra tester avec joie un == entre les deux, car il n'existe qu'une seule occurence d'une instance de String ayant la même valeur dans le pool. Ainsi , a et b pointant sur le même objet, le test sur les références sera vrai ;-) Pour ajouter une chaine explicite au pool de constante on peut utiliser la methode .intern(), qui retourne une référence sur une chaine identique mais présente dans le pool. Pratique pour optimiser certains algo ;-) Genre, "au hazard", le calcul de clé de hachage ou le tri de chaines dans un tableau à clé ... A noter que tout celà fonctionne car la classe String est dit non modifiable (unmutable string).

                    • [^] # Re: 100% D'accord ... sauf ;)

                      Posté par  . Évalué à 3.

                      Je pense qu'il voulait dire que les operateurs + et += sont surchargés pour String, ce qui n'est pas faisable pour les autres classes. En ce sens, String est un classe "speciale".

        • [^] # Re: Java Virtual Machine 1.4.2 beta

          Posté par  . Évalué à 7.

          N'importe quoi.
          Les classes virtuelles te permettent de faire du polymorphisme, alors que la genericite te permet d'adaptater un algorithme a un type...

          Ca permet entre autre d'avoir des vrais containers types, au lieu de ces infames Vector que l'on a en Java ...

          • [^] # La genericité ...

            Posté par  . Évalué à 5.

            Une pré-version de la genericité en Java
            http://minilien.com/?bqvde3x13R(...)

            Des implications de la genericité, un "for" amélioré dans le 1.5:
            http://minilien.com/?qQ1hWSQfaM(...)

            J'attend avec impatience la 1.5, car vraiment la genericité telle qu'elle a été implementé est un régal qui va faire oublier les cauchemards des template C++. Ceux qui ont déja joué avec le debogage de templace C++ me comprennent je pense ;)

            • [^] # Re: La genericité ...

              Posté par  . Évalué à 3.

              J'attend avec impatience la 1.5, car vraiment la genericité telle qu'elle a été implementé est un régal qui va faire oublier les cauchemards des template C++. Ceux qui ont déja joué avec le debogage de templace C++ me comprennent je pense ;)

              Clair! ;-)

              Au passage, parce que c intérressant de voir ce qu'il y'a ailleurs, un doc sur le futur de C#: generics, enumerator, methode anonyme, ...

              http://www.gotdotnet.com/team/csharp/learn/Future/default.aspx(...)

              Perso, tout comme pour java, moi ça me donne envie d'être demain...

              • [^] # C'est de bonne guerre ;-)

                Posté par  . Évalué à 5.

                Car on trouve par exemple pour Tiger (le code de la 1.5),
                une proposition d'introduction du autoboxing

                http://minilien.com/?uyQm2hDFMK(...)

                Par contre pour ce qui est de la genericité, et du reste, alors que chez MS cela reste au niveau du lab, on en est plutot au niveau de la derniere ligne droite du coté Java ...

                Car la genericité, cela n'est pas une "lubie", mais bien une decision longtement débatue et réfléchie. Et sera présente dans la 1.5 avant la fin de l'année !

                Sur ce point, il va etre interessant de noter les retards prit par les editeurs d'IDE Java, et il se peut bien que les outils opensource soit les premiers à proposer la compatibilité langage 1.5 ;-)

                (cf. la completion, le debug, etc ...)

                Pour finir, la JSR-045 semble être quelque chose d'interressant http://minilien.com/?53EJIPmK9p(...)

                Car elle permetrait ainsi de faciliter l'intégration de la foultitude de langages developpés pour la plateforme Java
                http://minilien.com/?jF4qfYTgy8(...)

                Tiens, c'est marrant mais cela me rappelle qqch, une plateforme avec plusieurs langages qui compile pour un meme bytecode ;-)

            • [^] # Re: La genericité ...

              Posté par  . Évalué à 5.

              Excuse mon ignorance, mais en quoi l'implementation de Java est-elle plus simple que celle de C++ ?
              Pour l'utilisation, a priori ca a l'air de pas mal se ressembler ...
              Pour la creation de template ? Mis a part qu'il n'y a plus le mot clef "template", le reste ressemble pas mal non ?

              Alors c'est quoi la difference fondamentale ?

              (je suis vraiment dans l'ignorance la ...)

              • [^] # Pour rentrer dans les details

                Posté par  . Évalué à 1.

                http://minilien.com/?E7gK3IALnu(...) (Un doc PDF sur la différence)

                En gros pour faire simple (que les experts de la STL me pardonnent), on pourrait effectuer le travail necessaire au templating C++ simplement par le preprocesseur, il ne subsiste aucune trace au runtime et ne peut être présent que de façon spécialisée.

                Dans le cas de la genericité, l'tuilisation du préprocesseur seul ne pourrait pas suffir car on peut voir le type parametré comme une "pré-condition" optionelle à une classe. Qui subsiste à l'execution, et qui peut étre à tout moment re-généralisé.

                Si tu veux plus de detail, je te conseille la lecture de la JSR-014.


                Et il n'y a aucun PB à ne pas connaitre qqch de nouveau ;-)

                Chacun ayant une limite a ses conaissances, il vaut mieux toujours rester humble face la connaissance, et ta position t'honnores.

                • [^] # Re: Pour rentrer dans les details

                  Posté par  (site web personnel) . Évalué à 3.

                  Il me semblait que Genericité* et template c'est la même chose. Template est le nom C++ et il ne faudrait pas utiliser ailleurs qu'en C++.

                  Il ne faut pas confondre un paradigme avec son implémentation.

                  Sinon, l'implémentation de la généricité à la C++ est mauvaise car en effet elle est pas beaucoup plus intéligente qu'un préprocesseur. Ainsi une classe générique (le .h et le .cpp associé) ne peuvent être compilés séparément ce qui pose des problèmes de surreté du code : en gros on doit attendre l'instanciation du composant générique pour avoir les éventuels messages d'erreurs. Donc on ne sait que la classe est correcte au niveau de l'interface qu'une fois celle-ci livré.

                  Un deuxième problème est que la généricité contrainte n'est pas présente en C++ (il me semble mais ca fait longtemps que j'ai pas touché au C++). C'est à dire on ne peut pas fabriquer une classé générique Pile en précisant que T doit être sous-type de Vaisselle, donc permettre l'instanciation d'une pile d'Assiette mais pas celle d'une pile de Poulet.

                  D'ailleurs, dans leurs projets, la généricité en Java sera-t-elle contrainte ?

                  * Un autre synomyme qui en jette auprès des filles est "Polymorphisme paramétrique" (attention, ça marche pas avec toutes les filles)

                  • [^] # Re: Pour rentrer dans les details

                    Posté par  . Évalué à 1.

                    Ainsi une classe générique (le .h et le .cpp associé) ne peuvent être compilés séparément ce qui pose des problèmes de surreté du code

                    Et le mot clef export alors ?


                    Bon d'accord, aucun compilateur C++ ne le reconnait, mais bon ...

                • [^] # Re: Pour rentrer dans les details

                  Posté par  . Évalué à 1.

                  OK je vois ...
                  C++ : le type template n'existe pas vraiment au runtime ...
                  Java : la classe generique est un vrai type, y compris au runtime

                  Par contre, le fait de creer une classe generique qui prend un fait un Object au runtime a son pour et son contre :
                  Pour : Une seule classe creee
                  Contre : implique de rajouter des casts de facon automatique alors que le type check a prouve qu'il n'y en avais pas besoin ... Bizarre ...

                  Rajouter des contraintes sur les types parametriques a l'aide du mot clef "implements", c'est assez marrant, c'est la solution qu'on a retenu pour Nosica il y a plus de deux ans ...

                  Sinon, je suis assez content de voir que ce qu'ils appellent la bonne methode (vrai type, contraintes sur les types) c'est ce qu'on a implemente en Nosica des le depart ... Sauf qu'on cree N vrai types a partir d'un type generique, du coup on peut optimiser chaque version independemment des autres versions, et surtout avoir une version type safe a la compilation et au runtime.

                  On peut aussi compiler integralement une class generique sans qu'elle soit utilisee ...

                  Content !! :-)

            • [^] # Re: La genericité ...

              Posté par  . Évalué à -1.

              Les template en C++ ... Le pire des cauchemards d'informaticien.

              Ca me donne des boutons rien que d'y penser ...

          • [^] # Re: Java Virtual Machine 1.4.2 beta

            Posté par  . Évalué à 1.

            C'est un peu comme le bon chasseur et le mauvais chasseur ? Le polymorphisme, ce n'est jamais qu'une solution pour faire de la généricité. Et pour avoir un conteneur typé en Java, rien de plus simple, il suffit de redéfinir la méthode add : (pardonnez mon Java un peu rouillé) class VectorType extends Vector { void add(Object o) { if (o instance of Type) print "Youpi" else print "pas youpi :(" } }

            BeOS le faisait il y a 20 ans !

            • [^] # Re: Java Virtual Machine 1.4.2 beta

              Posté par  . Évalué à 2.

              Tu as le même en typé statiquement, histoire de voir les problème d'insertions merdiques à la compilation et pas après 2 ans de fonctionnement en production. Et il n'y a pas que add à redéfinir, puisqu'autant typer tout ce qui rentre et qui sort dudit container.

            • [^] # Re: Java Virtual Machine 1.4.2 beta

              Posté par  . Évalué à 6.

              Syntaxiquement ça ne t'évite pas les cast pour tous ce qui est "get"... De plus ta solution prend du temps à l'éxecution, un template pas, et elle détecte l'erreur au runtime, un template te le signalera à la compilation. (note: un truc plus propre d'ailleurs génererait une exception, parce que pas youpi, c'est vraiment pas propre et pas utilisable... ce qui demanderait de modifier add pour qu'il throw cette exception). En bref, je pense que les generics apportent réellement un plus... Enfin le dernier problème avec ta solution est qu'elle demande la surchage de plus de fonction que cela pour avoir quelque choses de complet. Et si un jour on ajoute une méthode à Vector, il faudra modifier tout tes "vecteurs typés" avec les generics, ça marche tout seul!

            • [^] # Re: Java Virtual Machine 1.4.2 beta

              Posté par  . Évalué à 4.

              Excuse moi, mais sérieusement, t'appelle ca une solution ? Et tu dis que c'est typé ? Tu sais ce que ca veut dire que la verification de type a la compilation ? Parce que au cas ou t'aurais pas remarque c'est de ca qu'on parle ...

            • [^] # Re: Java Virtual Machine 1.4.2 beta

              Posté par  (site web personnel) . Évalué à 2.

              1) Il faut redéfinir *toutes* les méthodes de vector 2) C'est pas très efficace ton truc. Le instanceOf prends du temps CPU, alors qu'il n'est absolument pas nécessaire. Résultat : Il te faut 50 lignes pour faire un truc moins efficace que list x;

            • [^] # Re: Java Virtual Machine 1.4.2 beta

              Posté par  (site web personnel) . Évalué à 3.

              C'est juste que c'est con de le re-écrire à chaque fois, alors qu'un Vector<MonTYypeAMoiQueJAI> v; C'est quand même mieux ... surtout si après tu fais un int a; v.add(a) => planton à compile time Dans ma boite où on développe un langage à destination des électroniciens, ils tiquent un peu quand on leur dit que la généricité n'est pas encore implémentée: à quoi ça sert de développer une fifo où un protocole de bus si à chaque fois que tu veux changer le type de données il faut tout te repalucher ?

    • [^] # L'avenir ...

      Posté par  . Évalué à 10.

      La "normalisation" de C# n'as pas vraiment d'impact notable sur l'avenir de MS.net comme veritable plateforme concurente de Java.

      Car, malgrés l'excelente communication de MS sur le sujet (les FUD diront certains), le processus de standardisation n'a d'importance que lorsqu'il sert au plus grand nombre et lorsqu'il est significatif. Ce qui aurrait pu être le cas si MS avait standardisé intégralement l'ensemble de la plateforme. Or il n'en est rien. Ainsi seul les éléments fondateurs l'ont été (comme C# par ex), mais rien sur les elements un peu plus consitutifs qui font sa specificité.

      Force est de constater que MS est de plus en plus seul sur sa plateforme et que l'on constate même certains "bastions" VBistes sont tentés par les sirennes de Java.

      Du coté de Sun, si le spectre de voir MS récupérer Java semble s'eloigner, je doute qu'il soit encore suffisament loint pour qu'ils envisagent un opensource intégral. En effet MS serait "trop content" de pouvoir faire une annonce du style "MS.net compatible Java !", histoire de recuperer tout le parc existant des applicatifs Java et des developpeurs ... pour bien sur passer à Studio :)

      Enfin, il ne faut pas oublier que Sun, n'est plus le verritable maitre de Java, ainsi comme indiqué plus tot dans le fil, l'adoption de la genericité (solution comparable au template C++ ) pour le 1.5, s'est faite contre leur avis (poussé principalement par gosling, pour qui cela n'etait "pas necessaire"). Or le processus JCP est maintenant définit de façon à ce que tout soit public et les votes fait de façon ouvertes.

      Ce qui ne manque d'ailleur pas de démontrer les tentatives de certains de tirrer la couverture de telle ou telle spec au plus prés des specification de leur produit (cf. la derniere spec J2EE et la tentative d'IBM de passer en force ...).

      En fait, pour que Java soit de plus en plus un element moteur de la percée de linux, il ne manque plus guere que la volonté de certains guru de tux de ne plus voir Java comme un ennemi, mais comme une opportunité de vrai liberté de choix de plateforme.

      Ainsi, il n'y a plus guerre de raison à ce que le projet GNU-ClassPath, n'accouche pas bientot si tout le monde est de bonne volonté et arrete de transformer Linux en cloche-merle.

      A chacun de voir ce qui est vraiment important ...

      • [^] # Re: L'avenir ...

        Posté par  (site web personnel) . Évalué à 10.

        Je vais de ce pas entrer dans un méchant troll sur les langages mais qu'importe. Un très gros avantage du libre est de pouvoir choisir, et tant qu'a faire choisir le meilleur (ou un meilleur) sans être imposé par une contrainte.

        Je vrais prendre un exemple avec un niveau trollifère de 78,7. Imaginons que Microsoft libère son format .doc avec toute la documentation technique qui va bien (et même des bouts d'implémentation en GPL soyons fou). Est-ce que OpenOffice.org devrait mettre son format xml à la poubelle et utiliser nativement et par défaut le format de Micosoft ?
        Il y aurait sans doute des gens pour dire qu'en faisant cela OpenOffice aurait enfin un accès primordial avec le grand public car sont interoppérabilité complète avec l'existant serait énorme.
        Mais, amha, ce n'est pas une raison pour remplacer le formal OOo tout simplement car le format OOo est bien meilleur (lisibilité, concision, pas de bouts de vieux textes qui trainnent, etc.)

        Où je veux en venir. Ben, tout simplement java n'est pas un bon langage. Il a des tonnes de points positifs (portabilité, bibliotheques énormes, chargement dynamique, etc.) mais les concepts même du langage sont pour certains vraiment mal foutus. Je ne fais pas faire une liste mais je peux citer entre autre l'héritage simple (des fois c'est limitatif), types primitifs non objet (faire une liste d'entier nécessite de passer par un conteneur), contravariance (passer son temps à faire des coercitions), règles de protection limités mais complexes à mettre en oeuvre, syntaxe méchament lourde (et vieille) et d'autres trucs que j'ai pas en tête en ce moment.

        Les Fanatiques Java vont bien sûr me tomber dessus méchamment (en plus les gens qui ne s'interesse pas à Java ont peu de chance de lire les commentaires) et vont m'exposer des arguments valables pour la plupart mais sans vraiment réaliser que Java est à la base mal pensé et développé près de la machine à café.

        Pour finir de m'achever et passer en XP négatifs, il me semble que Java n'est pas complètement libre, alors pourquoi on en parle jamais alors que le moindre suse reçoit un tir de mortier en moins de trentes secondes ?

        • [^] # Re: L'avenir ...

          Posté par  (site web personnel) . Évalué à 4.

          Le post auquel tu réponds n'est pas un troll, par contre le tiens ... Allez, je marche dedans mais j'ai que 2 minutes devant moi alors je le fais court ... J'aime bien comme tu énonces "Java n'est pas un bon langage" comme si c'était une vérité ... Je suis curieux de connaitre tes critères pour classer des langages ? Le C++ c'est un "bon langage" ? Et le C ? Et le PERL ? Eclaire nous parce que je ne savais pas qu'il y avait des règles universelles pour classer les langages :-) Sinon tes arguments n'en sont absolument pas ... L'héritage simple n'a pas été choisi un hasard et n'est absolument pas une limitation. Cette règle est bien connue dans la POO "Prefer composition over inheritance". Et dans le cas ou tu dois effectivement hériter de plusieurs "comportements", tu peux implémenter plusieurs interfaces, magique, non ? ;-) Bref pour le reste c'est du même genre ("syntaxe méchament lourde et vieille", sur quoi tu te bases pour dire ça ? Et comparé à quoi ? La syntaxe de PERL tu la considères comment ? Et celle du C ?) ... Bref, troll troll troll (et FUD) :-) Sur ce bonne soirée, je dois y aller ! Nelis

          • [^] # Re: L'avenir ...

            Posté par  (site web personnel) . Évalué à 10.

            Je m'attendais à ce genre de réponse (mais en bien plus méchante alors ça va je suis content) Oui, c'est un troll, un vrai, un méchant, avec des poils. Mais je pense qu'il a pour avantage de donner petit coup de pied dans la cafetière. Les langages informatiques, il y en a plein mais on appercoit dans l'évolution de l'utilisation des langages une inertie énorme. (1 - je résume et 2 - je ne prétends pas être objectif ni même exaustif) Quand un nouveau paradigme, une nouvelle idée, un concept original de programmation se développe, on a deux types de langages qui émergent : - le langage qui ajoute grossièrement des fonctionnalités à un langage célèbre (et qui coupe les bouts qui dépassent) : fortran -> algol -> c -> c++ -> java - le langage qui essaye de tout miser sur les nouveaux concepts et qui les exploite pleinnement : SmallTalk, OCaml, Haskell, Ruby, GOTO++ Ce 2eme type de langage engendre souvent des choses mortes nés, parfois un peu trop dur ou sinon trop simpliste pour être utilisé en production. Mais on a aussi de vrais bon gros langages qui emmergent avec une vrai utilité et une facilité de modéliser le reel (toujours plus déconcertante). Or c'est toujours un langage du premier type qui est choisi par l'industrie, pour une raison bien simple : c'est comme quelque chose que l'on connait avec des trucs puissants en plus donc on change pas les habitudes. Prenon un exemple concret C++ (83) et Eiffel (86). Le premier est du C++ avec une couche honteuse d'objet avec tout un tas de concepts dénaturés pour des raisons de performances (ce qui est un argument valable comme un autre, c'est bien gentil d'avoir un bon langage mais si c'est pour faire une sieste pendant une addition je vois pas l'interet) Eiffel quand à lui est un très bon langage objet avec un vrai objet dedans (et de nos jours avec un excellent compilateur libre, SmartEiffel avec le label GNU madame) Eiffel a des défauts aussi (presque aussi contraignant que Ada et syntaxe originale parfois déroutante) Pour répondre brièvement : - L'héritage simple : la composition ne fait pas tout dans la vie car cela oblige bien trop à devoir coder un proxy pour chaque routine (ca nuit à la réutilisabilité). C'est vrai qu'on peut se passer de l'heritace multiple (comme on peut se passer de tout du moment qu'on est turring complete comme disent les jeunes) mais il ya bien des fois ou c'est utile - syntaxe méchament lourde et vieille : ben oui le ';' ou les () pour les routines sans arguments sont trainés depuis bien longtemps. Pour finir le troll. Pour moi le C est un bon langage. le C++ non le Perl était bon au début, maintenant cela devient un vrai monstre. Mon choix de langages à utiliser qui sont biens : C, Ruby et Eiffel Ta réponse, j'en ai déjà eu plein et souvent plus des véloces. Mais ce genre de réaction est plus du a une mauvaise connaissance des possibilités des langages de programmation, non pas dans ce qu'ils peuvent faire (car jusqu'a preuve du contraire ils peuvent faire la même chose) mais dans l'efficacité pour le faire faire (simplicité de code, de lecture, d'évolution, etc.) Parfois, quand je vois les gens essayer de me convaincre que C++ ou Java c'est super et qu'on a jamais fait mieux je retrouve le même conportement des gens qui pense que c'est normal qu'un OS puisse planter tous les jours, qu'un bon reset le fera mieux marcher et qu'une réinstallation complète tous les 2 mois est la bienvenue. Ces gens ne savent tout simplement pas que de meilleures choses existe et ce n'est pas parce qu'un truc est utilisé par 80% des gens qu'il est forcément mieux. Bien sur, il reste les problèmes de compatibilité avec l'existant, des choses que l'on ne peut faire simplement avec windows parceque le logiciel existe ou le materiel supporté. De la même façon les bibliotheques impressionnantes et les framework de java sont difficilement contournables pour certaines applis mais ce n'est pas une raison ! Bref, le combat des meilleurs langages est souvent bien plus dur que celui des meilleurs OS je pense.

            • [^] # Re: L'avenir ...

              Posté par  (site web personnel) . Évalué à 2.

              et pour les macophiles ? c'est bien Objective C ?

            • [^] # Re: L'avenir ...

              Posté par  (site web personnel) . Évalué à 3.

              Je ne dis pas que Java est le langage ultime ni qu'il est parfait pour faire tout.

              Chaque langage a ses points faibles et ses points forts, ils ont tous le mérite d'exister et peuvent d'adresser à des problèmes différents.

              Pour certaines choses j'adore le C, pour d'autres je préférerai le C++, ou Java, ...

              Ce que je n'aime pas, c'est les gens qui disent "tel langage c'est de la merde, c'est lent, ça pue" alors que si ça se met ils n'ont jamais écrit une ligne de code en ce langage (je ne dis absolument pas que c'est ton cas).

              En bref, je trouve qu'une guerre des langages est inutile et ridicule ... ;-)

              • [^] # Re: L'avenir ...

                Posté par  (site web personnel) . Évalué à 5.

                La guerre c'est mal.

                Mais de là a dire que tout le monde il est beau tout le monde il est gentil il y a un pas. Certains voient les lagages commes des mode de pensée voire des philosophie. Il ont peut-être raison mais pour moi un langage est avant tout un outil.

                Loin de moi l'idée de rentrer dans un jeu sans interet "mon langage il est plus gros que le tien" ! Mais certains outils ont des faiblesses et d'autre sont mieux. Et pour une raison ou pour une autre certain outils pas terribles se retrouvent utilisés par une majorité de gens voire plébicités. Quel informaticien programmeur oserait dire à un futur employeur qu'il ne connait pas Java par exemple ? Combien de developpement se focalisent sur Java parceque un guignon à trouvé que cela faisait tendance (quoique la tendance à baissée avec .NET) ?

                Java est un outil, il permet de faire des choses plus facilement ou mieux qu'avec d'autres outils. Mais cet outil a beaucoup de défauts, beaucoup trop. Mais on ne s'en rend compte que si l'on compare à autre chose : les gens écoutent et achètent de la soupe car il n'y a que ça à la radio et à la télé, la plupart ne connaissent tout simplement pas les vrais chanteurs, les vrais musiciens (ou en on un mauvais apriori). les gens utilisent un système d'exploitation peu stable et drolement cher pour ce que, il sont à cents lieux d'imaginer qu'il existe des tas de systèmes d'exploitations (ok pas des tas p'tet) efficaces, stables, etc (et s'il le savent, il en ont une mauvaise impression, et puis leurs materiels et données risquent de ne pas être utilisables). Et dans une moindre mesure, les gens vont s'entasser sur les plages parcequ'il s'imaginent que la campagne c'est chiant :p

                Java est un outil, un bon si on le compare à Cobol ou Basic. Mais je pense qu'il est fondatalement mauvais si on le compare avec certains langages moins connus. Je pense aussi que tous les points vraiment géniaux de Java (portable, et entre autre tous les machins aux sigles commerciaux plein de 'J' de 'E' et de 'X') ne sont pas spécifiques à Java dans le sens où is aurait pû être déployés sur la base d'un langage de programmation mieux foutu.
                (et c'est mon opinion personelle que je n'oblige personne à être d'accord, ch'uis pas fanatique comme RMS (oups, j'ai trollé))

              • [^] # Re: L'avenir ...

                Posté par  (site web personnel) . Évalué à 2.

                oui mais là tu cites encore C, C++ et java... or y'a quand même pas beaucoup de différence entre ces 3 là (à la rigueur entre C et C++, y'a des objets en plus). Les 3 sont des langages statiques, avec une syntaxe très proches.

                C'est quand même dommage que ce soit toujours ces 3 langages qui soient utilisés, alors que ce sont rarement les plus adaptés. Dans certains cas tu préfères pas un bon langage de scripts (Python, Perl,...) ou un Lisp/Scheme ?

                • [^] # Re: L'avenir ...

                  Posté par  . Évalué à 1.

                  Il faut aussi voir qu'au dela des avantages et defauts des langages, imposer un langage ,'est pas qu'une affaire de publicité. si la proximite de la syntaxe entre c/c++/java/c# etc est un defaut car cette syntaxe est ancienne, c'est aussi un atout parce que des milliers (millions?) de programeurs maitrisent cette syntaxe. on ne peut pas réaprendre a conduire tous les 2 ans sous pretexte que le code de la route a changé parce que des nouveaux concepts sont arrivés... il est clair que nous sommes tous formés pour etre polyvalents et adaptable, il n'en reste pas moins que nos employeurs ont besoin qu'on soit rentable...
                  de ce point de vu, la lourdeur de l'évolution des langages se comprend...
                  et pour qu'un langage entierrement nouveau prenne réellement le dessus, il faudra qu'il apporte vraiment beaucoup, sous peine de rester cantoné a des niches ou a la recherche.

          • [^] # Re: L'avenir ...

            Posté par  . Évalué à -4.

            L'héritage simple n'a pas été choisi un hasard et n'est absolument pas une limitation. Cette règle est bien connue dans la POO "Prefer composition over inheritance". Et dans le cas ou tu dois effectivement hériter de plusieurs "comportements", tu peux implémenter plusieurs interfaces, magique, non ? Tu es en train de nous dire que l'héritage multiple n'a pas été implémenté parce qu'il est "mauvais", mais qu'un ersatz est disponible parce que c'est "utile". Ce qui est critiqué dans la démarche de Java c'est d'avoir refusé de l'intégrer explicitement pour des raisons dogmatiques (littéralement : une "règle bien connue dans la POO" selon toi), mais d'avoir tout de même intégré une forme détournée car on sait bien que c'est nécessaire dans la vraie vie. Un langage conçu avec plus d'ouverture d'esprit n'aurait pas fait tant de chichis et aurait autorisé explicitement l'héritage multiple sans se soucier des préjugés. "syntaxe méchament lourde et vieille", sur quoi tu te bases pour dire ça ? Et comparé à quoi ? Comparé à tous les langages plus légers, c'est-à-dire C, C++, Perl, C#, PHP... Faut être sérieusement de mauvaise foi pour ne pas voir que Java est terriblement lourdingue et pénible à la fois à lire et à écrire comparé aux langages auxquels il fait concurrence. Si tu veux des mesures objectives tu peux même t'amuser à coder le même algorithme en C++ et Java et comparer le nombre de caractères et de lignes de code au final ; mais je pense qu'aucun programmeur informé et honnête n'a besoin d'un tel exercice pour accepter l'évidence. Ou alors tu peux crier au "FUD" si tu n'as pas envie de voir la vérité en face (comme c'est souvent le cas avec les inconditionnels de tel ou tel langage / système d'exploitation / logiciel / distribution...).

            • [^] # Re: L'avenir ...

              Posté par  (site web personnel) . Évalué à 2.

              Euh ... L'héritage multiple et l'implémentation d'interfaces, ce n'est pas la même chose ... Dans un cas tu hérites d'un état et de comportements, dans l'autre tu définis un certains nombre de comportements que ta classe implémente, ce qui est très différent en pratique.

              La deuxième partie de ton post est tellement ridicule et puerile que je ne vais même pas prendre la peine de répondre :-)

              Je dirais juste que contrairement à ce que tu as l'air d'insinuer, je n'ai jamais dit que Java était mieux que tel ou tel langage, chaque langage a des avantages et des inconvénients qui les rendent plus ou moins adaptés à certaines tâches.

              • [^] # Re: L'avenir ...

                Posté par  . Évalué à 0.

                La deuxième partie de ton post est tellement ridicule et puerile que je ne vais même pas prendre la peine de répondre :-)

                T'as raison, Java est léger à programmer, agréable à lire, on y fait des petits programmes de dix lignes ultra-puissants en quelques minutes et on n'a pas besoin d'installer un bousin plein de méga-octets pour en profiter (et là je parle seulement du runtime, même pas de l'environnement de développement). C'est toujours beaucoup plus facile de faire semblant d'ignorer les critiques auxquelles on n'a aucune réponse. Le ridicule ne tue pas :-))

                Je dirais juste que contrairement à ce que tu as l'air d'insinuer, je n'ai jamais dit que Java était mieux que tel ou tel langage, chaque langage a des avantages et des inconvénients qui les rendent plus ou moins adaptés à certaines tâches.

                Je n'insinue rien du tout. Resituons le message précédent : tu répondais fort prétentieusement à un autre intervenant qu'il était improuvable que Java est lourd et que c'était un FUD éhonté. Je répondais donc strictement à cela ; pour le reste je veux bien croire que certaines personnes trouvent Java adapté pour certaines tâches. Cependant dire que Java n'est pas lourd, là il y a de quoi rigoler très grassement :-)

                • [^] # Re: L'avenir ...

                  Posté par  (site web personnel) . Évalué à 2.

                  Ok, alors dis-moi ou MrTout dit que Java est lourd dans le post auquel je réponds ? Il dit que la syntaxe est lourde mais il ne parle pas de l'exécution.

                  Maintenant dis moi où j'ai été prétentieux ou bien où j'ai essayé de dire qu'il était improuvable que Java était lourd ? On ne parlait déjà pas du fait que Java soit lourd ou pas, et je n'ai dit nul part que Java était meilleur qu'un autre langage ...

                  Rappelle moi de t'offrir du Vu (tm) pour Noël, tu en as bien besoin ;-)

                  Sans racune, Nelis

              • [^] # Re: L'avenir ...

                Posté par  . Évalué à 2.

                Euh il y a truc qui m'a toujours surpris c'est les gens qui aiment les interface a la java et critiquent l'héritage..

                Pour moi, l'implémentation d'interface c'est juste un cas particulier d'héritage d'une classe purement abstraite..

                • [^] # Il y a la theorie et ...

                  Posté par  . Évalué à 1.

                  .. la pratique.

                  Et ne pas generaliser c'est toujours mieux ...

                  J'aime les interface et j'aime l'heritage ;-)

        • [^] # Re: L'avenir ...

          Posté par  (site web personnel) . Évalué à 0.

          Juste pour dire que l'héritage simple est avantageusement remplacable par les interafces, les types primitifs peuvent etre mis dans des objets (Integer par exemple), contravariance je sais pas ce que c'est, règles de protection pas vraiment utile dans la vie de programmeur de tous les jours.. POur la syntaxe, on a beosind e dépoussierer un peu mais faut pas abuser... Voila, Java n'est pas un mauvais langage... dais donc un peu de J2EE avec JOnAS, XDoclet et MySQL... et tu vas voir si c'est si mauvais que ça

          http://about.me/straumat

          • [^] # Re: L'avenir ...

            Posté par  . Évalué à 2.

            Integer, Double, etc... oui, mais pour les utiliser ça devient vite pénible. Par exemple : Double a = new Double (2.0); Double b = new Double (3.0); Double result = new Double( a.doubleValue() * b.doubleValue() ); C'est peut-être là que certains aimeraient voir de la surcharge d'opérateurs (si j'ai bien suivi le fil du débat), pour pouvoir faire plus simplement ce genre d'opérations. Sans compter que de faire des "doubleValue()" et "intValue()" à longueur de programme, ça prend un temps monstre au final (si, si, j'ai testé, JProbe a confirmé)

            • [^] # Deux choses...

              Posté par  . Évalué à 2.

              en premier l'aspect penible : http://minilien.com/?er1EyEGraO(...)

              Ensuite, le "temps monstre", c'est la raison pour laquelle Java utilise des type simple qui ne sont pas des objets !

              Et savoir quoi utiliser peut être considéré comme une optimisation possible du code ... d'ou un OptimizeIt ... ou ton JProbe :P

        • [^] # Pas vraiment un troll ...

          Posté par  . Évalué à 1.

          Chacun est libre de son choix ;-) En premier, avec des "si" on fait toujours bcp de choses. Ainsi, le format des DOC n'est : ni ouvert, ni standardisé, ni propre, ni même stable ... alors si openoffice voulais l'utiliser par défaut il faudrait plutot dire, de quel format DOC tu parles, celui de OfficeXP, 97, 95 ou le format MS-XMLizé ;-) Pour moi, je préfere clairement utilisé une spec dont tout est clairement définit et qui fonctionne partout : PDF ... faute de pouvoir utiliser FO ;-) On ne peut pas vraiment comparé un tel b*rdel MSien, avec une techno dont l'ensemble des specs, des documentation et des codes sources sont disponibles pour le public. Je comprend ta frustation par rapport à certains choix de java, mais là encore, Java n'es pas un langage d'expert mais bien généraliste. Oui, tel ou tel langage, fait mieux, plus concit, plus efficace pour tel ou tel point. Mais il n'en reste pas moins, qu'il reste relativement efficace pour pour une grande majorité de besoins. Et par experience, les cas ou il se revele moins adequat sont compensé par les gains (souplesse, simplicité) réalisés sur le reste du developpement. Enfin, si tu as suivit l'histoire de Java tu as put te rendre compte, que les utilisateurs Java son des gens plutot ouvert au débat et sensible à la découvertes d'autres techno (OS, langages, concepts ...). Java dans sa forme actuelle n'est pas une finalité, mais une étape pour plus d'ouverture. Si tu aimes les defits linguistiques regarde Kiev et OpenJava, 2 langages trés interessants par leur concepts : http://minilien.com/?Leh6p2bYVK

          • [^] # Re: Pas vraiment un troll ...

            Posté par  (site web personnel) . Évalué à 3.

            Et toi, de quelle version de Java tu parles :p Java n'est pas un modèle de compatiblité décendante/acendante non plus. Mais cela prouve qu'au moins les choses ne sont pas figées dans du marbre ce qui est potentiellement un bon point. "On ne peut pas vraiment comparé un tel b*rdel MSien, avec une techno dont l'ensemble des specs, des documentation et des codes sources sont disponibles pour le public." J'avais bien précisé que la comparaison avec Word était honteuse. Sinon Kiev et OpenJava sont de bon projets je pense comme Pizza en son temps (je sais plus où ça en est, ça fait longtemps que j'ai pas regardé) Mais je ne pense pas qu'un emplatre sur une jambe de bois rendra les choses meilleures. Je ne nie pas que java est efficace sur de nombreux points mais je trouve bizarre dans une comunauté (marginale ?) d'informaticiens qui pense que le plus utilisé est pas forcément le meilleur et que de bons concepts de base valent mieux qu'un discours marketting, peu de gens on fait la démarche : "et si Java n'était pas si bien que ça ?", "et s'il n'existait pas quelque chose de mieux, même emmergent, même incomplet, même pas autant utilisable en l'état ?" Croyez-moi, avant je faisait du C++ et du Perl, puis j'ai découvers des concepts nouveaux, des techniques de programmation nouvelles et c'est un peu la révélation : Eiffel, Ruby et GOTO++ pour n'en citer que quelques un qui ont déja une tres grande communauté d'utilisateur des des tas de bibliotheques, docs ou livres de cuisine. Bien sur il manque encore plein de choses, il manque des bibliothèques, il manque des interfaces avec tel ou tel autre composant mais après on se demande comment diable a-t-on pu faire avant. Je sais bien que malgré mes quelques messages sur linuxfr je ne vais pas décimer les Javaiste Intaigristes (d'ailleurs je ne le souhaite pas, Java sait faire des choses encore mieux que personne d'autre) mais si j'ai simplement donné envi à quelques un d'entre vous de regarder autre chose alors c'est déjà pas mal.

            • [^] # Re: Pas vraiment un troll ...

              Posté par  . Évalué à 4.

              Moi je préfère Python à Ruby pour la syntaxe. Je trouve que Ruby n'est pas assez naturel à lire.

              J'ai trouvé intéressant un post qui expliquait que les programmes Java sont difficiles à lire. Pour en avoir fait beaucoup (:-) mais avoir en même temps étudié de nombreux autres langages (entre autres : Ruby, Squeak, Perl, Python, C, C++, C#, etc.) je ne suis pas tout à fait d'accord. Certes, c'est parfois lourd (surtout pour les classes "wrappers" de types primitifs), mais c'est loin d'être illisible. Même certains script Python (que j'adore vraiment) peuvent être bien moins lisibles que Java. Je pense que l'absence, notamment de surcharge d'opérateurs y est pour quelque chose. Par lecture je parle de lire ET comprendre :-)

              Ah et pour moi la chose la plus horrible que j'ai pu croiser dans un langage de programmation, ce sont les variables implicites (hein messieurs Perl et Ruby :-))).

              Enfin, n'oubliez pas que Java n'est pas qu'un langage mais aussi une plate-forme. Ceux qui ont goûté à Jython me comprendront :-)

              • [^] # Re: Pas vraiment un troll ...

                Posté par  (site web personnel) . Évalué à 1.

                Je suis bien d'accord avec toi, s'il y a bien une plaie dans Ruby c'est les variables implicites, mais déjà elles sont implicitement locales ce qui est un moindre mal. (et puis c'est pratique quand on est un faignasse)

                Sinon je ne me suis froté qu'une fois à Python, pour un projet on avait le choix entre Java et Jython et j'ai été le seul a le faire en Jython :)
                Mais je connais pas assez Python pour en dire du bien ou du mal mais il m'avait l'air assez Objet et assez simple à utiliser.

                Quand au fait que Ruby soit naturel à lire, ben, c'est une question d'habitude (et de la personne qui code) mais il est généralement facilement facile à relire et facile à ecrire. Et puis ce que je prefère dans Ruby c'est les itérateurs, de vrais itérateurs virils à la SmallTalk ! :p

                • [^] # Re: Pas vraiment un troll ...

                  Posté par  . Évalué à 3.

                  <blockquote>Quand au fait que Ruby soit naturel à lire, ben, c'est une question d'habitude (et de la personne qui code) mais il est généralement facilement facile à relire et facile à ecrire.</blockquote>

                  Pareil pour Java selon moi :-) Pareil pour le C++ selon d'autres... comme quoi hein :-))

                  P.S : je doute que certains diront même cela du Perl !

                  • [^] # Re: Pas vraiment un troll ...

                    Posté par  (site web personnel) . Évalué à 0.

                    J'ai jamais dit le contraire du moins il ne me semble pas. Je n'attaque jamais les choses sur leur apparance ni le fait que des gens aiment où n'aiment pas.

                    Sauf evidemment les gens qui font du Perl bien endendu :p

                  • [^] # Re: Pas vraiment un troll ...

                    Posté par  (site web personnel) . Évalué à 0.

                    une différence quand même : la taille du code... Le même programme en Python est beacoup moins long qu'en Java, lui même plus court qu'en C++...

        • [^] # Re: L'avenir ...

          Posté par  . Évalué à 1.

          Rate, Java est invariant, et pas contravariant ... (voir la discussion sur http://linuxfr.org/~Epsos/1819.html pour plus d'infos)

          • [^] # Re: L'avenir ...

            Posté par  (site web personnel) . Évalué à 0.

            Je sais bien, c'est moi qui te l'ai dit :p C'est juste un abus de langage de dire contravariant à la place d'invariant. et puis le mot "invariant" a d'autres sens qui peuvent porter à confusion

            • [^] # Re: L'avenir ...

              Posté par  (site web personnel) . Évalué à 0.

              Moui mais c'est pas pareil quand même. Pour moi, qqch d'invariant n'est ni covariant ni contravariant.

            • [^] # Re: L'avenir ...

              Posté par  . Évalué à 1.

              Si tu changeais pas de nick sans arret ... :-)
              D'ailleurs en parlant de Nosica, j'ai trouve un truc sympa : finalement je vais garder l'invariance, mais je vais ajouter les multi methodes (multiple dispatch).
              Du coup ca me permettra de faire de la covariance, sauf que je serai type safe a la compilation et au runtime ...
              Qu'est ce que t'en dis ?

              • [^] # Re: L'avenir ...

                Posté par  (site web personnel) . Évalué à 1.

                C'est un point à creuser mais il me semble que c'est galère à implémenter efficacement ce genre de trucs puisqu'il te faut faire la sélection de la méthode sur plusieurs arguments.

                Mais je pense que c'est une bonne idée.

                • [^] # Re: L'avenir ...

                  Posté par  . Évalué à 1.

                  Dans le cas de Nosica, non seulement c'est pas dur a implementer, mais en plus c'est efficace...
                  En fait, ca ne prend du temps que dans le cas ou tu utilises vraiment la feature... (visiteur, covariance)
                  Merci l'analyse globale ... !! :-)

    • [^] # Re: Java Virtual Machine 1.4.2 beta

      Posté par  (site web personnel) . Évalué à -3.

      Pourquoi est ce qu'on oppose toujours Java et C# ? Y'a rien d'autre qui vale la peine d'être utilisé ?

      Il y a pourtant de très bon langage libre non ? Python, Perl, Ruby, Eiffel, Lisp, Scheme,...

      Et, pour ceux qui ne les ont pas essayés, ils offrent *vraiment* beaucoup plus de possibilités que C / C++ / Java... à quand des générateurs dans Java ?
      Si vous êtes programmeurs Java, n'essayez surtout pas ces langages parce que les essayer c'est les adopter ;-) mais bon ya peu de risque les programmeurs java sont pas assez ouverts pour essayer

      Par ailleurs, je me demande parfois si quelqu'un (Sun par exemple) n'aurait pas intérêt à rendre les specs de Java suffisamment confuses / lourdes / difficile à implémenter, de sorte à être les seuls capables de le faire... d'ailleurs y'a combien de vendeurs qui proposent des JVM à jour (>1.4) ? A part Sun et IBM j'en connais pas (BlackDown c'est le code de Sun je crois).

      Jiba, qui a laissé tombé Java pour Python quand il s'est rendu compte que son prog Java ne pourrait pas être inclu dans des distrib Linux à cause de Java (1.3) non libre.

      • [^] # Re: Java Virtual Machine 1.4.2 beta

        Posté par  . Évalué à 6.

        Mon cher monsieur, si tu avais lu certains posts précédents (j'ai comme l'impression de répondre à un beau troll :-), tu aurais pu constater que, parfois, les développeurs Java essayent voire utilisent d'autres langages. Peux-tu quant à toi comprendre que Java n'est pas qu'un langage mais une plate-forme ? Et que malgré les qualités des langages libres, ils ne constituent pas toujours le choix le plus adapté à telle ou telle tâche ? Mon cher, un développeur ouvert n'est pas celui qui n'utilise que des langages libres, mais celui qui utilise le langage le plus adapté à sa tâche courante.

  • # Re: Java Virtual Machine 1.4.2 beta

    Posté par  . Évalué à 9.

    Inclus une JRE i386 compilée avec GCC 3.2 (intéressant avec Mozilla).

  • # On les sent aux abois !

    Posté par  . Évalué à 7.

    Ahahah, regardez comment Sun sent que la fin du Java est proche. Ils essaient de se dépêcher, ils acceptent même de rajouter les templates. Mais leur langage est fini ! Le GOTO++ balaie tout sur son passage et leurs chances de survie sont nulles ! Toute résistance est futile, rejoignez le clan du GOTO++ !

  • # Java, Mozilla et gcc 3.2

    Posté par  (site web personnel) . Évalué à 3.

    Sinon, pour info, Sun fournit un plugin censé être compatible avec les versions de Mozilla compilées avec gcc 3.2. :

    /usr/java/j2sdk1.4.2/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so

    Jusqu'à présent il fallait se rabattre sur le JRE de Blackdown : http://plugindoc.mozdev.org/whichjava.html(...)

    (notons que cette doc est fausse en ce qui concerne la Mandrake 9.1 vu que Mozilla est compilé avec gcc 2.96 et le plugin de Sun fonctionne très bien avec)

    Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.