Je vois pas en quoi je ne maîtrise pas le sujet.
Parce que tu n'as pas l'air de savoir ce que l'on appelle un type primitif. Un type primitif est un type géré directement par le processeur. (int; float, long, double généralement - short, char, uint, etc. étant généralement un sous ensemble des précédents).

A partir du moment ou tu utilises des types évolués (ie. non primitfs) tu as forcément besoin d'un pointeur et la les perfs en Java et en C# seront exactement les mêmes, généricité ou pas (modulo la qualité de la VM). Et c'est 99,99% des cas.

Arréte donc de faire une obsession sur la généricité des types primitifs en Java. En réalité c'est extrêmement peu utilisé dans une liste et si tu as des besoins trés spécifiques tu peux tjs utiliser une blibliothèque adéquate trés simplement (il en existe des dizaines).

[ Répondre ]

Sauf que le libs en question font la plupart du temps appel à du code natif

N'importe quoi, toutes les libs que je connais, pour gérer des collections de types primitifs en Java sont toutes implémentées en Java. Arrête de propager du FUD. SVP.

Il existe des types primitifs en Java (comme en C#), car c'est plus performant qu'un pointeur sur un objet (même s'il s'agit d'un struct). T'as déja vu les perfs d'un programme smalltalk ou tous les types primitifs sont des objets. Excuse moi, mais tu n'as pas l'air vraiment de maîtriser le sujet.

[ Répondre ]

Au sujet de JNI, à partir du moment ou tu attaques une librairie C à partir de code C# tu retrouves exactement les mêmes pb qu'en Java(et heureusement!).

Pour les exceptions conditionnelles en Java, c'est une question de feeling certains sont pour, d'autres contre. Personnellement, je trouve que c'est plutot une bonne chose, cela avertit le programmeur d'une erreur potentielle (à lui de faire ce qu'il veut ensuite).

En terme de performance, la clause "final" ne sert à rien pour un bon compilateur, il détectera automatiquement que la classe est finale et pourra ainsi la dévirtualiser. Pour ce qui est de la dérivation.On peut aussi argumenter le contraire, combien d'entre nous n'ont pas pester parce que justement le développeur d'une librairie n'avait pas autorisé la dérivation d'une fonction. Bref les gouts et les couleurs.

Quant aux références, on peut difficilement faire moins partial, car il s'agit d'une interview d'Anders Hejlsberg, le créateur de C#, il serait étonnant qu'il dise autre chose.

[ Répondre ]

Comme tout problème, il est relatif. Si tu rencontres ce problème 2 fois sur un millions de ligne de code, je pense qu'il est facile d'y remédier. Encore faut faut-t-il que le code produit soit réellement un facteur de ralentissement. Selon mon expérience, c'est (trés) rarement le cas. Bref on est plus dans le domaine du micro-benchmark sans intéret que dans la réalité.

"tiens un mot clé que je ne connais pas utilisons le !"
Eh bien, je crois que justement il l'utisera...

Dans tous les cas C# ne t'oblige pas à utiliser les structs ou les pointeurs
Qu'il y t il de mal à utiliser une librairie plus performante. De toute pour éviter l'auto boxing et avoir des perfs max en c# tu seras obligé de faire pareil.

[ Répondre ]

Ton exemple n'est d'aucune utilité en pratique. J'ai sous les yeux un programme de 67000 lignes en Java et aucune des listes ne contient de types primitfs mais seulement des objets évolués. Si tel était le cas, et si j'avais un problème de perf, j'utiliserai une bibliothèque gérant les types primitifs. Il en existe des dizaines.

En revanvhe, le "struct"du c# comporte, AMHA, de nombreux problèmes: combien de développeurs ne vont pas comprendre son fonctionnement exacte et faire ainsi des recopies complète de structure plutot qu'une affection de pointeurs. (avec à la clef des consommation mémoire délirante et des problèmes de perf).

Bref je suis persuadé que l'on verra bcp plus de problèmes de ce type dans un programme en c# que de listes de type primitifs.

[ Répondre ]

Le C++ est compilé pour produire un code machine de la même nature et au même titre que la compilation assembleur. Certaines petites portions de programme peuvent être développées en ASM en ligne dans le code C++ ce qui permet de profiter à la fois du confort de codage du C++ et des performances de l'assembleur sur les points cruciaux.

En java, C#, en Python aussi, etc.

En revanche la production de code en pur C++ avec les STL est aussi rapide et, aux désallocation "delete" près, presqu'aussi sûr que la production de code Java.
Pas du tout d'accord. La STL reste compliquée à utiliser particulièrement avec les templates. Et il faut toujours allouer et désallouer la mêmoire manuellement.

L'utilisation (à mon avis très naze mais je peux me tromper) de la bibliothèque gc permet en plus de ne pas avoir à libérer les ressources manuellement.
C'est le moins que l'on puisse dire. C'est extrêment foireux et pour le cas bcp moins rapide du'un bon GC en java.

Java impose une couche supplémentaire merdique ; la JVM qui interprète le byte code et dont la justification est super discutable.
La JVM ne fait pas qu'interpréter le code, elle le compile et le transforme en langage machine. C'est particulèrement intéressant pour les langages objets car elle connait la structure exacte du programme et peut ainsi dévirtualiser des appels de fonctions et produire dans certains cas des programmes plus rapide qu'en C++. (je sais que les adeptes du C++ ont du mal à le croire mais c'est la réalité).

[ Répondre ]

Et cela n'a rien avoir avec Java car 99% du code de OOo et en C/C++. Comme quoi il est parfaitement possible de faire des programmes trés lent avec des langages conventionnels. Pour l'histoire, il faut savoir que StarOffice 5.2 était encore plus lent.

[ Répondre ]

J'ai essayé avec la librarie suivante et je n'ai eu aucun problème de perf :
http://www.sosnoski.com/opensrc/tclib/(...)

En fait,Timaniac fait référence à la manière dont sont traités les objets légers (struct) et l'auto-boxing (par ex. les types primitfs encapsulés dans des objets Integer/Float,etc.) en java par rapport à C#. Les implémentations sont différentes, chacune à ses avantages et ses inconvénients, mais cela n'empêche en aucun cas d'avoir de bonnes perfs en Java (comme en C#). De toute manière 99% des problèmes de perfs des applis réelles se retrouvent dans les algos et les libraries. Cf. un cas intéressant : http://www.spindazzle.org/green/wp-trackback.php/49(...) et http://www.spindazzle.org/green/wp-trackback.php/48(...) comme quoi !

[ Répondre ]

> beaucoup de cas d'utilisation c'est lent

Lequels ? Et si ce n'est pas le cas pour OOo, alors ou est le problème ?

Quant à moi, je pense que la gestion de mémoire à travers une GC est plutot une bonne chose (java ou autre). Moins de bugs, moins de fuites mémoires, dévéloppement plus rapide, etc. Bref plus d'avantages que d'inconvénients tant que ne développes pas des applications temps réel ou des drivers.

[ Répondre ]

Il existe des bibliothèques qui permettent d'attaquer les ports parallèles de manière assez simple. Si tu as peu d'expérience en programmation de bas niveau, c'est plutot par là que je commencerai à chercher. (rien ne sert de réinventer la roue - sauf si c'est pour apprendre).

Si tu veux faire du portable, il existe une petite api, développée en C, disponible sous Linux et Windows et qui peut être attaqué en Java : http://www.geocities.com/Juanga69/parport/(...)
Sur leur page d'accueil, tu trouveras pas mal d'infos intéressantes (particulièrement dans la section links).

[ Répondre ]

Certes, il s'agit de négligence mais ce n'est pas aussi facile que cela parait de controler tout le code que l'on peut mettre dans un projet. Rien de plus simple pour un développeur acculé par le temps (et c'est souvent le cas) que de repomper sauvagement qq milliers lignes de code GPL d'un projet libre. Et pour le vérifier, c'est vraiment pas évident.

Ca n'excuse pas la faute mais cela peut tout de même expliquer que certaines boites ont pu se faire "piéger". (et je suis presque certain que cela ne se sait pas, en interne comme en externe, dans 99% des cas).

[ Répondre ]

La communaité libre n'apprécie pas (à juste titre) la license proposée par Sun pour son environnement Java (comme elle n'apprécie pas la license DB2 d'IBM, de Photoshop, de Windows, etc...). Cela ne signifie pas qu'elle n'apprécie pas les mérites technologique du langage. Loin s'en faut. Regarde le nombre de projets libres écrits en Java, c'est assez impressionant.

> De mémoire, on n'a jamais vu une telle réaction
> pour le choix d'un autre langage dans un LL.

J'aurais bien été tenté par ksh88...

[ Répondre ]

Pourquoi ? simplement que la seule personne qui a proposé ses services pour faire ce genre de boulot était un développeur Java. C'est expliqué en détail dans un post plus ci-dessous.

C'est con parfois la vie !

[ Répondre ]

Pour mon meilleur ennemi : http://www.thisiscool.com/gcc_mingw.htm(...)

[ Répondre ]

Comme nid à troll on ne fait pas mieux. Et en plus c'est bourré de conneries ( Blackdown n'est pas libre mais "appartient" de fait à Sun, les projets Java libres sont nettement antérieurs à Mono, plus la cote : sur monster.fr 530 offres d'emplois en Java pour 92 en C#, bref que du n'importe quoi!). C'est tjs navrant de voir que moteurs à priori sérieux reprennent ce genre de news.

[ Répondre ]

Pas de panique. Selon un dev. de Classpath, il semble possible de faire tourner Oo 2. avec un environnement java libre : http://spindazzle.org/green/(...)

De toute manière le libre cela se mérite, il ne suffit pas de le décréter. C'est à la communauté libre de prendre son avenir en main pour produire un environnement libre en Java de qualité (et non de chialer/crier sur Sun qui ne fait pas comme elle le souhaiterait). Si certain, ici et ailleurs codaient autant qu'ils gueulaient, il est probable que bcp de projets libres seraient plus avancés.

[ Répondre ]

Et/ou de contribuer à GCJ/Classpath. Notons que Redhat (et compagnie...) fait un travail formidable de ce coté. Vivement un environnement (complètement) libre en Java.

[ Répondre ]

<i> Perdu. Le passage au 35h c'est fait sans diminution de salaire annuel. Du moins dans les textes. Dans ce cas s'etait sur. Tout le monde etait content, car rapporte a l'heure ca faisait une augmentation</i>

A court terme surement. A moyen et long terme c'est une autre histoire.

Quand tu bosses 35h, attends toi à être payé pour ... 35h.

[ Répondre ]

Avec Jakarta je sais pas mais avec celle la tu peux.

http://www.enterprisedt.com/products/edtftpj/overview.html(...)

[ Répondre ]

Tu te relis pas ou t'es de mauvaise foi.

C'est de toi trois posts plus haut :

C'est pas du tout la même philosophie que .NET, celà a des inconvénients, que j'ai cité, mais ausis des avantages : ils forcent le portage sur la plateforme en réécrivant le code à réutiliser et on y gagne en portabilité.

et maintenant :

C'est ce que je reproche à Java : il faut souvent tout réécrire pour tout réutiliser

Comprenne qui pourra !!!

[ Répondre ]