Java la synthèse - Vers la maturité avec le JDK 1.2

Posté par  . Modéré par trollhunter.
Étiquettes :
0
15
oct.
2000
Java
Vous débutez en Java et vous cherchez un ouvrage pour vous accompagner, cet ouvrage peut vous aider :
Extrait:
"Ce livre doit se voir soit comme une introduction au langage Java, visant les néophytes, soit comme un rappel occasionnel des concepts "de base" pour un public un peu plus averti. En aucun cas il ne faut en attendre plus"






























Java la synthèse - Vers la maturité avec le JDK 1.2
Auteur G. Clavet/N. Mirouze/S. Munerot/E. Pichon/M. Soukal
Editeur InterEditions( Dunod )
ISBN 2-225-83416-4
Pages 286
Prix Prix constate 195FF
Rédacteur Next



Couverture
<!-- Ceci est a mettre comme texte de la news annoncant la revue<br/> du livre -->



Ce livre doit se voir soit comme une introduction au langage Java,
visant les néophytes, soit comme un rappel occasionnel des concepts
"de base" pour un public un peu plus averti.
En aucun cas il ne faut en attendre plus!


<!-- Fin du texte de la news -->



Personnellement, j'ai commencé le développement Java
avec ce livre. Il est à la fois simple, clair et concis.
Contrairement à ce que l'on trouve dans certains autres ouvrages,
je n'y ai pas detecté d'erreurs facheuses!
Les concepts abordés dans java la synthese sont:




Le concept objet


  • classe

  • encapsulation

  • accesseurs

  • methodes

  • modificateurs d'acces

  • packages





les types primitifs et objets


  • operateurs

  • héritages

  • transtypage

  • polymorphisme





les outils avancés de java


  • classes abstraites

  • héritage simple et multiple

  • interface

  • implémentation dynamique de classe

  • gestion des exceptions

  • gestions des fluxs

  • sérialisation





Interface graphique sous AWT


  • conteneurs et composants

  • barre d'état

  • barre d'outils

  • barre de menu

  • applet

  • gestion des evenements

  • dessin





Applet et thread


  • thread et synchronisation

  • médiatracker

  • double buffer






En raison de sa date de parution (octobre 1998)
Ce livre ne traite pas des évolutions actuelles de Java 2
et ne traite pas non plus en détail de la maniere de construire et gerer
les JAR (Java ARchive) ni de la gestion de projet sous Java/UML.
La critique majeure que l'on pourrait emettre est que les exemples sont
parfois fournis uniquement en tant qu'applet. Il eu été bon de les
fournir également en tant qu'application.




En conclusion, étant un livre "d'introduction à java", on ne saurait
toutefois lui en tenir rigueur.
Après s'être fait la main sur 'Java la synthèse', on passera tout naturellement
à d'autres ouvrages qui traitent, eux, des points sus-cités.





NB: une nouvelle édition est à paraitre pour septembre 2000
sous l'ISBN 2-10-005040-0



Table des matières


  • chapitre 1 - Java et les objets

  • chapitre 2 - Des types primitifs à l'héritage

  • chapitre 3 - Les outils avancés du langage

  • chapitre 4 - Construire une interface graphique

  • chapitre 5 - Applets et threads

  • chapitre 6 - Développer des composants réutilisables avec les JavaBeans

  • chapitre 7 - Java, aujourd'hui et demain



Références



Aller plus loin

  • # Penser en Java

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

    Pour ceux qui cherchent un bouquin en francais sur Java, je vous conseille la traduction en francais du livre de Bruce Eckel "Thinking in Java".
    Le site officiel de la traduction est a:
    http://penserenjava.free.fr/(...)

    La traduction n'est pas terminee mais les premiers chapitres sont deja disponibles.

    Ce livre s'adresse aux debutants aussi bien qu'aux programmeurs avertis. La lecture du bouquin est plus facile si l'on a quelques connaissances en C.

    Le livre est interessant car il a ete ecrit un peu dans l'esprit open-source: il a toujours ete disponible sous version electronique a divers stades d'avancement. Des milliers de lecteurs ont contribue a enlever la plupart des erreurs et imprecisions du livre. Il s'agit de sa deuxieme edition, couvrant Java 2 Standard Edition (Swing est largement traite) plus une partie de Java 2 Enterprise Edition (Servlets/JSP/JNDI...).

    Pour en savoir plus, consultez le site de Bruce Eckel (en anglais):
    http://www.MindView.net/(...)

  • # vous débutez en JAVA...

    Posté par  . Évalué à 0.

    ... il est encore temps de fuir !!!
    Plus sérieusement il est encore temps d'étudier les alternatives avant de vous engager (en particulier Python, réellement multiplateforme et évolué, mais il existe bien d'autre langages ! Voir étude http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf(...)).

    Problèmes de JAVA :
    - verbeux (c'est comme du C++, les pointeurs en moins)
    - faut encore compiler
    - statiquement typé (aussi coincé au niveau objet que le C++)
    - pas d'héritage multiple (sémantique floue des "interfaces")
    - grosse conso mémoire des JVMs qui manquent de maturité

    Le seul avantage sur C++ : des tonnes de librairies *encore* standards (mais attention aux changement d'API sans préavis ; ce langage n'a rien d'ouvert, il est verouillé par SUN).

    • [^] # Re: vous débutez en JAVA...

      Posté par  . Évalué à 0.

      >faut encore compiler
      comme tu le dis. Y'en a qui considere que c'est un AVANTAGE de compiler

      et si java c'est si "merdique", tu expliques jPython ?

      et de toute facon, comme le rappelle sans arret les "vrais" trolleurs:
      USE THE RIGHT LANGUAGE FOR THE RIGHT JOB
      (pour ceuz qui cause pas l'angolais: une tondeuse pour couper l'herbe, une porsche pour l'autoroute, une twingo pour Paris)

      • [^] # Re: vous débutez en JAVA...

        Posté par  . Évalué à 0.

        JPython, c'est juste pour le hack (c'est carrément lent), pour dire que Python tourne partout ou ya du JAVA, et pour séduire les boîtes qui préfèrent diffuser du ByteCode que des sources !

      • [^] # Re: vous débutez en JAVA...

        Posté par  . Évalué à 1.

        le bon langage pour le bon boulot : c'est bien ce que semblait dire le message, non ? D'étudier ce qui existe avant de suivre la mode (ou l'intox, celon les expériences :-(

    • [^] # Python reellement multiplateforme

      Posté par  . Évalué à 0.

      ah bon ?
      c'est quoi le GUI standard pour Python ?


      et c'est ou l'equivalent de jBuilder pour python ?

      • [^] # Re: Python reellement multiplateforme

        Posté par  . Évalué à 0.

        Java a bien un GUI standard, il en a meme deux mais bon:
        - AWT: c'est le seul qui est vraiment disponible partout, mais au niveau API beurk! Carrement beurk!
        - Swing: nettement mieux au niveau API!
        Dans les cotes negatifs:
        -Ca n'est pas disponible partout.
        -L'API est bien, mais l'implementation est(etait?) pourrie: lente, buggee, quasiment impossible d'imprimer!,avec une consommation memoire pas sympa, plus des fuites memoires..

        Peut-etre qu'avec le JDK 1.3 ca va mieux, je ne sais pas, mais il vient a peine de sortir de la Beta alors il ne doit pas etre tres repandu.

        Bref utiliser Java pour faire des interfaces graphiques, ce n'est pas forcement une bonne idee!

        PS:
        je ne poste pas tres souvent, donc j'en ai marre de m'authentifier a chaque fois, mais mon login est renoX.

        • [^] # Re: Python reellement multiplateforme

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

          <<- AWT: c'est le seul qui est vraiment disponible partout,>>

          Tu parles des navigateurs. Effectivement, il faut java 2 pour utiliser swing et java 2 est quand même disponible sur pas mal de plateforme. Donc faudrait pas pousser.

          << mais au niveau API beurk! Carrement beurk!>>

          Bof. J'espère que tu parles de la 1.1. Parce que bien sûr si tu parles de la 1.0, nous sommes d'accord, mais c'est profondément débile. La 1.0 est morte. Parler d'une version obsolète du langage, ce n'est pas très fair play.

      • [^] # Re: Python reellement multiplateforme

        Posté par  . Évalué à 1.

        Disponibles pour toute plateforme :
        - wxWindow (qui te fait à partir d'un code standard, un GUI natif à ta plateforme, donc tu tintègre bein)
        - Tkinter (le fameux Tk, qu'on adore detester, mais qui est quasi-universel)

        sinon, c'est tellement facile d'étendre le langage, qu'en plus, t'as le choix en des toolkits spécifiques : ça peut toujours servir.

      • [^] # Re: Python reellement multiplateforme

        Posté par  . Évalué à 0.

        Un langage qui est multi-plateforme, assez puissant pour en faire un desktop Objet complet,
        qui a fait ses preuves (NeXtStep-MacOS X) c'est Obj-C et l'API openstep.

        Note : Il est désormais possible de faire des appels à des objets Java à partir de GNUstep et inversement.
        http://gnustep.net(...)
        http://gnustep.org/information/machines_toc.html(...)
        http://www.gnustep.it/jigs/index.html(...)

        • [^] # Java et OpenStep

          Posté par  . Évalué à 0.

          Accessoirement MacOSX, l'unix grand public, il a tous les bindings en Java aussi

          USE THE RIGHT TOOL FOR THE RIGHT TASK
          pour ceux qui parle pas l'angolais,
          c'est beurre pour derriere et preliminaires pour devant

    • [^] # Re: vous débutez en JAVA...

      Posté par  . Évalué à 1.

      Bien sûûûr!
      Et tu te sent d'attaque pour convaincre une société qui a déja un existant en Java, de tout porter dans un langage dont les « décideurs » n'ont jamais entendu parler ?

    • [^] # Re: vous débutez en JAVA...

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

      <<- verbeux >>

      Question de goût.

      <<(c'est comme du C++, les pointeurs en moins)>>

      N'importe quoi.

      <<- faut encore compiler>>

      Et alors ? Vraiment n'importe quoi.

      <<- statiquement typé>>

      Et alors ? N'importe qui avec une formation minimale en génie logiciel te dira que c'est justement une très bonne chose.

      <<(aussi coincé au niveau objet que le C++)>>

      Qu'est ce que ça veut dire ?

      <<- pas d'héritage multiple>>

      Soit, c'est un vrai défaut.

      <<(sémantique floue des "interfaces")>>

      J'ai l'impression que tu utilises le mot sémantique sans le comprendre. La sémantique des interfaces de Java est parfaitement claire. Ce sont des types abstraits.

      <<- grosse conso mémoire des JVMs qui manquent de maturité>>

      Effectivement, mais ça n'a pas grand chose à voir avec le langage lui-même.

      • [^] # Re: vous débutez en JAVA...

        Posté par  . Évalué à 0.

        T'as l'intention d'écrire des programmes réels avec un langage virtuel (puisque d'après toi, on se fout de la qualité des JVM !) ?

        Par "sémantique", je pense que le gars (ou la fille) voulait parler du "sens", du rôle, bref, qu'est ce que ça fout là à part boucher le trou laissé par l'abscence d'héritage multiple. D'ailleurs, les déveleppeurs de chez Sun n' utilisent pas beaucoup les interfaces - cf code de SWING).

        Une qualité majeure d'un langage, c'est la rapidité de développement. Dans ce cas en effet, la passe compilation, ou l'absence de mode interactif peut retarder, ou du moins fatiguer. Mais le pire, c'est bien le côté verbeux : + de lignes, + de temps passé à taper, + de risque d'erreur. C'est pas un progrès en matière de langage.

        POur ce qui est des types statiques, les deux approches se valent :
        1) un type est défini (et limité) par le nom qui lui a été attribué et pas seulement par ses propriétés.
        2) un type est défini d'abord par ses propriétés (comme en maths). Je trouve sympa de pouvoir passer en argument de fonction un objet fichier, buffer, chaîne ou socket dès lors qu'ils ont les mêmes attributs et méthodes. Ajouter dynamiquement des attributs à un objet ne changeant pas ses propriétés, c'est tout à fait acceptable d'imaginer qu'une fonction y colle ses propres "étiquettes" ou marqueurs pour usage privé. Voire même que l'objet s'auto-modifie ou se "questionne" (détection des méthodes ou attributs), ou se fasse questionner. De même, générer une définition de classe de façon dynamique et instancier ensuite des objets est génialement pratique. C'est super clean, on va au fond du concept objet. Et ça me manque en JAVA. C'est pour ça que moi aussi, je me tourne vers Python (moins connu en effet, mais ça vaut le coup de jeter un oeil, pour ceux que le concept objet passionne).

        Bon, moi aussi j'attends toujours, comme d'autres, les différences fondammentales, niveau langage pur, entre Java et un C++ à qui on aurait enlevé les pointeurs et autres. "n'importe quoi" n'avance pas, comme réponse. Qu'il n'y en ai pas tant n'est pas une tarre, car le but de JAVA étant de se répandre, il doit être facile de l'apprendre quand on connaît C ou C++ (très répandus).

        • [^] # Re: vous débutez en JAVA...

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

          <<T'as l'intention d'écrire des programmes réels avec un langage virtuel (puisque d'après toi, on se fout de la qualité des JVM !) ? >>

          J'ai dit que cela n'avait pas de rapport direct avec le langage lui-même, ce qui n'est pas exactement le même chose. Les JVM s'améliorent à chaque génération. Je pense qu'à terme, la consommation de mémoire ne sera plus un problème, car intrinsèquement, Java n'implique pas nécessairement une grosse consommation mémoire.

          <<Par "sémantique", je pense que le gars (ou la fille) voulait parler du "sens", du rôle, bref, qu'est ce que ça fout là à part boucher le trou laissé par l'abscence d'héritage multiple.>>

          Ca sert effectivement à remplacer (en partie seulement) l'héritage multiple, mais ça n'a rien à voir avec la sémantique. Quand on parle de langage de programmation, le minimum est d'utiliser correctement le vocabulaire technique. Sémantique, ça n'a jamais voulu dire "utilité". De plus, les interfaces permettent une séparation propre entre le sous-typage (dire que A et B ont même type) et l'héritage. Pour des raisons un peu longues à développer ici, c'est une très bonne idée (cf les documents de conception de Sather, par exemple).

          <<D'ailleurs, les déveleppeurs de chez Sun n' utilisent pas beaucoup les interfaces>>.

          Affirmation fausse. Cf le code des Collections. Ils utilisent les interfaces quand elles sont utiles.

          <<Une qualité majeure d'un langage, c'est la rapidité de développement.>>

          Ce n'est pas l'avis des spécialistes en génie logiciel. Pour certaines applications, il faut effectivement développer rapidement. Pour d'autres ce n'est pas le cas.

          <<Mais le pire, c'est bien le côté verbeux : + de lignes, + de temps passé à taper, + de risque d'erreur. C'est pas un progrès en matière de langage. >>

          Etrange que le DoD ait choisi en son temps ADA qui est pourtant très verbeux. Etrange que C/C++/Java trustent l'écrasante majorité du développement, avec VB pour le in-house. Ces langages sont pas mal verbeux (et encore).

          Je ne quote pas le passage sur le typage qui est risible. Comme tu ne sembles pas le savoir, je te précise simplement qu'il est effectivement possible en Java d'engendrer une définition de classe dynamiquement, d'instancier les objets, etc. On peut "questionner" les objets, comme tu dis. Va lire une doc Java et reviens discuter ensuite.

          <<"n'importe quoi" n'avance pas, comme réponse.>>

          En effet, mais face à des affirmations stupides, je ne sais pas quoi répondre. Les pointeurs existent en Java. D'ailleurs les objets sont tous manipulés par pointeurs. C'est pas parce que les ponteurs sont déréférencés et qu'on ne peut pas faire d'arithmétique avec eux qu'ils ont disparus. Quand je lis "Java c'est comme du C++, les pointeurs en moins", j'ai envie de baffer l'auteur. Comme je suis au fond un gentil garçon, je me contente de dire "n'importe quoi".

          • [^] # Re: vous débutez en JAVA...

            Posté par  . Évalué à 1.

            Tiens, je profite d'avoir un spécialiste sous la main. Dans ta réponse tu dis qu'il ya des possibilités de créer dynamiquement des classes d'objets. Si cette classe est créée de rien, sans héritage, comment tu écris ta fonction pour qu'elle puisse accepter des instances de cette classe ? Tu as un type "joker" qque part ? J'ai compris qu'après tu peux demander à l'objet la liste de ses méthodes (si j'ai bien suivi), mais c'est le prototype des fonctions qui auront à le manipuler qui me pose problème. Merci.

        • [^] # Re: vous débutez en JAVA...

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

          ENCORE !!!!!
          Je ne pense pas que vous puissiez vous mettre d'accord sur le "meillieur" langage avec une approche comme la votre...
          C'est comme répondre à : un pull ou un T-shirt.

          Pour moi c'est simple :
          - les langagues de scriptes pour les petites
          tâches.
          - L'ADA pour les "grosses" application ou le
          temps réel ( partout ou c critique )
          - Le JAVA pour les applications devant "voyager"
          ( pour moi son avantage c sa portabilité )
          - Et le C/C++ pour le reste...

          Vous ne pensez pas que chaque langage à un avantage pour un certain type d'application ?

          Sinon je ne pense pas que le java soit un bon langage pour débuter.
          Attention, j'adore la programmation objet mais je pense qu'il est préférable de débuter par la programmation procédurale.

          • [^] # Re: vous débutez en JAVA...

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

            <<ENCORE !!!!! Je ne pense pas que vous puissiez vous mettre d'accord sur le "meillieur" langage avec une approche comme la votre... >>

            Là n'est pas la question. Je me contente de répondre aux conneries dites.

            <<Vous ne pensez pas que chaque langage à un avantage pour un certain type d'application ? >>

            Si, bien que je ne sois pas d'accord avec votre classification.

            <<Sinon je ne pense pas que le java soit un bon langage pour débuter. Attention, j'adore la programmation objet mais je pense qu'il est préférable de débuter par la programmation procédurale.>>

            C'est faux pour deux raisons :

            1) on peut faire de la programmation procédurale en Java, donc votre objection n'a pas de sens
            2) j'enseigne Java comme premier langage depuis trois ans en Fac, et c'est une réussite totale : les élèves sont bien meilleurs qu'avant (je peux développer, mais c'est vraiment très hors sujet).

            • [^] # Re: vous débutez en JAVA...

              Posté par  . Évalué à 0.

              En vérité, l'erreur serait de venir à la programmation via un langage trop simpliste, style Visual Basic... Il faut que la personne soit face à du code et utilises le clavier plutôt que la souris...
              Cependant, je ne pense pas que Java soit génial comme premier langage, justement à cause de l'aspect orienté-objet... Même si on peut éviter la POO avec Java, mieux vaut utiliser C ou Pascal

            • [^] # Re: vous débutez en JAVA...

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

              Je ne suis pas d'accord, en java TOUT est objet
              ( même le main doit étre dans un objet... )
              J'ai constaté que les étudiants ne connaissant
              que le java sont incapable de faire la différence
              entre une méthode et une fonction...
              Ils ne savent plus détacher les données des methodes ( ce qui est trés bien avec une approche
              objet ).

              De plus s'ils programment en java sans les conceptes objets, les class qu'ils codent ne
              sont pas logique ( comment savoir quel méthodes grouper dans tel class sans approche objet )

              • [^] # Re: vous débutez en JAVA...

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

                <<Je ne suis pas d'accord, en java TOUT est objet
                ( même le main doit étre dans un objet... ) >>

                Faux. Le main doit être dans une classe. Il est vrai que Java utilise le terme de classe pour désigner deux choses différentes : un modèle pour des objets MAIS AUSSI un système d'organisation du code. Il n'y a AUCUN BESOIN de comprendre les objets pour écrire un main.

                <<J'ai constaté que les étudiants ne connaissant que le java sont incapable de faire la différence entre une méthode et une fonction...>>

                Question de vocabulaire. En Java, tout est méthode. Mes étudiants font la différence entre méthode de classe (i.e., fonction) et méthode d'instance (i.e., méthode au sens du C++).

                <<Ils ne savent plus détacher les données des methodes ( ce qui est trés bien avec une approche
                objet ). >>

                Je ne comprends pas cette phrase.

                <<De plus s'ils programment en java sans les conceptes objets, les class qu'ils codent ne sont pas logique ( comment savoir quel méthodes grouper dans tel class sans approche objet )>>

                Avec une approche procédurale. Il est aussi difficile de faire un .h cohérent que de faire une classe cohérente (vu que c'est la même chose pour le deuxième sens de classe).

          • [^] # Re: vous débutez en JAVA...

            Posté par  . Évalué à 0.

            J'ai peur que ta liste soit fort loin d'etre exhaustive... C tres tres partiel et partial comme choix !

          • [^] # Re: vous débutez en JAVA...

            Posté par  . Évalué à 0.

            Juste pour rappeler que LE C/C++ N'EXISTE PAS !!!
            Ce sont deux langages différents.

            Non mais.

        • [^] # Typage statique vs. typage dynamique

          Posté par  . Évalué à 0.

          Quelques precisions en passant:

          1. plus qu'un type abstrait algebrique, une interface Java est la declaration du type d'une certaine categorie d'objets.

          2. le typage statique n'est *absolument pas* incompatible avec la genericite qui, comme tu le dis, permet de manipuler des objets sans se soucier de leur classe, du moment qu'ils possedent les memes methodes. Cf. la theorie des types abstraits algebriques.

          3. Le type "induit" par une classe est constitue par l'ensemble de ses methodes, mais *pas* par ses attributs (qui constituent, eux, l'etat de l'objet, et non pas son comportement).

          4. Le fait de pouvoir s'auto-inspecter et de pouvoir generer des classes a la volee est peut-etre interessant, amis on ne peut pas dire que ce soit *elegant*. Ce concept -la reflexivite- est tres complexe et pose de serieux risques de plantage (quoique, concernant Java, la encore, il s'agit d'une restriction de la reflexivite). Notons que c'etait deja present dans Lisp il y a deja un bon moment.

          5. Quant a dire que Java est type statiquement, c'est un peu fort. On parle generalement de typage mixte, car une forte phase de compilation dynamique est effectuee (d'ou la lenteur du lancement d'un programme).

          6. Non seulement Java manque de l'heritage multiple, mais il lui faudrait aussi la genericite et la contravariance pour arriver a quelque chose de vraiment puissant. Je conseille a ceux que ca interesse de regarder du cote d'Eiffel (qui peut generer du bytecode Java ou du C) ou de son cousin (plus rigoureux sur certains aspects) Sather.

          Rogue.

          • [^] # Re: Typage statique vs. typage dynamique

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

            Tout à fait d'accord avec l'essentiel de ton post, en particulier avec le 6 (Sather, c'est de la balle). Pour le 5, je serais plus mitigé. Les vérifications effectuées par la JVM permettent d'éviter un bytecode bidouillé. Il y a donc un "double" typage (à la compilation vers le bytecode et lors de la vérification de celui-ci). En théorie cependant, Java est typé relativement statiquement. Je dis relativement car il y a des casts et de la reflection, donc nécessairement du typage dynamique. Mais en dehors de ces opérateurs, on peut typer statiquement un programme (contrairement à Eiffel et à sa covariance, d'ailleurs).

            • [^] # Hors-sujet: livre

              Posté par  . Évalué à 1.

              Ca veut dire quoi, "C'est de la balle"? Cool ou pas cool? Je venais juste de me ramener Sather alors je voudrai savoir si ca vaut le coup :-)

              Y'a t'il un bon bouquin en francais (ou en anglais) qui parle de tous ces concepts ( et accessoirement comment les langages les utilisent) : généricité, variance, reflexivité, ...? J'en apprend tous les jours sur les langages de programmation, mais j'aimerai bien le faire plus vite :-)

              Quant au post original, j'ajouterai qu'il est vrai que Python est un langage très agréable à utiliser, mais la plupart des différences sont des choix qui influencent la rapidité et la sécurité de l'implémantation du langage.

              Ainsi, Java est + rapide et + sur que Python AMHA.
              Par exemple, c'est pratique de pouvoir ajouter un champ dans un objet a tout moment, mais ca implique soit de vérifier à chaque fois les champs qu'il contient quand on l'utilise, soit de faire confiance au programmeur ...

              Enfin, concernant la rapidité de Java, c'est tout le langage qui en profite chaque fois qu'on améliore une VM ou qu'on trouve de nouvelles techniques pour optimiser le bytecode statiquement ( et hop un peu de pub: www.sable.mcgill.ca )

            • [^] # Re: Typage statique vs. typage dynamique

              Posté par  . Évalué à 0.

              Il me semble quand meme que tu omets la raison majeure du typage dynamique en Java, a savoir la liaison tardive. Le typage statique de la liaison dynamique me semble indecidable, en Java en tout cas (OCaml, avec sa differenciation entre classes et types inferes ne se pose pas ce genre de problemes).

              Effectivement, la covariance d'Eiffel implique un typage theoriquement indecidable, et c'est pour ca que j'apprecie Sather qui en retablissant la covariance resoud ce choix (en connaissance de cause, de la part de Meyer) de conception. Evidemment, c'est un peu moins puissant, mais on ne se sert generalement de la covariance que pour les methodes binaires, ce que permet Sather (avec son operateur a la "like Current" qui conserve la decidabilite).

              Pour l'autre post s'interessant aux concepts objets, je conseille personnellement, pour commencer, Object Oriented Software Construction 2eme ed., de Meyer, et le tutorial Sather qui est tres interessant (je suis tres agreablement surpris). Ensuite, je crains qu'il ne faille etudier des textes plus academiques comme les cours de l'X ou de l'ENS, par des gars comme Roberto Di Cosmo, http://www.pps.jussieu.fr/~dicosmo(...) ou Didier Remy, http://cristal.inria.fr/~remy.(...)

              Rogue

              • [^] # Re: Typage statique vs. typage dynamique

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

                <<Il me semble quand meme que tu omets la raison majeure du typage dynamique en Java, a savoir la liaison tardive. Le typage statique de la liaison dynamique me semble indecidable, en Java en tout cas>>

                En effet, et c'est le cas dans beaucoup de langages objets (Sather y compris). Tout dépend ce qu'on entend par typage. Je pense qu'il faut séparer le typage au niveau de l'interface qui doit être aussi statique que possible (d'où l'intérêt de la contravariance par rapport à la covariance) et l'exécution du code, effectivement dynamique.

                • [^] # Re: Typage statique vs. typage dynamique

                  Posté par  . Évalué à 0.

                  Ben, le typage, c'est la detection de sequences dans le programme qui sont susceptibles de provoquer une erreur a l'execution.
                  Java, avec son obligation de de typer dynamiquement la liaison tardive, qui constitue quand meme une des parties les plus importantes (en temps de calcul, disons) de son typage procede donc bien par typage mixte. La partie statique du typage consiste uniquement en de la verification, comme tu le dis, de coherence dans les interfaces.

                  M'enfin, on pinaille, la :-)

                  Rogue

        • [^] # Re: vous débutez en JAVA...

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

          > Mais le pire, c'est bien le côté verbeux : + de lignes, + de temps passé à taper, + de risque d'erreur.

          Si tu en es encore à utiliser 'vi', oui. Avec les IDEs modernes, ça n'est pas un pb. La verbosité d'un langage influe bien moins sur la rapidité de dév. que des choses comme sa simplicité ou la qualité des libs standards. Java est plus verbeux que C++, mais on développe bien plus vite en Java.


          En ce qui concerne la consommation mémoire, il y a pas mal de cas où on s'en fout, par exemple pour les serveurs. C'est pas pour rien que Java marche très bien dans ce domaine. Il suffit d'acheter des machines plus grosses. C'est un cout prévisible, qui diminue avec le temps, alors que le cout de développement avec un autre langage moins gourmand (genre C++) est presque impossible à évaluer (mais il est de toute façon supérieur à celui du hardware), et ne risque pas de diminuer :-).

          • [^] # Re: vous débutez en JAVA...

            Posté par  . Évalué à 0.

            Bof... Avec Perl, il ne te faut pas beaucoup de lignes pour exprimer ta pensée... Si tu maitrises le langage, c tres puissant et ca tient en bien peu de lignes... Aussi, il est bien clair que j'irai plus lentement dans un langage moins adapté et plus verbeux... Maintenant, coté risque d'erreur, je pense que ca change rien

            • [^] # Re: vous débutez en JAVA...

              Posté par  . Évalué à 0.

              Et la maintenance?
              Il faut que quand on repasse sur le code, on soit capable de comprendre aisément la pensée de l'auteur...

              Bref, pour des petits scripts vite torchés, c'est pratique d'Avoir un langage peu verbeux, mais pour faire des choses claires voire transparentes, je n'en suis pas sur ...

      • [^] # Re: vous débutez en JAVA...

        Posté par  . Évalué à 0.

        Un défaut, ne pas posséder d'interfaces multiples ??? "N'importe qui avec une formation minimale en génie logiciel te dira que c'est justement une très bonne chose". (de ne pas les avoir) : c'est un nid à bugs ce truc là. D'ailleurs c'est pourquoi les interfaces existent, pour remplacer de façon avantageuse les interfaces multiples !!!

        Interfaces = types abstraits ??? Tu as été chercher ça où ? Tu veux peut être parler de classes abstraites ? (ce qui n'est pas la même chose car celui qui étend une classe abstraite ne doit pas implémenter toutes ses méthodes)

  • # le nouveau Cobol

    Posté par  . Évalué à 0.

    parait que Java est tellement utilise dans les banques que c'est devenu le nouveau COBOL...

    vivement l'an trois mille qu'on rigole


    je suis identifie, c'est juste que anonyme c'est mon login

  • # oui mais java c très lent

    Posté par  . Évalué à 1.

    je ne connais pas grand chôse en java, mais je n aime pas du tout, dès qu il y a du java sur un site ca prends beaucoup de ressource CPU et memoire => c chiant. perso je n utilise jamais java car ca emmerde tout le monde , moi le premier , j utilise un petit pc et chaque fois qu il y a une tite animation debile en java ca bloque tout. Perso je trouve que pour les animations, le flash, bien que propriétaire , est bien mieux adapté.
    Pouvez vous m expliquer pourquoi java est si lourd ? est ce du micro$oft ou kwa ?

    • [^] # Re: oui mais java c très lent

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

      Cher béotien,

      Nous parlons ici du langage Java. Tu parles d'une application de ce langage : les applets. Je suis d'accord avec toi, c'est débile. Je ne suis pas d'accord avec toi, flash n'est pas mieux.

      Le fait que les applets rament n'a pas grand chose à voir avec le langage lui-même, mais plutôt avec les navigateurs (et aussi avec la programmation des débiles qui font des applets).

      • [^] # Re: oui mais java c très lent

        Posté par  . Évalué à 1.

        et accessoirement,
        la jvm MS est/etait plus rapide que la jvm sun

        Abandonnez Flash, tout le monde a le plugin:
        l'elite utilise SVG

      • [^] # Re: oui mais java c très lent

        Posté par  . Évalué à 0.

        1/ Tout cela est superbement argumenté :

        -- << flash n'est pas mieux >> ...
        Tu préfères Gnome ou KDE ?

        -- << Le fait que les applets rament n'a pas grand chose à voir avec le langage lui-même, mais plutôt avec les navigateurs >> ...
        Dans le même ordre d'idées : une application écrite en Java rame parce que les CPU ne sont encore pas assez puissants ...

        2/ Quelle prétention !

        -- << Cher béotien >>
        -- << la programmation des débiles qui font des applets >>


        Allez boubou, toi qui sait tout, apportes nous la bonne parole.

        P.S. : je suis preneur de references qui appuieraient toutes tes affirmations. Sans rancune mais avec un peu de méfiance à l'égard du "scientifique qui sait tout".

        • [^] # la preuve par neuf

          Posté par  . Évalué à 1.

          <<flash n'est pas mieux>>

          la plupart des interfaces en Flash sont du simple "tapaloeil"
          http://webword.com/flashusability.html(...)
          ( comme 95% des applets (grand classique la baniere qui scrolle et l'image avec les reflets)
          les 5% restants sont la preuve que tu peux faire des bonnes choses avec une applet (ex le truc de simulation de robot passe DEUX fois au moins sur LinuxFR )



          <<les applets rament>>
          en fait les applets rament pas,
          c'est l'invocation du JRE qui rame.
          Par exemple, si le JRE est demarre au debut du navigateur (comme NS le faisait a un moment) alors ca rame que dans la mesure ou faut patienter pour le chargement de l'applet (taille qui depend ENTIEREMENT de la capacite du programmeur. La plupart du temps, cedit programmeur etant FrontPage ou assimile, l'adjectif NEUNEU s'applique tres bien)


          Il dit "je ne connais pas grand chose en Java"
          et mon dictionnaire dit a propos de beotien
          béotien, enne adj. et n.
          1. De la Béotie. || Subst. Habitant, personne originaire de ce pays. Un(e) Béotien(ne). 2. Lourd d'esprit, ignorant (les Béotiens passaient pour tels parmi les anciens Grecs).


          Sinon WindowMaker c'est pas mal par rapport a WindowsPourLinux et Geant

        • [^] # Re: oui mais java c très lent

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

          <<flash n'est pas mieux>>

          raz donne lui-même l'argument : flash est propriétaire.

          <<Dans le même ordre d'idées : une application écrite en Java rame parce que les CPU ne sont encore pas assez puissants ... >>

          Si tu es trop borné pour comprendre que l'implantation de la machine virtuelle est déterminante pour les performances du langage, je ne peux rien pour toi. Va voir http://www.volano.com/report.html(...) par exemple. Il existe aussi des benchs pour les applets, je te laisse chercher, j'ai autre chose à faire que de prouver des trivialités à des incultes.

          << Quelle prétention ! >>

          En effet, je trouve incroyable que quelqu'un vienne nous dire qu'il n'aime pas Java parce que les applets rament. Je trouve ça pathétique et j'y vois une preuve d'une grande inculture. J'ai effectivement la prétention de bien connaître Java, d'où ma réponse.

          • [^] # Re: oui mais java c très lent

            Posté par  . Évalué à 0.

            JAVA est tout aussi proprio que FLASH, sinon plus.
            Comme java, les spécifs du format SWIFF sont disponibles et on peut implémenter un interpréteur ou éditeur sans licence.

            Sun ne donne pas le code source de son JVM, si ?
            Sun peut changer les termes quand il veut, non ?

            • [^] # Re: oui mais java c très lent

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

              <<Sun ne donne pas le code source de son JVM, si ? >>

              Ba si. La licence n'est pas vraiment open source, mais c'est mieux que rien et il y a effectivement une grosse différence entre donner une spec et une implantation.

              <<Sun peut changer les termes quand il veut, non ?>>

              C'est plus compliqué que ça. Il existe des comités et ça discute dur pour déterminer l'avenir du langage. Ce n'est pas aussi ouvert que d'autres choses, mais à mon avis, c'est mieux que flash.

            • [^] # Re: oui mais java c très lent

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

              Petite précision : le code de la JVM est disponible :
              http://www.sun.com/software/communitysource/java2(...)
              Mais ce n'est pas libre :
              Modified source code cannot be distributed without the express written permission of Sun
              Binary programs built using modified Java 2 SDK source code may not be distributed, internally or externally, without meeting the compatibility and royalty requirements described in the License Agreement

              • [^] # Re: oui mais java c très lent

                Posté par  . Évalué à 1.

                c'esta un peu le meme genre license, que la license d'apache ou je me trompe ?

                Depending on the time of day, the French go either way.

                • [^] # Re: oui mais java c très lent

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

                  Je crois que c'est beaucoup plus restrictif. Tu peux toujours distribuer un apache modifié. Dans ce cas, ce n'est plus apache. Alors que pour le jdk, il faut l'approbation de sun, même si tu appelles ta version blurch.

  • # Cooool !

    Posté par  . Évalué à 1.

    Je comprends que beaucoup aient eu des expériences malheureuses avec JAVA ou qu'ils aient été véxé de pas pouvoir en tirer ce qu'on leur avait promis (moi le premier, ouiinn, boubou va me traiter de débile), et qu'ils se font un devoir de mettre en garde ceux qui voudraient s'abandonner sans précautions aux sirènes marketing.

    Mais bon, on ne va pas non plus condamner défnitivement JAVA. Après tout, vive la diversité, c'est ainsi que l'on fini par trouver son bonheur.
    Attention cependant au désirs d'hégémonie et du tout langage X partout !

    • [^] # Re: Cooool !

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

      <<Je comprends que beaucoup aient eu des expériences malheureuses avec JAVA ou qu'ils aient été véxé de pas pouvoir en tirer ce qu'on leur avait promis (moi le premier, ouiinn, boubou va me traiter de débile), et qu'ils se font un devoir de mettre en garde ceux qui voudraient s'abandonner sans précautions aux sirènes marketing. >>

      Moi aussi. Je trouve simplement débile de raconter n'importe quoi sur le langage. Je trouve aussi débile de faire des applets (mais c'est une autre histoire et ça n'a pas vraiment de rapport avec Java lui-même). Enfin, je trouve pathétique de s'intéresser aux anciennes versions du langage. Il me semble malhonnête de critiquer en se basant sur des versions antérieures à 1.2.

      • [^] # Bof.

        Posté par  . Évalué à 1.

        Le hyping a mort de Java n'a pas attendu la version 1.2 pour dire que Java c'est super.

        Moi j'ai succombe a la mode Java apres avoir lu 2 revue sur Byte et Dr Dobbs (A PRIORI des revues serieuse sur le point de vue technique), bin je m'en suis mordu les doigts (ca depend surement de l'application evidemment).

        Quand tu regardait le contenu du BugParade sur le site de Sun, tu comprends mieux l'ampleur du probleme: il y a des bugs pour lesquels plein de gens avaient votes qui sont restes 2/3 ans sans corrections, ca c'est de la reactivite!

        Pour conclure sur une note optimiste le JDK1.3 a l'air (d'apres la BugParade) de contenir moins de bug...

  • # les bons vieux trolls

    Posté par  . Évalué à 0.

    news sur le C => 'C sux, faites du C++'
    news sur le C++ => 'C++ c'est incoherent, java roulaize'
    news sur java => 'java c'est nul, python c mieux'
    news sur python => 'python c'est interpreté, faites du C'

    • [^] # Re: les bons vieux trolls

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

      Tu oublies qu'on peut critiquer un langage sans pour autant déconseiller son utilisation. Il s'agit simplement de faire les choses en connaissance de cause.

  • # C#

    Posté par  . Évalué à 0.

    Ben alors, personne ne parle du nouveau langage de Microsoft, il faut vous reveiller, c'est l'avenir ;-).

Suivre le flux des commentaires

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