JDK 1.4.1 RC ...

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
24
août
2002
Java

Ca y est, la RC du JDK 1.4.1 est sortie...



Cette JVM va ravir tous les utilisateurs d'eclipse ! En effet, contrairement à la 1.4, il est maintenant possible, avec la 1.4.1 (depuis la bêta) de modifier le code executé de facon dynamique sans avoir à relancer l'application en cours de déverminage débogage. Je vous laisse imaginer le gain de temps !



Pour le reste, je ne vais pas vous recopier le site de Sun, allez y jeter un coup d'oeil...



Note du modérateur : je rappelle pour mémoire le JDK2 n'est pas libre. Cf la licence SCSL.


Node 2 du modérateur : déverminage s'applique à l'électronique et débogage à l'informatique, cf http://www.culture.gouv.fr/culture/dglf/terminologie/base-donnees.html

Aller plus loin

  • # Pas libre...

    Posté par  . Évalué à 10.

    AMHA, le problème n'est pas que le JDK soit un produit propriétaire. Le problème est plus complexe que ça.

    Déjà, les APIs du langages sont disponibles, on peut donc théoriquement faire des machines virtuelles compatibles Java (cf plus loin). Mais au vu de l'état d'avancement de certains projets, comme kaffe ( http://www.kaffe.org(...) ), on est en droit de penser que ça doit pas être simple.

    Le process d'intégration des nouvelles fonctionnalités aux langages est relativement ouvert (voir cependant les problèmes de l'Apache consortium http://linuxfr.org/2001/06/19/3932,0,1,0,0.html(...) et oui... 19 juin 2001).

    Je dis relativement parceque le process, même si l'idée est bonne, découle du problème de reconnaissance de Java. Autant tout le monde peut écrire un compilateur C, autant le fait d'utiliser le nom Java (et donc tout ce qui va avec, j2SE, J2EE par exemple) est protégé.

    Un exemple: JBoss ( http://www.jboss.org(...) ) est un serveur d'application 100 % Java (ça, ils ont le droit), basé sur les specs J2EE. Ils ne peuvent pas dire que c'est "J2EE compliant", pour ça, il faut payer Sun pour qu'il le teste. Ce qu'ont fait BEA (weblogic), IBM (Websphere) et tant d'autres.

    Je pense cependant que Java une idée pas si mal que ça, même si malgrè l'avis de quelques un de mes collègues, ça aurait pû être mieux pensé.

    • [^] # Re: Pas libre...

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

      Kaffe est un très mauvais exemple. Les développeurs ont justement choisi d'implémenter uniquement le JDK1 suite aux pressions de SUN. Le projet Kaffe est donc plus ou terminé puisque JDK1 ne bouge plus.

      Pour voir des implémentations libres du JDK2, il faut mieux regarder du côté de :
      - Classpath http://www.gnu.org/software/classpath/classpath.html(...)
      - Classpathx
      http://www.gnu.org/software/classpathx/(...)
      - gcj dans GCC
      http://gcc.gnu.org(...)
      - ORP
      http://orp.sourceforge.net/(...)
      - SableVM
      http://www.sablevm.org/(...)
      - Kissme
      http://kissme.sourceforge.net/(...)
      - Jupiter VM
      http://www.eecg.toronto.edu/~doylep/jupiter/(...)
      ...

      Voir aussi la Debian Java FAQ http://www.debian.org/doc/manuals/debian-java-faq/(...)
      En particulier la partie sur la licence SCSL
      http://www.debian.org/doc/manuals/debian-java-faq/ch2.html#s2.3(...)
      "about as free as the former Soviet Union"

      • [^] # Re: Pas libre...

        Posté par  . Évalué à 10.

        Bon, OK, Kaffe est un mauvais exemple. Mais on peut remplacer l'exemple de Kaffe par n'importe quel VM que tu as donné. Aucune ne fait ne serait-ce qu'approcher les capacité d'un J2SE. Ce que je déplore énormément.

        Personnellement, j'aime bien Java pour les applications qu'il m'apporte:


        Par exemple. C'est sur qu'il y a des remplacements libres qui ne sont pas en Java, mais je n'en connais d'aussi avancés que ça.

        • [^] # Re: Pas libre...

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

          Je maintiens mon propos. La SCSL n'est pas libre.

          http://www.gnu.org/licenses/license-list.html(...)

          "The Sun Community Source License.

          This is not a free software license; it lacks essential freedoms such as publication of modified versions. Please don't use this license, and we urge you to avoid any software that has been released under it."

          Il suffit de lire la licence pour s'en convaincre (tout développeur Java devrait s'intéresser à cette licence un jour, avant de l'utiliser serait le mieux (ce que je n'ai pas fait perso, et je regrette que personne ne m'ait parlé d'aspects légaux lorsque l'on m'a enseigné le Java)).

          Faite du Java, mais faite-le avec des implémentations libres. Si celles-ci sont insuffisantes, perso, et ça n'engage que moi, ou je contribue à les améliorer, ou je me débrouille pour le faire autrement (dans le cadre de mes développements pour le libre il s'entend, pour le boulot c'est un autre problème). C'est une des conditions de l'hébergement sur Savannah par exemple.

          • [^] # Re: Pas libre...

            Posté par  . Évalué à 10.

            J'étais persuadé en avoir discuté dans une autre news, mais en fait c'était de l'APSL. Qui est aussi libre que la SCSL. C'est à dire qu'elle l'est pas.

            Je ne te contredis pas.

            Concernant ça:

            > Il suffit de lire la licence pour s'en convaincre (tout développeur Java devrait s'intéresser à cette licence un jour, avant de l'utiliser serait le mieux (ce que je n'ai pas fait perso, et je regrette que personne ne m'ait parlé d'aspects légaux lorsque l'on m'a enseigné le Java)).

            Je ne parlerais pas de Java particulièrement, mais des aspects légaux du travail que chacun d'entre nous faisons. Je suis administrateur système. J'ai ccès à des informations confidentielles et privées. Tout comme les DBA par exemple. On en parle pas beaucoup non plus de ça, et je n'ai même jamais entendu parlé de déontologie.

            Mais je diverge.

    • [^] # Re: Pas libre...

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

      «AMHA, le problème n'est pas que le JDK soit un produit propriétaire.»

      En soi, c'est déjà un problème suffisant pour se demander si l'on doit choisir autre chose que Java (>1.1) pour développer un projet libre. Si on s'intéresse simplement à la disponibilité des sources c'est pas vraiment un problème, mais si on fait partie de ceux qui pensent que le logiciel propriétaire c'est Mal®, ça ne rime à rien de demander à ses utilisateurs d'utiliser une machine virtuelle non-libre.

      Je précise que j'ai moi même écrit quelques programmes en java, sous licence GPL, mais que je suis tellement mal à l'aise avec cette question que maintenant, à chaque fois que c'est possible, je choisis autre chose que Java. (D'ailleurs depuis que j'ai découvert Ruby, je suis ravi de choisir autre chose que Java ;)

      • [^] # Re: Pas libre...

        Posté par  . Évalué à 3.

        En fait, je prenais la comparaison avec le C. Hein, je l'ai pas dit? Mince... ;-)

        On a des compilateurs C propriétaires qui fonctionnent bien (celui d'Intel par exemple). On en a un libre qui fonctionne aussi bien (gcc bien sûr)(non, pas de troll, je connais pas assez bien les différences, mais bon, gcc il marche pas trop mal quand même).

        Le problème n'est pas que le jdk soit propriétaire. Le problème est qu'il n'existe pas d'alternative viable à un J2SE capable de faire tourner JBoss par exemple.

  • # changelog

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

    <<En effet, contrairement à la 1.4, il est maintenant possible, avec la 1.4.1 (depuis la bêta) de modifier le code executé de facon dynamique sans avoir à relancer l'application en cours de déverminage !>>

    heu désolé je vois rien dans le "changelog" à propos de ça :/

    j'ai loupé un truc ?

  • # Déverminage...

    Posté par  . Évalué à 6.

    Pourrait-on dire "débogage" s'il vous plaît ?? Je trouve ce mot affreux. ;)

    Et en plus « débogage » est le terme recommandé par l'office de la langue française. ( http://www.granddictionnaire.com/index.jsp?idDomaine=1003&idFic(...) )

    • [^] # Re: Déverminage...

      Posté par  . Évalué à -2.

      Certes... Cependant, LE site officiel pour connaître ce genre de chose, et pas seulement en informatique, c'est CRITER: http://www.culture.gouv.fr/culture/dglf/terminologie/base-donnees.h(...)

      My 0.30€

      • [^] # Re: Déverminage...

        Posté par  . Évalué à 0.

        Au passage, j'ai regardé "debug". Il faut donc effectivement dire débogage... L'arrêté date de 1983!!

    • [^] # Re: Déverminage...

      Posté par  . Évalué à 10.

      C'est vrai que pour avoir pratiqué le deverminage au sens propre du terme dans mon ancienne carrière, ca n'a pas grand chose à voir avec le debogage en plus ...

      Pour nous c'était faire tourner des circuits de traitement de signaux à 100 % pendant des jours afin d'éliminer les "maillons faibles" (:p) et leur faire atteindre l'âge de raison avant de pouvoir les calibrer.

      Je ne comprend pas trop pourquoi deverminage vient d'apparaitre en info... Et pourquoi pas "rodage" pour une béta, "révision des 10000" pour un patch et "options grand tourisme" pour un add'on ?

      Je dois pas assez lire 01net pour ignorer autant les termes informatiques à la mode :p

      Mike

      Je me colle moins un pour la peine

    • [^] # Re: Déverminage...

      Posté par  . Évalué à 0.

      Bon, ok, je me range à votre avis, et je ferai attention la prochaine fois !


      -1, parce que ca n'apporte rien à la news ...

  • # modifier le code executé de facon dynamique

    Posté par  . Évalué à 7.

    Au-delà du fait que Smalltalk le fait depuis 1972 (IBM depuis 1960 avec ses mainframes), c'est finalement pas si compliqué que ça a faire. La principale difficulté de java est que le compilo n'est pas dans l'environement d'exécution doc il faut un protocole entre le compilo et la VM et l'environnement.

    J'ai l'impression que si ça n'a pas été fait avant c'est parce que les utilisateurs n'étaient pas trop cultivés et n'ont pas poussé pour l'avoir (en C/C++ c'est pas trop à l'ordre du jour), car les concepteurs de java avaient travaillé sur Self (langage ressemblant à smalltalk mais innovant qd même) et conaissaient smalltalk (Self, les concepts de la VM, le package reflect, et d'autres choses encore).

    J'espère que Eclipse possède des inspecteurs corrects sinon tout ça n'est pas très utile (enfin le boulot serait fait à moitié).

    Un petit scrinechotte de squeak ( http://www.squeakland.org(...) ) pour la route :
    http://nraynaud.com/DEBUG.PNG(...)

    ça commence en bas à gauche par la tentative d'appeller une méthode qui n'existe pas dans la variable globale Object

    • Workspace est une sorte de terminal.

    • La fenêtre rose est le débogueur :

      • en haut la pile d'appels,

      • au milieu le code de la méthode courante avec le bout de code courant surligné (pas visible ici car la fenêtre est inactive) ; c'est là qu'on corrige la méthode et qu'on continue

      • en bas a gauche, un inspecteur sur self (l'aquivalent de this en C++)

      • en bas à droite un inspecteur sur le contexte courant


    • La fenêtre à droite est un inspecteur avec en blanc le menu de navigation dans les différentes propriétés de l'objet (la variable globale Object qui est en fait la classe Object comme on peut le deviner par ces propriétés : subclasses, superclass, methodDict ...)



    J'aimerais que ceux qui utilisent des langages qui penvent faire ça me montrent un scrinchotte du même type, c'est toujours intéressant à voir, et pas que pour moi. Et la même chose dans Eclipse.

    • [^] # Re: modifier le code executé de facon dynamique

      Posté par  . Évalué à 6.

      Je voulais commencer mon poste en disant que ta capture d'écran est horible, mais je ne le ferai pas ! ;)

      Concernant la modification dynamique du code executé (et des variables chargées aussi), VisualAge (IBM) le fait aussi, et tres tres bien ! Je ne l'ai pas ici (Pas Libre ...), mais je l'ai au boulot. Je te ferai une capture demain, si j'y pense ...

      En gros, tu peux voir tous les threads qui tournent, les interompre, les relancer, tracer le code, modifier le code, inspecter tous les objets, modifier leurs contenu, etc.

      Eclipse étant un clone de VAJ (au niveau fonctionnel j'entend, car on retrouve 90% des fonctions de VAJ dans Eclipse), on peut donc tout naturelement y faire exactement la même chose !

      JMS.

      • [^] # Re: modifier le code executé de facon dynamique

        Posté par  . Évalué à 3.

        Je suis pas responsable de la tronche de squeak, les version 3 sont entièrement en Morphic donc plus belles (et largement plus lentes). Là c'est juste l'image que j'utilise pour pocketsmalltalk, c'est une 2.7 et le projet courrant est en MVC.


        VAJ est dérivé de smalltalk (VisualAge était
        un smalltalk à la base).

      • [^] # Re: modifier le code executé de facon dynamique

        Posté par  . Évalué à 4.

        Si t'écoutes IBM, éclipse c'est le prochain visual age.

        IBM va prendre des versions d'éclipe, faire des plugins qu'il faudra payer et packager tout çà et les vendres.

        Sur le principe c'est un peu comme sun et star office. Les décideurs peuvent ainsi payer une boite en carton et par conséquent sont content !!

        • [^] # Re: modifier le code executé de facon dynamique

          Posté par  . Évalué à 3.

          J'aime bien ta facon de voir les choses "Les décideurs peuvent ainsi payer une boite en carton et par conséquent sont content !!" , malheureusement trop véridique ...

          Ici ils réchignent à utiliser CVS parce que c'est gratuit ! On croit rever !

          JMS.

          • [^] # Re: modifier le code executé de facon dynamique

            Posté par  . Évalué à 5.

            > On croit rever !

            Pas du tout malheureusement. C'est le syndrome du parapluie.

            Plus tu paies, plus le parapluie est large est solide. Tu peux pas te planter si tu achètes un produit très cher, même si le support est pas à la hauteur.

            De plus, beaucoup de gens en sont encore au "si c'est cher, c'est que c'est de la bonne qualité".

            Mais ça évolue tout doucement. On (enfin, ils) arrivera un jour à comprendre qu'un logiciel n'est pas un bien de consommation comme les autres.

      • [^] # Re: modifier le code executé de facon dynamique

        Posté par  . Évalué à 4.

        Je ne dirais pas qu'Eclipse est un clone de Visual Age for Java...

        Effectivement, Eclipse bénéficie de toute la capitalisation qui a pu être réalisée sur Visual Age et on retrouve dans Eclipse la plupart des fonctionnalités qui faisaient de Visual Age un outil formidable (si, si, bien que très très grourmand en ressources). Mais Eclipse est fondamentalement différent dans la mesure où :
        - c'est un framework pour le développemnt d'IDE. De ce fait et de part sa nature même, Eclipse est complètement extensible et modulaire.
        - Eclipse n'est pas "language centric" (orienté vers une seul langage) mais a été pensé pour les projets modernes qui combinent plusieurs technologies, plusieurs langages... Cela manquait terriblement dans VAJ.

        Maintenant, il est vrai que Visual Age for Java sait faire du hot compiling (VAJ compile à la volée tout code Java du plan de travail). Et cette fonctionnalité à été reprise dans Eclipse.

        Mais là, il s'agit de modifier le code executé de facon dynamique et ça, ce n'est pas directement VAJ qui le permettait mais bien le JDK d'IBM que tu étais obligé d'utiliser avec VAJ.

        Donc, c'est quand même plutôt une bonne nouvelle :)

        Enfin, juste pour clarifier les chose, oui IBM va vendre un produit qui est basé sur Eclipse (WebSphere Application Studio Developer ou WASD pour faire plus court). Oui IBM a développé des plug-ins proprio qu'ils vont vendre dans une offre packagée autour d'Eclipse. Mais où est le problème ? Rien n'empêche les utilisateurs de développer des plug-ins qui répondent à leurs besoins. IBM est une entreprise et doit gagner de l'argent. Alors cela ne me dérange pas qu'ils vendent un produit (WASD) dans la mesure ou la communauté du libre bénéfie directement de la R&D et du savoir faire d'IBM au travers du don de l'ossature de ce produit (Eclipse).

        • [^] # Re: modifier le code executé de facon dynamique

          Posté par  . Évalué à 0.

          modifier le code executé de facon dynamique J'ai un doute d'un coup, il ont rendu java self-réflexif ? On peut ajouter et retirer des méthodes au cours de l'exécution d'un programme normal (indépendemment d'Eclipse) ? Ou on peut juste réinjecter code code compilé dans la VM à partir de l'extérieur (pour corriger et repartir en début de méthode courante au lieu de relancer le programme) ?

          • [^] # Re: modifier le code executé de facon dynamique

            Posté par  . Évalué à 1.

            Dans ce document intitulé Eclipse / WebSphere Studio Application Developer : Retour d'expérience de Didier Girard - et disponible ici : http://www.application-servers.com/articles/pdf/a19s.wsad.pdf(...) - on peut lire à propos de la perspective "debugger" :

            [...]
            Perspective debugger :
            Elle propose des services de debug très classiques. C'est l'un des points en retrait par rapport à Visual Age for Java :

            • pas de point d'arrêt conditionnel,

            • pas de remplacement de code à chaud (HCR)

            • pas de passage méthode par méthode quand elles sont chaînées au sein d'une ligne

            • pas de reprise du debuggage en amont dans le code (drop to frame)

            Ces options très avancées étaient rendues possibles dans VAJ par une JVM supportant une API propriétaire IBM, et un compilateur qui permettait une instrumentation plus fine du code. Une partie de ces fonctionnalités (dont le magique HCR) ont été standardisées sous l'impulsion d'IBM, et seront présentes dans la JVM1.4. Le HCR commence à apparaitre dans les derniers builds de développement d'Eclipse2. WSAD4.0 étant basé sur une branche Eclipse1.0, le HCR est absent.
            Le débuggage sur serveur distant (remote debugging) est possible avec l'IBM Distributed Debugger, téléchargeable gratuitement (sous une licence propriétaire)
            [...]


            Pour en savoir plus, voici le papier de Sun sur JPDA (Java Platform Debugger Architecture) et sur ce qui s'appelle désormais le "HotSwap" Class File Replacement : http://java.sun.com/j2se/1.4/docs/guide/jpda/enhancements.html#hots(...)

Suivre le flux des commentaires

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