Brèves Java

Posté par . Modéré par Benoît Sibaud.
Tags : aucun
0
8
sept.
2004
Java
Voici quelques nouvelles du monde Java, dont beaucoup montrent l'importance qu'y prend l'open source.

Dans le monde des serveurs d'application, Jonas est mis en avant par Red Hat, quand Bea (Weblogic) semble vivre des heures difficiles.
Hors des grands serveurs d'application (Websphere, Weblogic, JBoss, Jonas,...) se sont développées des solutions spécialisées, plus ciblées, qui semblent moins ambitieuses au départ mais qui remplissent une attente.
À tel point qu'un mouvement mené par les développeurs - et relayé par les éditeurs de livres (O'Reilly, Manning) - pousse vers des solutions plus simples, mieux dimensionnées, plus flexibles et à terme souvent plus efficaces. Ces solutions sont d'autant plus vite menées et promues qu'elles sont toutes open source.
D'un côté Sun reconnaît l'apport du dialogue et de l'ouverture, et le besoin de fédérer des forces autour de Java, en engageant celui qui s'occupe du site de blogs jroller.
De l'autre l'open source se professionnalise: création de www.springframework.com pour soutenir le framework Spring et gagner sa vie sur les services - comme JBoss.
Pendant ce temps les discussions sur les EJB 3 font rage, et Google engage une armée de développeurs Java de très haut niveau... * Tiger : première RC de Java 5 (ou Java 1.5). Ce qui devait s'appeler Java 1.5 se nommera peut-être en fin de compte Java 5. (NdM : pour connaître la compatibilité de la plupart des JVM libres avec les différents JDK, voir GNU Classpath vs: JDK 1.0, JDK 1.1, JDK 1.2, JDK 1.3, JDK 1.4)

* RedHat propose depuis la fin du mois de juillet un serveur d'applications basé sur JOnAS. (serveur d'appli le 23/8)
* Sorties de deux versions de deux frameworks phares open source : Struts (version 1.2.2) et Spring (version 1.1).
* Première sortie de NetBeans 4.
* Version alpha de Hibernate 3.

* Rod Johnson, Juergen Hoeller, et Bruce Tate fondent springframework.com.
* Google engage des experts de Java à tour de bras : Josuah Bloch, Neal Gafter (Sun), Adam Bosworth, Cédric Beust (Bea),...
* Livres : sortie de "J2EE Development without EJB", "Better, faster, lighter Java" et de "Hibernate in Action".
* jdocs.com : les documentations des principales bibliothèques Java toutes accessibles.
* TestNG (de Cédric Beust), un framework permettant de tester, et qui utilise la programmation orientée aspect.
  • # Java et l'OpenSource.....

    Posté par . Évalué à 10.

    En effet, nous voyons de plus en plus fleurir des projets libres dynamiques tournant autour de Java.
    Néanmoins, il semble que peu de monde s'intéresse a contribuer aux différentes implémentations libres de Java (gcj, kaffe,.....)
    Je trouve ca dommage. Objectweb, Apache et autres Eclipse connaissent les Avantages de l'OpenSource, puisque c'est une part de leurs argumentaires.
    Pourtant, ces grosses organisations semblent totalement les ignorer en ce qui concerne les Jvm.
    Avec les moyens que ces organisations possèdent, il serait envisageable qu'ils offrent quelques contributions a gcj par exemple. Ecrire les classes qui leurs manquent pour faire tourner leurs softs, et les reverser. Cela permettrait d'obtenir rapidement un gcj bien plus abouti.
    Faudra t'il un coup bas de Sun, ou un rachat de celui ci par MS, pour les faire réagir ?
    • [^] # Re: Java et l'OpenSource.....

      Posté par (page perso) . Évalué à 4.

      Quand bien même classpath serait au niveau, il faudrait payer sa certification. Est-ce ça qui pose problème ? ou peut-être est-ce un problème de personne ?

      Toujours est-il qu'il me semble également que pour un projet libre relativement essentiel, classpath bouge bien peu.

      A tel point qu'aujourd'hui, la façon la plus simple executer du java de façon libre me semble encore être Mono
    • [^] # Re: Java et l'OpenSource.....

      Posté par . Évalué à 8.

      C'est vrai que le développement d'une JVM libre intéresse peu de gens et, je le comprends meme si je ne l'approuve pas :)

      C'est comme si on disait aux utilisateurs de Linux de développer des firmwares libres avant de développer linux.

      Il y a vraiment deux choses bien distinctes :
      - ce qui se passe en dessous de la jvm
      - ce qui se passe au dessus de la jvm
      Et généralement, les gens sont soit d'un coté de la barrière soit de l'autre.
      Donc les gens développent simplement sans se soucier de la JVM qui se retrouve être une abstraction...

      Notons quand même que Redhat est en train de porter JOnAS sous gcj. donc il y a bien des contributions des grands groupes à GCJ même si elles ne se voient pas :)

      http://about.me/straumat

      • [^] # Re: Java et l'OpenSource.....

        Posté par . Évalué à 4.

        Pour RedHat c'est vrai. Ils ont d'ailleurs aussi porté eclipse.
        Malheureusement, tout le monde n'est pas a cheval sur les principes comme l'est RedHat: Ces efforts ne sont pas suivis. RedHat a porté Eclipse sous gcj, mais Eclipse n'en fait toujours pas de builds officiels (je ne sais meme pas s'ils ont intégré les patchs de redhat)
        Esperons que pour Jonas cela aille différement.
        Pour ce qui est de contribuer a gcj, je l'aurais bien fait, mais ayant un jour accepté cette $*#!?&@ de licence de chez sun, je ne peut pas :(
    • [^] # Re: Java et l'OpenSource.....

      Posté par (page perso) . Évalué à 6.

      En effet, nous voyons de plus en plus fleurir des projets libres dynamiques tournant autour de Java.
      Néanmoins, il semble que peu de monde s'intéresse a contribuer aux différentes implémentations libres de Java (gcj, kaffe,.....)
      Je trouve ca dommage. Objectweb, Apache et autres Eclipse connaissent les Avantages de l'OpenSource, puisque c'est une part de leurs argumentaires.

      Je ne voudrais pas marcher dans le troll, mais ... pourquoi faire ?
      Soyons pragmatiques : les consortiums J2EE sont pour la plupart le fait de grosses structures (même ObjectWeb en fait partie). Et ces structures, si elles voient un intérêt à développer telle ou telle couche applicative, le font. Redévelopper une machine virtuelle, ou participer au développement, ne les intéresse pas, car celles existant (IBM, Sun, BEA) sont suffisament performantes pour leurs besoins.
      De plus, dans leur esprit, Java => JVM Sun. J'en veux pour preuve qu'à la SNCF, ils utilisent Weblogic, pourtant fourni avec JRockit (la meilleure JVM pour serveur J2EE), sur une JVM Sun (incompréhensible, mais vrai).


      Avec les moyens que ces organisations possèdent, il serait envisageable qu'ils offrent quelques contributions a gcj par exemple. Ecrire les classes qui leurs manquent pour faire tourner leurs softs, et les reverser. Cela permettrait d'obtenir rapidement un gcj bien plus abouti.


      C'est vrai que ce serait sympa, mais ça n'intéresse personne. par exemple, moi, réécrire les classes du JDK, je suis désolé, mais ça m'emmerde profondément.


      Faudra t'il un coup bas de Sun, ou un rachat de celui ci par MS, pour les faire réagir ?


      Tiens, un peu de paranoïa anti méga-corpo ?
      • [^] # Re: Java et l'OpenSource.....

        Posté par . Évalué à 4.

        > J'en veux pour preuve qu'à la SNCF, ils utilisent Weblogic, pourtant >fourni avec JRockit (la meilleure JVM pour serveur J2EE), sur une JVM >Sun (incompréhensible, mais vrai).
        Je ne suis pas aussi enthousiaste que toi sur Jrockit.
        Jrockit n'existe que sur Intel 32bits et 64Bits. Si Weblogic tourne sous SPARC(Solaris) ça me paraît logique d'utiliser la JVM de Sun. De plus, de part mon expérience en production de serveur Weblogic je n'ai pas trouvé la Jrockit très stable sous Windows (pas mal de bogues). Elle présente un intérêt que sous Linux car la JVM de SUN y est pas très stable et performante. De +, les outils de monitoring de la JVM existant avec Jrockit existent maintenant pour la JVM de Sun (JVMstat) et beaucoup d'autres arrivent pour Tiger (http://java.sun.com/j2se/1.5.0/docs/tooldocs/(...)).
      • [^] # Re: Java et l'OpenSource.....

        Posté par . Évalué à 3.

        Il y a 2 bonnes raisons:

        - Pour faire une distribution avec des applications Java on ne peut pas utiliser la JVM de Sun car Sun interdit ça redistribution.

        - Pour une distribution conne Debian qui tourne sur 11 architectures différentes, ils ont besoin d'une JVM don ils ont le code source pour la compiler sur les différentes architectures (ceci sans parle du contrat social de Debian).
        • [^] # Re: Java et l'OpenSource.....

          Posté par . Évalué à 2.

          car Sun interdit sa redistribution.

          Tu en es sûr ?

          D'après ce que je lis sur http://java.com/en/download/license.jsp(...) , on en a le droit sous certaines conditions (Paragraphe 2 dans SUPPLEMENTAL LICENSE TERMS).
          • [^] # Re: Java et l'OpenSource.....

            Posté par . Évalué à 2.

            En lisant la licence j'ai de la peine à comprendre toutes les conditions de redistributions, mais c'est la seul raison invoquée pour explique le fait qu'il n'y aie aucun paquet Debian contenant le JDK - JRE !
            • [^] # Re: Java et l'OpenSource.....

              Posté par . Évalué à 4.

              [la non redistribution de la jvm sun]est la seul raison invoquée pour explique le fait qu'il n'y aie aucun paquet Debian contenant le JDK - JRE !

              C'est probable mais je n'en suis pas complètement sûr. Il existe, en effet, sur Debian des packages (msttcorefonts par exemple) qui n'incluent pas réellement le logiciel mais le télécharge lors de l'installation. Ce genre de manipulation serait probablement faisable avec le JDK/JRE de Sun. J'ai donc tendance à penser qu'il y a d'autres raisons.
      • [^] # Re: Java et l'OpenSource.....

        Posté par (page perso) . Évalué à 3.

        L'absence de JVM libre pose un problème : les logiciels java ne pourront pas être inclus dans certaines distributions de Linux, et notamment Debian et Mandrake (ou alors dans les non-free ou dans la catégorie appli commercial).
        C'est une des raisons qui m'a fait abandonner Java (Je faisais des jeux, donc la disponibilité de paquet pour l'utlisateur final était assez importante).
        • [^] # Re: Java et l'OpenSource.....

          Posté par . Évalué à 1.

          Je vois pas le pb ???
          Il est parfaitement possible et légal de distribuer une JRE avec ses softs.
          • [^] # Re: Java et l'OpenSource.....

            Posté par (page perso) . Évalué à 1.

            Légal, oui... mais la politique de certaines distributions (Debian, Mandrake) est de n'inclure QUE du logiciel libre. Donc du coup ton programme en sera exclu.
      • [^] # Re: Java et l'OpenSource.....

        Posté par . Évalué à 3.

        >>Faudra t'il un coup bas de Sun, ou un rachat de celui ci par MS, pour les faire réagir ?

        >Tiens, un peu de paranoïa anti méga-corpo ?

        Peut tu nous garantir que cela n'arrivera pas ?
        En tout cas, si ca arrive, les "grosses structures" en question elles seront les premieres a raler parce que les Jvm libres sont pas assez avancées (et ce jour la tout bougera vite.
        Enfin, je rapelle qu'une grosse structure qui veut un java libre, il y en à, et elle s'apelle IBM. Pourtant je n'ai pas l'impression qu'Ibm contribue beaucoup a gcj/classpath
    • [^] # Re: Java et l'OpenSource.....

      Posté par . Évalué à 1.

      Est-il utopique d'envisager que ces organisations espèrent que Sun finira par livrer sa JVM en open source ? (quelles qu'en soient les raisons)
      • [^] # Quelques questions

        Posté par (page perso) . Évalué à 2.

        Pour ce qui est de contribuer a gcj, je l'aurais bien fait, mais ayant un jour accepté cette $*#!?&@ de licence de chez sun, je ne peut pas :(

        Ce serait sympa d'expliquer ça en détail.

        Sans lancer de Troll, Mono est parait-il capable d'executer du java. Quelqu'un a-t-il essayé ?

        Dernier petit détai (trollesque ?) tien, tien...le prochain java va s'appeler Tiger comme le prochain OS de chez apple ...
        • [^] # Re: Quelques questions

          Posté par . Évalué à 5.

          >>Pour ce qui est de contribuer a gcj, je l'aurais bien fait, mais ayant un jour
          >>accepté cette $*#!?&@ de licence de chez sun, je ne peut pas :(

          >Ce serait sympa d'expliquer ça en détail.

          Ma foi, c'est simple. Quand tu télécharge les sources du j2sdk de Sun, tu a acces a des sources copyrightées de sun, sous une licence (SCSL) qui est tout sauf libre ni OpenSource.
          Afin de limiter les risques légaux (genre l'affaire Sco) et sachant que Sun, ce ne sont pas des gens très gentils, les responsables de gcj/classpath ne permettent pas aux personnes ayant eu accès a ces sources de contribuer à leurs projets.
        • [^] # Re: Quelques questions

          Posté par . Évalué à 1.

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

          Pour Mono, ça se passe avec iKvm.
        • [^] # Re: Quelques questions

          Posté par (page perso) . Évalué à 2.

          Sans lancer de Troll, Mono est parait-il capable d'executer du java. Quelqu'un a-t-il essayé ?
          Oué j'ai essayé.
          Ils ont tout simplement fait une machine virtuelle Java au dessus de Mono (IKVM comme indiqué dans le post précédent)
          2 intérêts :
          utiliser le langage Java avec les outils habituels mais avec les API de Mono par exemple.
          lancer une application Java, les API ClassPath sont alors utilisés.
          On peut bien entendu mixer le tout, et on peut alors utiliser ClassPath et les API Mono en même temps :)
          • [^] # Re: Quelques questions

            Posté par (page perso) . Évalué à 0.

            On peut bien entendu mixer le tout, et on peut alors utiliser ClassPath et les API Mono en même temps :)

            Et écrire du code qJava qui ne marche qu'avec Mono ? Génial !
            A moins de rétroporter les APIs Mono en java, auquel cas ça pourrait être à peine plus générique ...
            • [^] # Re: Quelques questions

              Posté par (page perso) . Évalué à 3.

              Ben dans ce cas précis Mono est un API comme un autre, et utilise des API également bindés dans de nombreux autre langages, c'est juste un choix. Par contre dire que c'est limité à Mono n'est pas tout à fait exact, c'est limité aux plateformes spécifiés par l'ECMA, ce qui inclu .NET ;)
              Donc ce n'est pas se limiter, c'est utiliser une autre plateforme.
              coder en Java sur Mono, c'est avoir le choix entre les classpath ou l'ensemble des possibilité de Mono et de l'interopérabilité qui en découle avec d'autres langage de la plateforme. C'est une question de choix, je ne vois pas l'intérêt de tout backporté sur la machine officielle de Java.
  • # Hibernate

    Posté par . Évalué à 2.

    C'est vrai que je suis en train de remplacer des ejb entités grâce à hibernate et j'apprécie... mais je garde toujours les ejbs de sessions et mdb.. je les aime bien :)

    http://about.me/straumat

    • [^] # Re: Hibernate

      Posté par . Évalué à 2.

      Et qu'est-ce qui te fait encore bien aimer ces ejb? Qu'est-ce qu'ils t'apportent que tu ne pourrais pas avoir aileurs?
      Mis à part qu'ils tournent sur Jonas bien sûr ;-)
      • [^] # Re: Hibernate

        Posté par . Évalué à 1.

        EJB MDB -> traitement asynchrone :)
        EJB stateless -> pooling, transaction, exportable service web

        et c simple ( avec Xdoclet ), je pense que c'est le meilleur endroit pour y placer la logique métier !

        http://about.me/straumat

  • # Et encore, on est loin du compte ...

    Posté par (page perso) . Évalué à 5.

    Allez, encore quelques autres nouveautés, et des petites informations complémentaires


    Dans le monde des serveurs d'application, Jonas est mis en avant par Red Hat, quand Bea (Weblogic) semble vivre des heures difficiles.

    BEA a quand même sorti une très belle nouveauté cette année : Weblogic Workshop, associé au framework Beehive (surcouche de Struts) tous deux très convaincants, comme je l'écris ici http://nicolas.delsaux.free.fr/web/Java/formation.php(...) et qui plus est Open-Source livré à la fondation Apache (qui n'en est plus à un framework web de plus) !


    Hors des grands serveurs d'application (Websphere, Weblogic, JBoss, Jonas,...) se sont développées des solutions spécialisées, plus ciblées, qui semblent moins ambitieuses au départ mais qui remplissent une attente.


    Tu penses à Spring, manifestement. N'oublions pas Tapestry, WebWork et autres qui montrent une seule chose : il n'existe pas actuellement de solution web réellement convaincante.


    À tel point qu'un mouvement mené par les développeurs - et relayé par les éditeurs de livres (O'Reilly, Manning) - pousse vers des solutions plus simples, mieux dimensionnées, plus flexibles et à terme souvent plus efficaces. Ces solutions sont d'autant plus vite menées et promues qu'elles sont toutes open source.

    Tu pourrais être plus explicite ? Pour ma part, sur le front du concept, ces derniers mois ont amené l'émergence d'une vraie révolution sémantique, l'IoC, d'un vrai buzzword (l'architecture orientée service ou SOA).


    D'un côté Sun reconnaît l'apport du dialogue et de l'ouverture, et le besoin de fédérer des forces autour de Java, en engageant celui qui s'occupe du site de blogs jroller.


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


    Pendant ce temps les discussions sur les EJB 3 font rage,

    Ah ça, les EJB, c'est toujours pas gagné, surtout quand on voit qu'il faut environ un mois pour écrire un mapper O/R. La dernière fois que j'ai discuté avec des gens qui avaient écrit des EJB, je leur ai demandé ce que ça leur apportait. Difficile d'avoir une réponse claire sur le sujet, sauf de la part d'une personne bossant pour BEA ... Mais ça peut être une réponse orientée.

    et Google engage une armée de développeurs Java de très haut niveau...


    Et tout le monde se demande pourquoi : porter Google en Java ? Réécrire des interfaces web en J2EE qui sent, ou sortir son propre conteneur ?
    • [^] # Re: Et encore, on est loin du compte ...

      Posté par . Évalué à 2.

      Je suis pas sur que ce soit Java qui interesse Google.
      Plutot des gens qui ont reflechi sur les agents ou les problemes de parallelisation massive.
    • [^] # Re: Et encore, on est loin du compte ...

      Posté par . Évalué à 2.

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

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

      Posté par . Évalué à 3.

      des solutions plus simples, mieux dimensionnées, plus flexibles et à terme souvent plus efficaces. Ces solutions sont d'autant plus vite menées et promues qu'elles sont toutes open source.

      Tu pourrais être plus explicite ? Pour ma part, sur le front du concept, ces derniers mois ont amené l'émergence d'une vraie révolution sémantique, l'IoC, d'un vrai buzzword (l'architecture orientée service ou SOA).


      J'ai l'impression qu'on reprend les mêmes problèmes mais au lieu de construire une grande solution toute faite et qui se voudrait tout terrain (à la EJB), on reprend avec les bases du langage (POJO) et on construit de petites solutions ciblées : jdo/Hibernate pour la persistence, Struts/webwork/tapestry pour les vues... et un framework d'application (pico Container, Spring) pour relier le tout.

      ça amène d'un part à des solutions plus simples à construire et à appréhender. Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.

      Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
      Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.

      Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.

      Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.

      Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.

      Donc, oui, je pensais aussi à l' IoC :-)

      Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.
      • [^] # Re: Hasta la revolucion..

        Posté par . Évalué à 1.

        Juste par curiosité : ça veut dire quoi "Inversion of Control" ?
        • [^] # Re: Hasta la revolucion..

          Posté par . Évalué à 9.

          Suppose que tu as un objet qui veut sauvegarder des données en base de données.
          Naturellement tu fera

          ObjetQuiPermetAccesBaseDeDonnees o= new ObjetQuiPermetAccesBaseDeDonnees()

          o.save (mesDonnees)

          C'est ton objet qui appelle ObjetQuiPermetAccesBaseDeDonnees

          Bref, tu as codé en dur le nom de l'objet qui te permet de faire de la persistence.

          Tu pourrais mettre une interface (mais bien sûr tu mets déjà une interface), mais quand même quand tu vas instancier ton objet, il faudra bien dire quelle est la classe utilisée.

          InterfacePersistance o= new ObjetQuiPermetAccesBaseDeDonnees()

          Le principe de l'inversion de contrôle (aussi appelé drôlement "syndrôme d'Holywood") est:" Don't call me I call you"
          Objet, ne demande pas une instance de ObjetQuiPermetAccesBaseDeDonnees. C'est un moyen extérieur qui va te passer la référence à cet objet- en l'occurence un framework.
          Ce framework va lire un fichier xml de config où il y aura écrit : "Voici l'objet que je vais utiliser pour sauvegarder mes données : c'est ObjetQuiPermetAccesBaseDeDonnees"

          Autrement dit, tu as défini ce qui relie chacune entre elles chacune des couche qui font ton appli.
          Avantage : c'est défini en un seul endroit. Tu veux changer ton appel à une base de données par une gestion via un file système : tu changes la config. Ou tu veux tester ton objet - et pas l'accès à la base de données : au lieu d'utiliser l'objet qui fait l'accès à la base (et qui ets peut-être buggé) tu crées un faux objet (Mock) qui va mimer le comportement attendu - mais que tu veux pas tester.

          Avantage aussi : un seul lieu pour centraliser le cycle de vie des objets. En général, un accès en base c'est un singleton. Là, c'est ton framework qui va être responsable de la vie de l'objet , donc de son unicité.
          de même tu peux du coup très facilement, par config, quand tu crées un objet, dire d'executer telle méthode (log, sécurité) et ainsi tu implémentes en un seul endroit un comportement général (aop)

          http://martinfowler.com/articles/injection.html(...)
          http://www.dotnetguru.org/articles/dossiers/ioc/ioc.htm(...)
      • [^] # Re: Hasta la revolucion..

        Posté par (page perso) . Évalué à 2.

        J'ai l'impression qu'on reprend les mêmes problèmes mais au lieu de construire une grande solution toute faite et qui se voudrait tout terrain (à la EJB), on reprend avec les bases du langage (POJO) et on construit de petites solutions ciblées : jdo/Hibernate pour la persistence, Struts/webwork/tapestry pour les vues... et un framework d'application (pico Container, Spring) pour relier le tout.

        Tant mieux, parce que moi, la solution J2EE/EJB ne m'a pas du tout séduit : à chaque fois que j'ai eu des EJBs sous les yeux, j'ai trouvé que c'était nettement trop complexe pour le besoin exprimé. En fait, c'est bien simple, je n'ai jamais vu de cas où ça se justifiait.

        ça amène d'un part à des solutions plus simples à construire et à appréhender.

        Ca n'est pas non plus systématique. Une solution super-classe à base d'IoC pourra être particulièrement complexe à comprendre, pour le débutant, meêm si elle présentera bien plus d'élégance.

        Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.

        Et c'est justement ça qui est pour nous évident, alors que pour d'autres il est incompréhensible de faire la séparation. Il y a encore un rude travail d'éducation à faire.

        Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
        Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.


        Mais pourquoi utiliser un framework pour faire ça ? C'est la grosse question que je me pose à propos de l'IoC. Effectivement, c'est très bien dans le concept, mais je ne vois pas pourquoi je vais passer par l'un ou l'autre pour recâbler mon appli.

        Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.

        Je demande quand même à voir. Tout programme cache dans ses entrailles une bonne dose de dépendances non inversées (ou complexité cyclomatique, tant qu'on y est à utiliser des termes de barbares), et les enlever ne mérite parfois pas l'effort qu'on y fournit.

        Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.

        Oui, enfin, la doctrine KISS, ça fait un bout de temps que ça devrait être le livre de chevet des développeurs Java, même si en réalité ça n'est pas le cas, et de loin.

        Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.

        Pas pour les DBAs ;-)
        Là où un programme d'avant gérait lui-même sa charge par une espèce d'effet domino rigolo, le programme moderne risque fort de beaucoup plus charger (notamment dans le cas d'un mapping O/R), et de faire s'affoler inutilement le DBA (je l'ai vu encore tout récement). Et le problème, dans ce cas-là, c'est quon considère encore la base comme plus importante que le logiciel (un blasphème, à mon sens, mais bon ...).

        Donc, oui, je pensais aussi à l' IoC :-)

        Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.

        En fait, le SOA, j'ai bien l'impression que ça permet de vendre plus de webservice, alors même que mon esprit orienté performance me sussure que les webservices sont au service d'une contreperformance évidente. mais bon, ça fait plaisir aux dicaïdors pressés ...
        • [^] # Re: Hasta la revolucion..

          Posté par . Évalué à 1.

          Perso, j'aime bien les ejb de sessions avec XDoclet, je trouve que c un bon endroit pour centraliser/tester la logique métier et la rendre accesible aux applis web, lourde, webservices....

          et j'ai déja eu de très dur débats avec des DBA pour leur dire que quand je développais, je m'en fouttais un peu de la db :)

          http://about.me/straumat

          • [^] # Re: Hasta la revolucion..

            Posté par (page perso) . Évalué à 1.

            Perso, j'aime bien les ejb de sessions avec XDoclet, je trouve que c un bon endroit pour centraliser/tester la logique métier et la rendre accesible aux applis web, lourde, webservices....

            Excuse-moi de te dire ça froidement comme ça, mais ... tu rigoles, là ?

            Parce que moi, ma logique métier, je la mets dans des POJOs, et mes EJBs (je dis mes, mais c'est uniquement didactique) ne servent qu'à la faire s'interfacer avec un monde d'entreprise. En disant ça, est-ce que je passe pour un demi-extra-terrestre, ou est-ce que je peux éventuellement être dans le vrai ?


            et j'ai déja eu de très dur débats avec des DBA pour leur dire que quand je développais, je m'en fouttais un peu de la db :)


            Tiens, c'est marrant, moi aussi. Et générallement, ces DBAs te disent que la charge de leur base est hyper-importante, avant même que quiconque ait fait le moindre test de charge de l'application sur la base, bref, ils te demandent à toi d'optimiser, parce que eux, ça les fatigue ;-)
            • [^] # Re: Hasta la revolucion..

              Posté par . Évalué à 1.

              Parce que moi, ma logique métier, je la mets dans des POJOs, et mes EJBs (je dis mes, mais c'est uniquement didactique) ne servent qu'à la faire s'interfacer avec un monde d'entreprise.

              C'est pareil que moi.. n'empeche que la logique métier est partagée au monde via les ejbs. c'est poru cela que j'utilise les ejbs :)

              Pour les DBA, ils me disent qu'on peut pas faire abstration de la base de données ! tout à fait impossible et que de toute façon, ca dégraderait les performances

              http://about.me/straumat

              • [^] # De la psychologie du DBA was Re: Hasta la revolucion..

                Posté par (page perso) . Évalué à 1.

                Pour les DBA, ils me disent qu'on peut pas faire abstration de la base de données ! tout à fait impossible et que de toute façon, ca dégraderait les performances

                Il faut les comprendre : leur dire ça revient à leur dénier leur rôle de chef d'orchestre du système d'information, pour en faire de simples administrateurs d'archives. D'un coup, c'est moins classieux. D'un autre côté, c'est exactement leur boulot : une donnée dans une base est à peu près aussi utile qu'un classeur au fond des archives.
  • # C'est pas Neat-Bean...

    Posté par (page perso) . Évalué à 3.

    C'est NetBeans 4.0
    http://www.netbeans.org(...)
  • # Java trap

    Posté par . Évalué à 2.

    Super mais ça ne change rien au problème de base :
    http://www.gnu.org/philosophy/java-trap.fr.html(...)

    projets libres basés sur Java ne tournant que sur JVM de Sun, pas vraiment libre en somme...
    • [^] # Re: Java trap

      Posté par . Évalué à 3.

      et un système d'exploitation sur des composants et firmwares non libres ? c libre ?

      http://about.me/straumat

    • [^] # Re: Java trap

      Posté par . Évalué à 0.

      J'ajouterais aussi que stallman n'a pas écrit la définition universelle et éternelle de la liberté :)

      http://about.me/straumat

    • [^] # Re: Java trap

      Posté par (page perso) . Évalué à 3.

      C'est un tissu d'âneries ou quoi ?
      Est-ce que tu utilises actuellement un ordinateur libre ?
      Parce que bon, c'est bien gentil de développer avec une plateforme libre, mais ton OS, lui, il l'est ? (sans doute) Et ton processeur, est-il libre ? Le disque dur, la RAM, le câble réseau, les switches qui t'amènent jusqu'à LinuxFR, sont-ils complètement ouverts ?
      Qui qu'on soit, il est toujours bon de se renseigner un minimum avant de causer, quand bien même on s'appelle Stallman.
      Le processus définissant l'évolution du langage Java est libre, et organisé par le JCP. Ce qui n'est pas libre, ce sont les implémentations de machine virtuelle, dont celle de Sun. Maintenant, il me semble que cet appel à bosser sur CLASSPATH te vise autant que moi. Alors, si tu arrêtais de te plaindre pour l'aider ?

      Maintenant, vous pouvez toujours me moinsser, si ça vous amuse d'assurer l'orthodoxie de LinuxFR ...
      • [^] # Re: Java trap

        Posté par (page perso) . Évalué à 3.

        > Qui qu'on soit, il est toujours bon de se renseigner un minimum avant de causer, quand bien même on s'appelle Stallman.

        En même temps quand on s'appelle Nicolas Delsaux aussi on peut se renseigner... (et je ne prétends pas avoir la vérité absolue, mais bon quand on commence par « C'est un tissu d'âneries ou quoi ? » pour ensuite critiquer sans argument quelqu'un qui a déjà fait énormément de choses (qu'on l'on aime ou pas)...)

        Les différences entre le matériel et le logiciel sont telles que les problématiques y sont complètement différentes (enfin jusqu'à ce que quelqu'un ait fabriqué une machine à multiplier les cartes mères ou les disques durs à coût nul).

        Et même dans l'immatériel, les problématiques entre ce qui a une fonction utilitaire ou pas sont différentes. C'est d'ailleurs le coeur de la divergence d'opinion entre Debian et la FSF sur ce qu'est une documentation libre.
        • [^] # Re: Java trap

          Posté par . Évalué à 1.

          et les firmwares ? comment est ce considéré ?

          http://about.me/straumat

          • [^] # Re: Java trap

            Posté par (page perso) . Évalué à 3.

            Suffit de demander à Google.

            L'avis de la FSF :
            http://www.gnu.org/philosophy/linux-gnu-freedom.fr.html(...)
            « Pour la même raison, ajouter de tels binaires aux sources Linux viole la GPL.

            Les développeurs de Linux ont prévu de placer ces programmes de firmware dans des fichiers séparés; cela prendra des années avant d'y arriver, mais quand ce sera accompli, cela résoudra le deuxième problème; nous pourrions faire une version «Linux libre» qui ne contiendrait pas les fichiers de firmware non-libres. Ce ne sera pas très bénéfique en soi si la plupart des gens utilise la version «officielle» non-libre de Linux. Cela pourrait très bien arriver, car la version libre ne fonctionne pas sur bien des plateformes sans les programmes firmware non-libres. Le Projet «Linux libre» devra découvrir ce que font les programmes firmware et écrire le code source, peut-être en langage assembleur, sur un quelconque processeur intégré sur lequel il est exécuté. C'est un travail décourageant. Cela aurait été moins décourageant si nous l'avions fait petit à petit, au fil des années, plutôt que de le laisser s'accumuler. En recrutant des gens pour faire ce travail, nous devrons surmonter l'idée, répandue par quelques développeurs de Linux, que ce travail n'est pas nécessaire. »
            • [^] # Re: Java trap

              Posté par . Évalué à 1.

              Donc, si j'ai compris... Oui, Linux a des problèmes sur ce point la mais ca nous empeche pas de développer Linux pour autant...

              J'ai bon ou pas ?

              http://about.me/straumat

              • [^] # Re: Java trap

                Posté par (page perso) . Évalué à 2.

                D'abord ce n'est pas la FSF qui développe le noyau Linux. Ensuite la FSF dit qu'il faut d'une part isoler les firmware pour pouvoir avoir des versions du noyau sans (des vraiment « libres »), et d'autre part que ce n'est pas suffisant (matériel non supporté, architectures non supportées, etc.). Bref comme pour les autres logiciels : soit on se contente de la technique et on se fiche qu'ils soient libres, du moment que ça tourne chez soi sur son matos à un moment donné dans un environnement donné ; soit on est concerné par la liberté, et il faut trouver une solution (ne pas l'utiliser, trouver/écrire un remplacement libre, etc.)
              • [^] # Re: Java trap

                Posté par . Évalué à 4.

                Stallman dit au sujet de Java: choisir Java pour un nouveau projet est une mauvaise idée, car il n'y a pas de bonne machine virtuelle Java libre, et le projet GNU essaye de développer Classpath.

                Stallman dit au sujet de Linux qu'il est en partie non libre, et le projet GNU essaye de développer The Hurd.

                Je ne vois pas d'incohérence entre les deux cas.

                Évidemment, on peut faire remarquer que la plupart des BIOS ne sont pas libres, que le matériel lui même n'est pas libre, et utiliser cela pour "prouver" que l'on peut utiliser des logiciels propriétaires. C'est un peu bizarre d'utiliser l'imperfection du libre pour proposer encore plus d'imperfection, mais bon pourquoi pas.

                La différence entre les deux cas, cependant, est qu'il est très difficile de se passer des BIOS propriétaires, et impossible de se passer de matériel propriétaire (à ce jour), alors qu'il est très facile de se passer de Java pour développer un nouveau projet. D'où la validité de la recommandation de Stallman. Après, on peut être d'accord avec lui ou pas, mais sa recommandation est cohérente.
            • [^] # Re: Java trap

              Posté par . Évalué à -1.

              > Suffit de demander à Google.

              ... qui n'est pas libre non plus. Redescendez de votre nuage :)
        • [^] # Re: Java trap

          Posté par (page perso) . Évalué à 2.

          En même temps quand on s'appelle Nicolas Delsaux aussi on peut se renseigner... (et je ne prétends pas avoir la vérité absolue, mais bon quand on commence par « C'est un tissu d'âneries ou quoi ? » pour ensuite critiquer sans argument quelqu'un qui a déjà fait énormément de choses (qu'on l'on aime ou pas)...)
          L'un des avantages de l'industrie informatique, c'est son pragmatisme. Si Bill Gates fait une connerie, n'importe qui ici lui dira (s'il le peut). De la même manière, le fait que Stallman ait écrit un tas de choses pour le libre ne signifie pas qu'il aura raison à tous les coups. Et en l'occurence, ce document est un tissu d'inepties. Par exemple, quand il dit

          i vous développez un programme Java sur la plate-forme Java de Sun, vous êtes voués à utiliser de fonctionnalités Sun exclusives sans même vous en rendre compte.

          Il se gourre grave. Toutes les classes fournies dans la JVM de Sun, comme dans les autres, sont définies et évoluent grâce au JCP (ou Java Community Process) sur lequel je vous laisse vous documenter librement, mais qui est nettement ouvert dans son processus d'évolution. Il garantit par ailleurs que les fonctionnalités d'une JVM qui y sont définies (en clair, tout les packages java.* ou javax.*) sont standardisés dans leur interface et dans leur implémentation.
          Alors, évidement, je ne sais pas si le JCP respecte complètement la Philosophie du Libre comme il l'entend. Mais pour moi, je sais que je peux influencer les JSR en cours, et donc faire évoluer Java dans ma direction. Et ça me suffit largement.

          De la même manière, l'argument selon lequel il fallait "sauver" (sous-entendu pour le libre) le C, parce que c'était le seul langage existant, et le shell, parce que bon, sinon, compiler, c'est pas gagné, mais que Java ne mérite pas ce sauvetage parce que l'arche du libre n'est pas assez grande tient vachement la route, mais alors avec une classe folle.

          Et puis, terminer par une exhortation à aller vérifier sur le site de la FSF que le programme utilisé est bien libre, ça fait plus concours de hits à l'ancienne qu'autre chose. Surtout quand on compte le nombre de programmes Java majeurs Open Source (au choix Eclipse, Tomcat, Ant, JBoss, NetBeans, Struts (enfin, ça, c'est pas un bon exemple), Beehive, ...).

          Bref, pour moi, ça sonne beaucoup plus comme une espèce de message du vieux développeur C bien content d'être libre etr qui nous emmerde tous que comme autre chose.

          Les différences entre le matériel et le logiciel sont telles que les problématiques y sont complètement différentes (enfin jusqu'à ce que quelqu'un ait fabriqué une machine à multiplier les cartes mères ou les disques durs à coût nul).

          Ca, c'est étayé, comme argument. Il y a des tonnes de différences, et alors ? La JVM est, quelquesoit son constructeur, censée être un processeur virtuel fonctionnant à la base comme interpréteur de bytecode en code machine pour 'larchitecture cible.
          Dans un monde idéal, (que Sun n'a JAMAIS appelé de ses voeux), la JVM serait un coprocesseur (ça existe, les processeurs Java, mais ça marche moyen), et serait donc du matériel. Que dirait alors Stallman ? Faites plutôt vos opérations sur les coprocesseurs vidéo, au firmware nettement plus libre ?
          • [^] # Re: Java trap

            Posté par (page perso) . Évalué à 2.

            > vous développez un programme Java sur la plate-forme Java de Sun, vous êtes voués à utiliser de fonctionnalités Sun exclusives sans même vous en rendre compte

            Si tu utilises Swing dans un logiciel libre en Java, il y a de fortes chances qu'il ne soit pas utilisable dans le « Monde Libre » défini dans le texte. Cette fonctionnalité est disponible dans la plate-forme Java de Sun mais pas dans Classpath.

            Il aurait aussi pu parler de la plate-forme Java d'IBM. Bref ce n'est pas l'architecture Java qui est concernée mais les implémentations propriétaires.

            Exemple en C++ :
            « Dinkumware
            http://www.dinkumware.com/manuals/reader.aspx?b=p/&h=map.html#m(...)
            iterator erase(iterator where);
            iterator erase(iterator first, iterator last);
            size_type erase(const Key& keyval);

            GCC STL v3
            http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-3.3/cl(...)
            void erase (iterator __position)
            size_type erase (const key_type &__x)
            void erase (iterator __first, iterator __last)

            SGI STL
            http://www.sgi.com/tech/stl/Map.html(...)
            void erase(iterator pos)
            size_type erase(const key_type& k)
            void erase(iterator first, iterator last) »

            Si tu as codé ton logiciel libre en C++ avec la bibliothèque STL de Dinkum et que tu as utilisé la valeur de retour de la fonction membre erase(), ton code utilise des fonctionnalités spécifiques à Dinkum (et absentes de la norme).

            >
            Dans un monde idéal, (que Sun n'a JAMAIS appelé de ses voeux), la JVM serait un coprocesseur (ça existe, les processeurs Java, mais ça marche moyen), et serait donc du matériel. Que dirait alors Stallman ?

            La même chose (je présume) que pour les instructions MMX, 3DNow et Cie propres à certains processeurs. On pourrait avoir du logiciel libre sans dépendre de logiciels propriétaires. Par contre il faudrait forcément avoir un processeur de cette famille pour utiliser le logiciel. Le mieux serait bien sûr que d'autres fondeurs puissent cabler ces instructions.
            • [^] # Re: Java trap

              Posté par (page perso) . Évalué à 2.

              Si tu utilises Swing dans un logiciel libre en Java, il y a de fortes chances qu'il ne soit pas utilisable dans le « Monde Libre » défini dans le texte. Cette fonctionnalité est disponible dans la plate-forme Java de Sun mais pas dans Classpath.
              Sans doute parce que CLASSPATH n'est pas au niveau des autres JVM (je me demande même s'il s'agit d'une JVM validée). Les autres JVM doivent fournir Swing, qui fait partie des API de Java.

              Il aurait aussi pu parler de la plate-forme Java d'IBM. Bref ce n'est pas l'architecture Java qui est concernée mais les implémentations propriétaires.

              Je ne le comprend pas comme ça. Les classes java.* et javax.* sont disponibles dans toutes les JVM (ça, c'est le "contrat moral" que passent ceux qui fournissent des JVM). En revanche, lorsqu'on accède à une classe sun.tools.javac.Main (par exemple) on sait qu'on n'en disposera que dans la JVM de Sun (et encore, seulement en installant le JDK). Il me semble que Stallman mentionne plutôt le second cas (utiliser une classe non-standard en pensant qu'elle l'est) quel le premier (utiliser une classe standard, et tomber sur une "implémentation" ne respectant pas le standard).
              Et dans ce cas, il se gourre violement. Le code que j'écris n'utilise pas autre chose que du java.* (enfin, presque, il y a un peu de org.apache.*, mais ça, c'est quasi-obligé), et peut donc s'exécuter indifférement sur une JVM Sun, IBM, BEA ou CLASSPATH, pour peu qu'icelle supporte réellement les bibliothèques java.*
            • [^] # Re: Java trap

              Posté par (page perso) . Évalué à 6.

              > Si tu utilises Swing dans un logiciel libre en Java, il y a de fortes
              > chances qu'il ne soit pas utilisable dans le « Monde Libre » défini
              > dans le texte. Cette fonctionnalité est disponible dans la plate-forme
              > Java de Sun mais pas dans Classpath.

              et ben non, Swing en libre ca existe !
              http://forum.hardware.fr/forum2.php?config=hardwarefr.inc&post=(...)

              De facon generale je rappelle que Java n'est pas moins libre que C++, C, C# ou meme UNIX.
              Java c'est des specifications et un ensemble d'API, libre ensuite a chacun de programmer une implementation. Linus Torvalds a cree Linux il l'a voulu compatible avec UNIX, tout comme GCC implemente C++ et le C. Bref s'il n'y a pas d'implementation libre de Java c'est pas de la faute de Sun mais c'est de la faute des developpeurs de logiciels libres. Apres il est vrai que si Sun pouvait mettre Java sous LGPL ca serait "sympa".
      • [^] # Re: Java trap

        Posté par . Évalué à 2.

        Oui le langage Java est libre, mais si il n'y à pas d'implémentation libre qui permette de compiler et exécuter du code Java ton programme en java c'est fais piégé... (c'est d'ailleurs le cas pour mes programmes en Java sniff).
  • # Logiciel libre et java

    Posté par (page perso) . Évalué à 5.

    Concretement, lorsqu'on veut faire du code Java 100% libre et qui fonctionne avec des trucs libres, comment fait-on? On compile avec gcj ? La machine virtuelle, c'est classpath? Il faut autre chose? Pour ce qui est de javadoc (qui genère la doc d'un code commenté en html), il y a un equivalent libre?

    Pour ceux qui utilisent tout ça, ça a l'air pas mal avec les stats donnés plus haut... ça marche vraiment bien en pratique?

    Merci d'avance :)
    • [^] # Re: Logiciel libre et java

      Posté par . Évalué à -1.

      et l'executer sur une pascaline qui a l'époque n'utilisait pas encore de firmwares propietaire

      voyons, faut quand meme rester raisonnable, le libre, c'est formidable certes, mais tomber dans l'extremisme n'apporte jamais de bon.

      renoncer a tous les avantages de java parceque le JVM de sun n'est pas libre, tres peu pour moi, je prefere encore des initiatives comme celle d'IBM visant a faire ouvrir java plutot de de recoder une JVM qui sera toujours en retard (classpath n'est pas encore 100% compatabile avec le JDK 1.1)
      • [^] # Re: Logiciel libre et java

        Posté par . Évalué à -2.

        d'accord avec toi

        http://about.me/straumat

      • [^] # Re: Logiciel libre et java

        Posté par . Évalué à 5.

        «renoncer a tous les avantages de java parceque le JVM de sun n'est pas libre»

        D'un autre côté, si tout le monde s'était dit ça au sujet, au hasard, de Photoshop, on n'aurait jamais eu GIMP.

        J'ajouterais qu'on a de très bons langages et de très bonnes plateformes qui n'ont rien à envier à Java, en libre, et que beaucoup de gens choisissent Java parce que c'est connu, pas parce que c'est un bon produit.

        (J'ai fait du Java, beaucoup... depuis j'ai découvert des langages qui font que je n'ai aucune envie d'y retourner... Qui a dit Ruby ? :-)
        • [^] # Re: Logiciel libre et java

          Posté par . Évalué à 4.

          Le langage n'est pas que la chose importante, l'environnement, le soutien, les normes ( J2EE ), les projets libres ( Velocity, ant, JUnit, JOnAS, TOmcat... ) tout ça joue..

          Ruby, je ne le connais pas mais je sais que je peux tout faire en java et que vive les drivers jdbc :)

          http://about.me/straumat

          • [^] # Re: Logiciel libre et java

            Posté par . Évalué à 1.

            «mais je sais que je peux tout faire en java»

            Je sais que je peux tout faire en "machine de Turing", mais c'est pas très réconfortant :-)
            • [^] # Re: Logiciel libre et java

              Posté par . Évalué à 1.

              Tu te connectes à une base MySQL en 3 lignes avec ? :D

              http://about.me/straumat

              • [^] # Re: Logiciel libre et java

                Posté par . Évalué à 4.

                3 lignes, c'est 2 de trop : on peut toujours réduire une machine multi-bande à un machine mono-bande :p
              • [^] # Re: Logiciel libre et java

                Posté par . Évalué à 1.

                J'hallucine... Java, c'est bien parce que ça se connecte à une BD en 3 lignes ?

                Dans n'importe quel language actuel, ça se fait en 3 lignes ou moins. En ruby, en perl, en python... En C++ pur, c'est un peu plus dur, mais avec n'importe quel framework C++, pas de problème.

                Et sinon, comment tu fais en Java pour configurer l'accès à ta base de données ? Tu écris dans un fichier XML tellement imbittable qu'il faut une interface graphique pour écrire ce qu'il faut dedans pour le JNDI.
                Dans n'importe quel language, le fichier de conf, il faut 2-3 lignes et c'est compréhensible par un mortel qui n'est pas spécalisé dans la techno.

                Bref, ça tourne à du n'importe quoi tout ça...
                • [^] # Re: Logiciel libre et java

                  Posté par . Évalué à 3.

                  Relis... il s'agissait d'un exemple pour parler de la machine de turring...

                  Est ce qu'à un seul endroit tu m'as vu écrire que en ruby perl ou python, il était difficile de se connecter à une base de données ?

                  Et au lieu de me dire de ne pas donner de leçons sur les autres langages, apprends à ne pas donner de leçon en java que tu ne sembles pas connaitre.. tu n'as pas besoin forcément besoin de JNDI ou de fichier XML...

                  con = DriverManager.getConnection("jdbc:mysql:///test", "root", "secret");

                  Meme toi tu devrais comprendre non ?

                  TU dis vraiment n'importe koi, relis, apprends, et cesse de faire des amalgames

                  http://about.me/straumat

          • [^] # Re: Logiciel libre et java

            Posté par (page perso) . Évalué à 1.

            Ah bon tu peux tout faire en Java ?
            Et si t'avais pas les API et qu'il te fallait les écrire, tu crois pas que t'aurais du boulot et que tu rigolerais en Java ?
            En Java, tu peux tout faire, du moment que celà reste de haut niveau.
            Le langage Java a des limitations qui l'empêche d'utiliser certaines notions rendant impossible tout ce qui touche de près le matériel.
            Bref, Java c'est bien, mais pas pour tout faire.
            • [^] # Re: Logiciel libre et java

              Posté par . Évalué à 1.

              Je comprends pas ton post... un langage dans API, ca sert à koi ? tu en connais qui réinvente la roue tous les jours ?

              Bien entendu, java ne permet pas de parler au processeurs mais à part ça.. réseau, db, fichiers, xml, thread, graphisme, 3d, portable.... tu peux à peu près tout faire...

              http://about.me/straumat

              • [^] # Re: Logiciel libre et java

                Posté par (page perso) . Évalué à 0.

                un langage dans API, ca sert à koi ?
                Ben ca peut servir à faire des API tiens !
                J'imagines bien qu'il ne faille pas réinventer la roue, mais faut bien la fabriquer pour pouvoir l'utiliser...
                Tu ne pourras jamais faire un système d'exploitation en Java par exemple, ou très limité ! Et puis faut bien la faire la machine virtuelle aussi :)
                Bref, tu peux pas faire tout ce qui touche de près le système comme je l'ai dis. Tu ne peux pas faire de drivers par exemple.

                D'où mon explication : tu peux tout faire, du moment que celà reste de haut niveau.
                Autre truc : tu ne veux pas réinventer la roue et tu veux utiliser une bibliothèque non disponible en Java : tu vas devoir réinventer la roue ou faire un binding avec JNI, relativement pénible à écrire... celà devient parfois du travail de conception quand il faut essayer de contourner les limitations du langage Java (tout ce qui touche les pointeurs, structures, ne peuvent être "bindé" directement à la louche)
                • [^] # Re: Logiciel libre et java

                  Posté par . Évalué à 3.

                  «Ben ca peut servir à faire des API tiens !»

                  D'un autre côté, ça tourne un peu en rond... Tout langage a une API qui lui permet d'effectuer des calculs à un niveau inférieur, jusqu'au moment où on n'est plus dans le domaine du logiciel, mais dans celui du matériel.

                  Les langages de haut niveau ne proposent pas une API de bas niveau, mais ce n'est pas un bug, c'est une fonctionnalité. Donc en aucun cas un défaut lié à Java.
                  • [^] # Re: Logiciel libre et java

                    Posté par (page perso) . Évalué à 3.

                    Tout langage a une API qui lui permet d'effectuer des calculs à un niveau inférieur
                    Ben non, pas les langages de bas niveau, en l'absence d'API tu peux tout refaire à la main, sans aucune liaison avec une quelquonque bibliothèque : juste le compilateur pour traduire dans le langage machine.

                    Les langages de haut niveau ne proposent pas une API de bas niveau, mais ce n'est pas un bug, c'est une fonctionnalité.
                    Donc on est bien d'accord, Java est limité au Haut niveau et ne peut donc pas permettre de tout faire.

                    Mais tout de même, créer facilment des bindings est une feature intéressante justement pour un langage de haut niveau, et pour celà le langage Java n'est vraiment pas un exemple de simplicité.
                    • [^] # Re: Logiciel libre et java

                      Posté par . Évalué à 2.

                      «Ben non, pas les langages de bas niveau»

                      Même l'assembleur possède une API. L'API, c'est ton interface avec le niveau d'en dessous, par définition. L'API en assembleur va te permettre de savoir quelle interruption fait quoi, quel registre correspond à quoi. Si tu ne sais pas comment t'interfacer avec la couche inférieure, tu ne peux rien faire.

                      Il n'y a pas de différence fondamentale entre l'assembleur qui te permet de manipuler des registres et un langage de plus haut niveau qui te permet de manipuler des structures de plus haut niveau.
                      • [^] # Re: Logiciel libre et java

                        Posté par (page perso) . Évalué à 2.

                        Je vais répondre à tes 2 réponses à la fois :-)

                        Même l'assembleur possède une API.
                        Je parlais plus généralement d'API en tant que bibliothèques de fonctions... Ce n'est pas pour moi de simples interfaces, il y a du code derrière et des algorithmes (c'est ce qui fait pour la grosse différence entre l'assembleur et les classes du JDK ;) ). Considérer les instructions matérielles comme un API me semble donc sortir du contexte, puisque constituant notre socle commun. On pourrait alors étendre les limites du langages aux limites des instructions de la JVM, qui sont encore plus handicapantes que les possibilités du langage.

                        Java peut simuler une machine de Turing. donc Java peut faire ce que peut faire n'importe quel ordinateur.
                        Cette machine sera virtuelle et non physique, et n'aura donc accès à aucun périphérique autre que les ressources mises à dispositions par la JVM ou par l'intermédiaire d'API écrits dans d'autres langages (Comme qui dirait, En théorie c'est faisable, mais dans la pratique celà ne marchera jamais). Java est un langage, on ne le compare pas à aux fonctionnalités d'une machine, mais plutôt aux possibilités d'expressions offertes par sa grammaire.

                        Ce que je veux dire, c'est que certains éléments sont infaisables en Java car inexprimable à l'aide de sa syntaxe. C'est pourquoi certaines fonctionnalités doivent être codés dans un autre langages. Ce n'est pas insurmontable dans l'ensemble, puisque le langage Java n'a pas cette ambition d'exploiter toutes les possibilités offerte par une machine, mais celà est plutôt embêtant dans le sens où ces insuffisances demandent à être comblées par des API "natifs", et c'est là que le bas blaisse, Java ne facilite vraiment pas l'intégration de ces API, JNI n'est vraiment pas flexible et demande beaucoup d'adaptation.
                        • [^] # Re: Logiciel libre et java

                          Posté par . Évalué à 2.

                          le langage Java n'a pas cette ambition d'exploiter toutes les possibilités offerte par une machine

                          En fait, le langage Java a pour but de faire abstraction des possibilités des machines en utilisant leur caractéristiques communes et ainsi permettre aux développeurs de développer de manière indépdante.

                          99% des applications existantes pourraient être développée en Java.

                          http://about.me/straumat

                        • [^] # Re: Logiciel libre et java

                          Posté par . Évalué à 2.

                          «Java est un langage, on ne le compare pas à aux fonctionnalités d'une machine, mais plutôt aux possibilités d'expressions offertes par sa grammaire.»

                          Il n'y a pas de différence.
                          • [^] # Re: Logiciel libre et java

                            Posté par (page perso) . Évalué à 2.

                            oué effectivement, je me rend compte que c'est bidon ma phrase :)
                            Un processeur offrant un jeu d'instruction et donc d'opération et d'enchaînement, tout comme un langage.
                            Enfin je ne penses pas que celà remette en cause globalement mon raisonnement vis à vis des "lacunes" de Java, mineures certes, mais poussant parfois à réinventer la roue tellement l'utilisation d'une bibliothèque écrite dans un autre langage est fastidieuse.

                            Et puis en Java, il manque la feature qui tue : on ne peut pas faire une fonction inverse qui prend 2 entiers (pas leur équivalent wrappés) et inverse leurs valeurs =)
                            ok je sors -->[]
                    • [^] # Re: Logiciel libre et java

                      Posté par . Évalué à 4.

                      «Donc on est bien d'accord, Java est limité au Haut niveau et ne peut donc pas permettre de tout faire.»

                      On est à la fois d'accord et pas d'accord. Java peut simuler une machine de Turing, donc Java peut faire ce que peut faire n'importe quel ordinateur. Ça, c'est rêglé. Ensuite, Java obligeant à une abstraction vis à vis de la machine réelle sur laquelle il tourne, il impose des limitations d'accès à cette machine, là dessus on est d'accord.
                • [^] # Re: Logiciel libre et java

                  Posté par . Évalué à 3.

                  > Tu ne pourras jamais faire un système d'exploitation en Java par exemple, ou très limité !

                  http://jnode.sf.net(...)
                  • [^] # Re: Logiciel libre et java

                    Posté par (page perso) . Évalué à 0.

                    Non non, c'est bidon, tout ce qui touche le matos n'est pas géré en Java.
                    • [^] # Re: Logiciel libre et java

                      Posté par (page perso) . Évalué à 2.

                      http://jnode.sourceforge.net/portal/book/view/175(...)

                      C'est pas toi qui serait bidon par hasard ?
                      • [^] # Re: Logiciel libre et java

                        Posté par (page perso) . Évalué à 2.

                        Oh ben dis-donc c'est quoi cette partie toute rouge ? de l'assembleur ? tiens donc ! Ca doit être nouveau en Java ;-)
                        • [^] # Re: Logiciel libre et java

                          Posté par (page perso) . Évalué à 2.

                          JE vois déjà ta réaction : oui mais y'a du vert au dessus de hardware !
                          Et alors ? si le schéma l'a mis là ce n'est pas pour autant que y'a un lien direct entre les 2...
                          Suffit de voir où est la JVM... tout ce qui se trouve à droite devrait être au dessus de la JVM, sinon celà ne peut pas être en Java... Enfin je suppose que le schéma est plus "lisible" comme ceci, ils ont voulu faire l'analogie avec les fonctionnalités des kernels.
                          Y'a un n-kernel dont le but est d'effectuer (comme tout kernel) l'abstraction matérielle, bref, cet OS est en grande partie en Java si on prend la définition Windozienne d'un OS (avec les classes et tout), mais si on prend la définition Unixienne, y'a la moitié en rouge, la moitié en vert, et la partie eu rouge montre bien qu'on ne peut pas tout faire en Java.
                          • [^] # Re: Logiciel libre et java

                            Posté par (page perso) . Évalué à 3.

                            Les drivers sont codé en java... pratiquement tout est codé en java, sauf le "n-kernel" qui est un mini kernel (mini mini) qui sert a bootstrapper. La taille de la partie en rouge reflète la taille réelle de code natif de l'os et c'est pas 50% daisolai.
                            • [^] # Re: Logiciel libre et java

                              Posté par (page perso) . Évalué à 2.

                              sauf le "n-kernel" qui est un mini kernel (mini mini)
                              On s'en fou, il est là, et justement pour faire un des taf le plus important de l'OS.

                              La taille de la partie en rouge reflète la taille réelle de code natif de l'os et c'est pas 50% daisolai.
                              Moi j'aurai pas dit 50% non plus, mais dans ce acs la taille de la partie en rouge ne reflète PAS la taille réelle. Parcque sinon ca fait bien 50%, tout ce qui est au dessus de la JVM ce n'est plus l'OS.

                              Et puis il me fait marrer leur memory manager, y'a quand même le GC et le heap qui sont gérés "ailleur", dans un mélange vert/rouge qui montre bien que là encore faut de l'asm dès que sa touche au matos.

                              Bref, ils ont fait un OS en Java, mais ils se sont juste amuser à coder le maximum de choses en Java en évitantr la partie "sensible" parcque impossible à faire.
                              • [^] # Re: Logiciel libre et java

                                Posté par . Évalué à 3.

                                > On s'en fou, il est là, et justement pour faire un des taf le plus important de l'OS.

                                n'importe quoi :-)

                                De nos jour la partie la plus importe d'un OS c'est certainement pas la couche basse qui s'addresse directement au materiel. C'est d'ailleur bien souvent une couche interchangeanble ou tu pourrais mettre n'importe quoi d'autre dessous. Par exemple le port de NetBSD sur certaines archis s'est fait en un week end. Et bien evidement tout n'est pas écrit en java ! Sans asm point de salut, de toute facon l'affaire est pliée. Tu connais un langage portable qui est capable de positionner les drapeaux PE et PG du registre CR0 ? Moi pas.

                                Donc quoi que tu fasses, tu auras toujours le langage machine en dessous et une abstraction de la machine juste au desus (ou alors tu fais un OS pour une archi donnée).

                                Si suis ton raisonement linux n'est pas en C. Pourtant la VM, les drivers, la gestion des I/O etc. est ecrite en C (tout comme dans jnode elle est ecrite en Java) et toutes les fonctions generiques sont en fait specialisées pour chaque archi a la compile et bien souvent ecritent.... en assembleur :-)
                                • [^] # Re: Logiciel libre et java

                                  Posté par (page perso) . Évalué à 2.

                                  n'importe quoi :-)
                                  C'est vrai que faire la première couche d'abstraction pour un OS c'est vraiment pas un taf important. C'est pas parcqu'il est "simple" qu'il est pas important.

                                  Tu connais un langage portable qui est capable de positionner les drapeaux PE et PG du registre CR0
                                  Oué mais au moins en C tu peux toujours faire asm("mov ax,bx"), c'est simple et ça marche. D'où ma remarque concernant JNI, qui est parfaitement imbittable avec élégance.

                                  tu auras toujours le langage machine en dessous et une abstraction de la machine juste au desus (ou alors tu fais un OS pour une archi donnée
                                  Oué mais si tu regrde bien le schéma de l'"OS" en Java, même la couche au dessus n'est pas en Java mais toujours en ASM...

                                  Si suis ton raisonement linux n'est pas en C
                                  Non j'ai pas dis celà. Ce que j'ai dit c'est que Java ne permet pas de tout faire. J'ai pas dit que le C pouvait, mais le C peut faire beaucoup plus.

                                  (tout comme dans jnode elle est ecrite en Java)
                                  Euh, c'est bien joli mais le mélange rouge/vert montre bien qu'il doivent impérativement utiliser de l'asm, même au dessus du n-kernel...

                                  Franchement je vois pas où tu veux en venir :-) J'ai jamais dis que C pouvait tout faire, j'ai juste voulu montrer que Java était vraiment pas conçu pour faire du bas-niveau, ton exemple est parfait pour montrer celà.

                                  PS : j'aimerai bien voir une appli écrite en C tourner sur jnode... Parcqu'un OS ne doit pas limiter l'utilisateur en l'obligeant à utiliser un seul langage avec GC et tout le tralala... Il doit lui laisser libre accès à la mémoire si l'utilisateur en a envi.

                                  PS2 : tu gère comment la mémoire d'une carte graphique avec un driver en Java ?
                                  • [^] # Re: Logiciel libre et java

                                    Posté par (page perso) . Évalué à 2.

                                    PS : j'aimerai bien voir une appli écrite en C tourner sur jnode... Parcqu'un OS ne doit pas limiter l'utilisateur en l'obligeant à utiliser un seul langage avec GC et tout le tralala... Il doit lui laisser libre accès à la mémoire si l'utilisateur en a envi.

                                    Une vm peut faire tourner plusieurs langages (vm = virtual machine). Bien sûr le langage qui tourne de base sur une jvm, c'est java. Mais tu as par exemple rhino qui permet de faire du js, jpython du python... et pourquoi pas du C qui aurait comme target la jvm.

                                    Oué mais si tu regrde bien le schéma de l'"OS" en Java, même la couche au dessus n'est pas en Java mais toujours en ASM...

                                    Mais non les drivers, la gestion mémoire sont écrite en java. Il est évident que pour booter du java, il faut du code natif, c'est ce que fait ce nkernel qui bootstrap une minivm qui bootstrap la vm finale. Maintenant l'accès au matériel n'a rien avoir avec le fait que ça soit java ou non. Après ce que le proc execute c'est toujours du code natif. La vm compile à la volée en code binaire. Le code asm/C de jnode est ridicule comparé au code java. Dire que jnode n'est pas un OS en java est de la grosse foutaise.
                                    • [^] # Re: Logiciel libre et java

                                      Posté par (page perso) . Évalué à 2.

                                      Une vm peut faire tourner plusieurs langages
                                      Tout à fait d'accord. Après la vm peut quand même limiter les possibilités.

                                      pourquoi pas du C qui aurait comme target la jvm.
                                      Parcque les instructions de la JVM ne le permettent pas. La JVM n'a pas du tout les mêmes instructions qu'un proc classique...

                                      Mais non les drivers, la gestion mémoire sont écrite en java.
                                      mais si moi je te parlais de ce qu'il y avait au dessus du n-kernel, driver et IO sont au dessus de la JVM.

                                      Dire que jnode n'est pas un OS en java est de la grosse foutaise.
                                      Pas pour moi. C'est comme si tu faisais une voiture sans moteur : c'est joli, mais même si le moteur est petit, voir simple à faire, c'est un élément vital. Pour moi le boulot principal d'un OS est de fournir la première couche d'abstraction du matos, et de gérer l'allocation des ressources (processeur et mémoire centrale).
                                      Dans JNode, tout ce taf est fait grâce à l'assembleur, ils ont juste rajouté une surcouche Java pour la gestion mémoire (parcque par derrière tout ce fait au niveau du GC et de la JVM, la gestion des processus étant faite au niveau de la JVM, etc.
                                      • [^] # Re: Logiciel libre et java

                                        Posté par (page perso) . Évalué à 2.

                                        Parcque les instructions de la JVM ne le permettent pas. La JVM n'a pas du tout les mêmes instructions qu'un proc classique...

                                        C'est faux. La jvm est une machine de turing universelle... alors je vois pas pourquoi on pourrais pas faire un compilo qui target la jvm. Peut-être du au model de la jvm, le resultat ne sera pas forcement performant mais faisable ça l'est et sur les spec de la jvm actuelle.
                                        • [^] # Re: Logiciel libre et java

                                          Posté par (page perso) . Évalué à 2.

                                          Nan mais je m'en fou que en émulant tout tu puisses recréer une machine de turing, c'est pas du tout le but d'un OS, ce que je veux pouvoir faire c'est manipuler directement la mémoire de ma machine si j'en ai envi, comme je le ferai naturellement en C; pas me taper une pseudo mémoire représentée dans une classe "Stack" implémentée dans le heap avec des perfs dégueulasse. La machine virtuelle Java ne permet pas l'accès direct à la mémoire, c'est un de ses avantages mais c'est également limitatif. D'autres machines virtuelles sont plus souples et le permette, c'est que c'est donc possible.
                                  • [^] # Re: Logiciel libre et java

                                    Posté par (page perso) . Évalué à 2.

                                    PS2 : tu gère comment la mémoire d'une carte graphique avec un driver en Java ?

                                    Il y a un point d'entrée dans la vm qui permet d'accéder aux matos, et tu codes avec l'interface qui va bien et tu auras accès en java à la zone mémoire de la carte, je vois pas où se situe le problème. Il est évident qu'il y a une couche native qui donne l'accès au pointeur de la mémoire, à partir de là, tu fais tout le reste en java.
                                    • [^] # Re: Logiciel libre et java

                                      Posté par (page perso) . Évalué à 2.

                                      Il est évident qu'il y a une couche native qui donne l'accès au pointeur de la mémoire, à partir de là, tu fais tout le reste en java.
                                      Et après je fais comment pour faire des optimisations si je n'ai pas accès à la pile ? Je vais tout me colletiner sur le tas ? Parcque bon un driver c'est quand même principalement de l'optimisation des ressources, avec des astuces toutes les 2 lignes, je parle dans le cas d'une carte graphique...
    • [^] # Re: Logiciel libre et java

      Posté par (page perso) . Évalué à 3.

      Doxygen génère aussi la doc pour du code Java par exemple.
  • # à propos de classpath

    Posté par . Évalué à 3.

    Rapport à calsspath, j'imagine que c'est un projet complexe car on aborde des sujets très différents et toujours de spécialiste (dans le sens qu'on va au détail des implémentations).
    Y-a-t-il de la réutilisation de bouts de codes d'autres projets GPL. Mono et classpath font-il un peu de travail commun ? (les api sont très différentes mais travaillent sur le même type d'objets, exemple opur faire le module sur les polices d caractères il faut un spécialiste des polices et du code surement proche dans les deux cas).
    Je demande ça car je me demande toujours si la réutilisation du code est une utopie ou on y arrive parfois ?

Suivre le flux des commentaires

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