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.
Journal Java et Linux
21
août
2003
# Re: Java et Linux
Posté par Christophe GRAND (site web personnel) . Évalué à 2.
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 MrTout (site web personnel) . Évalué à 0.
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 julien . Évalué à 3.
mais ca te dirait pas d'argumenter un minimum quand meme ?
[^] # Re: Java et Linux
Posté par MrTout (site web personnel) . Évalué à 6.
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 Jean Meyrand . Évalué à 2.
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 MrTout (site web personnel) . Évalué à 4.
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 Pat Le Nain . Évalué à 2.
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 MrTout (site web personnel) . Évalué à 2.
>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 Pat Le Nain . Évalué à 1.
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 B r u n o (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 MrTout (site web personnel) . Évalué à 2.
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 B r u n o (site web personnel) . Évalué à 1.
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 MrTout (site web personnel) . Évalué à 1.
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 B r u n o (site web personnel) . Évalué à 1.
[^] # Re: Java et Linux
Posté par Tof . Évalué à 1.
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 Anonyme . Évalué à 2.
Explique un peu ... c'est trompeur en quoi ? Donne des exemples.
[^] # Re: Java et Linux
Posté par Jean Meyrand . Évalué à 1.
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 jmfayard . Évalué à 0.
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 dudesay . Évalué à 2.
[^] # Re: Java et Linux
Posté par Maillequeule . Évalué à 1.
N'est pas Pierre Tramo qui veut.
M
[^] # Re: Java et Linux
Posté par neoillogic . Évalué à 2.
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.