Posté par boubou .
En réponse à la dépêche Mono 0.24.
Évalué à 3.
Eh oui, il faut voir les choses en face, Java est propriétaire. Ok, la
spécification est publique, mais l'implémentation ne l'est pas du tout.
Putain, mais c'est incroyable de continuer à lire des conneries pareilles. Une grande partie de l'implémentation de Java est libre, point final. Par exemple, toute la partie XML du jdk 1.4 (versions se et ee) vient du projet apache. C'est très clairement indiqué dans la doc et la licence. Il s'agit de l'implémentation de référence, pas d'un clonage. De même, la meilleure implémentation des web services en Java (les api JAXRPC, entre autres) est clairement Axis qui est en avance sur Sun sur ce point. L'implémentation de référence des JSP et servlets est Tomcat, logiciel open source du groupe apache ! La spécification J2EE 1.4 est en cours d'implémentation par deux projets open source, JBoss et JOnAS qui implémentent déjà l'intégralité de J2EE 1.3, c'est-à-dire l'ensemble des api ajoutées à l'édition standard. La partie graphique spécifique au système du jdk 1.4 passe sous unix de motif à GTK dans l'implémentation de référence.
Mais Java a ses gros défauts. C'est un glouton de mémoire, c'est parfois
très lent et surtout... ce n'est pas utilisé dans la "vraie vie" !!
Sort de ton trou ! Ce n'est pas un répétant une connerie qu'elle devient vraie. Le site web de la SNCF est en Java (EJB), celui de Chronopost aussi. Les exemples sont légions. Et je ne parle pas simplement de la partie présentation (JSP servlet), mais bien sûr de la partie métier et de l'interfaçage avec les gros systèmes qui tournent derrière. Sur le serveur, Java est utilisé massivement. Autre exemple, j'ai participé à un appel d'offre gagné par une entreprise pour refaire le système de billeterie de la fnac (fance billet et billetel), le plus gros système de ce genre en France, et devine quoi, on va le faire en JAVA !!!!
Ah oui, il faudrait que cette plateforme soit "native" (i.e. *pas*
basée sur une machine virtuelle) pour offrir les performances que
l'on attends des logiciels "qui marchent".
C'est marrant les gens qui se la petent avec Eiffel super bien conçu, etc. et qui ensuite font "table rase" des énormes progrès réalisés par les machines virtuelles. Les machines virtuelles avec leur JIT offrent des performances excellentes, souvent meilleures que le code compilé. Elles peuvent en effet réaliser des optimisations basées sur le profil d'utilisation d'une méthode, chose impossible à faire sans VM, comme par exemple un inlining de méthode quand le besoin s'en fait sentir. De plus, le byte code extrêmement contrôlé permet des optimisations et une adaptation au hardware. Il est remarquable de voir que pour du calcul matriciel par exemple, la JVM d'IBM est capable d'obtenir des performances environ 2 fois inférieures à celle de la bibliothèque MKL d'intel implémentée en assembleur et adaptée à l'architecture physique de chaque CPU (en particulier la taille du cache). Par rapport à une implémentation naïve de calcul matriciel (en C ou C++), une bibliothèque évoluée comme COLT peut être 300 fois plus rapide, grâce aux algorithmes utilisés, mais aussi grâce à l'excellence de la JVM d'IBM, qui est capable par exemple de supprimer au vol les tests de débordement d'un tableau quand le prouveur de byte-code intégré démontre que les tests sont inutiles.
[^] # Re: Mono 0.24
Posté par boubou . En réponse à la dépêche Mono 0.24. Évalué à 3.
spécification est publique, mais l'implémentation ne l'est pas du tout.
Putain, mais c'est incroyable de continuer à lire des conneries pareilles. Une grande partie de l'implémentation de Java est libre, point final. Par exemple, toute la partie XML du jdk 1.4 (versions se et ee) vient du projet apache. C'est très clairement indiqué dans la doc et la licence. Il s'agit de l'implémentation de référence, pas d'un clonage. De même, la meilleure implémentation des web services en Java (les api JAXRPC, entre autres) est clairement Axis qui est en avance sur Sun sur ce point. L'implémentation de référence des JSP et servlets est Tomcat, logiciel open source du groupe apache ! La spécification J2EE 1.4 est en cours d'implémentation par deux projets open source, JBoss et JOnAS qui implémentent déjà l'intégralité de J2EE 1.3, c'est-à-dire l'ensemble des api ajoutées à l'édition standard. La partie graphique spécifique au système du jdk 1.4 passe sous unix de motif à GTK dans l'implémentation de référence.
Mais Java a ses gros défauts. C'est un glouton de mémoire, c'est parfois
très lent et surtout... ce n'est pas utilisé dans la "vraie vie" !!
Sort de ton trou ! Ce n'est pas un répétant une connerie qu'elle devient vraie. Le site web de la SNCF est en Java (EJB), celui de Chronopost aussi. Les exemples sont légions. Et je ne parle pas simplement de la partie présentation (JSP servlet), mais bien sûr de la partie métier et de l'interfaçage avec les gros systèmes qui tournent derrière. Sur le serveur, Java est utilisé massivement. Autre exemple, j'ai participé à un appel d'offre gagné par une entreprise pour refaire le système de billeterie de la fnac (fance billet et billetel), le plus gros système de ce genre en France, et devine quoi, on va le faire en JAVA !!!!
Ah oui, il faudrait que cette plateforme soit "native" (i.e. *pas*
basée sur une machine virtuelle) pour offrir les performances que
l'on attends des logiciels "qui marchent".
C'est marrant les gens qui se la petent avec Eiffel super bien conçu, etc. et qui ensuite font "table rase" des énormes progrès réalisés par les machines virtuelles. Les machines virtuelles avec leur JIT offrent des performances excellentes, souvent meilleures que le code compilé. Elles peuvent en effet réaliser des optimisations basées sur le profil d'utilisation d'une méthode, chose impossible à faire sans VM, comme par exemple un inlining de méthode quand le besoin s'en fait sentir. De plus, le byte code extrêmement contrôlé permet des optimisations et une adaptation au hardware. Il est remarquable de voir que pour du calcul matriciel par exemple, la JVM d'IBM est capable d'obtenir des performances environ 2 fois inférieures à celle de la bibliothèque MKL d'intel implémentée en assembleur et adaptée à l'architecture physique de chaque CPU (en particulier la taille du cache). Par rapport à une implémentation naïve de calcul matriciel (en C ou C++), une bibliothèque évoluée comme COLT peut être 300 fois plus rapide, grâce aux algorithmes utilisés, mais aussi grâce à l'excellence de la JVM d'IBM, qui est capable par exemple de supprimer au vol les tests de débordement d'un tableau quand le prouveur de byte-code intégré démontre que les tests sont inutiles.