Ok...

• [^]Re: Ok...

  Posté par Stéphane TRAUMAT (page perso, ) le 13/11/2006 à 11:55. (lien). Évalué à 8.

  Perso, je ne vois pas de "différence"... Java a été développé de manière assez "collaborative" (avec Apache, Jboss, IBM, Oracle..). Ce qui compte, c'est le résultat. Je ne vois pas ce que ça change de savoir qu'Open Office vient d'une société ou d'une communauté, ça n'enlève pas les qualités du projet
  
  Pourrais tu préciser ta deuxième question ? je suis pas sur de comprendre.
  Pour info, du code 1.4 compile et tourne très bien sur une JVM 1.5

  • [^]Re: Ok...

    Posté par popopo333 () le 13/11/2006 à 12:11. (lien). Évalué à 6.

    je pense que le monsieur parlait de plateforme materielle.

    [^]Re: Ok...

    Posté par JoeBar () le 13/11/2006 à 16:40. (lien). Évalué à 4.

    Pour info, du code 1.4 compile et tourne très bien sur une JVM 1.5

    
    
    C'est faux : tout ne passe pas, exemple ici.
    
    

    
    Enumeration enum = monObjet.getEnumeration();
    

    
    
    Le nom 'enum' est un mot clé réservé de java 1.5, ceci compile donc en 1.4 et pas en 1.5.
    Je pense qu'il y a d'autres exemples, mais je n'ai encore jamais travaillé avec java 1.5, désolé.

    • [^]Re: Ok...

      Posté par Stéphane TRAUMAT (page perso, ) le 13/11/2006 à 16:53. (lien). Évalué à 1.

      Tu veux dire que dans ton code 1.4, tu as crée une classe Enumeration ? ok, c'est vrai, je n'y avais pas pensé.
      Néanmoins, dans toutes les applis que ma société a développé, on a jamais eu de prbs pour passer à java 1.5... On s'en rend même pas compte !

      • [^]Re: Ok...

        Posté par TImaniac (page perso, ) le 13/11/2006 à 17:20. (lien). Évalué à 5.

        En même temps ca peut être un mot clé du langage mais pas de la VM, auquel cas du code déjà "compilé" en bytecode en 1.4 peut tourner sur 1.5. Quand à ceux qui ont un problème à la compilation, c'est qu'ils ont les sources pour faire la modif ;)
        (Ca reste à vérifier)

        --
        MonoFrance

        [^]Re: Ok...

        Posté par hophophop () le 13/11/2006 à 17:41. (lien). Évalué à 3.

        non, enum est un mot cle en 1.5 mais ne l'est pas en 1.4.
        
        ie : ce code compile avec un javac 1.4.x ou anterieur, mais pas avec un 1.5 qui t'envoie boulet car enum n'est pas accepte en tant que variable.
        
        Eclipse previent de ce genre de chose quand on developpe en 1.4, FYI.
        
        L'interface Enumeration est dans java depuis la version 1.0, FYI aussi.

        • [^]Re: Ok...

          Posté par tgl () le 13/11/2006 à 21:21. (lien). Évalué à 6.

          ce code compile avec un javac 1.4.x ou anterieur, mais pas avec un 1.5

          
          Ça n'est pas tout à fait vrai : tu peux compiler ce code avec le compilo du JDK 1.5, si tu passes le paramètre "-source 1.4".

  [^]Re: Ok...

  Posté par Julien CARTIGNY (page perso, ) le 13/11/2006 à 12:15. (lien). Évalué à 10.

  Une remarque: SUN libère l'ensemble de SON implémentation de Java, mais les specs déjà sont libres (http://jcp.org/en/home/index) et réalisées dans un cadre de participation ouverte.
  
  Le fait que sa machine est libéré en GPL est un pas intéressant, mais en même temps rien n'empechait une société de faire son compilateur ou sa machine virtuelle (si: l'argent et le temps).

  --
  "Nobody expects the spanish inquisition"

  • [+] [^]Re: Ok...

    Posté par enzodegap () le 13/11/2006 à 12:30. (lien). Évalué à -2.

    est-ce le fameux "y'a qu'à" dont tu parles ?
    
    si c'était si facile GJC nous permettrait depuis longtemps de nous passer d'une machine virtuelle.

    • [^]Re: Ok...

      Posté par Stéphane TRAUMAT (page perso, ) le 13/11/2006 à 12:32. (lien). Évalué à 1.

      beh oui... il y a qu'à... bea a fait la sienne !

      • [^]Re: Ok...

        Posté par duf (Jabber id, ) le 14/11/2006 à 02:17. (lien). Évalué à 2.

        Et le moins que l'on puisse dire, c'est que la jrockit est plutot performante. Certes des fois moins stable par défaut qu'une sun, mais en général plus performante. En tout cas c'est ce que j'ai pu tester sur différentes applications avec l'outil LoadRunner. Bon tout ça est proprio mais on fait le métier qu'on peu ;-)

      [^]Re: Ok...

      Posté par golum () le 13/11/2006 à 13:21. (lien). Évalué à 3.

      A ce propos
      http://www.lemondeinformatique.fr/actualites/lire-java-open-(...)

      [^]Re: Ok...

      Posté par hophophop () le 13/11/2006 à 17:43. (lien). Évalué à 3.

      toujours pas compris l'interet de gcj pour un langage dont l'une des caracteristiques et atout majeur est justement le byte code...
      
      Un peu comme si quelqu'un faisait une VM pour executer du code c++ compile...

      • [^]Re: Ok...

        Posté par lambada () le 13/11/2006 à 18:17. (lien). Évalué à 6.

        >Un peu comme si quelqu'un faisait une VM pour executer du code
        >c++ compile...
        
        http://llvm.org ?
        
        (compilé certes mais pas en natif, plus toute les possibilités d'optimisations à l'exécution)

    [^]Re: Ok...

    Posté par klessou (Jabber id, ) le 13/11/2006 à 14:53. (lien). Évalué à 2.

    mais les specs déjà sont libres

    
    Les specs sont peut être déjà libre mais seul Sun (et son réseau de partenaires : IBM, SAP, Apache, Jboss, ...) pouvait implémenté de nouvelles fonctionnalité à Java.
    
    Un JSR (Java Specification Request) doit obligatoirement :
    - implémenter complétement les spécifications,
    - ne pas ajouter ni supprimer no modifier quelque choses dans les packages définis par la spécification
    - passer les tests de compatibilité

    --
    Logiciel Libre à Telecom Lille 1

    • [^]Re: Ok...

      Posté par kadreg (page perso, ) le 13/11/2006 à 15:06. (lien). Évalué à 3.

      tu veux donc dire que que les développeurs du libres sont incapables d'implémenter correctement et complétement des specs ?

      • [^]Re: Ok...

        Posté par Yusei (page perso, ) le 13/11/2006 à 15:08. (lien). Évalué à 4.

        Je crois qu'il veut dire que si tu ajoutais un truc à Java, tu ne pouvais plus l'appeler "Java". Je ne pense pas que ça va changer avec la libération du code source, d'ailleurs.

        • [^]Re: Ok...

          Posté par hophophop () le 13/11/2006 à 17:45. (lien). Évalué à 3.

          si on s'en refere a l'article de boubou, en fait une fois la certif Java obtenue, tu peux diverger de la specif officielle.
          
          Par contre t'as pas le droit de diffuser avant d'avoir eu la certif, et du coup c'est relativement incompatible avec un developpement ouvert.
          
          toujours selon ce meme article (et non, pas lu la mise a jour parue recemment, les linux mag sont trop cher pour moi, desole)
          
          'fin c'est pas comme si sun avait deja emmerde un projet java open source.

      [^]Re: Ok...

      Posté par Christophe Merlet (page perso, ) le 13/11/2006 à 15:08. (lien). Évalué à 5.

      > Les specs sont peut être déjà libre mais seul Sun (et son réseau de partenaires : IBM, SAP, Apache, Jboss, ...) pouvait implémenté de nouvelles fonctionnalité à Java.
      
      Ou est le problème ???
      
      De la meme manière qu'il y a des spécifications pour le C, le C++, Python, Perl, etc...
      
      Dans tous les projets sans exception il y a un groupe, un comité qui décide de l'évolution du projet.
      Dans le cas de Java en quoi ça t'interdit de créer des nouvelles classes ? en quoi ça t'interdit de forker les specs de la JVM, a part le fait de ne plus appeler ça Java ?
      
      
      Faut arreter d'être ridicule !

      • [^]Re: Ok...

        Posté par klessou (Jabber id, ) le 13/11/2006 à 15:58. (lien). Évalué à 2.

        Ou est le problème ???

        
        - On réduit l'inovation possible à un groupe d'entreprise.
        - Toute diffusion d'une version incomplète d'une JSR ou qui ne passe pas le test (TCK) est potentiellement illegale.
        - Toute publication d'une implémentation libre qui ne passe pas le TCK est donc interdite.
        
        L'analyse de RMS : http://www.gnu.org/philosophy/java-trap.html
        
        Pour le passage en licence GPL change quand même pas mal le problème.
        
        

        De la meme manière qu'il y a des spécifications pour le C, le C++, Python, Perl, etc...

        
        Des spécifications qu'on peut "forker" sans tomber dans l'illégalité.
        
        

        Dans tous les projets sans exception il y a un groupe, un comité qui décide de l'évolution du projet.

        
        C'est une "vérité vrai". ;-)
        
        

        Dans le cas de Java en quoi ça t'interdit de créer des nouvelles classes ?

        
        Rien ne te l'interdit quand tu ne l'implémentes pas dans "java".
        
        

        en quoi ça t'interdit de forker les specs de la JVM, a part le fait de ne plus appeler ça Java ?

        
        
        Toute implémentation d'un JSR risque de violer des brevets des brevets, il faut donc obtenir une licence (contenu dans celle ou on accepte les spécifications).
        
        Sun possède actuellement 90 brevets mentionnant java mais (contrairement à .NET), il est clairement spécifié qu'il est permis réaliser une implémentation (qui respecte le JSR).
        
        
        Mais maintenant que Java est libre, JE dis "merci beaucoup" SUN et bravo ! (car même avant je ne crachait pas du tout sur JAVA, ... bien au contraire)
        
        PS : J'ai longement hésiter avant de parler au présent :-D

        --
        Logiciel Libre à Telecom Lille 1

        • [^]Re: Ok...

          Posté par briaeros007 () le 18/11/2006 à 10:18. (lien). Évalué à 5.

          c'est pas tout a fait vrai.
          Si tu implémente un compilo qui comprend des tas de trucs , mais qui implémente que la moitié de la norme c++, faut etre de mauvaise foi pour l'appeler 'compilo c++' (mais ca arrive).
          
          ensuite rien n'interdis de créer de nouvelles classes/API... du moment qu'elle ne soit pas dans java. mais par exemple gnu. .
          
          De toute facon , classiquement, il est inintéressant de modifier le langage en lui même , pour de simple raison de portabilité de code. Si tu veux modifier le langage, il faut mieux alors le forker.
          
          Enfin cela a été établis non pas pour etre méchant avec la communauté du libre (je crois que sun a plus grand chose a prouver de ce coté la), mais bel et bien pour empecher ms d'implémenter une vm et/ou un compilo pas totalement compatible pour tuer ce langage. Et ma foi ils ont eu gain de cause vu que ms a bien essayer de le faire, mais n'a pas pu l'appeler jvm.

          --
          Subete ga wakatta toki…watashi ga anta wo korosu.

  [^]Re: Ok...

  Posté par dev_nexen () le 13/11/2006 à 15:31. (lien). Évalué à 0.

  J avoue avoir du mal à comprendre mon moinssage j ai dit une connerie grosse comme le monde ??
  
  Teuz a bien compris c est effectivement de plateforme matérielle dont je parlais voilà ...

  • [^]Re: Ok...

    Posté par Mark Havel () le 13/11/2006 à 16:17. (lien). Évalué à 5.

    Si moinssage il y a eu, c'est certainement pour la partie "j'aurais préféré que ça ne vienne pas d'une vilaine entreprise capitaliste impérialiste exploitatrice du peuple".

  [+] [^]Re: Ok...

  Posté par finesse2600 () le 13/11/2006 à 17:40. (lien). Évalué à -6.

  Je constate que les seuls projets viables sont ceux soutenus par des sociétés et/ou par des chercheurs car ceux-ci applique de bonnes méthodes de dévellopement logiciel à leur projets à contrario des projets 100% communautaires où tt le monde peut coder avec ses habitudes.
  En devellopement logiciel l'important n'est pas le code mais l'architecture que l'on a pensé dés le début du projet avant de commençer à taper du code bêtement.
  Le cycle en V c pas pour les chiens.

  • [^]Re: Ok...

    Posté par Pierre Jarillon (page perso, ) le 13/11/2006 à 21:26. (lien). Évalué à 10.

    Le cycle en V est une méthode qui ne fonctionne que lorsque l'on fait une boite noire où tous les signaux entrants et sortants sont parfaitement définis. Mais quand une interface dépend d'un humain, l'expérience montre que ça conduit à bien des déboires. La cause, elle est simple : Le cycle en V permet de vérifier que le produit livré est conforme aux spécifications mais il n'existe aucune méthode pour vérifier que les spécifications correspondaient aux besoins qui ont la fâcheuse manie d'évoluer. De plus il n'existe aucune méthode pour spécifier la faculté d'adaptation aux évolutions du logiciel après réception. Parfois, il faut tout refaire.
    Les normes de Qualité sont issues du monde du hardware où l'on ne doit faire que ce qui est strictement défini. Elles s'appliquent bien au logiciel embarqué mais très mal quand ce n'est pas le cas.
    
    Le cycle en V présume que les spécifications sont exactes et exhaustives, ce n'est jamais le cas quand un humain interfère avec le logiciel.

    • [^]Re: Ok...

      Posté par pvincent () le 14/11/2006 à 08:16. (lien). Évalué à 1.

      Comme alternative au cycle en V, il y a Extreme Programming.
      
      Eclipse-Java-ExtremeProgramming, ça fonctionne très bien.

  [^]Re: Ok...

  Posté par erik_lallemand (page perso, ) le 13/11/2006 à 18:07. (lien). Évalué à 9.

  dev_nexen a dit : Plutot content meme si il faut rester vigilant et que j aurai préféré ce type de framework vienne vraiment de la communauté et non d une entreprise enfin ne boudons pas notre plaisir...
  
  Ca changerait quoi? Parce que j'ai l'impression que pas mal de gens font encore le maladroit amalgamme entre GPL et "développeurs contributeurs depuis chez eux" et "gratuité". L'argent n'est pas sale, et les entreprises jouent un rôle majeur dans la promotion des logiciels libres. A l'heure où l'industrie mondiale en est rendue à externaliser et sous-traiter la moindre de ses activités, l'intégration, le support et la maintenance informatique sur les logiciels libres sont un aspect essentiel à comprendre qui définira le futur succès des logiciels libres.

  • [^]Re: Ok...

    Posté par Stéphane TRAUMAT (page perso, ) le 13/11/2006 à 19:28. (lien). Évalué à 1.

    Tout à fait d'accord. Ce n'est pas important de savoir qui fait un logiciel libre. L'important est de savoir quelle est la licence et que vaut le logiciel et sa communauté. Qu'il soit maintenu par un groupe de boites ou un groupe d'individus ou un mix des deux, peu importe (à part le fait que ça donne un indice sur le soutien).
    
    Les entreprises, ce n'est pas forcément le mal absolu. On a le droit de gagner de l'argent avec les logiciels libres. Je suis fier de savoir que les développeurs que je paye peuvent développer du logiciel libre et je ne vais pas m'excuser du fait que l'on gagne de l'argent !

    • [+] [^]Re: Ok...

      Posté par dev_nexen () le 13/11/2006 à 22:14. (lien). Évalué à -1.

      C est pas vraiment à cause de ça, c est plus au fait que tout les morceaux de Java n appartiennent pas forcément à Sun, les brevets éventuels/supposés qui pésent dessus ... Mais c est tout de meme une bonne nouvelle ce passage à la GPL c est pas come si j avais dit Javaçapumachinchose... Ici plus ça va, plus t as intéret à avoir un avis polissé et qui rentre dans le moule pour etre plussé ... Ciao

      • [^]Re: Ok...

        Posté par erik_lallemand (page perso, ) le 14/11/2006 à 12:28. (lien). Évalué à 2.

        Ici plus ça va, plus t as intéret à avoir un avis polissé et qui rentre dans le moule pour etre plussé
        En soi, être plussé ne doit pas devenir un but, même si je reconnais que c'est vexant de voir un commentaire sincère se retrouver dans le négatif. Sinon, on n'en est (heureusement) pas encore rendu à mettre des disclaimers partout, mais pour revenir à ton commentaire et ma réponse précédents, il y a une certaine tournure d'esprit qui correspond à chaque licence et ton commentaire moinssé prenait la GPL à rebrousse-poil tout en se réclamant de la GPL. Il ne faut pas chercher plus loin. Les trolls sur Javaçapue, peu de monde (je crois) les prend encore au sérieux...
        
        tout les morceaux de Java n appartiennent pas forcément à Sun, les brevets éventuels/supposés qui pésent dessus
        Là-dessus, je ne crois pas qu'il y ait de souci à se faire. En modèle propriétaire, Sun défendait son beefsteak sur les aspect "brevets". En franchissant le cap du changement de licence, ils ont dû investir pas mal de temps (donc d'argent) dans l'inventaire des propriétés intellectuelles et l'audit du code source pour éviter des déboires juridiques et éventuellement négocier la libération de morceaux propriétaires avec leurs ayant-droit. Enfin, si un auteur se juge lésé de sa propriété intellectuelle à travers l'ouverture de Java, il se retournera contre Sun et celui-ci ou la communauté auront la possibilité de recréer les fonctionnalités pointées du doigt.

        • [^]Re: Ok...

          Posté par briaeros007 () le 18/11/2006 à 10:21. (lien). Évalué à 1.

          Les trolls sur Javaçapue, peu de monde (je crois) les prend encore au sérieux...
          Dis ca a mon ordi qui a pas forcément bcp de mémoire :( :( :( java seul ca va, mais une appli java + fx + icedove(thunderbird) je suis pas loin de la swap :(
          (rem c'est pas que la faute de java ;))

          --
          Subete ga wakatta toki…watashi ga anta wo korosu.