Hors Série Java, seconde édition

Posté par  . Modéré par Val.
Étiquettes :
0
28
sept.
2001
Java
Le Hors Série numéro 8 de Login: consacré à Java se penche sur l'utilisation des connexions réseau et de XML au sein de programmes Java.
Pour ce faire, trois petits logiciels sont étudiés:

  • Deux clients emails simple (envoi et réception)

  • Un dictionnaire de traduction simple (XML)

  • Un serveur de jeu de questionnaire (les quiz sont en XML)


Ce Hors Série s'adresse aux personnes possédant les bases de Java. Les gourous de Java n'y trouveront sûrement pas leur intérêt à moins de ne pas connaître le XML.
La partie consacrée au XML décrit la rédaction de documents XML et de DTD. Elle se base également sur l'utilisation d'un parser avec l'API SAX.

Aller plus loin

  • # Login!

    Posté par  . Évalué à -1.

    Plus le temps passe, et plus je le vois. LMF devient plus magasine de linux/hurd/scripting, et login! devient de plus en plus le journal officiel java/BSD (jext est l'oeuvre d'un pigiste login)/ .
    Enfin, cela n'est que mon avis.
    Et par la même occasion, je félicite l'un de leur redacteur qui est vraiment excellent: Gilbou!
    Gilbou, el guru del Bi aisse di

    • [^] # Re: Login!

      Posté par  . Évalué à 10.

      T'y vas un peu fort... s'il est vrai que LMF est a fond orienté technique, Login: n'évolue pas plus vers java/bsd qu'autre chose.

      Au contraire, je trouve de plus en plus de propositions, de découvertes et de choix qui nous sont proposés par ce magasine. Je le trouve généraliste : il parle de tout, avec un regard different, on retrouve une partie des passionnés qui ont codés sur atari, amiga et autre sasfépu, et ca fait du bien de trouver un magazine pour une cible autre que ceux qui ont découvert l'informatique avec windows.

      Je ne dit pas que Login: est une référence du monde libre, mais il permet de se rendre compte qu'on l'est quand même un peu...

      • [^] # Re: Login!

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

        En passant, Login: ne cherche pas à être une référence du monde libre. Le sujet du mag est l'informatique "alternative".

        QNX, BeOS et d'autres ne sont pas libre, mais dans le scope de Login:.

        • [^] # Re: Login!

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

          Je me rappelle d'ailleurs du numéro datant de la sortie du BeOS librement téléchargeable.
          L'éditorial ressemblait à cela :
          "Nous allons nous recentrer sur BeOS, Linux est entré dans une nouvelle ère et n'a plus rien d'alternatif."
          A mon avis, ils ont du revoir leur politique pour pouvoir faire faire du chiffre : J'ai cru voir qu'il parlait toujours de Linux.

      • [^] # Re: Login!

        Posté par  . Évalué à 9.

        Et d'ailleurs, en novembre vous découvrirez l'ouverture de la rubrique Zope pour faire bonne impression aux côtés des rubriques JSP et Python :)

      • [^] # Re: Login!

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

        De manière plus générale, il suffit de dire une seule chose pour résumer le tout : de la presse indépendante voilà ce qu'est Login et LMF.

        • [^] # Re: Login!

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

          Je parlerais plutot d'une presse de niche ; LMF appartient à une société Diamond Editions (pub page 8 du n°32 de LMF), qui n'a presque que des revues spécialisées (je ne pense pas que la diffusion d'un magazine de Magie soit très importante). On est donc pas dans le cas d'une publication indépendante, ie indépendante d'un groupe de presse.
          Attention, je ne veux pas dire par là que la rédaction n'est pas indépendante. Je tiens juste à signaler que l'on est ni face à un fanzine, ni face à une presse indépendante au niveau financier.

      • [^] # Re: Login!

        Posté par  . Évalué à -1.

        Oui, tu vas vraiment un peu fort... Login parle aussi beaucoup de Windows. Faut pas déconner, on peut pas enlever ça qd même.

        Laurent qui trouve que Login, c'est plus dream :o( ... pof un -1 pour ma pomme !

    • [^] # Re: Login!

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

      J'ai l'impression que tu as raison sur BSD (en tout cas sur une sorte de remplacement de linux par BSD), mais par contre Java était déjà très largement présent dans Dream, l'ex-login. Avec d'ailleurs (à l'époque) un contenu parfois étrange (des mises en garde un peu délirante contre le garbage collecting de Java qui rendrait les programmes plus difficiles à débugguer).

      • [^] # Re: Login!

        Posté par  . Évalué à 0.

        >J'ai l'impression que tu as raison sur BSD (en
        >tout cas sur une sorte de remplacement de linux
        >par BSD)

        En fait je n'utilise qu'OpenBSD et Moz Linux. Lorsque je rédige un article ou un dossier, tout ce qui requiert un shell, ou quoi que ce soit se trouve donc sous BSD. Moz qui teste le matos teste tout sous Debian.. C'est pour cela que de plus en plus les dossiers ont pour base un BSD et que mes "en pratiques" sont centrés sur Open ;-)

        --
        Gilbou
        (gilbertf@posse-press.com)

    • [^] # Re: Login!

      Posté par  . Évalué à 0.

      Heee merci c'est sympa =)
      Heureux de rencontrer un autre amateur d'OpenBSD he he ;-)

      Moi j'aime bien lire LMF. Chu pas abonné, mais je le lis tous les mois : un bon zine.

      C'est dommage qu'il y ait moins de presse Linux parce que de voir plein de magazines ça permettait d'occuper les étals et d'intéresser les gens. Il doit rester que trois magazines je crois actuellement et c'était quand même sympa d'avoir un bon contenu dense comme avant. Tout était pas toujours très bon mais même moi j'ai écrit des trucs dont j'ai un peu honte (burp)

      --
      Gilbou
      (gilbertf@posse-press.com)

  • # Un bel exemple de java

    Posté par  . Évalué à 5.

    ça n'a rien à voir avec la news a priori mais c'est joli et c'est du java.

    voilà : http://equinox.planet-d.net/java/pupul.html#java(...)


    source : http://www.joystick.fr/actus/fiche_actu.php3?ID=244(...)

    attention à la chute de productivité (ça ma été fatal cette aprem :)

  • # le site de Login suxe.

    Posté par  . Évalué à -7.

    Mais bon sang, c'est quoi ce putian de redirect à la con que
    vous utilisez ? C'est pour virer les vieux cons en Lynx ?

    --
    tontonTh, vieux con en Lynx.

    • [^] # Re: le site de Login suxe.

      Posté par  . Évalué à 6.

      La redirection fonctionne tres bien sous Lynx. Par contre, je n'en dirait pas autant du site de Login, il vaut mieux ne pas utiliser un browser alternatif...

  • # souhait pour un futur article sur java

    Posté par  . Évalué à 4.

    j'achéterais très certainement ce numéro, mais il me manque quelque chose quand meme :
    comment optimiser du java et comment utiliser le multithreading ?

    Sera-t-il possible de faire un article sur ces points, avec pour exemple le code de jext (a ce propos merci Romain) ?
    C'est pas pour faire de le lèche-bottes, mais c'est le seul éditeur écrit en java qui va à une vitesse raisonnable et ne nécessite pas 2 gigas de ram.

    --
    daniel desages

    • [^] # Re: souhait pour un futur article sur java

      Posté par  . Évalué à 7.

      [i]comment optimiser du java et comment utiliser le multithreading ? [/i]
      Pour l'optimisation de Java, tu trouveras un article "avorté" sur www.programmationworld.com. Je compte bien en refaire un un de ces jours. Mais pour le moment, il s'agit de couvrir la programmation Java sur Palm Pilot. Encore un mois ou deux et je m'y colle :)
      Pour le multi-threading, aucun problème, j'essayerais de pondre ça après le Palm :)

      [i]C'est pas pour faire de le lèche-bottes, mais c'est le seul éditeur écrit en java qui va à une vitesse raisonnable et ne nécessite pas 2 gigas de ram. [/i]
      Merci :-) A ce propos, la version 3.0 devrait sortir d'ici fin Octobre et elle ajoute pas mal de choses sympa (surtout la 3.0pre10 qui est encore sur mon HD :)

      • [^] # Désolé pour les tags

        Posté par  . Évalué à -7.

        Ooopss j'ai collé des tags UBB au lieu d'HTML :(

        • [^] # Re: Désolé pour les tags

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

          UBB ?
          qu'est-ce ?

          • [^] # Re: Désolé pour les tags

            Posté par  . Évalué à 3.

            UBB est un forum écrit en perl je crois... c celui utilisé sur les sites Login: et PC Team que je fréquente beaucoup (trop ? :))).

            • [^] # Re: Désolé pour les tags

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

              Oui oui beaucoup trop,
              et le forum est bien ecris en perle,
              d'ailleurs je viens aussi de mettre les codes ubb dans la tribune libre sans faire expres :)

              UBB comme tant d'autres boards/forums (c'est pareil..) demande de mettre des [] a la place des <> pour le html et simplifient certaines balises.

              [moua]

    • [^] # Re: souhait pour un futur article sur java

      Posté par  . Évalué à 10.

      Qu'est ce que tu appelles optimiser du Java ? Il y a de nombreuses manieres pour cela... Par exemple de nombreuses machines virtuelles Java disposent d'un 'compilateur' Just In Time qui a l'avantage d'optimiser les parties de codes deja executees (globalement au sein d'un process, la premiere execution d'un bout de code est lente et les suivantes sont presque aussi rapides que du code natif (en theorie du moins))
      Pour le multi-threading est Java est vraiment le langage le plus facile a ma connaissance pour faire du multi-threading, a un tel point que l'on a honte apres de dire que l'on sait utiliser des threads en Java :))

      • [^] # Re: souhait pour un futur article sur java

        Posté par  . Évalué à 10.

        Optimiser du code Java ? Je ressors mon exemple classique: une boucle itérative chargée de concaténer des éléments dans une chaîne. Chaque élément est pris d'un tableau de 10 000 objets.
        Si tu utilise l'objet String, la boucle prend plus de 10 secondes sur un P200 48 Mo de RAM et JDK 1.2.2. Avec l'objet StringBuffer on descend aux alentours de 170 milli-secondes... voilà de l'optimisation :)

        • [^] # Re: souhait pour un futur article sur java

          Posté par  . Évalué à 5.

          Je suis bien d'accord, mais il demandait simplement comment optimiser du Java et je voulais soulever que c'etait un vaste sujet.
          Optimiser le code est une possibilite. L'utilisation de tableaux a la place de Vector (ou tout autre type de set certes puissant mais gourmand) lorsque c'est possible est un autre exemple d'optimisation de code.

          • [^] # Re: souhait pour un futur article sur java

            Posté par  . Évalué à 9.

            je sais bien que le sujet est vaste et quand je dis optimiser du java je parle bien du code et pas des algos, autrement dit j'aimerais en savoir plus sur les fonctions du langage qui sont rapides, les structures de données à éviter, la manière d'utiliser des classes internes ou des fonctions statiques pour avoir une application plus rapide, etc.

            je ne suis pas un débutant en java. j'ai un niveau de connaissances suffisant, mais je cherche à devenir vraiment bon dans ce langage qui n'est pas mon préféré (c'est python mon préféré)

            • [^] # Re: souhait pour un futur article sur java

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

              Bah le texte de Romain sur www.programmationworld.com est rapide mais contient déjà des choses intéressantes.

              Perso, je pensais que le compilateur s'occupait tout seul de faire les optimisations style "a += b" et "a << 4" à la place de "a = a + b" et "a * 16". Et bien apparement ce n'est pas le cas.

              (en passant, pour Romain : s/notre/autre/ dans le 3ème paragraphe de la page sur l'optimisation (5))

              Et une petite précision (mais je suis sur que c'est pour garder un texte court que ça a été omit) : Le fait de déclarer une méthode "final" ne sert pas que à fournir une possibilité d'optimisation au compilateur. À ce que j'en sais, il y a aussi une amélioration des perf à l'execution dans certain cas (quand myRef.toto() est invoquée, pas la peine d'aller voir si le type "runtime" de myRef n'est pas une classe qui surcharge toto()). Donc ce n'est pas "L'intérêt de telles méthodes..." mais "Un des intérêts de telles méthodes..."

              Comment ça je chipotte ?
              Ce n'est pas du chipottage. Ce post est en fait une tentative d'obtenir confirmation de ce que j'ai marqué après "À ce que j'en sais" ;-)

              • [^] # Re: souhait pour un futur article sur java

                Posté par  . Évalué à -1.

                Je suis surpris qu'il soit necessaire de faire des optimisations de si bas niveau..

                A mon humble avis, ils sont un peu "faible" les compilateurs Java..
                Ca ne va pas faciliter la lecture du code..

                • [^] # Re: souhait pour un futur article sur java

                  Posté par  . Évalué à 10.

                  En réalité, ces optimisations sont utiles dans le cadre d'application demandant de gros calculs. Et encore. La principale optimisation que l'on peut faire en Java concerne la logique des algorithmes elle même. Le log(n) vaincra ! :-))

                  Pour faire un programme Java qui tienne la route, il faut également avoir une solide architecture objet, bien pensée. Ce sont là les deux meilleurs choses à faire avant d'utiliser les bidouilles de type "a << 4".

              • [^] # Re: souhait pour un futur article sur java

                Posté par  . Évalué à 3.

                Merci pour les remarques. Comme je l'ai dit il s'agit d'un article avorté. Il était destiné à Login: mais je l'ai (je ne sais plus pourquoi) laissé de côté en plein milieu. Conclusion: aucune relecture :-)))

                Pour ce qui est du final, il y a effectivement une optimisation d'exécution. Les static final permettent normalement d'être inlinée. Mais je crois que les derniers compilateurs javac ne le font plus.

                Enfin, l'option -O de javc ne sert plus à rien.

              • [^] # Re: souhait pour un futur article sur java

                Posté par  . Évalué à 10.

                Un problème de java par rapport à C++ c'est que _toutes_ les méthodes sont virtuelles par défaut. Au niveau langague objet, c'est un plus, l'héritage et bien plus facile et souple. Il n'y a pas non plus de problèmes avec les interfaces des API si les fonctions publiques changes.

                Mais quand je pense à tout les getTruc setTruc que contiennent les codes java avec:
                int getTruc(){ return this.truc; }
                void setTruc(int truc){ this.truc = truc; }

                ou pour affecter une variable on doit:
                1. aller chercher dans la v-table de l'objet le pointeur sur la fonction
                2. créer la fonction
                3. faire l'affectation
                4. gérer le retour de la fonction

                alors que si la fonction était non virtuelle le compilo aurait simplement mis en ligne this.truc = truc, je me dis que "a = a + b" ne doit pas être gros problème.

                Biensûr on peut mettre la fonction en final, mais comme personne ne le fait les compilos ne sont pas optimisés pour. On peut aussi tout écrire avec des variables publiques mais c'est très dangereux (pas de var en lecture seul).

                démo:

                class Test {
                public int var;
                public int getVar() {
                return this.var;
                }
                public void setVar(int var) {
                this.var = var;
                }

                public static void main() {
                int i;
                Test t = new Test();

                i = t.getVar();
                t.setVar(i);

                i = t.var;
                t.var= i;
                }
                }

                # javac Test.java
                # javap -c Test

                Method int getVar()
                0 aload_0
                1 getfield #2 <Field int var>
                4 ireturn

                Method void setVar(int)
                0 aload_0
                1 iload_1
                2 putfield #2 <Field int var>
                5 return

                Method void main()
                0 new #3 <Class Test>
                3 dup
                4 invokespecial #4 <Method Test()>
                7 astore_1
                8 aload_1
                9 invokevirtual #5 <Method int getVar()>
                12 istore_0
                13 aload_1
                14 iload_0
                15 invokevirtual #6 <Method void setVar(int)>
                18 aload_1
                19 getfield #2 <Field int var>
                22 istore_0
                23 aload_1
                24 iload_0
                25 putfield #2 <Field int var>
                28 return

                Même résultats avec et sans final get|setTruc.

                # java -version
                java version "1.3.0"
                Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.0-FCS)
                Java HotSpot(TM) Client VM (build Blackdown-1.3.0-FCS, mixed mode)

                hop -> -1, c'est un peu long

                • [^] # Re: souhait pour un futur article sur java

                  Posté par  . Évalué à 0.

                  Normalement le compilateur java 1.4 est capable de détecter les toutes fonctions non "overridees" pour automatiquement les "finaliser".

                  • [^] # Re: souhait pour un futur article sur java

                    Posté par  . Évalué à 2.

                    Comment il pourrait faire ?

                    Qu'es-ce qu'il lui prouve que dans un autre projet, utilisant le projet courant compilé, quelqu'un d'autre ne cherchera pas a surcharger une de ses méthode ?

                • [^] # Re: souhait pour un futur article sur java

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

                  Cool, c'est une des premières fois que je lis une critique correcte du "virtuel" en Java. Nous sommes bien d'accord que la sémantique de Java facilite la programmation objet et c'est d'ailleurs pour ça que la plupart des langages objets (Eiffel, Sather, etc.) ont adopté cette technique (bien avant Java). On peut d'ailleurs dire que C++ est un cas particulier qui rend la programmation objet plus délicate.

                  Tu as raison aussi de dire que c'est un problème de compilation. En effet, il est parfaitement possible d'écrire un compilateur optimisant qui utilise virtual quand il en a vraiment besoin et pas quand il peut s'en passer. C'est déjà fait pour Sather (http://www.gnu.org/software/sather/(...) ) ainsi qu'en Eiffel (http://www.loria.fr/projets/SmallEiffel/(...) ). Le résultat est en général assez puissant car on peut alors obtenir de l'inlining de méthodes "virtuelles", ce qu'aucun compilateur C++ ne sait faire à ma connaissance. Bien entendu, ce système repose sur une analyse globale du code et coûte donc très cher à la compilation.

Suivre le flux des commentaires

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