Comparé aux autres ?

• [+] [^]Re: Comparé aux autres ?

  Posté par Gniarf () le 24/05/2004 à 18:16. (lien). Évalué à -1.

  la JVM peut facilement être assimilée à un plugin propriétaire.

  --
  Windows has no users. It has hostages.

  • [^]Re: Comparé aux autres ?

    Posté par Stéphane TRAUMAT (page perso, ) le 24/05/2004 à 20:32. (lien). Évalué à 3.

    N'importe quoi.... ce n'est pas un plugin et certaines JVM sont libres...
    Donc assimilé n'est pas un mot qui convient du tout.

    • [^]Re: Comparé aux autres ?

      Posté par Gniarf () le 24/05/2004 à 22:16. (lien). Évalué à 2.

      si, mais il faut réfléchir un tout petit peu.
      
      allez, au pif : les classes java de base, ce qui fait le fichier rt.jar, tout ce qui rentre dans java.* et ceci inclut java2d aka Swing, les JFC, c'est libre ? c'est utilisable sans avoir à installer la JVM de Sun et en avoir accepté la licence et les conditions d'emploi ?
      
      oui, des implémentations compatibles au niveau de l'API existent ou sont en projet. mais ce n'est même pas sûr qu'on ait le droit de faire une implémentation libre de Swing/JFC sans devoir respecter certains points comme ne pas fournir de look&feel Windows ou Mac sous *nix, ou de look Apple depuis Windows.
      
      
      je ne dis pas ici que Java c'est mal, je dis juste qu'il y aura les mêmes contraintes, légales sinon techniques, qu'avec .NET et Mono.

      --
      Windows has no users. It has hostages.

      • [^]Re: Comparé aux autres ?

        Posté par Stéphane Brunner () le 25/05/2004 à 06:19. (lien). Évalué à 0.

        Pourquoi fournir un Look and Feed Windows ou Mac sous Linux ?
        Cela ne fait partie de l'API standard !
        Je ne vois donc pas le problème.

      • [^]Re: Comparé aux autres ?

        Posté par Nicolas Delsaux (page perso, ) le 25/05/2004 à 07:27. (lien). Évalué à 2.

        si, mais il faut réfléchir un tout petit peu.
        Oui, réfléchissons ensemble, encore une fois, sur le fait que le langage Java peut être utilisé dans un environnement libre.
        
        allez, au pif : les classes java de base, ce qui fait le fichier rt.jar, tout ce qui rentre dans java.* et ceci inclut java2d aka Swing, les JFC, c'est libre ?
        
        C'est défini intégralement par le Java Community Process (JCP) qui est une instance distincte de Sun. Celui-ci définit pour les versions à venir du langage et de la plateforme Java le contenu et la manière dont ce sera réalisé. N'importe qui peut se présenter pour participer à des JSR (Java specif... je-sais-plus-quoi). Ces JSR définissent chacune une fonctionnalité qui sera intégrée dans la prochaine version de la JVM. Par exemple, les JSR de Java 1.5 (que j'appelerais personnellement Java3) définissent la généricité (argl), les annotations (un truc formidablement génial) l'autoboxing des types primitifs (on se demande pourquoi ça arrive seulement maintenant), j'en passe et des meilleures.
        Une fois les JSR adoptées, les fournisseurs de JVM divers (dont fait partie Sun) doivent implémenter celles-ci pour se voir reconnus fabricants de JVM.
        
        c'est utilisable sans avoir à installer la JVM de Sun et en avoir accepté la licence et les conditions d'emploi ?
        
        Oui, grâce aux JVM libres, ou en utilisant une JVM d'un autre fabricant de Logiciel (BEA, IBM)
        
        oui, des implémentations compatibles au niveau de l'API existent ou sont en projet. mais ce n'est même pas sûr qu'on ait le droit de faire une implémentation libre de Swing/JFC
        
        Bien sûr que si, ces classes sont une partie des APIs Java. En tant que telles, si les implémentations fournies dans la JVM sont la propriété de Sun, on est toutefois libre d'en faire d'autres.
        
        sans devoir respecter certains points comme ne pas fournir de look&feel Windows ou Mac sous *nix, ou de look Apple depuis Windows.
        
        Tu dis quand même un peu n'importe quoi. Les restrictions de look'n'feel ne sont pas le fait de Sun, mais de Microsoft et d'Apple qui ne souhaitent pas (ce que je peux comprendre) voir leur travail utilisé sans leur accord sur un système d'exploitation concurrent.
        De la même manière, le fait que le look'n'feel Metal ne soit pas utilisable ne me dérange plas plus que ça.
        
        je ne dis pas ici que Java c'est mal, je dis juste qu'il y aura les mêmes contraintes, légales sinon techniques, qu'avec .NET et Mono.
        
        Pas du tout.

        --
        "Putain, mais quelle fichue imagination je peux avoir ! ..."
        John Brunner - Tous à Zanzibar

        • [^]Re: Comparé aux autres ?

          Posté par Gniarf () le 25/05/2004 à 15:59. (lien). Évalué à 2.

          je connais le JCP, et les JSR, merci. inutile de dire que ça ne concerne que les versions récentes et futures de Java. (1.4 et au delà, à vue de nez).
          
          mon point est qu'il n'est pas possible d'utiliser des JVMs libres avec les fichiers rt.jar de Sun ou d'autres JVMs sans respecter la licence de ces dernieres, en recopiant simplement les bons fichiers comme certains media players le font pour utiliser des codecs propriétaires.
          
          
          >> sans devoir respecter certains points comme ne pas fournir de
          >> look&feel Windows ou Mac sous *nix, ou de look Apple depuis
          >> Windows.
          
          > Tu dis quand même un peu n'importe quoi. Les restrictions de
          > look'n'feel ne sont pas le fait de Sun, mais de Microsoft et d'Apple
          > qui ne souhaitent pas (ce que je peux comprendre) voir leur
          > travail utilisé sans leur accord sur un système d'exploitation
          > concurrent.
          
          euh, si. ce n'est pas Apple ou Microsoft qui codent et distribuent les JVMs de Sun, c'est Sun.
          
          
          J'ai personnellement discuté en 1999 avec un des gus de la Swing Team à ce sujet, sur le thème "les loupes sont moches" (pour les JTree de l'époque) alors que des triangles étaient envisagés, puis furent abandonnés. il m'a explicitement dit que c'était le service juridique de Sun qui a décidé ça pour éviter les ennuis, ces triangles étant "ceux" du Mac OS de l'époque.
          
          mais avec le bon argument -Dqqchose=1 en ligne de commande, on pouvait faire apparaitre une application Swing avec un look Windows ou Mac OS sous Solaris. ce n'était pas un problème technique, juste de propriété intellectuelle et morale sur le look&feel d'une plateforme, on va dire.
          
          
          bref. je maintiens que, pour Mono/.NET comme pour Java, un gros interet pour le développeur est la bibliothèque de code existant, et que ce qui est actuellement disponible n'est pas forcément libre ou utilisable sans aucun danger à long terme.

          --
          Windows has no users. It has hostages.

• [^]Re: Comparé aux autres ?

  Posté par lorill (page perso, ) le 24/05/2004 à 19:06. (lien). Évalué à 3.

  je suppose que ca depends de votre besoin... cette page peut donner des pistes, mais elle est pas complete (si vous avez des infos supplémentaires, je suis preneur) :
  
  http://www.lucane.org/FR/groupware/documentation/general/comparison(...)
  
  en gros ce qu'il en ressort :
  * pour mail/calendrier/choses a faire, si tu as des besoins poussés (délégation, etc...), sans doute que kolab & OGo font mieux l'affaire.
  
  * pour le reste, les autres font simplement l'impasse, donc on doit sans doute faire mieux ;)
  
  par exemple, la on est en train de bosser sur le dessin partagé, et c'est typiquement un truc que tu trouveras pas dans OGo.

  • [^]Re: Comparé aux autres ?

    Posté par PsychoFox () le 25/05/2004 à 06:53. (lien). Évalué à 2.

    je vois dans cette page que le carnet d'adresse est marqué "planifié" pour Lucane, ça veut dire qu'il n'y a pas encore de carnet d'adresse centralisé ? c'est plutôt rédhibitoire pour l'instant non ?

    • [^]Re: Comparé aux autres ?

      Posté par lorill (page perso, ) le 25/05/2004 à 07:13. (lien). Évalué à 1.

      c'est de la que vient le "ca depends des besoins" ;)
      par exemple kolab n'a pas de messagerie instantanée, ni de forum, ni de partage de fichiers (reprennez moi si je me plante, ca me semble gros quand même, ca).
      
      Je veux pas défendre mon bout de gras a tout prix, c'est juste qu'on a pas les mêmes critères de sélections, si tu as un grand besoin de carnet d'adresse, laisse tomber lucane pour le moment...

• [^]Une alternative à venir peut être ...

  Posté par Maillequeule () le 24/05/2004 à 20:48. (lien). Évalué à 5.

  Un client libre, multiplateforme pour Kolab (et OGo à venir) : Aethera
  http://www.atolcd.com/article147.html(...)
  
  M

et pour les particuliers ?

• [^]Re: et pour les particuliers ?

  Posté par Staz (Jabber id, ) le 25/05/2004 à 17:40. (lien). Évalué à 0.

  et qui fait le café ? ;)
  
  sérieusement je vois pas comment tu peux faire la synchro avec un palm depuis une page web o.O
  
  enfin faudra d'abord que ca existe et puis après tu pourras esperer que quelqu'un en propose l'hebergement

  • [^]Re: et pour les particuliers ?

    Posté par Jeremy Monnet (page perso, ) le 26/05/2004 à 09:57. (lien). Évalué à 1.

    En fait pas avec du "web-php", mais avec des serveurs d'applis genre tomcat ou jboss si. Mais il faut au moins un navigateur avec java .... :(

    • [^]Re: et pour les particuliers ?

      Posté par lorill (page perso, ) le 26/05/2004 à 10:14. (lien). Évalué à 1.

      euh, j'ai du mal a voir le rapport entre la technologie utilisée sur le serveur et le fait de se connecter a un palm coté client, c'est normal ?

      • [^]Re: et pour les particuliers ?

        Posté par Jeremy Monnet (page perso, ) le 26/05/2004 à 20:54. (lien). Évalué à 1.

        En fait le principe est qu'avec les servers d'appli, ton navigateur (grace au java) se comporte comme une interface de logiciel, et peut communiquer avec ton matériel par exemple, alors que le javascript, ou toutes les technologies "coté server" en sont incapables.
        
        Le server d'appli, ca sert a centraliser le traitement, mais aussi a offrir plus de possibilités au client. Exemple : menu contextuel de l'appli alors que tu es dans un navigateur web, au lieu du "afficher la source" tu peux avoir un "palm synchro".
        
        A noter qu'on peux rajouter du java a petite dose meme quand c'est un groupware (par exemple) en php, mais ca reste sporadique.

[+] je répète