Journal Java et Linux

Posté par  .
Étiquettes :
0
21
août
2003
Bonjour cher journal !
Aujourd'hui je vais parler d'un langage de programmation que je connais depuis un peu plus de 2 ans : Java.
Ce langage a la particularité d'être portable sans recompilation sur diverses plate-formes, y compris Windows et GNU/Linux.
Il a également la particularité d'être souvent décrié par certains comme n'étant pas vraiment libre et ouvert.
Je vais vous faire part de mon expérience personnelle sur ce langage.

Donc il y a 2 ans, j'ai débarqué en stage dans une PME (6 personnes à l'époque, 9 maintenant) qui produit des systèmes de fidélité basés sur la carte à puce. Je ne connaissais que 2 langages de programmation : le C et le C++ (MFC principalement). Je devais normalement développer une application en C/C++ : communication modem/port série et traitement des trames reçues . Cependant, le jour de mon arrivée, j'eus la surprise d'apprendre que l'application serait développée en java.
J'ai donc appris le java à la va-vite, et j'ai fait cette application qui je dois le dire n'était pas très portable : API de port série spécial Windows, ...
Cependant, j'aurai appris ce langage ô combien facile comparé au C/C++.

Je suis retourné en stage dans cette entreprise cet été, où j'ai développé des outils opérateurs de base de donnée, toujours en java, et cette fois 100% portable.

Et c'est là que je vois l'écart qu'il y a eu en 2 ans.
A l'époque, leur serveur de suivi commercial était écrit en ASP et tournait sous IIS.
Leur serveur d'entreprise était Windows NT. Ils décrivaient le mode ASP comme quelque chose de génial.
Leurs applications "personnelles" étaient écrites avec Borland C++ Builder, en C++ donc, 100% Windows. Ils avaient une souscription MSDN, ...
Aujourd'hui, leur serveur de suivi commercial tourne toujours sous Windows, mais avec Apache et Tomcat, et va passer dans les mois qui viennent sous Linux (ils aiment bien Gentoo).
Leur serveur d'entreprise/de test vient de passer sous Gentoo. Plus de MSDN non plus..
Bon, c'est sur, la secrétaire va garder son PC sous Windows ave MS-Office and cie (quoi que j'entend de plus en plus souvent le nom d'OpenOffice).
Par contre les postes de Dev passent un par un sous Linux, même si il y aura toujours des postes sous Windows pour les tests.

Et Java dans tout ca?
Tout est en java : le serveur, les applis internes.
Coincidence ? Je ne pense pas.
Est-ce que c'est uniquement grâce à Java qu'il y a eu migration sous linux? sûrement pas !
Est-ce que c'est en prévision d'un passage sous linux qu'ils ont adopé Java comme solution principale de développement? un peu plus probable, vu que c'est eux qui le disent.

Je pense aussi que c'est un mélange des deux. Le fait d'avoir les applications écrites en Java a énormément facilité le passage vers le libre. Si les jsp/servlets n'avaient pas existé, il seraient probablement encore en ASP.
Le langage Java ayant la particularité d'être facile à manier, il peut se faire adopter facilement par de nombreux développeurs.

J'ai écrit ce journal parce que je vois beaucoup de personnes, y compris sur ce site, qui n'aiment pas ce langage pour diverses raisons. Cependant, je pense qu'un grand nombre de passages sous linux lui sont dus, ne serait-ce qu'au niveau des développeurs.
  • # Re: Java et Linux

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

    côté serveur ce n'est pas un cas isolé :
    http://news.netcraft.com/archives/2003/07/23/jsp_continues_fast_gro(...)

    maintenant, j'ai constaté la même tendance chez un éditeur de logiciels où j'ai bossé mais c'est plus compréhensible : jamais un de leurs clients n'a voulu mettre le serveur (mixte C++/J2EE) sous autre chose qu'Unix (HPUX et Solaris). Les versions Windows et Linux n'ont jamais été mises en prod.
  • # Re: Java et Linux

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

    Java est sans doute une très bonne plateforme de développement avec une bibliothèque de base très imposante et standard. De plus sa popularité fait que l'expérience, les outils et les personnes compétentes ne manquent pas.

    Malheureusement, le langage Java est une honte. Ben sûr en venant du monde C en ne conaissant que la gestion des concepts objets (mal-)traités par C++, on a souvent l'impression que Java est plus clair, plus simple, plus logique (plus hortogonal quoi) mais l'effet est trompeur. D'ailleurs, je fut également duppé :).

    Java né en 1991 avait déjà plus de 5 ans de retard sur la compréhension des concepts objets. C'est franchement domage, avec un environement pareil et la popularité du Java, même auprès des dessideurs pressés (surtout auprès ?), qu'est ce que ça aurait été si le jangage Java avait été un bon langage !
    • [^] # Re: Java et Linux

      Posté par  . Évalué à 3.

      t'aime pas Java .. ok pas de probleme et c'est ton droit.
      mais ca te dirait pas d'argumenter un minimum quand meme ?
      • [^] # Re: Java et Linux

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

        J'avais pas envie de faire une liste mais puisque deux personnes insistent :

        Pous les griefs syntaxiques et génie logiciel :
        - syntaxe souvent lourde (noms longs, points virgules, redondance de l'écriture) ;
        - pas de moyen simples de faire des blocs débug ou des assertions ;
        - héritages ancestraux (case, break).

        Pour les griefs plus spécifiques :
        - tout n'est pas objet (types primitifs, tableaux) ;
        - héritage simple (non, le sous-typage multiple ne suffit pas dans tous les cas) ;
        - les attributs statiques ne sont pas des attributs de classes ;
        - distinction entre méthodes et attributs (pas homogène, oblige à creer des accesseurs) ;
        - protections instables (cas complexes de protection difficiles à prévoir, surtout que la norme change parfois et que la JVM ne suit pas toujours la norme) ;
        - types de retour invariants (étrange non ?) ;
        - les tableaux ne se comportent pas comme des classes (contravariants vs invariants) ;
        - pas de généricité (ok, ça va arriver un jour).

        Pour finir sur les trucs optionnels :
        - pas de covariance (enfin si dans les tableaux) ;
        - pas de réflexivité (seulement de l'introspection) ;
        - pas de fonctions lambda :) ;
        - pas de contrats.

        Bon, bien sûr je sens qu'il va y avoir des gens pour raler sur ma liste (c'est normal) mais j'espère juste qu'il n'y aura pas trop de monde pour déformer/inventer mes propos.

        N'oubliez par que Java c'est entre autre :
        - un language ;
        - une bibliothèque énorme ;
        - une machine virtuelle ;
        - un modèle de sécurité.
        Je ne parle que du premier point et je troive domage que pour avoir les 3 points suivants on soit obligé de se farcir un lagage comme Java.
        • [^] # Re: Java et Linux

          Posté par  . Évalué à 2.

          j'avais pas créé ce journal pour que ca parte en troll, mais bon ...

          sur ta liste, deja il plein de critères que je ne connais pas :

          >- pas de covariance (enfin si dans les tableaux) ;
          >- pas de réflexivité (seulement de l'introspection) ;
          >- pas de fonctions lambda :) ;
          >- pas de contrats.


          Par contre tu le dis toi meme :

          >N'oubliez par que Java c'est entre autre :
          >- un language ;
          >- une bibliothèque énorme ;
          >- une machine virtuelle ;
          >- un modèle de sécurité.
          >Je ne parle que du premier point et je troive domage que pour avoir
          >les 3 points suivants on soit obligé de se farcir un lagage comme
          >Java.

          Personnellement le langage me convient (question d'habitude,j'ai été élevé au C).
          Le fait d'avoir des noms longs ne me dérange pas, je trouve même que c'est un avantage, si on s'en sert bien on arrive à avoir du code très facilement relisible et reprenable. ...

          Pour info, c'est quoi tes langages préférés, ou plutot, est-ce que tu connais un langage qui correspond à ce que tu décris plus haut ?
          • [^] # Re: Java et Linux

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

            >- pas de covariance (enfin si dans les tableaux) ;

            Le covariance est le fait de faire varier le types des paramètres (ecriture et lecture) dans le même sens que l'héritage.

            exemple (en pseudo code) :

            class Animal {
            void mange(Nouriture);
            }
            class Vache extends Animal {
            void mange(Herbe);
            }

            >- pas de réflexivité (seulement de l'introspection) ;

            L'introspection c'est pourvoir « lire » les infos structurelles du langage (exemple parcourir les méthodes d'une classe).
            La réflexivité c'est pouvoir « modifier » les infos structurelles du langage (exemple modifier une méthode d'une classe)

            >- pas de fonctions lambda :) ;

            ce sont des fonctions anonymes crées à la demande. Une des nombreuses utilités est de pouvoir avoir une méthode de comparaison ad-hoc pour faire des tris, des itérateurs, etc. en fait ce que j'apelle « lamda » regroupe plutot les fermeture et autres blocs mais le principe à la base est globalement le même.

            >- pas de contrats.

            C'est le fait d'écrire les contraintes de fonctionnement requis dans le code plutôt que dans la doc. Le programme pouvant alors s'auto-vérifier dans les phases de débug.

            exemple grossier pour comprendre

            class A {
            int toto;
            void set_toto(int t)
            require t > 0
            { toto = t }
            ensure t = toto
            }

            ici la fonction set_toto exprime que son paramètre doit être positif et que le résultat de son action sera de rentre l'attribut toto egal à t.
            L'interet de ce genre de chose est de faciliter le developpement et de séparer interface et implémentation.


            « Personnellement le langage me convient (question d'habitude,j'ai été élevé au C). »

            est-ce une raison pour ne pas chercher les limites du langage ? est-ce une raison pour ne par chercher, ne serait-ce que par curiosité, comment dépasser ces limites ?

            J'ai également été élevé au C, c'est pas pour autant je n'essaye pas de porter un regard critique (certains diront « de critique ») sur les langages que j'étudie.

            « Le fait d'avoir des noms longs ne me dérange pas, je trouve même que c'est un avantage, si on s'en sert bien on arrive à avoir du code très facilement relisible et reprenable. ... »

            Oui mais ya souvent de l'abus, il suffit d'une chaine avec 3 ou 4 envois de messages, un peu d'indentation et on dépasse les 80 caractères. Question lisibilité c'est pas forcément ce qu'on fait de mieux.
            Je reconnais que ce point est faible. et puis on a le complettement automatique et de grands écrans.

            « Pour info, c'est quoi tes langages préférés, ou plutot, est-ce que tu connais un langage qui correspond à ce que tu décris plus haut ? »

            J'en ai pas, je me contente de critiquer comme un vieux raleur. :)

            Eiffel : un langage grandiose et largement en avance sur son temps au niveau des concepts (c'est un peu comme si linux 2.6 était sorti en même temps de DOS 3.0). Malheureusement il est verbeux et tros rigoureux pour une utilisation comme la mienne. Mais en entreprise il roxor d'après des gens. Son principal défaut : les boucles sont vraiment nulles (for, while, etc.)

            Ruby : un langage de script tout objet bien qu'étant le contraire d'Eiffel. Proche de SmallTalk il gère les lambas de façon élégantes. Son défaut : héritage multiple remplacé par des mixins, c'est pas si grave vu qu'il est a typage dynamique (c'est juste lourd parfois).

            CLOS : (Comon (LISt Processing) Object System). Il faut aimer les parenthèses. J'ai jamais accroché au LISP mais ya des gens qui aiment. Point fort : selection multiple (en gros tous les arguments d'un appel de méthode sont les receveurs).

            OCaml : plusieurs fois j'ai essayé de m'y mettre sérieusement mais à chaque fois je me suis évanoui en lisant la syntaxe (et pourtant je connais BrainFuck et GOTO++ donc niveau syntaxe je me pensais blindé).

            En ce moment je bosse en Eiffel pour mon travail.
            • [^] # Re: Java et Linux

              Posté par  . Évalué à 2.

              >>- pas de réflexivité
              Ce choix a été fait pour simplifier la machine virtuelle et pour des raisons de sécurités (si tu as le droit de modifier les classes de sécurités ou les classloaders, t'es mal).

              >>- pas de fonctions lambda :) ;
              Ces fonctions sont émulés par les objets et les interfaces. exemple : l'interface java.util.Comparator qui définit une méthode public int compareTo(Object o1, Object o2). Tu crées une classe implémentant Comparator (de type inner, toplevel ou anonyme) avec ta méthode de tri et tu la passe à la méthode voulue (Arrays.sort() par ex). Ca marche pareil avec les Iterator, les Enumeration, etc.
              Je trouve que ça a l'avantage de clarifier le language (au détriment peut-etre de la rapidité d'écriture et encore).

              >>- pas de contrats
              Conceptuellement, je suis d'accord, c'est un gros manque. Mais qui va coder les tests des contrats dans ses classes à part ceux qui font des choses carrées ? (j'ai deux exemples sous la main de codeurs non propres, je les imaginent mal utiliser les contrats).

              Pour ce qui est des noms longs, ça a l'avantage d'etre lisible et compréhensible (compare strftime() et DateFormat.format()). L'inconvénient, je le reconnais, c'est cette lignes des 80 colonnes qu'on atteint voire franchit allègrement.
              • [^] # Re: Java et Linux

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

                >>- pas de réflexivité
                >Ce choix a été fait pour simplifier la machine virtuelle et pour des raisons de sécurités >(si tu as le droit de modifier les classes de sécurités ou les classloaders, t'es mal).

                D'une part il ne faut jamais mélanger implémentation et langages. La réflexivité est une torture à compiler en natif, avec une marchine virtuelle cela ne devient que très très difficile et peu efficace. Mais j'ai bien précisé que je ne parlait que du langage et pas de son implémentation.
                Le langage Java est le même qui est utilisé par les compilateurs natifs (tel gcc) et la machine virtuelle peut faire tourner du byte-code qui ne provient pas d'un programme en Java (SmartEiffel peut produire du byte code JVM). Le langage Java n'est pas lié à la JVM.

                Ensuite, que Java ne fasse pas de réflexivité c'est pas non plus la fin du monde. C'est déjà vachement bien qu'on aie l'introspection je trouve.

                Pour conclure, rien n'empeche que le gestionnaire de sécurité soit en read-only et qu'il vérifie les modifications apportés au système.

                >>- pas de fonctions lambda :) ;
                >Ces fonctions sont émulés par les objets et les interfaces. exemple : l'interface >java.util.Comparator qui définit une méthode public int compareTo(Object o1, Object >o2). Tu crées une classe implémentant Comparator (de type inner, toplevel ou >anonyme) avec ta méthode de tri et tu la passe à la méthode voulue (Arrays.sort() >par ex). Ca marche pareil avec les Iterator, les Enumeration, etc.

                Arg !
                Je savais pas ça. C'est terriblement lourd comme système. Forcer la création d'une classe avec une méthode particulière pour charque fonction de comparaison est monstrueux. Sans compter que d'une part pour que le typage accepte ça il faut faire des coercition à tout va et d'autre par ce n'est plus la classe d'origine qui est responsable des ses comparaisons mais un autre classe.

                Un solution simple pour faire ça serait quelque chose du genre :
                creer une méthode par comparaison dans la classe.

                class Persone
                {
                int compare_by_name() {...}
                int compare_by_age() {...}
                }

                le container possédant une méthode de tri qui necessite une méthode de comparaions
                class Container
                {
                void sort_using(Function comparator) {...}
                }

                D'une part il me semble que c'est faisable avec l'introspection Java et d'autre part Java aurait à y gagner en spécifiant ce genre de trucs correctement (SmartEiffel fait ça de façon originale et plutot pas mal) et pas par des stratagèmes qui pervertissent notre belle jeunesse !

                >Je trouve que ça a l'avantage de clarifier le language (au détriment peut-etre de la >rapidité d'écriture et encore).

                méthode coué, hein ?

                >>- pas de contrats
                >Conceptuellement, je suis d'accord, c'est un gros manque. Mais qui va coder les tests >des contrats dans ses classes à part ceux qui font des choses carrées ? (j'ai deux >exemples sous la main de codeurs non propres, je les imaginent mal utiliser les >contrats).

                Les contrats publics sont construits lors de la spécification en même temps que l'interface. En plus de les écrire sur un bout de parier ou dans un graphe UML tu les ajoute dans ton code.

                Si tes codeurs non propres sont incapable d'utiliser les contrats, je les vois mal utiliser l'autodocumentation, les commentaires ou les assertions.

                Les contrats c'est fait pour faire des trucs carrés avec un accord entre plusieurs entités (entre classes, entre développeurs, entre donneur d'ordre et fournisseur). D'ailleurs le nom n'est pas annodin.

                > Pour ce qui est des noms longs, ça a l'avantage d'etre lisible et compréhensible
                > (compare strftime() et DateFormat.format()). L'inconvénient, je le reconnais, c'est
                > cette lignes des 80 colonnes qu'on atteint voire franchit allègrement.

                c'est pour ça qu'il y à un juste milieu entre

                p "hello world"

                et

                system.out.screen.display.string.print_ended_with_a_new_line("hello word");

                :p

                Le but pas d'avoir des noms longs ou des noms courts mais des noms explicites !
                • [^] # Re: Java et Linux

                  Posté par  . Évalué à 1.

                  Pour les comparaisons, j'ai oublié une petite chose, c'est l'interface Comparable. Elle définit une méthode compareTo(Object objet_a_comparer). Cette interface est implémenté dans un certain nombre d'objet bas-niveau comme String, Integer, Double, etc.
                  La méthode Arrays.sort() travaille avec les deux possibilités (selon la signature).

                  >Forcer la création d'une classe avec une méthode particulière pour charque fonction de comparaison est monstrueux.
                  Tu peux définir une seule classe de comparaison par type de comparaison (une pour trier les chaines en tenant compte de la casse et une sans tenir compte de la casse). De plus tu peux exporter ces classes de façon à ce qu'un objet extérieur puisser trier une liste d'objet selon l'un ou l'autre critère sans avoir à savoir comment est fait le tri dans le détail.

                  > Si tes codeurs non propres sont incapable d'utiliser les contrats, je les vois mal utiliser l'autodocumentation, les commentaires ou les assertions.
                  C'est exactement le cas. Il faut préciser qu'on fait de la spécification en live sans papier, sans graphe UML ou autre chose :-( (la spéc est toujours en discussion avec le client et elle change sans arret)

                  >c'est pour ça qu'il y à un juste milieu
                  Je suis d'accord, il s'agit de ne pas tomber dans l'un ou l'autre abus.
            • [^] # Re: Java et Linux

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


              Le covariance est le fait de faire varier le types des paramètres (ecriture et lecture) dans le même sens que l'héritage.

              exemple (en pseudo code) :

              class Animal {
              void mange(Nouriture);
              }
              class Vache extends Animal {
              void mange(Herbe);
              }


              tu veux dire que la méthode mange(Herbe) remplace totalement la methode mange(Nouriture) ? une instropection ne donnerait que cette methode et pas celle de la classe héritée? Plus de polymorphisme possible alors?
              Parceque dans le cas d'un animal carnassier, en plus de la methode mange(Nouriture) j'aimerai bien ajouter un mange(Animal)
              • [^] # Re: Java et Linux

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

                C'était un exemple simple pour comprendre mais c'est raté il me semble :-/
                C'est un sujet un peut compliqué. Si on comprend bien les notions Objet c'est relativement facile à comprendre (mais plus dur à expliquer malheureusement pour moi).

                Je me place dans un modèle conceptuel qui n'a rien à voire avec l'implémentation (l'implémentation et la compilation efficace est un autre sujet, certes lié, mais qui n'a rien à voire) ni avec la syntaxe Java (car la syntaxe est addapté au comportement). En parlant d'introspection à la Java tu te limites au modèle Java qui forcément n'est pas addapté aux concepts étrangers à Java.

                Il faut savoir que la covariance ne change en rien le concept de spécialisation (héritage) ni de sous-classage. Par contre elle pose un problème avec la théorie des types qui est incompatible avec la covariance bien qu'il fut montré que c'est la théorie des types qui n'est pas addapté à la réalité (pour preuve l'existence du cas particulier des coercitions (cast)).

                Les règles de typage que respecte Java (en parti car Java n'est pas cohérent) est celle utilisé par presque tous les langages de programmation fortement typés.

                Tu emplois le mot « remplace ». deux sens possible pour un tel mot :
                1- redéfinition : une fonction toto qui a un comportement dans une classe A aquiert un comportement particulier (et spécialisé) dans une sous-classe B. Le polymorphisme marche.

                exemple :

                A v
                v = new B
                v.toto

                bien que toto soit appelée sur un objet de type statique A, c'est la fonction B::toto qui est exécuté car le type dynamique de v sera B.

                2- surcharge statique : une fonction toto qui a un comportement dans une class A est écrasée par une autre foction toto dans une sous-classe B. Les deux fonctions toto n'ont rien en commun si ce n'est le nom. Le polymorphisme ne marche pas.

                dans l'exemple précedent, c'est la fonction A::toto qui serait appelée.

                Ces deux définition de « remplacement » sont indépendante du modèle de variance du langage (puisque je n'ai pas parlé de paramètres).


                Maintenant un cas concret. En Java on doit écrire quelque chose du genre
                class Animal {
                void mange(Nouriture n);
                }
                class Carnassier {
                void mange(Nouriture n) {
                Animal a;
                a = (Animal)n; // je sais plus comment on fait les casts en Java :p
                // le reste
                }

                avec la covariance on aurait

                class Animal {
                void mange(Nouriture n);
                }
                class Carnassier {
                void mange(Animal a) {
                // le reste
                }

                Tout chose étant égale par ailleurs.

                Quel est l'interet ?
                - autospécification des paramètres ;
                - plus besoin de cast ;
                - pas besoin de se trainer une signature qui n'a presque plus rien à voire avec son utilisation dans une petite petite sous-classe.

                Limitation : la surcharge statique devient impossible. Mais c'est pas un mal car il n'y a plus ambiguité entre redéfinition et surcharge statique : le modèle est plus clair. (la surcharge statique est souvent décriée).

                Remarque, la covariance du type de retour n'est pas non plus incluse dans Java malgrè que :
                - la covariance du type de retour est compatible avec la théorie des types (si si) ;
                - le cout d'implémentation dans langage à héritage simple est négligeable. D'ailleurs en C++ cette coraviance est dans la norme mais peu de compilo l'implémentent car le coût est sans commune mesure en héritage multiple. Au dernières nouvelles g++ nous sortait un message d'excuse :)
                • [^] # Re: Java et Linux

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

                  Donc dans le cas que tu présentes, passer en paramètre autre chose que de l'Animal en nourriture à un Carnassier serait une erreur?
                  Ca revient à faire un contrat sur le type du paramètre en qq sorte

                  En tout cas, merci pour la tentative d'explication... J'ai essayé de chercher sur le net, effectivement, ca tombe trés vite sur des articles assez pointus en theorie de la programmation objet... Interessant, mais un peu eloigné de mes préoccupations actuelles :))

                  ps : dans mon exemple précédent, je ne placais pas Animal dans l'arbre d'héritage de Nouriture. Mon propos était de savoir si cette histoire de covariance n'empéchait pas la surcharge d'une methode avec d'autres types de paramètres, apparement non, puisque d'apres ce que j'ai compris, ca n'entre en jeux que lorsque les classes sont de la meme arborescence d'heritage.
                  • [^] # Re: Java et Linux

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

                    Si tu donnes de la viande à manger à une vache par ce principe

                    class Nouriture {}
                    class Viande extends Nouriture {}
                    class Herbe extends Nouriture {}
                    class Animal { void mange(Nouriture) }
                    class Vache extends Animal { void mange(Herbe) }

                    Animal margueritte = new Vache
                    Viande farine_animale = new Viande
                    margueritte.mange(farine_animale)

                    le verificateur de types laissera passer mais lors de l'exécution tu auras une erreur de type. Si tu faisais la même chose avec des casts tu aurais aussi une erreur de type de toute façon.

                    PS: c'est pas interdit de plusser les gens qui passent du temps a essayer d'expliquer des choses (même si c'est parfois obscur) :)
                    • [^] # Re: Java et Linux

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

                      ha vi, j'ai pas pensé à plusser... Habituellement, j'plusse plutot les commentaires cachés, et qui empechent de lire facilement une enfilade, bref, un vieu débat sur ce site. Mais bon, comme j'ai appris des choses 'hui, j'vais claquer mes droits de notes dans ce journal :))))))
        • [^] # Re: Java et Linux

          Posté par  . Évalué à 1.

          Merci !

          de poser enfin des arguments en parlant de java.
          De dire que ce langage est une honte est abusé, mais ça change de l'insupportable "java c'est lent ca sux et en plus c'est pas libre".

          C'est évident que java n'est pas le meilleur langage qu'il soit, mais c'est toujours pareil: ce ne sont pas les meilleurs technologies qui sont les plus répandues, ce sont celles qui arrivent au bon moment au bon endroit...

          Et puis il faut lui donner encore un peu de temps, on en reparlera dans 5 ans :)
    • [^] # Re: Java et Linux

      Posté par  . Évalué à 2.

      Malheureusement, le langage Java est une honte. Ben sûr en venant du monde C en ne conaissant que la gestion des concepts objets (mal-)traités par C++, on a souvent l'impression que Java est plus clair, plus simple, plus logique (plus hortogonal quoi) mais l'effet est trompeur. D'ailleurs, je fut également duppé :).
      Explique un peu ... c'est trompeur en quoi ? Donne des exemples.
    • [^] # Re: Java et Linux

      Posté par  . Évalué à 1.

      Ben le langage java est peut-etre une honte mais explique nous pourquoi !
      Sur les concepts objet ? J'avais pas l'impression que c'etait un mauvais langage, en tout cas il est utilisé par la plupart des facs françaises pour illustrer la programmation orientée objet. Evidemment, si ils se plantent tous en utilisant ce langage, ben nos diplômés (moi y compris) sont mal partis dans la vie active !

      Peut-etre aussi que la compréhension d'un langage dépend de son utlisation : quelqu'un qui utilise java tous les jours le trouvera très accessible, alors qu'il aura beaucoup de peine à se mettre à un langage que toi tu trouverais _plus clair, plus simple, plus logique_.
  • # Re: Java et Linux

    Posté par  . Évalué à 0.

    Ce langage a la particularité d'être portable sans recompilation sur diverses plate-formes, y compris Windows et GNU/Linux.
    La théorie est belle.
    En pratique, dès qu'on veut utiliser Java + Swing | SWT, on se retrouve avec des performances de merde qui rendent ton application quasi inutilisable sous autre chose que Windows XP
    Python, Perl, Ruby sont largement aussi multi-plateformes que Java.
    Même avec le bon vieux C, les outils GNU, + peut-être la glib et gtk, tu peux faire des programmes tournant sur une 30aine d'architectures et d'OS.

    Donc non, ce n'est pas la particularité de Java.

    Write once, Debug everywhere











    Oui, vous l'aviez compris c'est un troll.
    Non, il n'est pas terrible, mais comme je débute, j'ai voulu le faire dans un journal pour ne pas trop m'exposer.
    Allez hop, [-] et je sors
    • [^] # Re: Java et Linux

      Posté par  . Évalué à 2.

      Tiens, j'aurrai jamais cru qu'un J2EE Lead Architect aussi réputé puisse dire ça.
      • [^] # Re: Java et Linux

        Posté par  . Évalué à 1.

        Ben oui, Pierre Tramo qui troll sur Java, c'est n'importe quoi !

        N'est pas Pierre Tramo qui veut.

        M
    • [^] # Re: Java et Linux

      Posté par  . Évalué à 2.

      Baaah quelques lecteurs naïfs tels que moi aurait pu se faire prendre si tu avais enlevé sa laisse :p

      En plus un troll argumenté =) avec des vrais et des faux arguments, beau troll!

      Mais pensez vous que maintenant on peut encore se servir de l'argument "Java portable".. Parce que portable on a
      Python
      Perl
      OCaml (et performant en plus)
      Ruby
      Erlang (je crois que ya un mode bytecode)
      etc. (tous ceux qui ont un mode bytecode quoi :p)

      Et souvent on peut faire du portable avec de meilleures performances qu'en Java... Style OCaml bytecode(interface)/OCaml compilé(traitements)

      Ou pour des plus traditionnalistes Python/C(++)
      Avec lua tout ca n'est plus vraiment très dur...

      NB:
      Aaaah j'oublias, le bash :)

Suivre le flux des commentaires

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