IBM demande à Sun de "libérer" Java

Posté par matli le 26 février 2004 à 18:02. Modéré par Nÿco.

Étiquettes : aucune

fév.

2004

Rob Smith, le vice-président du département "technologies émergentes" d'IBM, a proposé à Sun de travailler à la création d'un projet de type Open Source pour encadrer le développement de la plate-forme Java. Celui-ci signale notamment que le passage en Open Source de Java accélèrerait notablement l'adoption de celui-ci.
IBM "presse" Sun depuis quelques années pour libérer Java, et ils reviennent à la charge suite à une récente position plus "pro-libre" de Sun qui est toujours hésitant sur la question.

Mise à jour : LinuxToday publie une analyse plus détaillée (et elle retrace les déclarations de Scott McNealy "The open-source model is our friend" puis la lettre ouverte d'Eric Raymond (ESR) et le follow-up par Simon Phipps) IBM propose que Sun, IBM et d'autres déterminent quelles parties devraient passer en libre (JRE, bibliothèques) afin de créer une version Open Source officielle de Java. On voit ici une démarche assez similaire à celle de la plate-forme Eclipse: un socle libre commun sur lequel chaque éditeur peut ajouter ses propres extensions.

Aller plus loin

L'article sur Silicon.com (1 clic)
LinuxToday : " Community: Beyond an Open Source Java " (1 clic)

# Re: IBM demande à Sun de "libérer" Java

Posté par Pascal Terjan (site web personnel) le 26 février 2004 à 12:44. Évalué à 2.

Le DNS a l'air de foirer donc :
212.187.242.215 www.silicon.com
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par Nap le 26 février 2004 à 13:24. Évalué à 7.
  
  c'est quand même triste de gacher un first post comme ça, avec l'armée de trolls qui attend derrière cette ---> []
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Julien Bidault le 26 février 2004 à 20:10. Évalué à 2.
    
    ouhais, ben l'armée de trolls est arrivée...
    
    Franchement, je sais même pas pourquoi je lis les commentaires sur les topic java, ca part tjs en vrille...
    
    Le plus amusant étant bien souvent la méconnaissance totale que la plupart des gens ont des versions récentes de Java...
    
    C'est un langage qui a une vrai utilité, ais faudrait peut etre se prendre une JVM récente, Eclipse, pis coder un peu au lieu de troller betement...vous découvririez un langage très intéressant...dont la partie J2EE est très très intéressante (cf les offres de stage, lisez c édifiant...), une très bonne interopérabilité avec le PHP et les bases de données via JDBC en font en langage orienté web très sympa...
    
    Pis soyez pas intransigeants : Java est ***BEAUCOUP*** plus jeune que C/C++, et a donc encore le temps de murir...
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Pierre Jarillon (site web personnel) le 26 février 2004 à 21:17. Évalué à 2.
      
      // Voila le résumé de la situation :
      
      while ( licence("JAVA") != Libre )
      {
      java.status= PasMur;
      Demander_a(Sun);
      }
      java.status= Mur;
      
      // on est toujours dans la boucle !
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par free2.org le 27 février 2004 à 04:50. Évalué à 1.
        
        C'est le même genre de situation pour de nombreux logiciels non libres !
        Ce qui est particulier c'est que un Java encore non libre sert de base à de nombreux projets libres.
# Re: IBM demande à Sun de "libérer" Java

Posté par troll hunter le 26 février 2004 à 12:51. Évalué à -5.

Chouette un super coin pour la chasse au Troll.
AU fait, JAVA, ça à quoi comme avantge par rapport aux autres langages?
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par LupusMic (site web personnel, Mastodon) le 26 février 2004 à 12:56. Évalué à -1.
  
  Ben, il n'y a pas de pointeurs.
  Tu peux fermer ton code tout en restant multi-plateforme.
  Tout est objet (même les types de base, me semble-t-il ?).
  Tu ne peux déclarrer qu'une classe par module, ce qui t'oblige à un découpage méticuleux.
  
  Doit y en avoir d'autre...
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Pascal Terjan (site web personnel) le 26 février 2004 à 13:06. Évalué à 3.
    
    Tout est objet (même les types de base, me semble-t-il ?).
    Non justement, pas les types de base.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Cédric Chantepie le 26 février 2004 à 13:42. Évalué à 0.
      
      En fait si, tous les types de base sont en objet mais en partique manipulable également par des type primitifs, ex. int pour java.lang.Integer, char pour java.lang.Charater.
      
      Exception pour String qui n'est qu'en objet.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Pascal Terjan (site web personnel) le 26 février 2004 à 13:55. Évalué à 3.
        
        "en partique manipulable également"
        Si tu pouvais mettre une constante int dans un Vector ca serait cool
        Si tu pouvais facilement faire un switch sur des Integer (la val mais aussi chaque case prendre une constante Integer, vu qu'on avait besoin d'un Integer pour avoir un objet) ca serait cool aussi
        
        Perso je prefere franchement le Ruby ou au moins _tout_ est un objet.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par franck (site web personnel) le 26 février 2004 à 13:57. Évalué à 1.
        
        java 1.5 est fait pour toi ...
        
        Vector monVector = new Vector();
        monVector.add(42);
        
        ... vivement demain .... :-)
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 14:02. Évalué à 2.
        
        Ouai, sauf que la spec indique précisément que le 42 en question est placé dans un objet Integer avant d'être mis dans le Vector (d'ailleurs, il ne faut plus utiliser Vector depuis le 1.2, mais bon). Donc au niveau syntaxique, c'est sympa, mais au niveau perf...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par spell (site web personnel) le 26 février 2004 à 14:49. Évalué à 1.
        
        > d'ailleurs, il ne faut plus utiliser Vector depuis le 1.2, mais bon
        
        Hein quoi ? pourquoi tu dis ça ?
        C'est pas "deprecated" le Vector ?
        Je veux bien un lien ou une explication stp
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 14:57. Évalué à 1.
        
        Vector est avantageusement remplacé par les List, en version ArrayList. Vector est synchronized (thread safe) ce qui la rend lente comparée à ArrayList quand on n'a justement pas besoin de l'aspect synchronized.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par allcolor (site web personnel) le 26 février 2004 à 16:34. Évalué à 1.
        
        Euh un vector est une List, c'est juste une List(l'interface) synchronizée, mais tu peux tjrs utiliser vector.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 16:39. Évalué à 2.
        
        Oui, tu peux, mais c'est moins efficace.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Jean-Marc Spaggiari le 26 février 2004 à 17:38. Évalué à 1.
        
        Mais dans un fonctionnement multi-thread, ca peut etre un peu plus sur... Non?
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gabriel le 26 février 2004 à 17:56. Évalué à 1.
        
        ...mais ça ne sert à rien si tu fais de la lecture simple.
        Possible à utiliser : les bag de chez apache Commons fastArray et autre...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Nicolas le 26 février 2004 à 20:12. Évalué à 1.
        
        > Mais dans un fonctionnement multi-thread, ca peut etre un peu plus
        > sur... Non?
        
        Oui, mais un bon programmeur s'en charge lui-même et synchronise à un niveau supérieur, là où c'est nécessaire pour son application. C'est plus rapide de synchroniser un bloc dans ta classe, où tu accèdes à la liste, que de synchroniser deux fois - dans ton bloc ET dans la liste.
        
        Un Vector, oui, c'est plus sûr, mais tu ne devrais pratiquement pas avoir besoin de sa synchronisation. Si tu ne veux pas prendre de chances, ok, mais un Collections.synchronizedList(new ArrayList(...)) fait tout aussi bien l'affaire.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Cook Captain le 26 février 2004 à 15:14. Évalué à 1.
        
        A partir du moment ou tu souhaites considérer les types de base comme des objets, il faut accepter une perte de perf et ça quelque soit le langage. Après le compilateur peut essayer de faire qq optimisations mais ça doit pas toujours être évident.
        
        Dans ton cas, tu peux toujours utiliser des listes qui manipulent des types primitifs pour optimiser les perfs, il en existe pléthore. en java (cf. apache.org).
        
        Comme souvent, c'est un compromis en perf et facilité/généricité.
        
        Nb. Rien à voir avec post en cours.
        Je suis toujours surpris du nombre de trolls déclenché par le mot Java sur le dlfp. Quelqu'un aurait-il une explication? Le geek linux ne parle-t-il que le C, et accessoirement le Perl?
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 15:30. Évalué à 1.
        
        A partir du moment ou tu souhaites considérer les types de base comme des objets, il faut accepter une perte de perf et ça quelque soit le langage.
        
        C'est faux. Eiffel et Sather considèrent les types de base comme objet sans perte de performance. Pour ce faire, il faut distinguer deux catégories d'objets (comme en C#), ces objets passés par référence et des objets passés par valeurs. Les types de base sont des objets passés par valeur, ce qui élimine les problèmes d'occupation mémoire et d'efficacité induit par l'autoboxing.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Cook Captain le 26 février 2004 à 16:09. Évalué à 2.
        
        Un objet même passé par valeur reste de toute manière beaucoup plus lent qu'un vrai type primitif "mappable" directement sur l'architecture de données du processeur.
        
        Ceci dit c'est effectivement un domaine ou j'aimerais bien que Java évolue, cela permettrait d'améliorer les perfs de qq softs de manière notable au détriment, malheureusement, d'une complication du langage.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 16:41. Évalué à 2.
        
        Un objet même passé par valeur reste de toute manière beaucoup plus lent qu'un vrai type primitif "mappable" directement sur l'architecture de données du processeur.
        
        Non, les tests de Sather et Eiffel prouvent le contraire. Un objet passé par valeur ne supporte pas l'héritage, il n'y a donc pas de table de méthodes "virtuelles" à la C++. Un int Eiffel est un objet, mais il est manipulé comme un int natif dans le code engendré.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Matthieu Moy (site web personnel) le 26 février 2004 à 16:14. Évalué à 3.
        
        Le problème, c'est qu'en Java, tout objet hérite de java.lang.Object, qui contient déjà pas mal de bazard : Une info de typage dynamique, des verrous pour les éventuels "synchronized", ...
        
        Résultat, un Integer en Java occupe entre 20 et 30 octets, alors qu'en principe, c'est seulement 4 !
        
        Si tu les passe par valeur, il faut tout recopier à chaque fois, si tu passe par référence, il y a une indirection de plus a chaque accès. Pas trop de compromis possible là dessus.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 26 février 2004 à 16:26. Évalué à 1.
        
        si tu passe par référence, il y a une indirection de plus
        Le cout perdu a l'indirection est extremement faible dans une grosse appli.
        
        Je me rappele encore mes profs me repeter qu'il ne sert a rien de se battre sur ce genre d'optimisations et d'essayer plutot d'optimiser l'algo lui meme.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 16:49. Évalué à 3.
        
        Tes profs sont des cons. Le coût perdu par l'indirection en Java est énorme car il participe de la mauvaise gestion de la mémoire des applis Java. Tout objet en Java est manipulé par référence. Oui, l'indirection elle-même ne coûte pas grand chose pour un objet. Mais quand tu scannes un tableau d'objets, tu n'as plus de localité en mémoire et ça peut donner des résultats catastrophiques à cause des accès "random" à la mémoire qui ne profitent pas du tout du cache. Un exemple : produit matriciel programmé en tenant compte de la localité du stockage peut être 100 fois plus rapide que le même produit matriciel programmé à la grand père, en ne tenant pas compte de la localité. Sur des tableaux d'objets, on obtient le même genre de perfs...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 26 février 2004 à 17:07. Évalué à 1.
        
        Arrete c'est bon, tu prends justement l'exemple qui evidement contredit ce que je venais de dire. Si tu savais lire tu verrai que je parlais d'une appli et pas d'un algo particulier.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Jean-Marc Spaggiari le 26 février 2004 à 17:41. Évalué à 2.
        
        C'est le principe. Il faut toujours adapter la structure de données à l'algo qu'on utilise. Effectivement, on pourra toujours, dans tous les langages, faire un tres bon algo qui va tres mal fonctionner à cause des données mal présentées, et faire des données super bien présentées qui sont mal traitées à cause de l'algo de merde...
        
        Bref, en gros, discution stérile.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 26 février 2004 à 17:43. Évalué à 1.
        
        C'est vrai, mais je parlais pas de ca.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 09:23. Évalué à 1.
        
        Je sais lire la masse de conneries que tu as postées dans cette news. Toutes les applis Java que je connais sont pénalisées par une consommation de mémoire pléthorique. Avec une grosse quantité de mémoire, elles fonctionnent très bien, avec des performances très honorables. D'où vient cette consommation ? Du fait que tous les objets sont manipulés par référence (d'où l'occupation de 4 octets pour chaque objet au minimum) et que Object est bloated pour des raisons de conception.
        
        Le problème de Java est que tu ne peux pas faire autrement : tu ne peux pas manipuler les objets par valeur, même quand ça permet d'économiser de la mémoire et des perfs. Donc, oui l'indirection coûte quelque chose, à la fois en occupation mémoire et en perfs. Mais tu appliques servilement les préceptes de mauvais profs, donc tu ne comprends rien. Dans mes cours, tu aurais des sales notes.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 27 février 2004 à 09:56. Évalué à 1.
        
        Ok, maintenant regarde un peu le code deroulé quand tu utilises Corba, Com, l'overhead des interfaces graphiques et des commandes utilisateurs ... ce n'est pas une indirection sur un objet qui va bouffer tes perfs.
        
        Ton probleme c'est que tu n'as qu'une vue locale de ce que tu developpes. Je suis d'accord avec toi que sur un algo bien precis il faut effectuer ce genre d'optimisation comme pour l'exemple que tu as cite. Mais d'une maniere generale, l'utilisation d'un formalisme de haut niveau tel que la programation distribuée ou par composants, les IHM, permettent un developpement plus rapide et de meilleur qualite au detriment des perfs (indirections, overhead inevitables)
        
        Pour mes profs, je ne prends pas tous leur préceptes a coeur, j'essaie plutot de me construire mon propre avis, et sur ce point la je suis d'accord avec eux car je l'ai mesuré concretement.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 11:40. Évalué à 0.
        
        Ok, maintenant regarde un peu le code deroulé quand tu utilises Corba, Com, l'overhead des interfaces graphiques et des commandes utilisateurs ... ce n'est pas une indirection sur un objet qui va bouffer tes perfs.
        
        Tu ne comprends donc rien. L'indirection obligatoire en Java fait qu'on ne peut pas économiser la mémoire et donc ça bouffe tes perfs même avec des usines à gaz comme Corba ou Swing (qui subissent elles aussi cette contrainte et donc sont encore plus des usines à gaz en Java que dans leur version C++). L'absence de l'équivalent des structs du C# en Java est une catastrophe en terme de performances à cause de la mémoire.
        
        Ton probleme c'est que tu n'as qu'une vue locale de ce que tu developpes. Je suis d'accord avec toi que sur un algo bien precis il faut effectuer ce genre d'optimisation comme pour l'exemple que tu as cite. Mais d'une maniere generale, l'utilisation d'un formalisme de haut niveau tel que la programation distribuée ou par composants, les IHM, permettent un developpement plus rapide et de meilleur qualite au detriment des perfs (indirections, overhead inevitables)
        
        Tu lis O1, c'est ça ? Je me demande comment tu utilises un formalisme de haut niveau alors que tu n'as rien compris à l'objet...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 27 février 2004 à 12:10. Évalué à 0.
        
        Tu ne comprends donc rien. L'indirection obligatoire en Java fait qu'on ne peut pas économiser la mémoire
        Sur ce point je suis d'accord.
        
        Tu lis O1, c'est ça ? Je me demande comment tu utilises un formalisme de haut niveau alors que tu n'as rien compris à l'objet...
        Ba ouai ca doit etre ca... d'ailleur dans la boite ou je suis on est tous abonné a 01.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 27 février 2004 à 09:58. Évalué à 2.
        
        Autre chose, tu es autant intolerant et irrespecteux avec tes eleves ?
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 11:35. Évalué à 1.
        
        Je suis en effet très intolérant avec la connerie et très irrespecteux de celle-ci. Tu l'incarnes ici. Tu arrives dans ce thread et tu multiplies les posts débiles du genre :
        
        - "C++ n'est pas objet car il ne supporte pas le typage dynamique" : n'importe quoi. Une telle déclaration prouve simplement que tu ne connais rien aux langages objets, en particulier certains des plus avancés comme Eiffel ou Objective Caml.
        
        - "Dans un monde objet l'heritage n'a pas vraiment de sens" : désolé, mais là, ce n'est même plus n'importe quoi, c'est tout simplement débile
        
        - "L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet. " : j'ai déjà répondu à ça, mais visiblement tu ne sais pas comment un modèle objet est implémenté (sur le hardware), donc ça ne sert à rien de continuer
        
        - "De toute facon la notion d'objet, a mes yeux, n'est pas dependante du langage mais plutot de la facon dont le developpeur utilise les fonctionnalités du langage utilisé. Elles ne sont la que pour l'aider et formaliser syntaxiquement ce concept." : tu n'as encore rien compris, comme toutes les personnes qui prétendent faire de l'objet en C.
        
        Bon, je m'arrête, ça suffira. Tu démontres pas ces posts que tu parles de choses que tu ne connais pas. Je n'ai aucun respect pour ça (soit dit en passant, tu m'indiques que je ne sais pas lire, ce qui n'est pas très respectueux non plus).
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 27 février 2004 à 12:07. Évalué à 2.
        
        Je persiste, tu ne sais effectivement pas lire, tu viens de sortir des phrases de leur contexte d'une part, et tu as deformé mes propos.
        
        1. Le typage dynamique etait juste un exemple parmi d'autres des concepts objets non implementés par le C++, de plus je n'ai jamais dit que ce n'etait pas objet, tu remarqueras le vrai entre guillemets, mais malheureusement ta "connerie", mot que tu affectionnes particulierement, te fait lire les choses qu'a moitié.
        
        2. Pour l'heritage, reportez vous a l'ensemble de mon post. (C'etait volontairement provocateur)
        
        3. Sur ce point la j'avoue ne pas tout connaitre, d'ailleur je n'ai rien compris a tes reponses. Est-ce volontaire de ta part ? C'est dommage tu sembles avoir sur ce point beaucoup d'experiences.
        
        4. gni ???
        
        En gros je crois avoir saisit le personnage, tu aimes apparement te faire passer pour un pro (ce que tu es certainement, je n'en doute pas). Mais quand tu reponds aux "conneries", pourrais-tu plus souvent justifier ces conneries, car repondre "tu n'as encore rien compris", "ça ne sert à rien de continuer", " c'est tout simplement débile", ... et repondre a des posts de maniere imprecise n'est pas tres constructif.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 27 février 2004 à 12:37. Évalué à 3.
        
        Dans mes cours, tu aurais des sales notes.
        
        On dirait Tanenbaum.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 16:45. Évalué à 2.
        
        Je suis d'accord, le problème essentiel de Java est son occupation mémoire causée par les un java.lang.Object complètement bloated. Ceci étant, ce n'est pas une fatalité :
        
        1) il existe des techniques pour virer le verrou nécessaire au synchronized. C'est implémenté dans SableVM (http://www.sablevm.org/(...)).
        
        2) des langages objets plus vieux de Java (Eiffel et Sather) ont une notion d'objets passés par valeur (et uniquement par valeur) qui ressemblent aux structs du C et qui permettent de régler le problème poser par Integer. Comme le typage devient 100% statique avec ces objets, on peut s'arranger pour qu'ils occupent exactement la place mémoire nécessaire. Pour les petits objets type Integer, ou nombre complexe, c'est la fête.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Nicolas le 26 février 2004 à 20:19. Évalué à 1.
        
        C'est très rare que c'est nécessaire de passer un Integer par valeur (clôné). Un Integer ne se modifie pas, une fois qu'il est instancié, alors tu ne devrais pas avoir peur qu'il soit changé par un autre thread.
        
        La seule situation où clôner un Integer peut être souhaitable, est si tu synchronises dessus. Mais encore là, ça dépend beaucoup du contexte, et je ne crois pas que ça arrive souvent.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Pierre Jarillon (site web personnel) le 26 février 2004 à 16:29. Évalué à 1.
        
        Je suis toujours surpris du nombre de trolls déclenché par le mot Java sur le dlfp
        
        Je pense que c'est essentiellement parce que Java n'est pas libre. S'il l'était, il aurait eu un développement bien plus important car Java est potentiellement très intéressant. L'attitude de Sun est frileuse et fait qu'un utilisateur de Java ressent toujours l'épée de Damoclès au dessus de sa tête.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Tutur le 26 février 2004 à 16:41. Évalué à -4.
        
        Non, le probléme, c'est que Java est présenté comme le langage ultime, celui qui sert à tout. Alors que le probléme, c'est que dans tout les domaines, il existe un langage qui est plus efficace que Java.
        Au début, il a été utilisé comme un langage pour le web, puis php et companie se sont révelé plus éfficace. Depuis, il n'a pas retrouvé de place.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Nelis (site web personnel) le 26 février 2004 à 16:47. Évalué à 2.
        
        Au début, il a été utilisé comme un langage pour le web, puis php et companie se sont révelé plus éfficace.
        
        :-) LOL
        
        On voit que tu connais le domaine !!
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par plagiats le 26 février 2004 à 19:17. Évalué à 1.
        
        faut l'excuser le pauvre il a confondu java et javascript :D
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Christophe Merlet (site web personnel) le 26 février 2004 à 19:51. Évalué à 3.
        
        Pas sûr, il pensait peut être aux applets Java. Mais même dans ce cas, PHP ne remplace pas les applets Java...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Tutur le 27 février 2004 à 11:09. Évalué à 1.
        
        En effet, j'ai fait une erreur, c'est plutôt le flash qui à remplacer les applets Java. Enfin, ça fait un moment que j'ai plus vue d'applets Java.
        Puis au lieu de moinsser, dite moi plutôt dans quel domaine java est meilleur qu'un autre langage.
        Puis tant qu'on y est: Pourquoi dans le mot javascript, y'a java?
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 14:04. Évalué à 2.
        
        Vraiment n'importe quoi. Les types de base ne sont pas des objets, ils sont manipulés par valeur uniquement, n'ont pas de méthode, etc. Il existe effectivement un type objet associé à chaque type de base (genre Integer pour int), mais il a fallut attendre la version 1.5 pour avoir un autoboxing qui simplifie les jonglages entre int et Integer du point de vue syntaxique mais est toujours une horreur du point de vue des perfs.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Nap le 26 février 2004 à 13:09. Évalué à 1.
    
    il te force à gérer les exceptions à la compilation
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Cédric Chantepie le 26 février 2004 à 13:24. Évalué à 3.
      
      Par forcement ya Exception et RuntimeException le tout est de bien chargé en fonction des cas.
      
      EJB Exception Handling :
      http://www-106.ibm.com/developerworks/java/library/j-ejb01283.html(...)
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par arthurr (site web personnel) le 26 février 2004 à 13:01. Évalué à -1.
  
  Je vais aider mais je pense que c'est trop enorme :
  Quel est l'interet de liberer Java puisque Perl est libre ?
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par celastus le 26 février 2004 à 13:24. Évalué à 4.
    
    Java et Perl ont autant de points communs que le basic et le C++, à savoir à peu pres aucun.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Nap le 26 février 2004 à 13:29. Évalué à 3.
      
      beurk t'as marché dedans :(
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Matthieu BENOIST le 26 février 2004 à 14:53. Évalué à -1.
      
      Java et Perl ont autant de points communs que le basic et le C++, à savoir à peu pres aucun.
      
      Java == basic
      Perl == C++
      
      ?
      
      ^^; plus là ! ->[]
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par #3588 le 26 février 2004 à 22:10. Évalué à -1.
      
      « Java et Perl ont autant de points communs que le basic et le C++, à savoir à peu pres aucun. »
      
      Il y en a un des deux que tu ne connais pas. Surtout s'il était question de Perl6.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Yann Forget le 26 février 2004 à 14:58. Évalué à 0.
    
    Moi, je verrais bien Java sous la nouvelle licence XFree et la doc sous GFDL.
    
    Poilu ? Comment ça, poilu ?
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par dcp le 26 février 2004 à 13:12. Évalué à 10.
  AU fait, JAVA, ça à quoi comme avantge par rapport aux autres langages?
  - C'est peut-être le seul langage au monde qui te permet d'avoir la certitude que la totalité de ta mémoire fonctionne bien (tu peux jeter ton memcheck86)
  - Il permet de donner une utilité accrue aux ventilos de ton PC.
  - Par sa rapiditié légendaire, il facilite le débuggage: tu vois arriver le bug bien avant qu'il se produise, et le rectifier avant la catastrophe
  - Il lutte activement contre le chomage et la précarité de l'emploi, en permettant à 10 personnes de se partagaer le projet d'une seule
  A l'attaque!!!!!
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Barthelemy le 26 février 2004 à 13:20. Évalué à 3.
    
    C'est méchant !
    Tu as oublié de préciser qu'il a relancé la demande mondiale de RAM parce qu'en dessous de 256, tu peux oublier des environnement comme Jbuilder
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par 36 75 le 26 février 2004 à 14:20. Évalué à 3.
      
      oui, mais grâce à Java et Websphere Commerce ma machine de dev (au taf) a 1Go de RAM !!!
      Donc moi je dit merci à SUN et à IBM :))
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Jean-Marc Spaggiari le 26 février 2004 à 17:45. Évalué à 2.
      
      Effectivement, JBuilder pour faire du Java, c'est un peu comme OpenOffice pour éditer un script bash...
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Tierre Pramo le 26 février 2004 à 13:27. Évalué à 3.
    
    Il permet de se souvenir des joies de l'optimisation, en ramenant la puissance d'un octoprocesseur Opteron à 8 G(i)B de RAM (sec) à un processeur 386 SX virtuel, mais multiplateformes ! (Comment une machine peut-elle être multiplatormes déjà ? Ah, oui, avec un processeur Java natif ?!)
    
    On doit donc se tuer le cerveau à pratiquer des optimisations dépassées, avec deux contraintes supplémentaires: le faire en orienté objet, et sans les pointeurs.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Franck Yvonnet le 27 février 2004 à 08:17. Évalué à 1.
      
      Ah, oui, avec un processeur Java natif ?!)
      
      Ça fait pas un peu des années que Sun a abandonné le truc ? (un peu comme Oracle avec ses NetPC)
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Matthieu Moy (site web personnel) le 26 février 2004 à 14:20. Évalué à -1.
    
    s/memcheck86/valgrind/
    
    Sauf erreur de ma part, memcheck86, c'est pour vérifier que la mémoire physique est OK, ce qu'aucun language ne peut faire.
    
    Ce n'est surement pas le seul language au monde a garantir ça. La plupart des languages interpretés sont comme ça aussi. Les langages sans pointeurs sont à ma connaissance tous comme ça (Si on fait les tests de débordements de tableau, c'est bon). On peut citer Lisp, C#, BASIC (!), perl je crois, bash, ...
    
    Et dans des langages un minimum défensifs comme Ada, il faut vraiment demander gentilment pour faire des conneries avec la mémoire. Là, ça ne se règle pas à coup de valgrind, mais à coup de "grep" dans le source !
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par boubou (site web personnel) le 26 février 2004 à 14:27. Évalué à 3.
      
      En fait, un truc ultra puissant de Java c'est que les vérifications pour la mémoire se font dynamiquement, à partir du .class. Tu peux charger une application compilée dans une sandbox et l'exécuter en contrôlant parfaitement son exécution en terme de droit d'accès aux ressources de la machine virtuelle. En fait, tu peux charger dans une même machine plusieurs applications et maîtriser parfaitement les communications entre elles. A ma connaissance, seul C# possède des fonctionnalités de ce genre. Les exemples que tu cites sont bons à partir du moment ou on dispose du source. Par contre, quand on produit un code exécutable, on ne peut plus vérifier grand chose sur celui-ci. En Java et en C#, un modèle de sécurité très évolué permet au contraire de contrôler parfaitement l'exécution d'un code compilé. L'aspect mémoire est une petite partie de ces fonctionnalités.
      
      Ceci étant, tu as parfaitement raison pour memcheck86, mais je crois que ton interlocuteur faisait une "petite blague" sur l'utilisation mémoire de Java, un vrai problème...
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par PLuG le 26 février 2004 à 14:27. Évalué à 4.
      
      Tu n'as pas compris c'est bien de memcheck86 dont il parle...
      traduction: java utilise TOUTE ta ram et donc la teste (comme memcheck86).
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gniarf le 26 février 2004 à 20:58. Évalué à 1.
        
        et ça teste à fond ta partition de swap, par le même coup.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Moby-Dik le 26 février 2004 à 14:28. Évalué à 2.
      
      J'ai déjà eu un memory leak avec les exceptions sous Perl (eval / die). Quand ton programme tourne 24h/24 c'est un peu chiant de constater qu'au bout d'une semaine il bouffe 50 Mo de RAM. ;)
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par free2.org le 26 février 2004 à 19:37. Évalué à 3.
        
        la notion de garbage collector est indépendante des langages. il existe des GC pour à peu près tous les langages à commencer par le C
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 09:26. Évalué à 2.
        
        C'est sûr qu'ils sont vachement utilisés en C, il n'y a qu'a regarder dans gnome. Comme le C est intrinsèquement non sûr, on ne peux pas faire un GC parfaitement sûr pour ce langage, de même que pour le C++. Donc désolé, mais pour qu'un GC puisse (au moins en théorie) fonctionner parfaitement, il faut que le langage soit conçu pour.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par #3588 le 27 février 2004 à 15:16. Évalué à 0.
        
        C'est le cas de C++, tu trouveras quelques mots de Stroustrup à ce propos. Évidemment comme toujours, C++ ne l'impose pas, la norme est simplement compatible, des compilateurs pourraient le faire.
        
        Ceci dit, il ne faut pas négliger l'utilisation d'une bibliothèque dédiée, qui propose ses services d'allocation. Et là pas besoin que le langage soit conçu pour tourner avec un GC.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 15:24. Évalué à 1.
        
        Oui, sauf que non. Si tu utilises un GC dans un environement de production, ce n'est pas pour avoir un memory leak. Or, les GC destinés aux langages comme le C ou le C++ ne peuvent pas garantir à 100% qu'il n'y aura pas de memory leak. Tu me diras qu'il y a toujours des bugs dans les GC et donc que du 100%, ça n'existe pas, ce qui n'est pas faux. Sauf que dans la situation présente, ce n'est un bug dans le GC qui est à craindre, mais un problème dans ton code qui fait que le GC ne peut pas désallouer une partie de la mémoire...
        
        Sinon, je t'avoue que la prose de Stroustrup ne m'intéresse absolument pas. Ce brave homme a montré depuis des années qui ne connaissait absolument rien à ce que la recherche a produit dans le domaine des langages de programmation et le résultat est C++, plein de bonne volonté et plein d'erreurs de conception. Ca m'arrache le coeur de l'avouer, mais Microsoft a bien compris le problème et a donc embaucher des gens compétents dans le domaine pour faire C#, et franchement, ça se voit...
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par VACHOR (site web personnel) le 26 février 2004 à 14:26. Évalué à 1.
    
    Contrairement à pas mal de languages de script adorés par tous les boutonneux de service, Java est vraiment un language objet. En plus il est compilable (bytecode et natif). Et il dispose de toutes les fonctionnalités pour une adoption en entreprise, pas seulement pour faire un système "qui marche" dans un coin (activité favorite des boutonneux nommés ci-dessus) mais qui se révèle inutilisable en exploitation.
    Quant aux performances, l'indulgence m'empêche de parler de celles d'un certain language qui porte le nom d'un serpent tropical, et dont les boutonneux sont tombés amoureux, sans doute parce-que le nom leur plait et que ça fait bien de parler d'animaux sauvages plus ou moins dangereux devant les nanas.
    Si l'amour rend aveugle, la branlette rend sourd...
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par deftones_chris le 26 février 2004 à 14:33. Évalué à 1.
      
      qu'est ce que cela aurait donné, si tu avais comparé Java à Ruby (les pierres précieuses aussi ça doit arracher devant les nanas :) )
      
      Heureusement qu'on a dans la partie Troll, sinon je penserais vraiment que ce site est parcouru par des pédants qui se croient supérieurs car ils utilisent tel langage au lieu de tel autre.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par VACHOR (site web personnel) le 26 février 2004 à 14:37. Évalué à 4.
        
        ce site est parcouru par des pédants qui se croient supérieurs car ils utilisent tel langage au lieu de tel autre.
        Je crois bien que c'est le cas malheureusement !
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Moby-Dik le 26 février 2004 à 14:44. Évalué à 2.
        
        sinon je penserais vraiment que ce site est parcouru par des pédants qui se croient supérieurs car ils utilisent tel langage au lieu de tel autre.
        
        Meuh non :-))))))))))))))))))))))))))))
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par HappyPeng le 26 février 2004 à 14:38. Évalué à -3.
      
      Et ne parlons même pas de ceux que ça fait bander d'utiliser un langage au nom également tropical qui rappelle une célèbre île d'Indonésie (ça doit leur rappeller leurs vacances), à la syntaxe verbeuse et souvent inutile mais qui ressemble à des langages célèbres et autrement excellents (ça doit leur faire croire qu'ils savent coder), et supportées par l'un des plus gros géant de l'informatique dans le monde (ça leur fait trouver du boulot, seul point positif, et ça leur fait croire que quand on y met de l'argent c'est bien).
      
      Plus concrètement, vous faites pitié.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par VACHOR (site web personnel) le 26 février 2004 à 18:00. Évalué à -4.
        
        Dans le style commentaire de pauvre cloche, c'est un record !
        
        Aucun commentaire supplémentaire ne s'impose :-))))
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par HappyPeng le 26 février 2004 à 18:35. Évalué à -2.
        
        C'est toujours affligeant de voir que les idiots ne se reconnaissent pas dans les critiques qui sont faites d'eux.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Matthieu BENOIST le 26 février 2004 à 14:58. Évalué à 4.
      
      s/un certain language qui porte le nom d'un serpent tropical/un certain language qui fait réference à une bande de comiques anglais culte/
      
      Ni !
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gabriel le 26 février 2004 à 18:32. Évalué à 0.
        
        Riki riki riki pam pam!
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par #3588 le 26 février 2004 à 22:16. Évalué à -1.
      
      « Contrairement à pas mal de languages de script adorés par tous les boutonneux de service, Java est vraiment un language objet. »
      
      Ce n'est pas un langage objet. Il y a des langages objet, et Java n'en fait pas partie.
      
      Et le pire, c'est que ce langage se veut objet, donc au final : il ne propose pas d'autres types de programmation, et il n'est pas terrible dans celui qu'il prétend être.
      
      Java est apparemment bien adapté aux applications web. Pour toute autre application, on trouve plus adapté (mais évidemment, ça dépend de l'application).
      
      Un avantage quand même : il est pas mal pour l'enseignement.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Moby-Dik le 27 février 2004 à 00:57. Évalué à 3.
        
        Un avantage quand même : il est pas mal pour l'enseignement.
        
        Oui, un manuel de référence Java dans la tronche, ça te calme vite les cancres les plus aguerris.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gabriel le 27 février 2004 à 09:08. Évalué à 1.
        
        ...Mais sur le pied ça te bousille les vacances à la montagne
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par Tierre Pramo le 26 février 2004 à 13:30. Évalué à -6.
  
  Quel intéret par rapport au C++ ?
  
  Même portabilité, et le C++ est plus joli est plus rapide !
  
  Franchement, il y a des c*ns partout.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Cédric Chantepie le 26 février 2004 à 13:39. Évalué à -3.
    
    C'est sur qu'en terme de performances pures C++ est plus puissant mais pas portable en réalité.
    
    Si ton programme C++ dépend d'une lib C++ il faut que cette lib existe sur toute les plateformes, ce qui n'est pas toujours le cas.
    En du moment qu'il ya un JVM pour la plateforme, quasi toute les plateformes, ta lib windows marchera sous la JVM linux et donc, le programme en Java dépendant de la lib fonctionnera lui aussi, à fortiori.
    
    Et puis le C++ c'est moins objet (je dis pas que Java est tout objet, je dis qu'il est largement plus objet que C++), avec les histoires d'héritage multiple qui viole la notion d'objet.
    
    C++ pour les performances pures
    Java pour la portabilité et l'objet
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Gruik Man le 26 février 2004 à 13:50. Évalué à 5.
      
      avec les histoires d'héritage multiple qui viole la notion d'objet.
      
      Heuuu, comment dire... « n'importe quoi » ?
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 26 février 2004 à 13:58. Évalué à -2.
        
        Renseigne toi ...
        
        C++ n'est pas un "vrai" langage objet et pour plusieurs raisons (heritage multiple entre autre a la place d'interface) mais aussi le fait qu'il ne supporte pas le typage dynamique ...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 26 février 2004 à 14:04. Évalué à -3.
        
        Une derniere chose, UML permet effectivement de modeliser l'heritage multiple, mais UML n'a pas inventer la conception objet.
        
        Dans un monde objet l'heritage n'a pas vraiment de sens, on lui prefere la notion d'extension (equivalente a l'heritage simple) pour specialiser l'objet et la notion d'interface pour ajouter un comportement. Generalement l'extension implement l'interface et etend un objet pour lui ajouter le comportement de cette interface. Je ne sais pas si c tres clair ce que je viens d'ecrire ;)
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 14:07. Évalué à 3.
        
        C'est pas un peu fini, les conneries ?! Ce n'est pas parce que smalltalk était complètement dynamique qu'il faut obligatoirement supporté le "typage dynamique" (ce qui ne veut rien dire) pour être objet. Eiffel et Sather sont des vrais langages objets et ils sont plus proche de C++ que de smalltalk, par exemple.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gruik Man le 26 février 2004 à 14:15. Évalué à 3.
        
        Ben...
        
        1) Explique-moi ce qu'est un « vrai langage objet » alors, et en quoi l'héritage multiple viole ce concept de véritable objectitude
        
        2) Eiffel gère l'héritage multiple, ce n'est pas un « vrai langage objet » ?
        
        3) Java est un langage fortement typé ET statiquement typé, comme C++. On peut, en Java, caster un objet en une de ses sous-classes, si l'objet est du bon type (si c'était ça que tu voulais dire). Mais en C++ aussi, grâce à dynamic_cast.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 26 février 2004 à 14:23. Évalué à 2.
        
        J'ai mis vrai entre guillement.
        
        C++ est un langage objet, puisqu'il reprend les principaux principes, mais, comme pratiquement tous les langages et pour des raisons de facilité d'utilisation il va plus loin et propose des fonctionnalités qui sorte du cadre de la conception purement objet.
        
        On peut, en Java, caster un objet en une de ses sous-classes, si l'objet est du bon type (si c'était ça que tu voulais dire). Mais en C++ aussi, grâce à dynamic_cast.
        Le typage dynamique permet juste de determiner le type d'un objet a l'execution. Il n'y a pas de controle a la compilation. Dans l'exemple que tu as cite le "cast" est controle a la compilation. L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 14:30. Évalué à -1.
        
        L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet.
        
        Ultra puissant, on remplace une table de fonctions virtuelles par un pointeur vers le type de l'objet. Quel gain remarquable !!! De toute manière, Java est typé à la compilation...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gruik Man le 26 février 2004 à 14:39. Évalué à 2.
        
        Nan nan, la particularité de dynamic_cast est justement de vérifier le type de l'objet à l'exécution (voir ici: http://www.cplusplus.com/doc/tutorial/tut5-4.html(...) )
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Moby-Dik le 26 février 2004 à 18:22. Évalué à 1.
        
        Bon, ceci dit, dynamic_cast c'est loin d'être la feature la plus heureuse du C++.
        
        En passant, j'ai lu la doc Ruby récemment, ça a l'air très sympathique (beaucoup plus que Python) : syntaxe légère, grande expressivité, et l'implémentation des itérateurs est particulièrement alléchante. Vivement que ça mûrisse.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gruik Man le 26 février 2004 à 19:27. Évalué à 2.
        
        Ah, un troll python/ruby, ça change des vieux trolls C++/Java!
        
        Ceci dit, en quoi tu trouves que Ruby est beaucoup plus sympathique que Python?
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Moby-Dik le 27 février 2004 à 01:02. Évalué à 5.
        
        Le Python, c'est des types distincts pour les tuples et les listes, les strings qui sont invariables, la fausse bonne idée des indentations pour délimiter les blocs de code, le self explicite dans les déclarations de méthode, les globales qui se retrouvent locales quand tu écris dedans... Et c'est à moitié objet (types de bases vs. objets). Ruby quant à lui conserve la syntaxe ultra-concise d'un langage comme Perl, tout en apportant une sémantique beaucoup plus haut niveau (mate les coroutines, qui permettent d'engendrer les itérateurs en un tournemain avec le mot-clé yield).
        
        Bref j'ai l'impression que Ruby est beaucoup plus abouti conceptuellement. Note que je n'aborde pas le sujet de la vitesse ou de la richesse des bibliothèques.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par gallenza le 27 février 2004 à 02:28. Évalué à 0.
        
        Bon pour rester dans le conceptuellement, Ruby s'inspire beaucoup de python et pourtant n'apporte presque rien. Syntaxe utra-concise, Python est plus concis, pas à moitié-objet,Python est totalement objet.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Moby-Dik le 27 février 2004 à 03:40. Évalué à 1.
        
        Python est totalement objet
        
        Les types de base de Python (entiers, etc.) ne sont pas des objets.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par TazForEver le 27 février 2004 à 11:28. Évalué à 1.
        
        mince alors, comment ça se fait que j'arrive à hériter de tous les types de bases alors ? c'est pas très sérieux tout ça, tu ferais mieux de lire un peu et la documentation et les sources
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par LeMagicien Garcimore le 27 février 2004 à 05:22. Évalué à 2.
        
        Syntaxe utra-concise, Python est plus concis, pas à moitié-objet,Python est totalement objet.
        Moi aussi je veux troller !!
        
        Je suis pas un pro de la conception objet, mais un langage de prog objet, mais quand je lis ça :
        
        There is limited support for class-private identifiers. [...] Note that the mangling rules are designed mostly to avoid accidents; it still is possible for a determined soul to access or modify a variable that is considered private.
        
        Ba j'ai des doutes...
        
        plus ce que disait Moby-Dik sur le self exoplicit...
        En fait, quand tu regarde un peu la doc, tu te rends vite compte que le support des classes dans python, c'est un infâme bricolage degueulasse. Alors oui, c'est facile de coder en Python, on peut faire des progs vraiment bon (cf Zope) mais arrêtez de balancer a qui veut l'entendre que c'est un language totalement objet, c'est pas vrai à mon sens.
        
        Pour finir sur les apport de Ruby, y'en a certe peu (et encore c'est relatif) mais ils sont de taille. Pour moi, rien que pour les code blocks, la gestion de la visibilité des méthodes et des variables d'instance, des getters/setters et de certains design patterns ça me suffit.
        
        Garci
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par totof2000 le 27 février 2004 à 10:31. Évalué à 2.
        
        Je ne connais pas Ruby. Y a-t-il une (ou des) bibliothèques permettant de développer une interface graphique de facon relativement simple, et surtout portable (style tkinter)?
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par VACHOR (site web personnel) le 27 février 2004 à 10:53. Évalué à 0.
        
        Faut se renseigner avant de dire des conneries ! ;-)
        Python est orienté objet, mais n'est pas objet. Même les pythoneux les plus aguerris le savent...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gruik Man le 27 février 2004 à 12:40. Évalué à 2.
        
        Le Python, c'est des types distincts pour les tuples et les listes,
        
        OK, c'est assez critiquable en effet. Ceci dit , y'a de bonnes raisons à ça (ok il y en a toujours), et en pratique c'est pas si gênant.
        
        les strings qui sont invariables,
        
        Ça, c'est un gros problème, je te l'accorde.
        
        la fausse bonne idée des indentations pour délimiter les blocs de code,
        
        Alors là oui mais non ! Cette méthode est bien plus élégante que toutes les autres méthodes qui nécessitent un formatage redondant (indentation + délimiteurs)
        
        le self explicite dans les déclarations de méthode,
        
        Bof, je vois pas en quoi c'est gênant.
        
        les globales qui se retrouvent locales quand tu écris dedans
        
        Les globales ça sux, de toutes façons. La solution Pythonesque évite au moins qu'elles viennent pourrir l'espace de nommage de tes fonctions. J'aime mieux ça à PERL ou PHP où les variables sont globales par défaut.
        
        Et c'est à moitié objet (types de bases vs. objets)
        
        Ben euh, non pas vraiment. Les types de bases aussi sont des objets (et ont parfois des méthodes)
        
        (mate les coroutines, qui permettent d'engendrer les itérateurs en un tournemain avec le mot-clé yield).
        
        En python aussi, on peut générer des itérateurs instantanément avec le mot-clé yield : )
        
        (ceci dit, je ne nie pas que Ruby a l'air d'être un très bon langage aussi, mais je le connais peu)
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Troy McClure (site web personnel) le 27 février 2004 à 20:00. Évalué à 2.
        
        > Alors là oui mais non ! Cette méthode est bien plus élégante que toutes les autres méthodes qui nécessitent un formatage redondant (indentation + délimiteurs)
        
        sauf que quand tu fais du copier coller ça devient vite le bordel pour retrouver où commencent et finissent les blocs
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gruik Man le 28 février 2004 à 00:30. Évalué à 1.
        
        Oui, c'est sûr, faut ajuster l'indentation après chaque collage.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Éric (site web personnel) le 29 février 2004 à 20:17. Évalué à 1.
        
        > J'aime mieux ça à PERL ou PHP où les variables sont globales par défaut.
        
        Les variables PHP sont *locales* par défaut. Pour utiliser une globale il faut le demander explicitement, aucune confusion ni aucune ambiguité n'est possible.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 26 février 2004 à 14:42. Évalué à 4.
        
        "C++ est un langage objet"
        
        Non. C++ est un langage multi-paradigmes, il _peut_ etre objet, mais la partie généricité STL est loin d'être objet ...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Anonyme le 26 février 2004 à 16:22. Évalué à 4.
        
        il _peut_ etre objet
        
        Arreter de jouer sur les mots, si tu avais pris la peine de me lire depuis le debut tu verrais qu'on pense exactement la meme chose.
        
        De toute facon la notion d'objet, a mes yeux, n'est pas dependante du langage mais plutot de la facon dont le developpeur utilise les fonctionnalités du langage utilisé. Elles ne sont la que pour l'aider et formaliser syntaxiquement ce concept.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par #3588 le 26 février 2004 à 22:18. Évalué à -1.
        
        Ouais, m'enfin faire tous les types de polymorphisme en assembleur, c'est quand même pas terrible par rapport à un langage qui les supporte :)
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Nicolas Chapin le 26 février 2004 à 14:26. Évalué à 2.
        
        Violer est peut-être une notion un peu forte, foutre le bordel est plus exact.
        
        Prends une classe A avec une methode m, tu la dérives en classe A1 et A2 dans lesquels tu surcharge m par respectivement m1 et m2.
        Maintenant tu prends une clase B qui hérite à la fois de A1 et A2.
        
        Tu commence à voir un peu le problème ...
        
        Bon on y est, tu instancies B et tu fais appel à la méthode m.
        
        C'est quelle version que tu vas executer?
        Est-tu sûr que c'est celle que tu voulais?
        
        En C++ cela dépend du compilo, si celui ci accepte l'héritage mutiple
        En Java tu ne peux hériter que d'une classe et de plusieurs interface ce qui ne pose pas de problème vu que dans une interface toutes les méthodes sont abstraites.
        En Eiffel, tu peux indiquer quelle version tu veux mais là on commence à dénaturer l'héritage.
        
        Cela reste une différence de point de vue:
        Pour le C++ c'est au programmeur à savoir programmer et tant pis pour lui s'il code comme un porc.
        Pour Java, on considère que cela est source d'erreur donc on ne l'authorise pas
        Pour Eiffel on laisse la possibilité mais avec des mécanismes de sécurité
        
        Mais si tu veux vraiment du code élégant vaut mieux utiliser un langage fonctionnel :) (Qui a dit que cela sent le troll?)
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par vincent LECOQ (site web personnel) le 26 février 2004 à 18:12. Évalué à 1.
        
        OOOOOOOO Cam il est poilu ! ...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gruik Man le 27 février 2004 à 13:06. Évalué à 2.
        
        Ben oui, l'héritage multiple peut poser des problèmes de « diamant » si les développeurs / concepteurs se débrouillent mal, mais c'est pas pour ça que ça « viole » les concepts objet d'une quelconque manière.
  - [^] #
    
    Posté par Frédéric Desmoulins (site web personnel) le 26 février 2004 à 13:53. Évalué à -1.
    
    Effectivement.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par ZeGrunt le 26 février 2004 à 13:56. Évalué à 5.
    
    Ah, ah, ah. Allez, je me lance dans le troll.
    
    C++ plus joli, non mais franchement !! Un mix infâme entre un vieux langage (très bon au demeurant) qu'était le C avec les principes objet.
    
    On va me dire que c'est au programmeur de coder proprement, de ne pas mélanger le C et le C++. Mais c'est justement là toute la différence entre un langage propre (et vous remarquerez que je n'ai pas cité Java) et un langage qui n'est qu'une rustine pour éviter aux gens pleins d'inertie d'apprendre une nouvelle syntaxe.
    
    Parlant de Java, il présente un des problèmes qui me font bondir régulièrement quand on parle de langage à objets. D'ailleurs, je fais le distingo entre un langage à objet et un langage orienté objet (même si c'est un terme anglais mal traduit) : les types de bases.
    
    Java et C++ sont des langages orientés objet parce que justement tout n'est pas objet (int, long et consorts), donc ils tendent vers la prog à objet mais n'y sont pas. Java est plus proche du but que C++ avec ces objets Integer, etc. et il possède au moins l'avantage d'avoir un objet de base Object, ce qui manque cruellement en C++ (pff). Et je parle même pas des templates en C++ sur lesquels je m'arrache les cheveux juste pour une pseudo généricité.
    Un langage à objet est, par exemple, Eiffel. Il a ses défauts comme tous langage mais au moins, pas de questions pour savoir si on a objet ou non. Les conneries du style créer un objet à partir d'un int pour mettre ça dans un container de la lib standard me foutent hors de moi.
    
    En bref, tous les langages ont leurs défauts et il serait bien d'arrêter dire Java, c'est nul, C++, c'est de la balle. D'une part, ça n'apporte pas grand chose, d'autre part, c'est vraiment très loin de la réalité. La qualité d'un langage ne se juge pas que sur sa rapidité d'exécution pure.
    
    Bon, je me suis un peu défoulé, ça fait du bien.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Boa Treize (site web personnel) le 26 février 2004 à 14:11. Évalué à -5.
      
      Un mix infâme entre un vieux langage (très bon au demeurant) qu'était le C
      
      Mwaha ahahaha ! Le C, un « très bon » langage ?! :-D
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Hobgoblins Master (Mastodon) le 26 février 2004 à 14:38. Évalué à 2.
      
      C++ plus joli, non mais franchement !! Un mix infâme entre un vieux langage (très bon au demeurant) qu'était le C avec les principes objet.
      
      Surtout qu'on peut très bien faire de "l'orienté" objet en C pur !
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Nicolas Chapin le 26 février 2004 à 14:43. Évalué à -2.
      
      Le c un un trés bon langage?
      
      Faudrait voir à ne pas pousser mémé dans les orties là.
      
      Un langage qui permet de créer un tableau de 10 éléments et d'aller taper allègrement dans le 15ième est un peu fonctionnellement déficient :)
      
      Le c à des avantages (rapide, proche du système) mais ne reste qu'une surcouche à l'assembleur.
      C'est à dire aucun mécanisme de sécurité et une factorisation du code proche de zero sans faire appel à tout un tas de mécanisme plus ou moins tordus.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par totof2000 le 26 février 2004 à 14:58. Évalué à 1.
        
        AAAAh l'assembleur!!! Voila un langage pour les hommes, les VRAIS.
        
        C'est le seul VRAI langage qui permet de TOUT faire!!!
        
        Quand vous saurez réécrire MultideskOS en assembleur, là vous pourrez parler !!!
        
        En attendant, arrêtez de racconter des conneries!
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par niavlys le 26 février 2004 à 15:25. Évalué à 7.
        
        AAAAh l'assembleur!!! Voila un langage pour les hommes, les VRAIS.
        
        euh non, l'assembleur c'est un langage pour les machines...
        
        pù là --->[]
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par totof2000 le 26 février 2004 à 15:31. Évalué à 1.
        
        Nan, le langage pour les machine c'est justement le langage machine (une série de 0 et de 1 que seule une machine peut comprendre).
        
        Ca, c'est pas un langage pour les hommes mais pour les Dieux!!!
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par niavlys le 26 février 2004 à 15:50. Évalué à 1.
        
        00101110010111011000110101001
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par PachaFonk le 26 février 2004 à 16:28. Évalué à 1.
        
        big endian, little endian ????????
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Matthieu BENOIST le 26 février 2004 à 16:38. Évalué à 2.
        
        gros boutiste, petit boutiste ????????
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par MagicNinja le 26 février 2004 à 19:08. Évalué à 1.
        
        les oeufs je commence d'abord par les couper en 2 :)
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par vazco le 27 février 2004 à 15:01. Évalué à 1.
        
        Et tu les coupes en deux en commençant par le gros bout ou par le petit bout ?
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par totof2000 le 03 mars 2004 à 12:05. Évalué à 1.
        
        Moi je les coupe en deux mais dans le sens de la hauteur, comme ca je suis pas embêté par le bout :)
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Jean-Yves LENHOF (site web personnel) le 26 février 2004 à 21:38. Évalué à 4.
      
      Et Ada alors....
      
      La généricité....
      Un langage complétement portable au niveau source
      
      Mais le problème d'Ada (mois c'est pour ca que j'adore) c'est qu'il ne permet pas de bricoler comme dans les autres langages.... Si on a pas bien réfléchi à ce que l'on code.... on code n'importe quoi et donc le compilo Ada nous le fait sentir....
      
      Mais vaut-il mieux avoir des problèmes lors de la compilation ou lors de l'éxécution ?
      
      Moi quand j'ai Java qui se plante de façon aléatoire ou un prog en C qui me fait un segmentation fault ca m'énerve plus que de débugguer mon programme lors du codage (Les problèmes relevés par les compilateurs sont toujours à prendre aux sérieux.... )
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Tutur le 27 février 2004 à 11:04. Évalué à 2.
        
        L'ada a quand même quelques défauts:
        - On n'a pas à s'embeter avec les pointeurs et c'est dur pour les gens qui ont appris à pisser du C.
        - La norme, n'inclus pas les sockets réseaux.
        - L'instruction use pour les packages est a ne pas utiliser.
        - L'execution des programmes est plus lent qu'en C, mais c'est normal, car il verifie les indices de boucles, tableau, etc... ainsi que d'autres choses. Ce qui à l'avantage d'eviter des buffer overflow. Enfin tans que tu n'utilises pas #pragma supress all_cheks.
        
        - Mais surtout son gros problémes, c'est ça philosophie et si tu ne l'as pas apprise en même temps, tu ne pourra pas l'utiliser correctement.
        
        Par contre, il a de nombreux avantages:
        - Faciliter de relecture si la personne qui a codé n'a pas fait trop de connerie.
        - C'est une norme (contrairement à d'autres langages normés, on trouve facilement la nrome sur internet)
        - Il y a de l'objet pour ceux qui veulent à tous pris en faire, mais c'est souvent plus simple de faire un package.
        - On ne s'emmerde pas avec les pointeurs
        Et plein d'autre encore que j'oublie.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par #3588 le 26 février 2004 à 22:31. Évalué à -1.
      
      Je me lance aussi :)
      
      « On va me dire que c'est au programmeur de coder proprement, de ne pas mélanger le C et le C++. Mais c'est justement là toute la différence entre un langage propre et un langage qui n'est qu'une rustine pour éviter aux gens pleins d'inertie d'apprendre une nouvelle syntaxe. »
      
      Il suffit de connaître son langage, et il n'y a pas besoin de connaître C pour connaître le C++. Et vu la syntaxe de C++, il est clair que le but n'est pas de faciliter la transitions aux développeurs C.
      
      « Java est plus proche du but que C++ avec ces objets Integer, etc. et il possède au moins l'avantage d'avoir un objet de base Object, ce qui manque cruellement en C++ (pff). Et je parle même pas des templates en C++ sur lesquels je m'arrache les cheveux juste pour une pseudo généricité. »
      
      Ah, la classe Object, un des trucs les plus dégueulasses jamais réalisés. Heureusement Java reconnaît son erreur et va admettre des templates dans la prochaine version. Faire du générique sans support, c'est quand même aussi crade que de l'objet sans support du langage (comme de l'objet en C)
      
      « En bref, tous les langages ont leurs défauts et il serait bien d'arrêter dire Java, c'est nul, C++, c'est de la balle. »
      
      Ce n'est pas aussi simple. Le problème c'est que Java a trop de limitations (volontaires) censées simplifier, mais qui *manquent* vraiment. Java m'a longtemps paru meilleur, mais finalement C++ est un meilleur investissement. Par contre, il est clair qu'il faut très bien le connaître, et que son apprentissage est nettement plus long.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par ZeGrunt le 27 février 2004 à 00:19. Évalué à 2.
        
        > Ah, la classe Object, un des trucs les plus dégueulasses jamais réalisés.
        
        Va falloir m'expliquer là. Parce que dans un langage à objet, il est quand même bien d'avoir un objet de base qui permette d'avoir un contenant universel.
        
        > Heureusement Java reconnaît son erreur et va admettre des templates dans la prochaine version.
        
        Quel est le rapport entre les templates et la classe Object ??? Les templates vont amener une certaine généricité (je ne suis pas encore assez au courant pour savoir si elle pourra être contrainte) mais si c'est à la C++, je préfère me tirer une baste tout de suite. :p
        
        > Par contre, il est clair qu'il faut très bien le connaître, et que son apprentissage est nettement plus long.
        
        Ca doit faire maintenant 7 ans que je me paluche du C++ et du Java dans mon taf et, franchement, mon avis est moins tranché que le tien entre Java et C++. Et j'en ai suffisament soupé des limites de C++ pour avoir un doute quant au terme "meilleur" investissement. En tous cas, concernant les concepts objet, ces deux-là sont loin derrière Eiffel à mon humble avis. ;)
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par #3588 le 27 février 2004 à 00:33. Évalué à -1.
        
        « Va falloir m'expliquer là. Parce que dans un langage à objet, il est quand même bien d'avoir un objet de base qui permette d'avoir un contenant universel. »
        
        J'aurais dû préciser. Je n'en vois pas le besoin mais pourquoi pas. Par contre, quand c'est la seule solution pour remplacer des templates, c'est très crade. Mais des cas où c'est utile, oui je veux bien croire, ça doit exister... quoique ça paraît étrange sur un schéma de conception.
        
        « Quel est le rapport entre les templates et la classe Object ??? Les templates vont amener une certaine généricité (je ne suis pas encore assez au courant pour savoir si elle pourra être contrainte) mais si c'est à la C++, je préfère me tirer une baste tout de suite. :p »
        
        La syntaxe sera pourtant inspirée de celle de C++. Qu'est-ce qui ne te convient pas ? Moi ça me paraît plutot aberrant qu'un langage qui se veut assez généraliste n'en propose pas.
        
        « Ca doit faire maintenant 7 ans que je me paluche du C++ et du Java dans mon taf et, franchement, mon avis est moins tranché que le tien entre Java et C++. Et j'en ai suffisament soupé des limites de C++ pour avoir un doute quant au terme "meilleur" investissement. »
        
        Je vois surtout des limites dans Java. D'ailleurs, c'est ce qu'on reproche à C++ : ne pas en mettre assez (de limites). Ce n'est pas une mauvaise chose de mettre des limites, mais je trouve que Java les a mal placées.
        
        « En tous cas, concernant les concepts objet, ces deux-là sont loin derrière Eiffel à mon humble avis. ;) »
        
        On est d'accord. Mais au moins C++ n'a pas la prétention d'être un langage tout-objet, juste de supporter un minimum de POO (ce qu'il fait mieux que Java: fonctions non virtuelles, héritage multiple, etc.)
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par ZeGrunt le 27 février 2004 à 08:30. Évalué à 2.
        
        > La syntaxe sera pourtant inspirée de celle de C++. Qu'est-ce qui ne te convient pas ? Moi ça me paraît plutot aberrant qu'un langage qui se veut assez généraliste n'en propose pas.
        
        En fait peu m'importe la syntaxe. Et, oui, un langage généraliste devrait avoir de la généricité. Il devrait aussi avoir une gestion des droits d'accès bcp plus précise que private/protected/public/default (déjà 10 ans que Eiffel a les deux !).
        
        Par contre, j'ai bcp de mal à dire templates==généricité. En fait mon problème avec le templates est cette différence : template <int valeur> et template<class nom>. Même syntaxe, comportement à l'opposé. Surtout que, d'après moi, la première n'apporte "pas grand chose" par rapport à un constructeur à paramètre si ce n'est que ça a l'avantage d'être un typage plus fort. Mais je crois que je me suis braqué à un moment à force de me prendre la tête. ;)
        
        > mieux que Java: fonctions non virtuelles.
        
        Euh, c'est pas un peu le but de final ?
        A tout prendre, je préfère largement "les fonctions virtuelles" (lire "la liaison dynamique") par défaut, c'est bcp plus proche du raisonnement humain à mon avis. De plus, je trouve plus simple de dire quand la liaison dynamique doit s'arrêter que de dire tout le tps qu'elle doit avoir lieu.
        
        Mais on en revient tjs à une question de goût vis à vis des langages. La majorité apporte de bonnes choses et trainent qq casseroles. Le tout, c'est de choisir celui qui en trainent le moins pour le projet en cours.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 09:32. Évalué à 0.
        
        A tout prendre, je préfère largement "les fonctions virtuelles" (lire "la liaison dynamique") par défaut, c'est bcp plus proche du raisonnement humain à mon avis. De plus, je trouve plus simple de dire quand la liaison dynamique doit s'arrêter que de dire tout le tps qu'elle doit avoir lieu
        
        Parfaitement d'accord, d'autant qu'un bon compilateur (cf smalleiffel) est capable d'enlever lui-même l'aspect "virtuel" quand il peut démonntrer (si, si, il s'agit d'une preuve) qu'il n'en n'aura pas besoin à l'exécution. Mais bon, dès que quelqu'un te dit que les virtuels du C++ c'est super pour l'optimisation, tu dois détecter qu'il a dix ans de retard sur l'état de l'art en compilation des langages objets (et encore, 10 ans, je minimise). Les virtuels, c'est la plus grosse connerie du C++ avec l'absence de GC.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par #3588 le 27 février 2004 à 15:29. Évalué à 0.
        
        « Par contre, j'ai bcp de mal à dire templates==généricité. »
        
        Je n'ai rien contre ce que tu dis ensuite, mais je ne vois pas en quoi ça joue... Je trouve qu'il manque ce type de polymorphisme à Java, et l'appréciant en C++, ça me semble un vrai manque. Ca me parait vraiment une bonne chose que ça arrive en Java. Pour tout ce qui est conteneurs, ce que propose Java est quand même ridicule par rapport à la STL à cause de ça, non ?
        
        « Euh, c'est pas un peu le but de final ? »
        
        « final » peut être une solution mais pas toujours, ce n'est pas exactement la même chose.
        Maintenant pour ce qui est de la valeur par défaut, personnellement ça ne me dérange pas, mais en effet si je devais en choisir un, je choisirais plutôt comme Java : virtuel par défaut. Et on préciserait les choses avec un mot clé nonvirtual. Mais je parlais surtout de l'existence, pas de valeur par défaut.
        
        Bah, une question de goût. J'ai pour habitude de considérer les fonctions non virtuelles et de ne les rendre virtuelles que quand c'est nécessaire. Mais c'est juste une question d'habitude.
        
        « Mais on en revient tjs à une question de goût vis à vis des langages. La majorité apporte de bonnes choses et trainent qq casseroles. Le tout, c'est de choisir celui qui en trainent le moins pour le projet en cours. »
        
        Tout à fait, je préfère le C++ en général mais parfois je trouverais Java plus adapté. Et C++ est un langage qu'il faut vraiment bien connaître, c'est pas du "C avec classes", il est complexe et ça peut aussi être un inconvénient sérieux.
        
        Quand C++ ne s'impose pas, j'ai l'impression que des langages comme Python sont souvent préférables à Java. Je n'en suis pas sûr, parce que je connais surtout Java et beaucoup moins les langages comme Python, mais j'ai l'impression que ce qui me ferait délaisser C++ dans un projet irait plutot dans le sens de Python (ou similaire) que de Java. Il faudra que je me mette sérieusement à Python pour me faire un avis.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 15:51. Évalué à 0.
        
        Pour tout ce qui est conteneurs, ce que propose Java est quand même ridicule par rapport à la STL à cause de ça, non ?
        
        C'est sûrement moins efficace, mais ridicule, je dois dire que je ne comprends pas pourquoi, d'autant que la STL est très complexe à cause de la gestion mémoire. Et puis bon, les templates c'est dans java 1.5 qui est déjà disponible en version beta...
        
        « final » peut être une solution mais pas toujours, ce n'est pas exactement la même chose.
        
        Pourrais-tu détailler pourquoi ? J'ai fait pas mal d'années de programmation C++ et je t'avoue que je ne vois pas à quoi tu peux bien faire référence.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par #3588 le 27 février 2004 à 22:05. Évalué à -1.
        
        « C'est sûrement moins efficace, mais ridicule, je dois dire que je ne comprends pas pourquoi, d'autant que la STL est très complexe à cause de la gestion mémoire. Et puis bon, les templates c'est dans java 1.5 qui est déjà disponible en version beta... »
        
        Pas ridicule alors, mais « pas très propre ». J'espère l'arrivée des templates changera tout ça, ça devrait être assez sympathique après :)
        
        « Pourrais-tu détailler pourquoi ? »
        
        Juste le fait que final n'est pas l'exact opposé de virtual. C++ n'empêche pas de "redéfinir" une fonction non virtuelle dans une sous-classe. Elle ne sera pas prise dans une recherche dynamique, mais elle peut exister.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 28 février 2004 à 14:09. Évalué à 1.
        
        Juste le fait que final n'est pas l'exact opposé de virtual. C++ n'empêche pas de "redéfinir" une fonction non virtuelle dans une sous-classe. Elle ne sera pas prise dans une recherche dynamique, mais elle peut exister.
        
        Effectivement, j'avais oublié cette horreur. Avoue que parler ensuite de choses pas très propres au sujet du Object de Java, est un peu unilatéral, comme point de vue. Parce que franchement, le modèle objet du C++ qui permet ce que tu viens de rappeler ainsi que la perte du type de l'objet lors du passage par valeur, est vraiment immonde (ou pas propre, comme tu veux).
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par #3588 le 28 février 2004 à 14:56. Évalué à 0.
        
        Attention je ne dis pas que C++ amène forcément à faire des choses propres, hein, loin de là ! Mais il existe des trucs propres qu'on souhaiterait faire, qui sont possibles en C++ et pas en Java. La contrepartie c'est la possibilité de faire aussi des choses pas propres, mais ce n'est qu'une possibilité. Faut prendre tout ça en compte avant de choisir.
        
        Mais je trouve qu'il y a quand même une différence entre permettre des choses pas propres (bien des aspects de C++, mais si on les connait on les évite), et les rendre obligatoires (emploi d'Object au lieu de templates).
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par free2.org le 27 février 2004 à 14:18. Évalué à 1.
      
      Un langage à objet est, par exemple, Eiffel.
      C'est encore mieux, Eiffel est un langage "par contrat": chaque interface a un cahier des charges qui peut être vérifié à plusieurs endroits stratégiques dans chaque méthode.
      C'est rigoureux !
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par Cédric Chantepie le 26 février 2004 à 13:33. Évalué à 6.
  
  - gestion en standart du multi-cpu
  - reflexivité
  - plein d'api gratuites
  - très bon support des bases (en standart) avec jdbc
  - une bonne api de distribué intégrée en standart
  - connection aux annuaires (ldap, open directory, active directory , etc...) en trois coup de cuiller à pot
  - Simplicité
  - Objet
  
  etc....
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par reno le 26 février 2004 à 13:52. Évalué à 0.
    
    > - gestion en standard du multi-cpu
    
    Le terme est multi-threading.
    
    > - plein d'api gratuites
    
    Certes, il y a des librairies pour faire tout même le café, mais il y en a pas mal qui sont buggés: Swing..
    
    J'ai utilisé Java a l'époque du JDK 1.1.8 / 1.2.x, je me souviens de l'horreur pour imprimer..
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Samuel Ortiz le 26 février 2004 à 13:58. Évalué à 1.
      
      >> - gestion en standard du multi-cpu
      
      >Le terme est multi-threading.
      
      La gestion du multi-threading est indépendante du nombre de CPUs, donc multi-threading != multi-cpu.
      D'un autre cote, gestion en standard du multi-cpu, je vois pas trop ce que ca veut dire...
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par franck (site web personnel) le 26 février 2004 à 13:58. Évalué à 3.
      
      J'ai utilisé Java a l'époque du JDK 1.1.8 / 1.2.x, je me souviens de l'horreur pour imprimer..
      
      1.2 ????
      
      et oui ... et linux 0.99 il n'y a pas d'interface graphique ...
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par cbronson le 26 février 2004 à 14:01. Évalué à 1.
        
        Linux 2.6 non-plus d'ailleurs.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Moby-Dik le 26 février 2004 à 14:06. Évalué à 2.
        
        make gconfig non ?
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Axel R. (site web personnel) le 27 février 2004 à 09:53. Évalué à 1.
        
        Si tu passes plus de temps sur make gconfig que sur ton kernel... bah ça expliquerait certaines choses :-)
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par reno le 26 février 2004 à 23:25. Évalué à 3.
        
        Sun mets des ANNEES pour corriger des bugs, spécialement sur Swing et compagnie donc en "années Sun", 99 ça ne fait pas si longtemps..
        
        Et pour ton info, à cette époque là, le marketing de Sun poussait Java pour faire des interface graphique, sauf que Java n'était pas près du tout..
        
        Un conseil pour ceux qui veulent faire sérieusement du Java: regarder d'abord la "bugparade", c'est amusant: il y a des problèmes importants qui sont toujours ouvert depuis des années: à étudier avant de se mettre à Java..
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par harbort le 26 février 2004 à 14:02. Évalué à 1.
      
      > > - gestion en standard du multi-cpu
      >
      > Le terme est multi-threading.
      
      euh ... je sais pas ce que gère Java exactement, mais le multi-threading et le multi-cpu c'est pas pareil !
      
      multi-cpu = utilisation possible de plusieurs CPU en cas de multi-threading (par exemple, python n'est pas multi-cpu avec l'implémentation actuelle, par contre il est multi-thread)
      
      disons que multi-cpu est plus contraignant que multi-thread
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par gallenza le 27 février 2004 à 02:32. Évalué à 0.
        
        à mon avis tu dis n'importe quoi, je ne sais pas où tu as vu que des threads python ne pouvaient pas être exécutées sur des CPU différents, ça c'est du ressort de l'OS, sinon ça n'a aucun sens. Un programme multi-threadé se retrouve de facto optimisé multi-CPU...
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par jde le 27 février 2004 à 09:21. Évalué à 1.
        
        > Un programme multi-threadé se retrouve de facto optimisé multi-CPU
        > c'est du ressort de l'OS
        
        Non.
        Pour preuve Java pour qui les threads n'étaient pas système mais gérés par la JVM (au départ).
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 11:26. Évalué à 1.
        
        Ca prouve juste que les vieilles versions de Java étaient pourries.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par jde le 28 février 2004 à 14:30. Évalué à 1.
        
        ça prouve surtout qu'il ne faut pas généraliser sans savoir.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Gruik Man le 26 février 2004 à 13:54. Évalué à -1.
    
    Tu as raison, c'est sacrément bien, Python... Ah, vous parliez de Java? ^^
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Christophe Martel le 26 février 2004 à 14:14. Évalué à -1.
    
    -template (jdk 1.5 - enfin!!)
    -tres bon support xml | xsl (FOP)
    -technologie de dev client et serveur (servlet|jsp)
    -standardisation des API !!!
    -langage sécurisé et disposant de reglesd'acces en standard
    
    comparéé a C++
    -interface graphique certe gourmande en memoire mais identique quelque soit la plate forme
    -bien plus portable que le C++
    pasque faire du développement C++ sous...disons --windows-- oblige le développeur a utiliser des API de crosoft...
    mais moi, je demande juste a voir le resultat sous linux de la compilation d'un tel source....de la même façon,
    développe une appli avec des librairies graphique QT et ensuite recompile sous windows : ha ben zut, ça marche pas...
    -essayes de faire un virus en Java...au pire winzip ouvrira le .jar
    quand Mr Toto cliquera sur britnet_spear_nude_et_qui_avale_tout.mpg.jar dans son client mail O--l--k de merde ^_^
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par boubou (site web personnel) le 26 février 2004 à 14:18. Évalué à 1.
      
      -interface graphique certe gourmande en memoire mais identique quelque soit la plate forme
      
      Ouai, sauf que c'est resté assez moche jusqu'à il y a peu. De plus, la consommation mémoire, c'est le problème majeur de Java et ça risque de ne pas changer tout de suite, pour de profondes raisons d'architecture interne (genre le lock contenu dans chaque objet et l'aspect très dynamique du système de type).
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par ZeGrunt le 26 février 2004 à 14:24. Évalué à 0.
      
      > -template (jdk 1.5 - enfin!!)
      
      Snif, j'aurais franchement préféré de la vraie généricité plutôt que des templates à la C++...
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par LeMagicien Garcimore le 27 février 2004 à 05:31. Évalué à 2.
        
        Et c'est quoi de la vraie généricité ?
        
        je demande hein, c'est pas maichant :)
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Gruik Man le 26 février 2004 à 14:33. Évalué à 2.
      
      comparéé a C++
      -interface graphique certe gourmande en memoire mais identique quelque soit la plate forme
      
      Donc, aussi moche sous MacOSX que Linux et Windows.
      
      (l'utilisateur s'en fout que la version OSX ressemble à la version Win32, ce qu'il veut, avant tout, c'est qu'elle soit cohérente avec les autres applis de son système)
      
      -bien plus portable que le C++
      
      GCC supporte les plateformes suivantes: http://gcc.gnu.org/install/specific.html(...) . Sur combien d'entre elles est-il possible de faire tourner une JVM récente? Et si l'utilisateur n'a pas la bonne version de la JVM et de l'environnement Java?
      
      (gcj? Oui d'accord. Mais là où tourne GCJ, tourne aussi g++)
      
      essayes de faire un virus en Java
      
      Ben non, ça marchera pas, vu que le virus prévu pour la JDK 1.42 ne tournera jamais si l'utilisateur a une JDK 1.54, et plus ça fera ramer tellement son ordinateur qu'il se rendra aussitôt compte de quelque chose : p
      
      (oui c'est un troll)
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Dais Starry le 26 février 2004 à 14:44. Évalué à 1.
        
        "comparéé a C++
        -interface graphique certe gourmande en memoire mais identique quelque soit la plate forme
        
        Donc, aussi moche sous MacOSX que Linux et Windows.
        
        (l'utilisateur s'en fout que la version OSX ressemble à la version Win32, ce qu'il veut, avant tout, c'est qu'elle soit cohérente avec les autres applis de son système)"
        
        Euh .. à ma connaissance, tu as deux manières de coder l'interface graphique d'une appli en Java .. soit en te servant des possibilités de Swing, soit de celles de AWT (tu peux faire un mélange mais bonjour l'interface lol).
        Et que je sache, l'un (SWING) permet d'avoir un rendu identique sur toutes les plateformes, l'autre (AWT) permet de se servir de fonctionnalités propres au système d'exploitation et donc harmonise l'interface de l'appli.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Pierre Tramonson le 26 février 2004 à 14:59. Évalué à 1.
        
        Donc, aussi moche sous MacOSX que Linux et Windows.
        
        (l'utilisateur s'en fout que la version OSX ressemble à la version Win32, ce qu'il veut, avant tout, c'est qu'elle soit cohérente avec les autres applis de son système)
        Ca c'est par défaut.
        Tu as quand même la possibilité de choisir la tronche de ton appli en utilisant le Look&Feel de la plate-forme sous laquelle ton appli tourne.
        Tu peux aussi définir toi même tes propres Look&Feel (à réutiliser pour plusieurs applis par exemple), il y a tout ce qu'il faut dans l'API pour ça.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gruik Man le 26 février 2004 à 19:35. Évalué à 1.
        
        Oui oui je sais, mais je disais ça en réponse à un post qui prétendait que l'interface « identique quelle que soit la plate-forme » était une des forces de Java... Pour moi, une bonne API d'interface graphique devrait utiliser le Look&Feel natif du système par défaut, et ne présenter une interface différente que si le développeur le souhaite vraiment.
        J'irais pas jusqu'à présenter ça comme une tare (c'est pas si dur que ça à changer -- mais combien d'applications Java, hélas, imposent cet affreux look&feel metal aux couleur de cimetière avec des polices grasses systématiques), mais de là à le présenter comme une force du langage...
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Nicolas le 26 février 2004 à 20:53. Évalué à 1.
        
        > l'utilisateur s'en fout que la version OSX ressemble à la version
        > Win32, ce qu'il veut, avant tout, c'est qu'elle soit cohérente avec
        > les autres applis de son système)
        
        C'est pour ça que Sun a sorti SWT. Ce n'est pas aussi multi-plateforme que Java lui-même, mais c'est supporté sur quelques unes.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Bungee Tux le 26 février 2004 à 22:52. Évalué à 1.
        
        s/Sun/Ibm/g
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Guillaume Laurent (site web personnel) le 26 février 2004 à 19:04. Évalué à 1.
      
      > développe une appli avec des librairies graphique QT et ensuite recompile sous windows : ha ben zut, ça marche pas...
      
      Mais si ca marche (sauf si tu appelles des API specifiques Linux en plus de Qt).
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par #3588 le 26 février 2004 à 22:34. Évalué à 0.
      
      « -bien plus portable que le C++ »
      
      Non, pas si on parle du langage. A toi d'utiliser des bibliothèques portables.
      
      Et un programme Java n'est jamais portable que là où il y a de bonnes JVM, ce qui est plus limité que les plateformes disposant de compilateur C++.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par pasBill pasGates le 27 février 2004 à 07:09. Évalué à 3.
      
      pasque faire du développement C++ sous...disons --windows-- oblige le développeur a utiliser des API de crosoft...
      
      Marrant ca, je me demandes comment moi et mon pote avons reussi a ecrire un soft de quasiment 100'000 lignes de c++ qui compile sur Solaris, Linux, NT, BSD, Irix,...
      
      Et pourtant il y a du reseau, du threading, du stockage massif de donnees,...
      
      Ca doit etre de la magie noire je pense.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Gabriel le 27 février 2004 à 09:17. Évalué à 0.
        
        C'est quoi ce soft? Windows 98? (c'est le soft de m$ qui se rapproche le plus de la magie noire à mon avis: autant de bugs en si peu de place!)
        Allez zou je retourne faire mes propres bugs portables ;-)
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par B. franck le 26 février 2004 à 14:23. Évalué à 2.
    
    c'est perl ça non ?
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par matli le 26 février 2004 à 13:49. Évalué à -1.
  
  Java en soit, je ne sais pas, c'est meme moins bien que Perl à mon sens. Par contre, les serveurs d'appli J2EE sont quand même intéressants, notamment à cause du fait que l'accès aux ressources est gérée au niveau du serveur et pas par l'appli en elle même. Cela permet notamment d'utiliser et de controler des pools de connexion à une base de données, chose qui n'est pas encore possible en PHP il me semble. Et quand on voit la sensiblité de ce paramètre sur les perfs générale, c'est vraiment un avantage d'avoir la main dessus.
  Il y a de très bon serveurs J2EE libre (tomcat, Jonas pour les EJB,...), il manque juste une plate-forme Java libre pour avoir un environnement complet libre prêt pour la production.
# Re: IBM demande à Sun de "libérer" Java

Posté par Christophe Merlet (site web personnel) le 26 février 2004 à 12:51. Évalué à -6.

Et IBM, de leur coté, il libère quoi ?
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par olympien le 26 février 2004 à 13:00. Évalué à 3.
  
  Eclipse
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par Emmanuel Seyman le 26 février 2004 à 13:04. Évalué à 8.
  
  Et IBM, de leur coté, il libère quoi ?
  
  JFS, RCU, un meilleur suport du SMP, Elipse, des tests de performance sur les differents kernel, du support pour leurs plateformes, postfix et surtout... beaucoup de pub.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Christophe Merlet (site web personnel) le 26 février 2004 à 13:29. Évalué à 2.
    
    Je ne crois pas que toutes les micro contributions d'IBM soit aussi Importante que ce que Sun fait, a savoir la libération d'OpenOffice.org et des grosses contrib à GNOME (documentation, accessibilité, ...)
    
    JFS ? On a déjà ext3 et reiserfs, sans compter XFS.
    RCU ? une centaine de lignes de code dans le kernel !
    Un meilleur SMP ? bof, y'avait déjà du SMP avant et beaucoup de monde pour bosser dessus. Disons qu'IBM a validé le SMP sur des grosses bécanes.
    Eclipse ? Sun a libéré NetBeans !
    Des tests de performance ? Tout le monde passe son temps a en faire !
    Du support pour leur plate-forme ? et pour les autres ?
    Postfix ? C'est fait par un salarié d'IBM, certes, mais IBM supporte t'il postfix ?
    De la pub ? Là ok, je suis d'accord, 1 point pour IBM, surtout comparé aux déclarations tordues de Sun vis à vis de l'affaire SCO.
    
    Au final, je trouve qu'IBM est quand même trés loin derrière Sun concernant leurs contributions au logiciel libre. Alors oser demander en plus à Sun de "libérer" Java, je trouve qu'ils abusent un peu...
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par vrm (site web personnel) le 26 février 2004 à 13:40. Évalué à 4.
      
      franchement comparer Eclipse avec Netbeans c'est indécent ...
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Dais Starry le 26 février 2004 à 14:33. Évalué à 0.
        
        C'est clair .. Eclipse de IBM (& Co) fait pas mal d'ombre à NetBeans de Sun .. enfin c'est le jour et la nuit de toute manière ! On ne compare pas un effet astronomique saisissant avec un pauvre plat de haricots recouverts de toiles d'araignées ..
        
        PS: saurez-vous trouver toutes les co**eries ? ^^
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Yusei (Mastodon) le 26 février 2004 à 13:50. Évalué à 3.
      
      Moi j'ai clairement fait moins de choses qu'IBM, et j'aimerais bien que Sun libère Java :-) S'il y avait la moindre chance que Sun m'écoute, je ne me generais pas pour le lui demander.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Emmanuel Seyman le 26 février 2004 à 13:57. Évalué à 2.
      
      Je ne crois pas que toutes les micro contributions d'IBM soit aussi Importante que ce que Sun fait, a savoir la libération d'OpenOffice.org et des grosses contrib à GNOME (documentation, accessibilité, ...)
      
      C'est vrai que Sun à déja fait beaucoup. J'y reviens a la fin.
      
      JFS ? On a déjà ext3 et reiserfs, sans compter XFS.
      
      Plus de filesystems == plus de choix donc je pense qu'on a pas à critiquer.
      
      RCU ? une centaine de lignes de code dans le kernel
      
      qui permettent un gain de perf assez conséquent, de ce que j'ai pu lire.
      
      Eclipse ? Sun a libéré NetBeans !
      
      Tous les developeurs Java à qui j'ai parlé préferent Eclipse à NetBeans
      
      Postfix ? C'est fait par un salarié d'IBM, certes, mais IBM supporte t'il postfix ?
      
      Il me semble que oui. Je ne vois pas Wietse Venema faire les developements qu'il fait sur Postfix uniquement dans son temps libre. En plus, il a décrit Postfix comme étant le premier projet Open Source d'IBM.
      
      Au final, je trouve qu'IBM est quand même trés loin derrière Sun concernant leurs contributions au logiciel libre. Alors oser demander en plus à Sun de "libérer" Java, je trouve qu'ils abusent un peu...
      
      Si c'était juste une question de savoir qui a la plus grosse (je parle de contribution au libre, bien sur :-)), je pense que c'est ni IBM ni Sun que serait en ligne de mire. Simplement, Sun reproche à IBM d'avoir la main mise sur le consortium Eclipse ce qui fait que IBM se permet de lui renvoyer la balle en ce qui concerne le langage Java en lui-même.
      
      Ceci dit, toutes les sources que j'ai lu disent que le débat de mettre Java en Open Source revient régulièrement chez Sun. S'il suffit de 2-3 encouragements comme celui-ci pour qu'ils franchissent enfin le pas, c'est globalement une bonne chose.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Cook Captain le 26 février 2004 à 15:27. Évalué à 1.
        
        >>JFS ? On a déjà ext3 et reiserfs, sans compter XFS.
        >Plus de filesystems == plus de choix donc je pense qu'on a pas à critiquer
        
        >> Eclipse ? Sun a libéré NetBeans !
        >Tous les developeurs Java à qui j'ai parlé préferent Eclipse à NetBeans
        
        Cherchez l'erreur.
        
        Et moi dévelopeur Java, je préfère Netbeans, Emacs et intellij à Eclipse. eh Na :-).
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Moby-Dik le 26 février 2004 à 14:07. Évalué à 3.
      
      Tu serais pas J2EE Lead Architect, toi ?
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Cook Captain le 26 février 2004 à 15:21. Évalué à 1.
      
      et NFS.
      
      Que serait Unix sans ce superbe protocole ....
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par GaGadget le 26 février 2004 à 15:53. Évalué à 0.
      
      IBM a toujours eu une approche tres proprio tout au long de son histoire. Ce qui n'est pas le cas de SUN qui a toujours travaillé de manière "ouverte".
      
      Il faut rappeler que SUN a été fondé par Bill Joy, un des développeurs du système BSD ( OS opensource ), sur lequel SunOS était basé.
      
      SUN est donc issue d'un monde ouvert, ce qui n'est pas le cas d'IBM.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Jean-Yves LENHOF (site web personnel) le 26 février 2004 à 21:24. Évalué à 1.
        
        Je regarderai dans les contributeurs noyaux sur le 2.6.... et ben il y a plus de monde venant d'IBM que de personnes venant de Sun...
        
        A+
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Troy McClure (site web personnel) le 26 février 2004 à 20:55. Évalué à 1.
    
    et opendx http://www.opendx.org(...) , qui est loin d'etre un petit morceau
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par twisla (site web personnel) le 26 février 2004 à 13:04. Évalué à 3.
  
  Entre autre, ils paient des kernels hackers, ils contribuent jfs, et surement plein d'autres choses, y a qu'à voir http://www-124.ibm.com/developerworks/oss/linux/(...) par exemple.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Guillaume POIRIER le 26 février 2004 à 13:24. Évalué à 2.
    
    On peut d'ailleurs noter qu'ils sont l'initiateur du projet "Jikes" ( http://www.research.ibm.com/jikes/(...) ) qui est un compilateur Java très rapide (je crois que c'est parcequ'il est pas écrit en Java, mais en grande partie en C ou C++).
    Ce qu'il est amusant de contater, c'est que quand bien même le projet a débuté en 98, il n'a jamais réussi à toucher un large public.
    On comprend ainsi d'autant mieux la volonté d'IBM que Sun libère Java.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Cédric Chantepie le 26 février 2004 à 13:28. Évalué à 0.
      
      Quasi tout les compile Java que je connais sont en natif (pas en java eux-même), la force de celui d'IBM c'est surtout qu'IBM à réécrit de manière plus optimale les classes du JDK.
      
      Celui d'Apple est pas mal non plus ;-)
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 14:11. Évalué à 1.
        
        Mais qu'est-ce que tu racontes ? IBM a réécrit de manière plus optimale les classes du JDK dans son compilateur jikes ? Tu es fou, c'est ça ? Ou alors tu confond le JRE et le compilateur ?
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par franck (site web personnel) le 26 février 2004 à 14:12. Évalué à 1.
        
        attention compilateur != pré-compilateur
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 14:15. Évalué à 1.
        
        Ok, donc jikes fait .java -> .class et c'est un super compilateur open source écrit en C++ (ou en C, je ne sais plus). Ensuite .class -> .o, c'est un autre problème.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Cook Captain le 26 février 2004 à 15:30. Évalué à 2.
        
        Jike d'IBM est écrit en C.
        Javac de Sun est écrit en java
        Apple utilise le compilateur de Sun.
        
        Perso, j'ai utilisé Jikes et Javac, et au bout d'une journée on voit pas vraiment la différence surtout avec une IDE qui compile de manière incrémentale.
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par arapaho le 26 février 2004 à 13:05. Évalué à 1.
  
  JFS
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par Matthieu BENOIST le 26 février 2004 à 15:19. Évalué à 4.
  
  demande à SCO ^_^
  
  et un troll de plus, un !
# Re: IBM demande à Sun de "libérer" Java

Posté par kesako le 26 février 2004 à 12:52. Évalué à 2.

Je m'interresse peu a java en partie parce que justement Sun controle trop java.

Quelqu'un pourrait-il resumer ici les raisons pour lesquelles Sun veut garder ce controle ?

merci
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par LupusMic (site web personnel, Mastodon) le 26 février 2004 à 12:57. Évalué à 3.
  
  Éviter que MS ne s'approprie le Java en faisant une version du langage totalement incompatible ?
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par ghunt (site web personnel) le 26 février 2004 à 13:16. Évalué à 0.
    
    Éviter que MS ne s'approprie le Java en faisant une version du langage totalement incompatible ?
    MS ne ferait jamais ça, voyons!
    Du reste, MS ne l'a jamais fait! si?
    
    Pourtant, tout le monde sait que MS a tout inventé: le TCP/IP, le DOS, le système de fenêtrage graphique, la souris, etc.
    
    -1
    http://www.ifrance.com/trombinanar/tusors.jpg(...)
    suivez la flèche ----> [ ]
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Erwan le 26 février 2004 à 13:44. Évalué à 3.
    
    Maintenant qu'ils ont C# et .net, ca m'etonnerai que MS essaye encore de faire un Java incompatible.
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par franck (site web personnel) le 26 février 2004 à 13:07. Évalué à 10.
  
  La raison est ancienne ...
  
  Au commancement (java 1.0 et java 1.1), rien n'empèchait quelqu'un de faire un java open source ou closed source ... en modifiant ce qu'il voulait ...
  
  Ainsi Microsoft a "créer" MS-Java ... qui ressemble autant au java que moi à un tirrailleur du sénégal ....
  
  Résultat plein de proces par que tout le monde pensait que le MS-Java était du vrai java ...
  
  Donc Sun à protéger son bébé en disant que tout ceux qui voulaient appeler un binaire "java" devait le faire certifier par SUN ...
  
  Ce qui a bloqué MS d'ou le plug-in ms-java limité à du java1.1 tout vieux , et l'évolution du ms-java en visual J++ qui n'est pas du vrai java ...
  
  Mais ça a bloqué également l'open source .... puisque si il faut faire certifier par SUn après chaque compilation/modification ça va pas être pratique d'avancé ... c'est pourquoi on trouve quand même des jvm libre "compatible java" et non pas "java"
  
  En gros IBM voudrait pouvoir mettre sa jvm en GPL (ou autre) mais sun à peur qu'en modifiant les conditions pour pouvoir s'appeller "java", MS revienne avec son MS-Java ...
  
  l'idée de certaine personne de SUN et d'IBM est de permettre au jvm sous licence GPL de ne pas être certifié à chaque compilation/modification mais tous les x temps ... vu que ça obligerais MS à faire du GPL pour pouvoir faire du java ...
  
  voila en TRES TRES gros ...
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Anonyme le 26 février 2004 à 14:58. Évalué à 1.
    
    "En gros IBM voudrait pouvoir mettre sa jvm en GPL (ou autre)"
    
    Ca serait certainement plutot "autre" que GPL, trop de contraintes. Je pense en particulier à tout le travail du groupe Jakarta Apache sans qui Java[tm] ne serait rien aujourd'hui. Et la GPL ne permet pas de travailler avec toutes les licences libres comme Apache et CPL par exemple. Donc une licence libre oui, mais pas la GPL.
# Re: IBM demande à Sun de "libérer" Java

Posté par mammique le 26 février 2004 à 13:08. Évalué à 1.

Après le portage de MS-Office sous Linux IBM croie de nouveau au Libre ? A quoi jouent-il ?
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par Pascal Terjan (site web personnel) le 26 février 2004 à 13:11. Évalué à 1.
  
  Pour eux porter MS Office c'est juste un moyen de faciliter la transition des boites qui voudront pas le lacher comme ca pour pas envoyer les secretaires completement affoclées à l'asile.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Anonyme le 26 février 2004 à 22:11. Évalué à 1.
    
    Peux être surtout pour ceux qui ont des trucs compliqués avec pleins de macros en VisualBasic qui fonctionnent sous MS Office, et pas encore completement avec OpenOffice.
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par franck (site web personnel) le 26 février 2004 à 13:11. Évalué à 1.
  
  au chat et à la souris avec MS ???
  
  vu que MS ne veut pas entendre parler de Linux ...
  
  il a autant d'annonce que de démenti pour l'instant
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par deftones_chris le 26 février 2004 à 13:30. Évalué à 3.
  
  IBM mise sur Linux car cela leur permet:
  * d'avoir un OS pour leur serveur
  * et d'avoir le même OS pour les stations de travail et autres machines bureautique
  
  ... et tout ceci pour beaucoup moins cher que s'ils devaient développer leur propre OS (ils l'ont déjà fait sur les mainframes et une tentative sur les pc et cela leur a couté et leur coute encore cher).
  
  Et IBM mise sur MS-Office* car actuellement c'est l'outil de bureautique qu'ils doivent proposer dans leurs solutions car aucune autre solution ne peut satisfaire les clients à 100%. Certains vont dire qu'il y a OOo mais faut être réaliste et reconnaître que ce dernier ne peut pas remplacer tout MS-Office (au niveau du traitement de texte je veux bien, mais pas pour le reste) pour l'instant.
  
  * l'ensemble de la solution et ne pas se limiter à MS-Word
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par matli le 26 février 2004 à 13:43. Évalué à 6.
    
    OS pour leur serveur? N'allons pas trop vite, IBM a son AIX 5.2 et il n'est pas près de le lacher. En effet, il s'agit de l'OS qui te permets sur Regatta (sorte de mainframe Unix) de faire de l'allocation dynamique de ressource. Je m'explique:
    tu as ton Regatta avec par exemple 16 procs et plein de mémoires, et t'as une partition de prod qui soudain subit une grosse montée en charge, ton LA grimpe dangereusement, dépasse les 5, et toi, tu alloues tranquillement 2 procs de plus et 2 G de RAM, et c'est pris en compte sans redémarrer quoique ce soit, et hop, ta partition ronronne à nouveau. Pour l'instant, Linux ne permet pas ce genre de chose.
    Par contre, ils doivent surement le voir comme OS sur les plate-forme Intel en remplacement de Win---s
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par deftones_chris le 26 février 2004 à 13:56. Évalué à 1.
      
      Certes, ma pensée était plus tourner vers les mainframe tournant sous CMS (z/900 par ex) et le fait qu'IBM font pas mal de pression pour les faire passer à Linux. Là où je travaille on est en plein dans l'expèrience mais pour l'instant c'est pas jojo (les perfs sont lamentables :( )
      Mais bon, peut être qu'avec beaucoup de travail cela ira mieux.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Gruik Man le 26 février 2004 à 13:59. Évalué à 1.
      
      Moui, enfin, rien ne dit qu'ils ne sont pas, quelque part dans un de leurs labos, en train de porter leur système d'allocation dynamique de ressources sous Linux.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Samuel Ortiz le 26 février 2004 à 14:07. Évalué à 3.
      
      Ton allocation dynamique de resources, elle existe aussi sous Linux:
      
      BULL et SGI s'en occupent:
      - http://www.bullopensource.org/cpuset(...)
      - http://oss.sgi.com/projects/cpumemsets(...)
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par deftones_chris le 26 février 2004 à 14:12. Évalué à 2.
      
      Par contre, ils doivent surement le voir comme OS sur les plate-forme Intel en remplacement de Win---s
      
      Pour avoir des infos sur comment IBM voit Linux, il suffit d'aller là:
      http://www-1.ibm.com/servers/eserver/linux/home.html?c=serversintro(...)
      
      où on a (pour ceux qui ne veulent pas cliquer)
      
      Combining open standards with POWER technology for maximum performance and reliability.
      · IBM eServer pSeries® (UNIX servers)
      · IBM eServer iSeries (Midrange servers)
      · IBM eServer BladeCenter JS20
      
      Linux on Intel processor-based servers
      Performance, reliability and manageability for core business applications.
      · IBM eServer xSeries
      · IBM eServer Cluster 1350
      
      Linux on AMD processor-based servers
      Industry-leading price performance, running both 32-bit and 64-bit applications.
      · IBM eServer 325
      
      Linux on Mainframe
      Reliable mission-critical data transaction with the flexibility and openness of Linux.
      · IBM eServer zSeries®
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par xcoder_nux le 26 février 2004 à 13:45. Évalué à 1.
    
    MS office est plus complet c'est certain mais ceux qui ont fait la migration ne le regrette pas. Il y a surtout une rivalité entre SUN et IBM sachant qu'IBM est en train de grignoter les pdm de SUN et que ça agace SUN prodigieusement.
    
    Ensuite les choix stratégique ne sont pas les mêmes, quoi qu'on en pense SUN fait du propriétaire alors qu'IBM s'est clairement orienté open source.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par deftones_chris le 26 février 2004 à 14:04. Évalué à 0.
      
      MS office est plus complet c'est certain mais ceux qui ont fait la migration ne le regrette pas.
      Tout simplement car ils n'avaient pas besoin des fonctions de MS Office. Là où je bosse, tout les postes ont MS Office et 98% des personnes n'utilisent que Word et il ne font que des documents types documents techniques dont la seule différence avec un document texte basique est la présence d'une entete et d'un pied de page. Par faire cela, utiliser MSWord c'est le marteau pillon pour tuer la mouche :)
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par bad sheep (site web personnel) le 27 février 2004 à 09:51. Évalué à 1.
        
        > Par faire cela, utiliser MSWord c'est le marteau pillon pour tuer la mouche :)
        
        Oui, d'autant plus qu'à chaque fois que j'ai utilisé le marteau pilon, je me suis blessé tout seul <argh... mon document est cassé/perdu/pas_lisible_avec_word_XX !> :)
        
        GO OpenSource, use the «tapette à mouche» Luke !
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Anonyme le 26 février 2004 à 13:52. Évalué à 2.
    
    et tout ceci pour beaucoup moins cher que s'ils devaient développer leur propre OS
    
    et AIX ??? A mon avis c'est plus un effet de mode de vendre Linux avec leurs stations de travail que de mettre de l'AIX. Leurs clients doivent en effet leur demander Linux car il pense que tout est gratuit et que ca leur reviendra a moins cher.
# Re: IBM demande à Sun de "libérer" Java

Posté par ours Ours (site web personnel) le 26 février 2004 à 13:55. Évalué à 3.

si java devenait libre, cela faciliterait la portabilité car actuellement elle n'est ... pas top. la dernière jvm native sur freebsd - la 1.3.1 - est sortie cet été alors que la 1.5 bêta pointe le bout de son nez, d'autant plus que la version linux ne tourne que sur les i386.
# Re: IBM demande à Sun de "libérer" Java

Posté par Docteur_Canard le 26 février 2004 à 13:57. Évalué à 3.

Java, c'était mieux avant :

http://linuxfr.org/2000/09/09/1.html(...)
# Java et logiciels libres

Posté par HappyPeng le 26 février 2004 à 14:32. Évalué à 1.

Une fois de plus, alors qu'énormément de gens trouvent scandaleux que la moindre application orientée GNOME soit développée avec Mono sous prétexte de .NET, on en fait des pages et des pages sur Java dans un espace consacré au logiciel libre, alors que la grande majorité des logiciels libres développés en Java sont incapables de tourner sans une machine virtuelle propriétaire.

Pour moi, Java est la plus grande contradiction du logiciel libre, parce que des centaines de développeurs du libre déclarent ne pas pouvoir s'en passer, sans pour autant que les environnements Java libres semblent avancer, et tout en trouvant cela parfaitement normal puisqu'utilisé sous des systèmes d'exploitations libres.

Ajoutons à cela la mode Java qui s'installe. On avait déjà Java et une pelletée d'autre langages dont la syntaxe est voisine (Javascript, C#, J# et j'en passe), voilà maintenant qu'on voit des langages comme PHP (avec PHP5) adopter la même syntaxe boursouflée, parce que "c'est l'avenir". D'aucuns disent que c'est la syntaxe du C : c'est une erreur, en C on peut toujours faire des programmes clairs et concis. Certains vont jusqu'à dire que cette syntaxe Java-like rend obsolète celle du Python, mais mieux vaut lire de telles aberrations qu'être aveugle, regardez simplement quelques comparatifs là dessus.

L'effet Java en arrive à un point où il est difficile dans certains domaines (XML) de trouver des bibliothèques libres qui tournent autrement que sur des machines virtuelles totalement propriétaires.

Ajoutez à cela la présence d'alternative utilisables au bas mot dans 75% des cas pour lesquels Java est utilisé, au moins en ce qui concerne les logiciels libres : nous avons Python, dont les performances ne semblent pas toujours devoir craindre celles de Java et disposant d'excellentes bibliothèques et d'environnements d'une grande qualité et bénéficiant de support comme Zope, nous avons Ruby, nous avons même Perl, et PHP. Tous ces langages disposent de la portabilité, et d'environnement d'exécution de plus en plus rapides, ainsi que d'un temps d'apprentissage réduit et d'une simplicité de code souvent exemplaire. En plus des langages traditionnels, C, C++, Objective-C, Objective CAML, Lisp, Scheme, ... (Et nous ne parlons _même pas_ de la difficulté par exemple d'écrire des interfaces graphiques en Java.)

Alors maintenant, il est certain qu'avoir une machine virtuelle libre compatible avec les dernières norme Java est positif, en effet cela permet de faire tourner des logiciels libres sur des environnements libres. Maintenant, est-ce qu'il faut l'attendre pour s'intéresser au Java, personnellement, je ne le pense pas, et j'encourage les développeurs à s'intéresser à tout ce qui existe avant d'envisager utiliser Java.

À présent, si quelqu'un a des arguments concrets et réels en faveur de Java (je n'en ai vraiment quasiment jamais vu), qu'il se prononce.
- [^] # Re: Java et logiciels libres
  
  Posté par Black Fox le 26 février 2004 à 14:50. Évalué à 2.
  
  langages traditionnels, C, C++, Objective-C, Objective CAML, Lisp, Scheme, ...
  
  Je rajouterais le pascal objet avec freepascal et lazarus en libre ou Delphi/Kylix en proprio qui marchent bien et qui ont pas mal de choses OpenSource...
  - [^] # Re: Java et logiciels libres
    
    Posté par Croconux le 26 février 2004 à 20:55. Évalué à 3.
    
    Je plussoie à fond. Ma boite a eu le bon gout il y a environ 10 ans de partir sur du delphi et franchement c'est que du bonheur : Une syntaxe clean, un modèle objet proche de ce que java propose, pas de pointeurs et autres cochoneries et le plus beau tout compilé en N_A_T_I_F (et avec une consommation mémoire résonnable).
    
    Si le pascal objet était plus standardisé, je m'en foutrais royalement de java...
- [^] # Re: Java et logiciels libres
  
  Posté par Infernal Quack (site web personnel) le 26 février 2004 à 14:51. Évalué à 6.
  
  À présent, si quelqu'un a des arguments concrets et réels en faveur de Java (je n'en ai vraiment quasiment jamais vu), qu'il se prononce.
  
  Java c'est bien parce qu'on peut faire des jeux de mots débile avec.
  
  Bon java retourner travailler moi ;)
  L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
  - [^] # Re: Java et logiciels libres
    
    Posté par Pierre Tramonson le 26 février 2004 à 15:03. Évalué à 2.
    
    Java la tête ?
    
    --->[on va se faire moinsser]
    - [^] # Re: Java et logiciels libres
      
      Posté par JMVF le 26 février 2004 à 15:55. Évalué à 0.
      
      mais non, java être gentil :)
    - [^] # Re: Java et logiciels libres
      
      Posté par Alexandre le 26 février 2004 à 16:59. Évalué à 1.
      
      si javabien, c'est que javamine !
      
      (dehors)
      - [^] # Re: Java et logiciels libres
        
        Posté par AlexZl le 26 février 2004 à 18:10. Évalué à 1.
        
        Gloups, javalé de travers
        > ; )
- [^] # Re: Java et logiciels libres
  
  Posté par Pipo2 le 26 février 2004 à 15:01. Évalué à -1.
  
  une raison ? Pour une raison que j'ignore, 01 informatique ainsi que la plupart des SSII qui traînent par là se sont entiché de cette technologie. Les raisons, pour ces gens là, doivent exister mais ne sont probablement pas liées à la technique, à la propreté de conception ou aux besoins d'optimisation.
  Toujours est-il que 01 schtroumpf (je cite 01 comme je pourrais citer le Monde Informatique ou autres) étant le Paris-Match des décideurs informatique et les SSII les premier marchands de viande, et conditionneurs, de France, une population importante d'individus immergé dans cette idée que les technologies Java sont cohérentes et ne remettent plus en cause cette pseudo vérité et constituent un marché potentiel pour d'éventuels revendeurs ou conseilleurs (tel IBM) autres que Sun. Voilà la raison de la popularité de Java.
  Java est une usine mal dégrossie qui rajoute des couches (bugs, lenteurs, ...) entre l'OS et l'exécutable, la portabilité n'est absolument pas aussi bien assurée entre différents OS, et donc différentes JVM, que lorsqu'on utilise gcc pour du C++. Autrement dit il s'agit d'une aberration techno.
  Java est en complète contradiction avec le libre non seulement dans les faits, comme décrit ci-dessus, mais aussi dans l'esprit puisque cette obsession de la portabilité ne différe de celle du C ansi ou du C++ ansi que dans la mesure où n'est pas obligé de livrer les sources (juste du byte code imbitable).
  - [^] # Re: Java et logiciels libres
    
    Posté par Nelis (site web personnel) le 26 février 2004 à 15:31. Évalué à 1.
    
    ......
    
    Merci de nous éclairer, toi qui connait la vérité sur ce qui est bon et ne l'est pas ...
    
    Pathétique .....
  - [^] # Re: Java et logiciels libres
    
    Posté par Cook Captain le 26 février 2004 à 15:46. Évalué à 3.
    
    TROLL TROL TROLL TROLL TROLL
    
    Allez je me lance (honte à moi);
    
    Sans même parler de Python, Ruby, et XXX
    
    Le Ksh est une aberration technique
    Le C++ est une aberration technique
    Le C est une aberration technique
    Le Fortran est une aberration technique
    Et l'assembleur est le comble de l'absurdité.
    
    Messieurs dorénavant, comme Pipo2, pour éviter les sur-couches (bugguées, lentes, et mal-conçues) entre le langage, l'os et le processeur on passe tous au Langage Machine sans évidemment utiliser aucune bibliothèque de peur d'être contaminé par un mauvais développeur.
    
    ARRRrrggh, petit joueur que je suis, demain je me remets à VHDL et je me refais mon propre porcesseur avec un FPGA. Non ca vas pas, ou sonts mes transistors et mes portes NAND... J' m'en fous si ça marche pas demain je serai le roi du monde et je refabriquerai Dieu. Gniiiiiii.
    - [^] # Re: Java et logiciels libres
      
      Posté par Pipo2 le 26 février 2004 à 16:31. Évalué à 1.
      
      Non, rassure toi, il y a une existence entre le byte code et la machine.
    - [^] # Re: Java et logiciels libres
      
      Posté par Lebas Sébastien le 26 février 2004 à 19:29. Évalué à 2.
      
      je me refais mon propre porcesseur
      
      Ouais ! Et on après nous on pourra coder dessus en Assembleur comme des gorets ;)
- [^] # Re: Java et logiciels libres
  
  Posté par Matthieu Moy (site web personnel) le 26 février 2004 à 15:12. Évalué à 2.
  
  Bon, alors des arguments en faveur de Java :
  
  - On peut faire plein de trucs plutôt réservés aux langages interprêtés avant Java :
  
  * Introspection de type, manipulation des classes en temps qu'objet
  
  * Chargement dynamique de code simple
  
  * Portabilité (en théorie), sans avoir a recompiler
  
  * Garantie sur l'utilisation de la mémoire, pas de pointeur qui pointe en l'air.
  
  - Pourtant, avec les compilateurs JIT, on a des performances (CPU) acceptables. (Mais la consomation mémoire et le temps de lancement est un gros problème sur les petites et moyennes config)
  
  - Orienté objet joli et simple.
  
  - ...
  - [^] # Re: Java et logiciels libres
    
    Posté par HappyPeng le 26 février 2004 à 16:45. Évalué à 1.
    
    Tout cela est bien gentil, mais il me semble qu'on peut arriver à de telles choses grâce à des progrès en ce qui concerne le bytecode Python et la façon dont il est executé, tout en concervant de telles propriétés et poussées à leur extrême. Pour énormément d'utilisations, Java est lourd et lent alors que Python, et probablement Ruby et Perl, sont légers et rapides.
    - [^] # Re: Java et logiciels libres
      
      Posté par Gruik Man le 26 février 2004 à 19:46. Évalué à 5.
      
      Nan
      
      Java est lourd et lent, si tu veux.
      Perl est beaucoup moins lourd, mais beaucoup plus lent (sauf si le traitement consiste essentiellement en des regexps)
      Quant à python, il est encore moins lourd que PERL, mais encore plus lent.
      
      Fais le test, si tu veux: prends un problème d'algorithmique quelconque qui nécessaite un certain temps de calcul, et résouds-le en ces trois langages. Malgré les apparences, Java sera le plus rapide (même si bien plus lent que du C ou du C++)
      
      Les langages interprétés n'ont jamais eu pour but la performance brute, de toutes façons.
      
      (rha, voilà que je me mets à défendre Java, maintenant, faudrait que je maintienne une cohérence dans ma ligne éditoriale)
      - [^] # Re: Java et logiciels libres
        
        Posté par HappyPeng le 27 février 2004 à 09:16. Évalué à 1.
        
        C'est bien ce qui est dit dans les comparatifs. Si on fait de l'algorithmique pure (pas d'IO, notamment) et si l'on ne regarde pas le temps que met la VM à se lancer, Java est plus rapide. Maintenant, dans les situations réelles ... notamment lorsque l'on a des interfaces graphiques à réaliser ... il se pourrait bien que Python ait un net avantage.
        
        http://twistedmatrix.com/users/glyph/rant/python-vs-java.html(...)
        
        [^] # Re: Java et logiciels libres
        
        Posté par Gruik Man le 28 février 2004 à 00:35. Évalué à 1.
        
        Je veux bien te croire: pour une GUI, l'important n'est pas tellement la rapidité de base (l'utilisateur est plus lent encore, de toutes façons) que l'utilisation mémoire (si ça fait swapper la machine, là ça apparaîtra comme lent). Et si une application graphique exige 256 mo de ram dès qu'elle est un peu complexe (qui a dit Swing ?), c'est un vrai problème.
  - [^] # Re: Java et logiciels libres
    
    Posté par Pipo2 le 26 février 2004 à 16:45. Évalué à 2.
    
    > Bon, alors des arguments en faveur de Java :
    >
    > - On peut faire plein de trucs plutôt réservés aux langages
    > interprêtés avant Java :
    >
    > * Introspection de type, manipulation des classes en temps qu'objet
    
    Ca c'est vrai que c'est cool
    >
    > * Chargement dynamique de code simple
    
    Ca c'est vrai que c'est cool aussi
    >
    > * Portabilité (en théorie), sans avoir a recompiler
    
    Ca c'est une arnaque commerciale et au fond la recompilation ne gène que les défenseur du code fermé
    >
    > * Garantie sur l'utilisation de la mémoire, pas de pointeur qui pointe en l'air.
    
    Ca c'est cool, mais certains langage compilés, genre C++ avec STL, permettent d'éviter l'utilisation perilleuse des pointeurs et autres fonctions d'allocation à la malloc/free. En même temps, l'utilisation de pointeurs est une pratique plutôt rigolote; tout ce qui comporte un peu de risque est plus rigolo non?
    >
    > - Pourtant, avec les compilateurs JIT, on a des performances (CPU)
    > acceptables. (Mais la consomation mémoire et le temps de lancement
    > est un gros problème sur les petites et moyennes config)
    
    Je trouve qu'ici se trouve le problème principal de cette techno
    >
    > - Orienté objet joli et simple.
    
    Faux derche, ceci n'est pas un monopole de Java et reste subjectif.
    >
    > - ...
    ??
    
    Désolé, mais sur cette réponse je n'ai pas pu être agressif dans la mesure où il y a là beaucoup de chose intéressantes qui gagnent à être mises en avant. Mais je redeviendrai bête dès que possible!
- [^] # Re: Java et logiciels libres
  
  Posté par pvincent le 26 février 2004 à 17:57. Évalué à 4.
  
  Pour ma part, je viens du monde Java et je commence à m'adapter à GNU/Linux. C'est vrai que je me pose de sérieuses questions sur le langage Java et comme tu le dis, j'envisage de programmer sur d'autres langages pour conserver l'esprit du libre.
  
  Cependant si Java devient 100% libre, je pense que ca serait une bonne nouvelle.
  
  Voici qq arguments en faveur de Java :
  - premièrement Eclipse reste à mon avis le seul IDE qui propose des fonctions avancées de refactoring, cf. la méthode XP
  - le langage Java fonctionne sur un modèle de specifications (JSR) avec un protocole démocratique pour concevoir de nouvelles API
  - les spécifications ca permet de switcher proprement entres diverses implémentations : je pense à JDBC qui s'adapte à une floppée de base de données, JNDI pour les serveurs LDAP, etc...
  - le nombre de librairies en Java est assez impressionnant, et certaines librairies font référence, je pense à FOP pour le langage XSL:FO
  - Java reste un langage Objet simple et abordable, plébiscité à l'apprentissage comme Pascal l'était autrefois en tant que langage structuré
  - la programmation orientée aspect AspectJ pourrait prendre un essor considérable si à sa base Java était libre
  
  D'un autre côté, même si SUN garantissait, jusqu'à présent, un niveau d'excellence et une grande harmonie dans sa plateforme Java, il lui est arrivé aussi de pencher sur certaines technologies poussé par un lobby qui se voulait plus marketing que technologique.
  
  C'est pourquoi la question de libérer totalement Java est d'actualité.
  A mon humble avis, seule la transition à l'open-source pourrait encore sauver ce langage.
  GNU/Linux peut se passer de Java mais Java ne peut pas se passer de GNU/Linux...
  - [^] # Re: Java et logiciels libres
    
    Posté par Infernal Quack (site web personnel) le 26 février 2004 à 21:13. Évalué à 1.
    
    premièrement Eclipse reste à mon avis le seul IDE qui propose des fonctions avancées de refactoring, cf. la méthode XP
    
    Désolé mais IDEA l'explose méchament :)
    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
    - [^] # Re: Java et logiciels libres
      
      Posté par niavlys le 27 février 2004 à 10:42. Évalué à 2.
      
      ouais mais IDEA sapucepalibre!!
# Re: IBM demande à Sun de "libérer" Java

Posté par Pipo2 le 26 février 2004 à 14:44. Évalué à -1.

Bon, question, quel est l'intérêt d'IBM de demander ça ? Comprends pô.

Java est un produit développé par une société d'informatique (Sun microsystem) pour des utilisateurs appartenant à une branche d'activité proche de l'informatique.

Un type qui crache des lignes interprétables par une JVM n'est pas un développeur sans ça il se rapprocherait du système, non pas pour se compliquer la vie contrairement à ce qu'affirment certains, mais surtout pour répondre aux deux tiers des problèmes qui font le métier d'un informaticien à savoir, les performances et la stabilité: la conception n'est pas la seule qualité demandée et elle ne s'appuie en rien, de toute façon, sur le langage futurement employé. Qu'on se rassure, Sun est une société sérieuse et les produits qui constituent leur fer de lance commercial ne sont pas développés en Java; Cf. la JVM elle-même. Aucune critique dans mes propos, je tiens juste à distinguer les fournisseurs (Sun) des utilisateurs ("développeurs" Java).

Pour conclure donc, pourquoi IBM ne demande pas l'ouverture du code d'Access par Microsoft utilisé par de bien plus nombreux pseudo-développeurs que Java que diantre. Et que pourrait bien apporter l'ouverture de la JVM?
Explication: quand des informaticiens du libre éprouvent le besoin de développer un produit, ils montent un projet pour le faire. Hors les seuls intéressés par une JVM sont les "développeurs" Java qui, comme le libellé l'indiquent, sont à priori incompétents pour développer une JVM: hé oui, il s'agit là d'un interpréteur fichtrement compliqué à concevoir et impossible de penser que cela puisse tourner en Java également ne serait-ce que pour des questions de performance. Donc ?
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par franck (site web personnel) le 26 février 2004 à 14:50. Évalué à 2.
  
  java n'est PAS un produit développé par SUN ...
  
  java est un language controllé par sun dont SUN fournit un jvm (ainsi que IBM)
  
  tu mélanges tout ....
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Pipo2 le 26 février 2004 à 15:10. Évalué à 1.
    
    Désolé ma puce, mais développer un langage revient à développer l'interpréteur autrement dit la JVM. Historiquement Sun inventa le Oak pour la domotique qui n'a jamais pu se développer.
    Oak, meublé pour faire Java, s'est donc appelé Java suivant les mêmes principe de fonctionnement fondés sur la possibilté de télécharger la couche logique d'une application pour faire fonctionner un appareil déjà équipé des classes de base -> les applets ou comment adapter un projet foireux de domotique à un monde naissant: Internet. Super bonne idée.
    
    Par la suite, quelques utilisateurs limités en développement ont émis l'idée de concevoir des programmes standalone dans cette techno absolument pas prévue pour ça à la base et Sun a sauté sur l'occasion pour en arriver à la situation actuelle où les servlet sont des fast CGI pour développeur pauvre (en connaissances).
    
    Si IBM a raccroché son wagon c'est bien pour eux mais pour Sun reste le dépositaire de toute innovation ayant trait à Java.
    
    Conclusion: je ne mélange pas tout, mais je ne suis pas un affectif et je ne fais pas dans la nuance bien pensante comme toi: je cherche juste à développer un troll assez monstrueux pour me détendre et pour me vanter à la machine à café.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par franck (site web personnel) le 26 février 2004 à 15:14. Évalué à 4.
      
      c'est triste ta vision sur la plateforme java ...
      
      et tu confond toujours language java, plateforme java et jvm ...
      
      et IBM ne demande pas à SUN de libérer sa jvm ...
      
      et tes trolls sont trop visible et mal réaliser
      
      et tu connait très mal java (ou alors tu troll très mal)
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Pipo2 le 26 février 2004 à 15:42. Évalué à 1.
        
        Tu as répondu! Mon troll est correct. On ne dit pas d'un troll qu'il est nul lorsqu'on vient de marcher dans ses excréments.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par boubou (site web personnel) le 26 février 2004 à 15:57. Évalué à 1.
        
        Juste une petite remarque : quand on parle de troll, il ne s'agit pas des bestioles sympathiques du folklore nordique ou de leurs versions tolkienesque, mais d'un verbe anglais qui désigne une technique de pèche (cf http://info.astrian.net/jargon/terms/t/troll.html(...)). Je doute qu'on puisse marcher dans ses excréments.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Pipo2 le 26 février 2004 à 17:13. Évalué à 1.
        
        Tout le monde fait des excréments, même les techniques de pêche et même les anglais. On peut marcher dans ses excréments si on ne fait pas attention monsieur. Et puis moi je préfère le folklore nordique que les verbes anglais, sans blague.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Aldoo le 26 février 2004 à 19:19. Évalué à 1.
        
        Non !
        Il y a d'autres interprétations !!!
        
        http://www.uzine.net/article1032.html(...)
        
        .... et puis d'abord, comment une technique de pêche peut-elle être poilue ?
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par Nelis (site web personnel) le 26 février 2004 à 15:35. Évalué à 0.
      
      J'ai rarement vu qq'un avec un égo comme le tiens ... J'ai remarqué que ça arrivait souvent à ceux qui parlaient pour ne rien dire ...
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Pipo2 le 26 février 2004 à 15:46. Évalué à 1.
        
        Un ego? Mais je n'ai pas parlé de moi!
        En revanche il est vrai que mon discours revêt peu de valeur mais d'ici à affirmer qu'il ne veut rien dire c'est bien peu de respect pour le temps passé à rédiger cette négative chose.
        
        [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Nelis (site web personnel) le 26 février 2004 à 16:18. Évalué à 0.
        
        Par la suite, quelques utilisateurs limités en développement ont émis l'idée de concevoir des programmes standalone dans cette techno absolument pas prévue pour ça à la base et Sun a sauté sur l'occasion pour en arriver à la situation actuelle où les servlet sont des fast CGI pour développeur pauvre (en connaissances).
        
        Que de toi ??
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par boubou (site web personnel) le 26 février 2004 à 14:54. Évalué à 2.
  
  Ta démonstration serait formidable si elle ne s'appuyait pas sur des erreurs factuelles importantes. Tout d'abord, les JVM libres existent, elles sont même assez nombreuses. Le problème est le JRE, c'est-à-dire l'ensemble constitué de la JVM et des classes de base. Or, ces classes de base sont en grande partie développée en Java, dans le JRE de Sun lui même. Quand IBM demande l'ouverture de Java, c'est bien du JRE qu'il s'agit et les développeurs Java sont parfaitement compétents pour participer à son développement (cf classpath, d'ailleurs).
  
  De plus, il existe une JVM open source et entièrement (ou presque) écrite en Java. L'ironie du sort veut qu'elle soit justement écrite par IBM (cf http://www-124.ibm.com/developerworks/opensource/jikesrvm/(...)). Les divers échos que j'en ai eu sont qu'elle tourne plutôt efficacement, à condition, comme toujours en Java, d'avoir une mémoire conséquente.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par Pipo2 le 26 février 2004 à 15:12. Évalué à -2.
    
    Ha ouai! Je me demandais si certains osaient utiliser Kaffe pour leur exploit. On en a trouvé un: chapeau bas.
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par HappyPeng le 27 février 2004 à 09:20. Évalué à 1.
    
    Le problème de cette VM libre semble ne pas venir d'elle-même mais justement des bibliothèques standard nécessaire pour faire tourner les logiciels en Java, puisque celle-ci se fonde sur GNU Classpath, comme GIJ, or elle n'est pas compatible J2SE 1.4 et n'inclue pas (ou inclue partiellement) Swing.
# JAVA Sun | EGL IBM

Posté par Dalton joe le 26 février 2004 à 14:46. Évalué à 1.

pourquoi Sun libererait il JAVA alors qu'IBM lance EGL ?

http://www-106.ibm.com/developerworks/websphere/techjournal/0304_ba(...)
# Re: IBM demande à Sun de "libérer" Java

Posté par kruskal le 26 février 2004 à 16:02. Évalué à 1.

Hum, si quelqu'un peut m'eclairer, il sera le bienvenu.

Le contrat entre IBM et Sun interdit il a IBM de liberer son propre JDK ?
Si oui, cela s'applique t-il aussi si ce JDK etait distribué en OpenSource sans utiliser la marque Java ?
IBM aurait il le droit d'injecter du code de son propre JDK dans gcj (par exemple) qui n'utilise pas la marque Java ?

En tout cas, pour moi qui me refusait a toucher a Java, justement a cause du manque de bases libres, je ne peut que me réjouir a cette perspective. Esperons que la démarche d'IBM réussira.
- [^] # Re: IBM demande à Sun de "libérer" Java
  
  Posté par franck (site web personnel) le 26 février 2004 à 16:22. Évalué à 1.
  
  1) c'est le droit d'utiliser le terme java et d'être considéré comme tel qui n'est pas libre
  
  2) tu peux distribuer en GPL un truc que tu appellera Wisual K ++ qui a l'odeur de java et qui fait tout comme java ... mais comme personne ne l'utilisera (tu sais ... les gars en cravate ...)
  
  3) si la licence choisit par IBM pour sa jvm le permettait ET que la licence de gcj était compatible oui (en pratique non)
  
  le problème de java n'est le manque de liberté des jvm (quoi que) mais l'impossibilité de faire une jvm en GPL (par exemple) qui puisse s'appellé java après avoir été recompilé/modifier ...
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par kruskal le 26 février 2004 à 16:44. Évalué à 1.
    
    "2) tu peux distribuer en GPL un truc que tu appellera Wisual K ++ qui a l'odeur de java et qui fait tout comme java ... mais comme personne ne l'utilisera (tu sais ... les gars en cravate ...)"
    
    Oui les gars en cravate, mais on s'en fout, ca nous permettrait au moins d'avoir un clone de java libre et complet. Les gens du libre s'en tripotent un peu que ca s'apelle java ou pas.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par franck (site web personnel) le 26 février 2004 à 17:00. Évalué à 0.
      
      bin les gens du libre n'ont cas le coder ... c'est bien le problème ... :-(
      
      et ça explique gcj ...
  - [^] # Re: IBM demande à Sun de "libérer" Java
    
    Posté par kruskal le 26 février 2004 à 19:56. Évalué à 1.
    
    "2) tu peux distribuer en GPL un truc que tu appellera Wisual K ++ qui a l'odeur de java et qui fait tout comme java ... mais comme personne ne l'utilisera (tu sais ... les gars en cravate ...)"
    
    Maintenant que j'y repense, si c'est moi qui sort ce truc, bien sur que ca marchera pas, mais si c'est IBM ? Ils ont les moyens de "forker" Java en opensource nan ? Et meme si ils peuvent pas utiliser la marque Java, ils ont quand meme la force commerciale qu'il faut pour que ce soit utilisé.
    - [^] # Re: IBM demande à Sun de "libérer" Java
      
      Posté par ASpirit le 26 février 2004 à 22:34. Évalué à 1.
      
      Ils ont les moyens de "forker" Java en opensource nan ?
      
      Dans ce cas je crois que l'on dit "faire un clone de Java"... un fork étant la reprise d'un code existant pour faire un nouveau projet...
      
      Je doute que SUN veuille bien donner ses sources à IBM pour qu'il en fasse un fork ;o).
      
      ----
      
      IBM a les moyens... ça reste à voir, mais en tous cas ils ont surtout envie d'en gagner de l'argent... alors s'ils peuvent exploiter ce qui est déjà existant, ils le feront.
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par Moby-Dik le 27 février 2004 à 01:58. Évalué à 1.
        
        J'ai entendu dire que Sun n'avait rien réellement inventé et que tout le code venait de SCO. Ca expliquerait certaines choses...
      - [^] # Re: IBM demande à Sun de "libérer" Java
        
        Posté par kruskal le 27 février 2004 à 10:23. Évalué à 1.
        
        D'ou les guillemets autour du mot "forker"
        Il fallait bien sur comprendre qu'Ibm pourrait partir de sa propre Jvm pour faire cela.
        Mais il semblerait que les classes livrees dans le jre d'Ibm soient celles ecrites par Sun..... Comme quoi Ibm a le meme probleme que gcj, classpath, kaffe: c'est vraiment un énorme boulot.
# Remettons les pendules à l'heure

Posté par Moby-Dik le 26 février 2004 à 18:26. Évalué à 2.

« If you can't do it in Fortran, do it in assembly language. If you can't do it in assembly language, it isn't worth doing. »

http://www.pbm.com/~lindahl/real.programmers.html(...)
# rapide

Posté par arslan le 26 février 2004 à 20:47. Évalué à 1.

J'ai appris plus en une demi-heure de lecture de cette page qu'en plusieurs des tutoriels sur les differents langages de programmation (on inspire).

Au fait vous me conseillez....

Hé ! poussez-pas ! Cette porte mene a Troy...
# Des utilisateurs heureux de Java

Posté par crusher le 26 février 2004 à 21:26. Évalué à 7.

Devant les nombreuses critiques sur java dans les réponses précédentes,
et voyons peu de réponses positives, je me permet de vous déclarer que nous sommes des utilisateurs heureux de java.
En effet, nous utilisons Java dans notre société pour un site internet + serveur applicatif + serveur JMS + batches d'import/export
dans un environnement de production sur des sun/solaris et des PC pour le développement.
Et bien ça fonctionne trés bien !!!

Effectivement Java est gourmand en RAM (compter au moins 250Mo uniquement pour le process java
pour être à l'aise dans un process qui reste longtemps en mémoire),
mais si votre appli est bien développé (pas de memory leak) cela reste stable grace au garbage collector.
Donc si vos serveurs sont bien dimensionner dès le départ, la place en RAM n'est pas un problème.
Cela peut peut-être un problème de coût financier mais même sans prendre en compte le fait
que le prix RAM baisse continuellement, le confort/sécurité/fiabilité de développement en java vaut le cout/coup.

Au niveau des performances, on va essayer d'être concret:
Cela fait plus de 5 ans qu'on bosse en java sur le même site et
la majorité des problèmes de performance que l'on a eu venait:
- des requetes SQL
- d'algorithmes pas assez efficace,
- d'erreurs de programmation ( memory leak, boucle sans fin)
- ...
Les problèmes de performances spécifiques au langage java ne nous sont pas prioritaire par rapport à tous les autres.
On n'est pas borné non plus et si jamais on a un problème de perf. sur
un point précis java comme par exemple des traitements numériques massifs, vidéo ou autres
on externaliserait ces traitements dans une lib en C ou autre mais appelé en Java via JNI.

Voila, je voulais rassurer ceux qui aiment java ou qui s'interrogent,
que oui java en environnement professionnel c'est viable et utilisé par mal de sociétés (enfin au moins nous :-).

PS.: Désolé que ce soit hors sujer par rapport au thème, mais je vois rarement des réponses positives sur java
- [^] # Re: Des utilisateurs heureux de Java
  
  Posté par Bungee Tux le 26 février 2004 à 23:07. Évalué à 3.
  
  J'ai developpé pendant 2 ans sous Java, un projet de simulateur Radar dans un service R&D au sein de Thales Air Defence.
  
  Et franchement Java n'a pas a rougir. Il est plus rapide que le mathlab cher a ce service et il permet de développer tout aussi rapidement (du moins un projet complet).
  
  Python, Perl et autres ont beau être bourrés de sucrerie syntaxique et d'approches sympas avec des exemples en dix lignes de codes qui font bcp de choses. Leur librairie est bien moins homogène et documentée que la librairie de base de Java.En plus, y'a quasiment tout dans cette librairie. De l'ihm aux expressions régulières en passant par le XML, la sérialisation, la compression de données, les undo/redo, l'accès aux bases de données etc ...
  
  C n'est pas un langage objet et ne correspond pas a la demande en logiciel de plus en plus sophistiqué.
  
  C++ n'est qu'un amoncellement d'ajouts pour permettre au programmeur toutes les dernières folies. Un jour peut être finiront t'il par nettoyer une bonne fois pour toutes la gestion des pointeur, l'allocation dynamique et autre qui finissent par couter très cher en temps de développement sur une appli ou on chercher tous les bugs.
  - [^] # Re: Des utilisateurs heureux de Java
    
    Posté par #3588 le 26 février 2004 à 23:13. Évalué à -1.
    
    « C++ n'est qu'un amoncellement d'ajouts pour permettre au programmeur toutes les dernières folies. »
    
    Permettre des choses que Java ne permet pas toujours, et qui le disqualifie.
    
    « Un jour peut être finiront t'il par nettoyer une bonne fois pour toutes la gestion des pointeur »
    
    Très souvent on peut s'en passer, encore faut-il le faire.
    
    « l'allocation dynamique et autre qui finissent par couter très cher en temps de développement sur une appli ou on chercher tous les bugs. »
    
    Là c'est le comble ! Java ne fait que de l'allocation dynamique ! Au moins C++ permet de faire de l'allocation automatique. Et si c'est un ramasse-miettes qui te manque, eh bien il suffit d'en mettre un.
    - [^] # Re: Des utilisateurs heureux de Java
      
      Posté par babar33 le 26 février 2004 à 23:24. Évalué à 1.
      
      Je suis totalement ok sur l'amoncellement d'ajouts pour faire plaisir aux programmeurs. Et non, ca ne disqualifie pas java, il faut juste penser la conception correctement.
      
      J'aimerai bien un example disqualifiant comme tu dis ...
      
      Personnellement, pour avoir commencer l'objet en c++, et avoir continuer en java, je produis plus rapidement un code de meilleure qualité en java, et c'est ca le plus important au final.
      
      Je trouve qu'il est plus facile de relire du mauvais code java que du bon code c++
      - [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 26 février 2004 à 23:59. Évalué à -1.
        
        « Je suis totalement ok sur l'amoncellement d'ajouts pour faire plaisir aux programmeurs. »
        
        Ce n'est pas « pour faire plaisir », c'est pour être utile.
        
        « Et non, ca ne disqualifie pas java, il faut juste penser la conception correctement. »
        
        Rien à voir. La conception est aussi importante dans les deux cas.
        
        « J'aimerai bien un example disqualifiant comme tu dis ... »
        
        Les plus évidents:
        
        - l'absence de templates, on ne peut s'en sortir que de manière crade (classe Object).
        - les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente).
        - l'absence des foncteurs (si ma mémoire est bonne) - c'est vrai que sans templates, sans conteneurs en sémantique de valeur etc. c'est moins utile, mais l'ensemble permet de faire des choses efficaces et propres
        - tout ce qui incite à ne faire que de la sémantique d'identité
        - dans une moindre mesure : pas de surcharge d'opérateurs, pas d'héritage multiple (oui ça sert à faire des choses propres)
        - les destructeurs dont l'appel n'est pas garanti
        
        « Personnellement, pour avoir commencer l'objet en c++, et avoir continuer en java, je produis plus rapidement un code de meilleure qualité en java, et c'est ca le plus important au final. »
        
        Qu'est-ce qui te permets de dire qu'il est de meilleure qualité, si tu as arrêté le C++ en cours de route ? Et tu parles toujours des aspects objets, ou d'autre chose ?
        
        « Je trouve qu'il est plus facile de relire du mauvais code java que du bon code c++ »
        
        Ça ce n'est qu'une question d'habitude. J'ai aussi fait des deux, et je fais surtout du C++ maintenant, je trouve Java moins lisible. La SL est sûrement plus ardue à appréhender, mais plus lisible une fois qu'on s'y est investi.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 09:45. Évalué à 0.
        
        - l'absence de templates, on ne peut s'en sortir que de manière crade (classe Object).
        
        Java 1.5 propose des templates bien plus intéressants et propres que ceux du C++.
        
        les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente).
        
        Qu'est-ce que c'est que ce délire ? Tu as déjà entendu parler de final qui permet de faire exactement la même chose que l'absence de virtual en C++ ? Et quel est le rapport avec les pré et post conditions ?
        
        l'absence des foncteurs
        
        De quoi parle tu, des foncteurs de caml ?
        
        pas de surcharge d'opérateurs
        
        Très gênant, nous sommes d'accord.
        
        pas d'héritage multiple (oui ça sert à faire des choses propres)
        
        C'est sûr, quand on ne comprend rien à la conception objet, c'est très utile.
        
        les destructeurs dont l'appel n'est pas garanti
        
        Il n'y a pas de destructeurs, mais des finalizers dont le but n'est absolument pas le même. De toute manière, si tu as besoin des finalizers, c'est certainement que tu devrais programmer ton appli autrement.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 15:47. Évalué à 0.
        
        « Java 1.5 propose des templates bien plus intéressants et propres que ceux du C++. »
        
        Il y a une incohérence dans ta phrase : un verbe au présent. Quand ce sera du concret, j'enlèverai ce manque, mais pas avant.
        
        « Qu'est-ce que c'est que ce délire ? Tu as déjà entendu parler de final qui permet de faire exactement la même chose que l'absence de virtual en C++ ? Et quel est le rapport avec les pré et post conditions ? »
        
        final et non-virtual c'est pas la même chose. Ah, ça y ressemble de loin, dans le détail non.
        Et si tu ne vois pas le rapport avec les pré/post conditions vérifiées dans une interface, ton commentaire suivant sur « comprendre la conception objet » est assez comique.
        
        « De quoi parle tu, des foncteurs de caml ? »
        
        Non des foncteurs de C++. Mais là j'ai dit que je n'étais pas sûr de l'absence d'équivalent. Si tu en vois...
        
        « C'est sûr, quand on ne comprend rien à la conception objet, c'est très utile. »
        
        Ca fait partie de la conception objet, et ça ne pose strictement aucun problème en conception. C'est dans la réalisation qu'il y a problème. Ce n'est pas une raison valable pour l'interdire. Et ça reste à utiliser à bon escient, mais c'est comme tout.
        
        « Il n'y a pas de destructeurs, mais des finalizers dont le but n'est absolument pas le même. De toute manière, si tu as besoin des finalizers, c'est certainement que tu devrais programmer ton appli autrement. »
        
        Oui en faisant un destructeur (c'est le terme générique) que l'on est obligé d'appeler manuellement avant de supprimer la dernière référence. Super propre.
        
        Ta réponse résume le problème de Java : des choix ont été faits, arbitrairement, faites selon cette méthode, pas la votre. C'est pas la meilleure ? Tant pis, c'est celle de Java. Le résultat c'est que Java n'est pas assez généraliste, et que du coup on trouve des langages plus adaptés, pour la plupart des problèmes. A part les applications web, et quelques autres niches. C'est dommage pour ce langage qui a pas mal de qualités, par ailleurs.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 16:24. Évalué à 2.
        
        Il y a une incohérence dans ta phrase : un verbe au présent. Quand ce sera du concret, j'enlèverai ce manque, mais pas avant.
        
        Java 1.5 est disponible en version beta, tu peux tester. La plupart des concepts derrière l'implémentation actuelle datent de gj, une extension de Java qui a au moins 5 ou 6 ans et qui est une technologie très éprouvée. C'est du concret.
        
        final et non-virtual c'est pas la même chose. Ah, ça y ressemble de loin, dans le détail non.
        Et si tu ne vois pas le rapport avec les pré/post conditions vérifiées dans une interface, ton commentaire suivant sur « comprendre la conception objet » est assez comique.
        
        Oui, oui, bien sûr. Donne un exemple et on va voir. Si ton seul argument est que C++ perd le type d'un objet passé par valeur, nous sommes d'accord, il y a bien une différence entre non virtual et final, mais si tu arrives à défendre ça en terme de conception objet, je te tire mon chapeau.
        
        Non des foncteurs de C++. Mais là j'ai dit que je n'étais pas sûr de l'absence d'équivalent. Si tu en vois...
        
        Classes anonymes et interface. Tu connais bien Java, ça fait peur. Tu n'a pas pratiqué depuis la version 1.1 ?
        
        Oui en faisant un destructeur (c'est le terme générique) que l'on est obligé d'appeler manuellement avant de supprimer la dernière référence. Super propre.
        
        T'as tout compris, ça se sent. C'est clair que quand on supprime la dernière référence en Java, on a la super classe et on connaît bien le langage. Aller, je suis de bonne humeur (faut dire que tu es très drole), je t'explique. Si un objet accapare une ressource unique qui doit être relachée à un moment ou à un autre, tu peux utiliser le destructeur de l'objet en C++ pour lui faire relacher cette ressource : c'est un idiome de programmation C++ qui vaut ce qu'il vaut. Il est totalement incompatible avec la notion même de GC dans laquelle on ne sait jamais quand on objet va être détruit (ce qui est bien plus efficace en terme de gestion de la mémoire, d'ailleurs). En Java et en général dans les langages avec GC, tu ne peux pas utiliser cet idiome, donc tu programmes proprement avec un autre idiome. Par exemple, tu fabriques un objet qui prend comme paramètre du code à faire tourner (implémenter par une classe anonyme), qui récupère la ressource, exécute le code, puis relache la ressource.
        
        De toute manière, si tu as vraiment besoin d'utiliser des ressources uniques critiques, en général tu as vraiment intérêt à faire du J2EE car le serveur d'application gère ces ressources à ta place de façon très efficace. Mais j'oubliais que Java ne sert qu'à faire du web, idiot que je suis.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 17:32. Évalué à -1.
        
        « Java 1.5 est disponible en version beta, tu peux tester. La plupart des concepts derrière l'implémentation actuelle datent de gj, une extension de Java qui a au moins 5 ou 6 ans et qui est une technologie très éprouvée. C'est du concret. »
        
        Une version beta ce n'est pas du concret. Quand ce sera stable, ce sera un bon point. Pour l'instant on peut seulement dire : « cet inconvénient sérieux disparaîtra, à plus ou moins long terme ». J'attends le jour où ce sera dans les java libres, d'ici là ça ne vaut rien.
        
        « Oui, oui, bien sûr. Donne un exemple et on va voir. »
        
        Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition.
        
        « Classes anonymes et interface. Tu connais bien Java, ça fait peur. Tu n'a pas pratiqué depuis la version 1.1 ? »
        
        Et toi tu ferais pas mal de lire (ou plus dur : réfléchir) avant de répondre. Tiens lis donc ma remarque initiale pour voir à quel point tu réponds à coté.
        
        « En Java et en général dans les langages avec GC, tu ne peux pas utiliser cet idiome, donc tu programmes proprement avec un autre idiome. »
        
        C'est bete, des langages utilisent cet idiome. Celui que tu présente s'appelle plutot « bidouille pour compenser une faiblesse ».
        
        « Mais j'oubliais que Java ne sert qu'à faire du web, idiot que je suis. »
        
        Non il ne sert pas qu'à ça, il est idéal pour ça. Il est idéal pour l'enseignement. Au cas par cas, on trouve souvent plus adapté, mais il peut très bien s'en sortir. L'inconvénient est surtout qu'il est frustrant car il ne permet pas de faire des choses propres, à cause de restrictions idiotes.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 17:53. Évalué à -1.
        
        Comme je m'attends à une bonne dose de mauvaise foi, je complète :
        
        « Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition. »
        
        Pour résumer simplement, plutot que d'entrer dans chaque détail : C++ a ce qu'il faut pour faire des contrats. L'approche Java des fonctions virtuelles pose problème, entre autres par l'absence de fonctions virtuelles privées.
        
        Bien sûr la solution encore plus propre c'était d'intégrer les contrats au langage, c'est même ce que Gosling aurait souhaité. Mais au final ça n'y est pas, et il n'y a pas de solution pour faire les choses proprement.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 18:58. Évalué à 0.
        
        Comme je m'attends à une bonne dose de mauvaise foi, je complète :
        
        Tu es formidable. Tu te rends compte que tu as au mieux mélangé un peu tout et hop, en avance, tu évacues toute contestation par une sympathique accusation de mauvaise foi. Pathétique.
        
        Donc, si j'ai bien lu entre les lignes, tu proposes de créer une classe abstraite avec une méthode bidule non virtuelle qui contient des tests (pré/post conditions, etc.) et qui appelle une méthode bidule_interne qui est elle virtuelle et privée.
        
        Effectivement, en Java, on ne peut pas faire exactement ça pour deux raisons :
        
        1) l'absence d'héritage mutliple fait qu'on ne peut pas faire ça pour plusieurs classes abstraites
        2) la méthode bidule_interne ne peut pas être private mais protected (franchement, ce n'est pas un drame)
        
        Et oui, les primitives de contrôle d'accès de C++ sont plus riches que celles de Java et le langage supporte l'héritage multiple. Je n'ai jamais dit le contraire. Ceci étant, explique moi en quoi ceci démontre la différence entre le final de Java et le virtual de C++ et on verra qui est le plus de mauvaise foi.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 19:16. Évalué à -3.
        
        Bien essayé mais c'est toi qui détourne le sujet : la question est, et a toujours été les « manques » de Java, ou ses limitations, qui empêchent de faire des idiomes qui ne sont pas réputés pour être sales. Les contrats, c'est un des meilleurs exemples. Et il y en a d'autres, moins importants, qu'on peut contourner. C'est la question initiale, et tes posts ne servant qu'à détourner de ce sujet, je m'en cogne pas mal. Merci bien pour la causette.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 19:23. Évalué à -1.
        
        Ce que j'adore avec toi, c'est ton caractère borné. Je n'ai jamais dit que Java était formidable et bien meilleur que C++, j'ai juste mis en cause certains éléments de tes critiques. Et maintenant que tu te rends compte que tu t'es lourdement trompé, tu oublies tes délires sur final/virtual pour revenir à un élément sur lequel tu as partiellement raison. C'est affligeant.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 20:31. Évalué à -2.
        
        « Et maintenant que tu te rends compte que tu t'es lourdement trompé, tu oublies tes délires sur final/virtual pour revenir à un élément sur lequel tu as partiellement raison. C'est affligeant. »
        
        Non, je ne me suis pas lourdement trompé, j'ai parlé d'un exemple à quelqu'un qui en demandait. IL était à mon avis suffisamment explicite, tu as jugé que non, tu as demandé des détails et tu les as eus. Je n'y suis pas revenu dans ce post pour te rappeler quel était le véritable objet du fil. J'y ai par contre répondu plus bas en faisant une seconde réponse. Mais ça ne vient que de ta difficulté à comprendre cet idiome pourtant courant, Le problème je l'ai résumé correctement dès le premier post : Java ne propose pas de fonctions non-virtuelles (final c'est autre chose, ça ramène plus que ça) ce qui pose problème pour mettre de la vérification de pré/post conditions dans une interface.
        
        « Je n'ai jamais dit que Java était formidable et bien meilleur que C++ »
        
        Et ? Je n'ai pas dit le contraire, mais figure toi que tu n'es pas le seul participant à ce fil. J'ai répondu, en premier lieu, à quelqu'un qui voulait des exemples de faiblesse de Java, donc je te rappelle que c'est ça le sujet, malgré tes remarques pointilleuses (et surtout sans intérêt, puisque j'avais donné le point essentiel de la critique dès le début).
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 19:23. Évalué à -1.
        
        J'oubliais:
        
        « Ceci étant, explique moi en quoi ceci démontre la différence entre le final de Java et le virtual de C++ et on verra qui est le plus de mauvaise foi. »
        
        final n'est pas acceptable quand on veut du non-virtual uniquement (donc permettre ce que final n'autorise pas : des fonctions avec le nom en question). Et s'il n'y a pas de final, il n'y a pas de fonctions non-virtuelles, donc la vérification du contrat peut être modifiée par le client, ce qui est un léger problème.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 19:27. Évalué à 2.
        
        Pour ton exemple, ca n'a aucun rapport avec final, mais avec la sémantique du private en Java. Pour le reste, je ne comprends rien à ton charabia (permettre ce que final n'autorise pas : des fonctions avec le nom en question qu'est-ce que ça veut dire ?).
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 20:47. Évalué à -1.
        
        « Pour ton exemple, ca n'a aucun rapport avec final, »
        
        Ca tombe bien, c'est toi qui a commencé à parle de final, comme solution au problème que j'évoquais. Ce que je disais en premier lieu : « les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface ».
        
        « Pour le reste, je ne comprends rien à ton charabia »
        
        Un expert comme toi n'a sans doute pas besoin de ce qu'il y a entre parenthèses. Contente toi de ce qu'il y a devant : le final de Java n'est pas l'exact contraire de l'absence de virtual en C++. J'avais dit « final n'est pas acceptable quand on veut du non-virtual uniquement », tu as l'air de ne pas vouloir comprendre. Je ne dis pas qu'un final ne peut jamais faire l'affaire, mais qu'il peut être jugé inacceptable.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 28 février 2004 à 14:32. Évalué à 3.
        
        final n'est pas acceptable quand on veut du non-virtual uniquement
        
        Mais donne le ton exemple ! C'est quoi ton problème, tu n'as pas d'exemple, c'est ça ? Par ce que franchement, je ne vois pas de problème lié à final/virtual (éventuellement aux différences de sémantique entre les privates et bien entendu en raison de l'absence d'héritage multiple).
        
        Tu as bien dit au départ : "les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente)."
        
        Voici donc un exemple en Java. Bidule est une "interface" dans laquelle on implémente les pré/post condition.
        
        public abstract class Bidule {
        protected abstract void versionInterne();
        public final void versionExterne() {
        // précondition
        versionInterne();
        // postcondition
        }
        }
        
        Truc est une implémentation de l'interface.
        
        public class Truc extends Bidule {
        protected void versionInterne() {
        System.out.println("Et hop");
        }
        }
        
        Quelles sont les différences avec un design pattern équivalent en C++ :
        
        1) pas d'héritage multiple, donc des limitations pratiques du schéma en Java : je suis d'accord, l'héritage multiple apporte beaucoup sur ce genre d'exemple
        
        2) il est impossible de mettre versionInterne en private en Java : soit, c'est une limitation, mais personnellement elle ne me choque pas plus que ça.
        
        Tu en trouveras sûrement d'autres, mais je ne vois toujours pas en quoi avoir des fonctions virtuelles par défaut pose un problème sur cet exemple. Et je maintiens qu'il n'y pas de différences importantes entre final/virtual. Ce que tu as mentionné plus haut (le fait qu'on puisse redéfinir une fonction même si elle n'est pas marquée virtual en C++) est une différence factuelle, mais elle permet de telles horreurs sémantiques en C++ que tout programmeur qui se respecte devrait l'oublier.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 28 février 2004 à 15:14. Évalué à 0.
        
        « Tu en trouveras sûrement d'autres, mais je ne vois toujours pas en quoi avoir des fonctions virtuelles par défaut pose un problème sur cet exemple. Et je maintiens qu'il n'y pas de différences importantes entre final/virtual. Ce que tu as mentionné plus haut (le fait qu'on puisse redéfinir une fonction même si elle n'est pas marquée virtual en C++) est une différence factuelle, mais elle permet de telles horreurs sémantiques en C++ que tout programmeur qui se respecte devrait l'oublier. »
        
        Eh bien si pour toi l'approximation final = non-virtual te convient, ne prend pas cet argument comme inconvénient, que veux-tu que je te dise. Je donnais un exemple à une personne, au cours de la discussion on a parlé de 2 autres aspects encore plus genants dans le meme idiome, si ce sont les seuls qui te paraissent pertinents ne tient compte que de ceux là.
        
        Ailleurs quelqu'un me disait à propos de cette liste qu'aucun exemple ne correspondait à son utilisation. Eh bien tant mieux, dans ce cas il ne rencontre pas ces inconvénients. Si je fais une liste d'inconvénients, je n'ai pas la prétention de dire que ce sont des inconvénients pour tout le monde et dans toutes les situations ! Il fallait juste des exemples, ou plutot des contre-exemples histoire de dire que ça existe. Suivant la manière dont on programme, certains paraitront pertinents, d'autres pas du tout.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 28 février 2004 à 15:28. Évalué à 1.
        
        Eh bien si pour toi l'approximation final = non-virtual te convient, ne prend pas cet argument comme inconvénient, que veux-tu que je te dise.
        
        Serait-ce une retraite honteuse ? Tu ne réponds toujours pas sur le fond : pourquoi final ne permettrait il pas de faire proprement cette histoire de contrat ? Qu'est-ce qui n'est pas propre dans ma construction (oui, je sais, elle est limitée par l'absence d'héritage multiple) ?
        
        Je donnais un exemple à une personne, au cours de la discussion on a parlé de 2 autres aspects encore plus genants dans le meme idiome, si ce sont les seuls qui te paraissent pertinents ne tient compte que de ceux là.
        
        Ce sont surtout les seuls réels. Tu as trouvé un argument très pertinent pour justifier l'héritage multiple : bravo, ce ne pas si évident et je trouve ton exemple très convainquant (et je retire donc mon ". C'est sûr, quand on ne comprend rien à la conception objet, c'est très utile." qui visait l'héritage multiple). Mais pourquoi t'obstiner sur une interprétation foireuse de ton propre exemple ? Donne moi un seul exemple dans lequel l'hérésie du C++ (je peux redéfinir une méthode qui n'est pas virtuelle) permet de faire plus propre que Java. Je suis sûr que tu n'en trouveras pas car c'est une des conneries fondamentale du C++, dont le principal vrai défaut est d'avoir un système de types objets plus que bancal (et pas de GC).
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 29 février 2004 à 16:48. Évalué à -1.
        
        « Serait-ce une retraite honteuse ? Tu ne réponds toujours pas sur le fond : pourquoi final ne permettrait il pas de faire proprement cette histoire de contrat ? Qu'est-ce qui n'est pas propre dans ma construction (oui, je sais, elle est limitée par l'absence d'héritage multiple) ? »
        
        Parce qu'on peut ne pas vouloir l'ensemble de ce qu'apporte final. Parce qu'en C++ on n'a pas pour objectif d'être un intégriste de l'objet et on utilise le paradigme qui va bien en fonction de la situation. final interdit toute redéfinition, je n'en veux pas, point barre, ce n'est pas difficile à comprendre, c'est une restriction trop forte.
        Faire des contrats de cette manière c'est utile, et pas forcément parce qu'il y a un besoin objet derrière. Un point de vue obtus ne concevant qu'objet ne peut pas le comprendre.
        
        Tu vois l'importance des inconvénients comme tu veux, tu n'as pas voulu du premier je t'en ai donné un autre. Pour moi le problème de l'héritage multiple est moins important, parce qu'en pratique quand il y a des contrats, la classe n'implémente pas 36 interfaces différentes. En pratique. Les avantages et inconvénients que toi tu vois ne sont pas forcément partagés par le reste du monde. Ca a l'air très difficile à comprendre.
        
        « Donne moi un seul exemple dans lequel l'hérésie du C++ [snip conneries]»
        
        Ce n'est pas une hérésie parce que C++ n'a pas la prétention (contrairement à Java) d'être exclusivement orienté objet. Ça ne te plait pas dans une approche objet, ne l'utilise pas dans une approche objet. Je ne m'en sers pas dans une approche purement objet, ce n'est pas pour ça que je compte m'en passer ailleurs.
        
        Merci pour cet exposé extrémiste « Seul l'objet existe ». Sur ce, *plonk*.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 29 février 2004 à 18:41. Évalué à 4.
        
        Parce qu'en C++ on n'a pas pour objectif d'être un intégriste de l'objet
        
        J'adore ce genre de chose. Tu pourrais aussi me traiter d'autre chose, je laisse ton imagination débridée choisir parmi les nombreuses possibilités.
        
        Faire des contrats de cette manière c'est utile, et pas forcément parce qu'il y a un besoin objet derrière. Un point de vue obtus ne concevant qu'objet ne peut pas le comprendre.
        
        De retraite en retraite, la défaite s'approche. Tu es formidable. Depuis quelques posts, tu refuses de donner un exemple pertinent. Alors que j'ai accepté de reconnaître mes erreurs (par exemple sur l'héritage multiple dont tu as donné un excellent exemple d'application), tu t'enfonces, tellement lamentable que tu passes aux "insultes". C'est affligeant. Je supposes que tu ne viens pas ici pour débatre, enrichir ta connaissance et celle des autres, mais lancer des affirmations gratuites puis terminer en attaques personnelles...
        
        Ce n'est pas une hérésie parce que C++ n'a pas la prétention (contrairement à Java) d'être exclusivement orienté objet. Ça ne te plait pas dans une approche objet, ne l'utilise pas dans une approche objet. Je ne m'en sers pas dans une approche purement objet, ce n'est pas pour ça que je compte m'en passer ailleurs.
        
        Tu peux toujours qualifier mes propos de conneries ou d'intégrisme de l'objet, ça ne change rien au fond du problème (et ça ne te grandit pas, d'ailleurs). Tout le monde, praticien comme théoricien, reconnaît le grand intérêt des langages typés. Le système de type du C++ est bancal car la sémantique d'un objet diffère selon le mode de passage, ce qui pertube les possibilités de prédiction du comportement d'un programme. Le reconnaître n'a aucun rapport avec un quelconque intégrisme, il s'agit simplement d'une reflexion critique sur le design d'un langage. C++ a été conçu par quelqu'un qui ne connaissait pas bien les langages objets et surtout qui confondait les concepts (héritage par exemple) avec leur implémentation (table de méthodes virtuelles). Le résultat est utile en pratique car C++ permet une énorme abstraction par rapport au C, mais il est aussi très criticable. La mauvaise conception du C++ le rend par exemple beaucoup plus difficile à apprendre que des langages nettement plus riches comme Eiffel et Sather. Mais comme ces derniers ont une syntaxe à la Pascal, ils n'ont pas le succès mérité. Heureusement que Java et C# sont arrivés.
        
        Merci pour cet exposé extrémiste « Seul l'objet existe ».
        
        Où est-ce que tu as lu ça ?
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par boubou (site web personnel) le 27 février 2004 à 18:00. Évalué à 1.
        
        Une version beta ce n'est pas du concret. Quand ce sera stable, ce sera un bon point.
        
        Oui, oui, bien sûr. Puisque je te dis que c'est la même techno que celle de GJ (ce sont les mêmes auteurs) qui est testé littéralement depuis des années !
        
        Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition.
        
        Quel est le rapport avec final/virtual ? Tu peux implémenter plusieurs interfaces avec une même classe en Java, puisque justement la notion d'interface est faite pour : il n'y a pas de corps de méthodes dans les interfaces. Donc, je suppose que tu veux dire qu'en C++ tu peux écrire plusieurs classes abstraites (mélangeant des méthodes implémentées et des en-têtes seuls) et en hériter. Nous sommes d'accord, c'est l'héritage multiple qui n'existe pas en Java. Je vois bien l'intérêt que tu trouves à ça, mais toujours pas le rapport avec final/virtual. Donc, si tu donnais un exemple concret, ça serait peut être idéal. Je vais finir par croire que tu te fous de moi.
        
        Et toi tu ferais pas mal de lire (ou plus dur : réfléchir) avant de répondre. Tiens lis donc ma remarque initiale pour voir à quel point tu réponds à coté.
        
        La technologie qui permet les foncteurs existe de façon nettemment plus puissante en Java. L'implémentation proprement dite existe sous forme d'une bibliothèque open source (cf http://jga.sourceforge.net/(...)).
        
        C'est bete, des langages utilisent cet idiome. Celui que tu présente s'appelle plutot « bidouille pour compenser une faiblesse ».
        
        Quelle puissance dans l'argumentation. Note bien que je n'ai pas dit que c'était un mauvais idiome, juste qu'il était incompatible avec les langages à GC.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 19:04. Évalué à -1.
        
        « Oui, oui, bien sûr. Puisque je te dis que c'est la même techno que celle de GJ (ce sont les mêmes auteurs) qui est testé littéralement depuis des années ! »
        
        Ben oui, mais c'est pas encore dans le-java-d'aujourd'hui. Si c'est parfait dès Java 1.5 c'est très bien, J'espère qu'ils n'hésiteront pas à aller vers d'autres bonnes évolutions comme ça.
        
        « Quel est le rapport avec final/virtual ? »
        
        C'est un autre exemple, et j'en ai donné encore un autre dans le post suivant, j'ai donné ceux là parce qu'ils sont plus clairs. Je ne vais pas perdre de temps à en prendre d'autres, moins évidents à décrire : c'est juste qu'il existe des cas comme ça où une chose propre peut se faire en C++ et pas en Java. Et si on y tient ça fait un gros plus pour choisir C++.
        
        « La technologie qui permet les foncteurs existe de façon nettemment plus puissante en Java. L'implémentation proprement dite existe sous forme d'une bibliothèque open source »
        
        Ca fait partie de Java 1.4 ou pas ? Comme je le disais c'est leur conjonction avec d'autres choses qui est appréciable en C++. Il faut déjà attendre les templates, puis si un truc comme ça est intégré (ça n'a pas l'air de l'etre) ce sera très bien. Ca va dans le bon sens, Java répare ses erreurs, mais quelle lenteur de réactivité...
        
        « Note bien que je n'ai pas dit que c'était un mauvais idiome, juste qu'il était incompatible avec les langages à GC. »
        
        Si ça te fait plaisir, oublions celui-là, on m'avait demandé une liste, j'ai donné une liste, d'autres points comme les templates, les contrats sont les vrais problèmes. Celui-ci reste du détail, c'est juste que l'idiome est foireux, mais on peut le contourner en effet.
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par Pierre Tramonson le 27 février 2004 à 10:06. Évalué à 1.
        
        Ben tous tes exemples soit disant disqualifiants, je ne m'en sers pas. Donc en fait je m'en fous :)
        Et puis il faut apprendre pendant combien de temps le C++ avant d'arriver à trouver une utilité à ces concepts ? 10 ans avant d'écrire un code propre ?
        C'est très couteux finalement. Dans de rares cas ça doit valoir le coût, mais sur la majorité des projets je ne crois pas.
        
        A part sur tout ce qui est IHM Java, peut-être. J'ai vécu des expériences traumatisantes avec les bugs de l'API Swing ;)
        Il reste encore pas mal de conneries et de comportements pas très clairs (et il faut utiliser des astuces de prog pour les contourner).
        
        [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 15:36. Évalué à -1.
        
        « Ben tous tes exemples soit disant disqualifiants, je ne m'en sers pas. Donc en fait je m'en fous :) »
        
        Eh, je ne dis pas que Java est inutile !
        Si tu ne te sers pas de ces choses là, pas de problème. Ce que je dis simplement, c'est que si on en a besoin, Java se retrouve disqualifié. Personnellement sur un gros projet, je préfère avoir des interfaces propres, incluant les pré/post conditions, et Java ne le permet pas. Il me faut aussi des templates, il n'y en a pas pour l'instant.
        
        « Et puis il faut apprendre pendant combien de temps le C++ avant d'arriver à trouver une utilité à ces concepts ? 10 ans avant d'écrire un code propre ? »
        
        Il faut plus de temps que pour Java. Java est facile à apprendre, mais pas forcément facile à utiliser. Il faut aussi du temps. Après ça dépend du temps que tu y passes, si tu vas lire les bons bouquins. Donc oui, plus de temps pour C++ (mais *tout* n'est pas indispensable au début) mais quand on le connaît bien, c'est très payant.
        
        « C'est très couteux finalement. Dans de rares cas ça doit valoir le coût, mais sur la majorité des projets je ne crois pas. »
        
        Certes, mais on ne réapprend pas à chaque début de projet, hein. Et rien n'interdit de connaître plusieurs langages, etc.
    - [^] # Re: Des utilisateurs heureux de Java
      
      Posté par Moby-Dik le 27 février 2004 à 01:17. Évalué à 2.
      
      Là c'est le comble ! Java ne fait que de l'allocation dynamique ! Au moins C++ permet de faire de l'allocation automatique. Et si c'est un ramasse-miettes qui te manque, eh bien il suffit d'en mettre un.
      
      Tout juste. Depuis que j'ai acheté une turbo-brosse, mon aspirateur G++ est devenu d'une efficacité époustouflante pour ramasser les saloperies !
      Alors certains diront que la shampouineuse est critiquable, qu'il aurait mieux valu le prendre en senteur citron, que ceci cela...
      
      Moi je peux vous dire qu'une fois le tuyau en main, on oublie tout ça pour le plaisir complice d'un vrombissement feutré qui nettoie en douceur et en profondeur !
    - [^] # Re: Des utilisateurs heureux de Java
      
      Posté par Bungee Tux le 27 février 2004 à 09:10. Évalué à 1.
      
      Oui, c'est vrai java n'a qu'un mode d'allocation des objets. Alors qu'en C++, même si tu as décidé de n'utiliser que de l'allocation automatique et des smart pointeurs et des références, tu finis par utiliser des librairies qui veulent des pointeurs, des référence ou autre.
      
      Le passage par référence est soit disant la version la plus clean mais quand tu lis le code appelant, tu ne sais pas si c'est un passage par valeur ou référence.
      Si tu fais un programme un peu évolué, tu utilises la STL et tu finis par plus savoir quoi mettre dans tes containers, ref ou pointeur.
      
      En plus dans tes classes, t'es obligé d'utiliser des pointeurs si tu dois préciser des paramètres calculés au constructeur.
      
      Alors oui, je n'aime pas les nouveautés quand on laisse les anciennes solutions. Soit pointeur tout le temps soit référence mais pas les deux. Et oui un bon ramasse miettes obligatoire sur tous les applications non temps réels.
      
      Alors oui, on peut surcharger des opérateurs en c++ pour simplifier l'écriture mais on est obligé d'écrire des horreurs comme smart_pointeur pour utiliser une allocation dynamique.
      
      Pour la généricité, c'est p-e propre intellectuellement parlant mais suivant le compilateur, c'est une procédure différente a chaque fois pour compiler. Pour le coté portable de la chose, c'est presque à éviter.
      
      Le must en Java, que c++ n'a pas du moins difficilement, c'est quand un programme plante en java, il t'écrit la pile des appels de facon compréhensive dans la console.
      - [^] # Re: Des utilisateurs heureux de Java
        
        Posté par #3588 le 27 février 2004 à 15:58. Évalué à 0.
        
        « Oui, c'est vrai java n'a qu'un mode d'allocation des objets. Alors qu'en C++, même si tu as décidé de n'utiliser que de l'allocation automatique et des smart pointeurs et des références, tu finis par utiliser des librairies qui veulent des pointeurs, des référence ou autre. »
        
        Une bibliothèque qui fonctionne de manière trop différente de ton programme, tu commences par l'encapsuler, non ? Enfin, la plupart du temps ça ne me paraît pas nécessaire.
        
        « Le passage par référence est soit disant la version la plus clean mais quand tu lis le code appelant, tu ne sais pas si c'est un passage par valeur ou référence. »
        
        Ton code appelant a de grosses lacunes en documentation... mais en général const dit ce qu'il en est.
        
        « Si tu fais un programme un peu évolué, tu utilises la STL et tu finis par plus savoir quoi mettre dans tes containers, ref ou pointeur. »
        
        On ne peut pas mettre de ref dans la STL. La STL est orientée valeur, c'est donc de la copie d'objets. Si tu as une sémantique d'identité, tu prends des pointeurs. Éventuellement des pointeurs automatiques de boost.
        
        « En plus dans tes classes, t'es obligé d'utiliser des pointeurs si tu dois préciser des paramètres calculés au constructeur. »
        
        Là je ne vois pas, la liste d'initialisation doit suffire. Ou alors les calculs sont après le constructeur.
        
        « Pour la généricité, c'est p-e propre intellectuellement parlant mais suivant le compilateur, c'est une procédure différente a chaque fois pour compiler. Pour le coté portable de la chose, c'est presque à éviter. »
        
        C'est dans le standard, et c'est bien implanté dans pas mal de compilateurs. Je crois que question portabilité Java est mal placé (dans la pratique, je sais qu'en théorie c'est censé etre le top).
        
        « Le must en Java, que c++ n'a pas du moins difficilement, c'est quand un programme plante en java, il t'écrit la pile des appels de facon compréhensive dans la console. »
        
        Oui, là rien à redire.
  - [^] # Re: Des utilisateurs heureux de Java
    
    Posté par Troy McClure (site web personnel) le 27 février 2004 à 00:08. Évalué à 1.
    
    > Et franchement Java n'a pas a rougir. Il est plus rapide que le mathlab cher a ce service et il permet de développer tout aussi rapidement
    
    Peu de langages ont a rougir devant celui de matlab, à part peut être le logo -- ceci dit pour rester dans le troll, toute l'ui de matlab est maintenant en java, et c'est un euphemisme que de la décrire comme une grouse bouse bloated: c'est une sombre m
- [^] # Re: Des utilisateurs heureux de Java
  
  Posté par babar33 le 26 février 2004 à 23:18. Évalué à 4.
  
  Je suis entierement d'accord
  
  J'utilise Java au quotidien, et je n'ai pas à m'en pleindre, bien au contraire. Je suis allergique au vb, ou au c++ ... Je n'ai pas particulierement de pb de perfs. Oui il faut de la ram, mais le confort d'utilisation est sans commune mesure.
  
  C'est pas plus lent que d'autre langages, et c'est plus facile de bien coder en java que dans d'autres langages. La javadoc est géniale.
  
  Et memes remarques, toutes les fois ou j'ai eu des gros pbs de perfs c'etait liés à des choses annexes (requettes sql, réseau, mauvais algo ...)
  
  Je pense que si c'etait aussi nul que tout le monde veut bien le dire au dessus, les banques, les assurances, les impots ne lui ferait pas confiance. (Les impots sont memes en train de passer sous jboss, tomcat, linux ... bref bcp de libre)
  
  On critique bcp le java, mais dans l'ensemble, il n'y a pas bcp de langage qui font aussi bien dans tout les domaines qu'il touche. L'interet me direz vous ? avoir un SI homogène. Oui on peut trouver un langage mieu pour ci un autre pour ca, mais au final, que du non homogène.
  
  J'aime l'objet, les ejb (memes les entity, et je n'ai pas de pb de perfs particulier, du moment que j'ai réfléchi leur utilisation), le jms, les servlets, les jsp, toutes les libs apaches, la connection aux annuaires, le jdbc, le jca (hmmm c'est bon le cics en java), la syntaxe, le confort d'un ide comme eclipse, l'introspection et j'en passe... Meme les packages swing et swt sont super bien pensés. C'est tres propre conceptuellement.
  
  Je n'aime pas: ben pas grand chose en fait, tout ce que je reprocherais serait autour des classes Date et Calendar qui sont chiantes.
  
  Le seul langage qui tienne la route en face est le c# à mon gout. Le seul pb, c'est que des que l'on rentre dans les mécanismes krosoft, on ne comprend plus ce qui ce passe, et des fois c'est génant...
  
  Alors oui pour un java plus libre, et oui pour arretter de casser du sucre sur le dos de java parcequ'on a entendu dire ci et la: ca marche pas, c'est lent, les ejb c'est pas bien ...
  
  Forgez vous vos avis par vous memes
  - [^] # Re: Des utilisateurs heureux de Java
    
    Posté par #3588 le 27 février 2004 à 00:04. Évalué à 0.
    
    « Je pense que si c'etait aussi nul que tout le monde veut bien le dire au dessus, les banques, les assurances, les impots ne lui ferait pas confiance. (Les impots sont memes en train de passer sous jboss, tomcat, linux ... bref bcp de libre) »
    
    Il faut faire la distinction entre les différents reproches qui sont faits. Entre autres, la fiabilité d'une part, le langage d'autre part.
  - [^] # Re: Des utilisateurs heureux de Java
    
    Posté par Moby-Dik le 27 février 2004 à 01:21. Évalué à 1.
    
    J'aime l'objet, les ejb (memes les entity, et je n'ai pas de pb de perfs particulier, du moment que j'ai réfléchi leur utilisation), le jms, les servlets, les jsp, toutes les libs apaches, la connection aux annuaires, le jdbc, le jca (hmmm c'est bon le cics en java), la syntaxe, le confort d'un ide comme eclipse, l'introspection et j'en passe... Meme les packages swing et swt sont super bien pensés. C'est tres propre conceptuellement.
    
    J'espère qu'ils font des cadeaux promotionnels, chez Sun ? ;)
# Re: IBM demande à Sun de "libérer" Java

Posté par Anonyme le 26 février 2004 à 22:27. Évalué à 1.

Tiens, a un moment c'était RedHat qui nous parlait d'une version OpenSource de Java. Mais plus de nouvelles :/
https://linuxfr.org/2003/06/24/13002.html(...)

Suivre le flux des commentaires

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