Discussion :

[adiGuba]

Les generics .Net implémentent les interfaces non-génériques en plus des leurs.

Autant pour moi il me semblait que ce n'était pas le cas (j'me disais bien que j'allais dire une connerie ).

Mais à moins que je me trompe encore, il n'est pas possible de changer une classe standard en classe "Generic" sans casser la compatibilité. Or en Java plusieurs classes existante ont pu être adaptées pour utiliser les Generics sans que cela ne pose problème. Et cela pourrait être encore plus généralisé dans les futures versions...

Les generics de java ne sont même pas pris en charge par le runtime

Oui je l'ai dit !
Mais cela apporte les mêmes fonctionnalités in fine

De plus pour l'API de Collections il est quand même possible d'avoir du typesafe à l'exécution via Collections.checkedCollection()...

(pas plus que les types valeurs non-primitifs comme DateTime, etc.)...

C'est à dire ? Qu'est-ce que DateTime exactement ???

Pour moi, les seuls avantages techniques de Java sont sa portabilité actuelle et sa quantité de code existante (et encore, un wrapper COM peut faire bien des choses à ce sujet).

Concernant le langage, je suis d'accord sur le fait qu'il peut faire un peu "vieux jeux" comparé à C#, mais il conserve sa "simplicité" qui fait qu'il n'y a pas 36 manière de faire quelque chose...

Perso j'ai été impressionné par le nombre de mot-clef de C#... Déjà qu'en Java il y en a plusieurs qui sont méconnu voir carrément inconnu de la plupart des développeurs, je n'ose imaginer ce que cela doit donner...

a++

[Keihilin]

Perso j'ai été impressionné par le nombre de mot-clef de C#... Déjà qu'en Java il y en a plusieurs qui sont méconnu voir carrément inconnu de la plupart des développeurs, je n'ose imaginer ce que cela doit donner...

environ 80 mots-clé pour C# 2.0 ça ne me paraît pas énorme, d'autant plus qu'à part "goto" qui est là pour des raisons (pré)historique, tous ont une utilité et aucun ne me sont inconnus...

[adiGuba]

environ 80 mots-clé pour C# 2.0 ça ne me paraît pas énorme, d'autant plus qu'à part "goto" qui est là pour des raisons (pré)historique,

Pour info il y en a un peu moins de 50 en Java (y compris le goto qui est un mot-clé inutilisé -- d'ailleurs je pensait que c'était la même chose en C#).

tous ont une utilité et aucun ne me sont inconnus...

Je n'en doute pas... mais je ne pense sérieusement pas que ce soit le cas pour un grand nombre de développeurs...

Ce qui me gène en C# c'est qu'il semble y avoir plusieurs moyens de faire la même chose au niveau du langage. D'ailleurs c'est ce qui me gène concernant certaines propositions pour Java 7...

a++

[Keihilin]

Pour info il y en a un peu moins de 50 en Java (y compris le goto qui est un mot-clé inutilisé -- d'ailleurs je pensait que c'était la même chose en C#).

Je pense que ça doit être pareil en Java et en C#, si tu te retrouves à utiliser goto, c'est déjà que tu fais quelque chose de faux.

Ce qui me gène en C# c'est qu'il semble y avoir plusieurs moyens de faire la même chose au niveau du langage. D'ailleurs c'est ce qui me gène concernant certaines propositions pour Java 7...

Plusieurs moyens de faire la même chose c'est classique en développement, surtout en POO.
Maintenant si tu parles d'une redondance dans les mots-clé, je n'en vois pas des masses...à part peut être do until(){} qui fait la même chose qu'un while(){} à -1 près

Tu avais un exemple en particulier ?

[Médinoc]

C'est à dire ? Qu'est-ce que DateTime exactement ???

À première vue, DateTime (comme bien d'autres) peut ressembler à une classe ordinaire : Ça a des variables (généralement peu, DateTime ne contient qu'un grand entier de 64 bits) et des méthodes.
... Mais ça a toute la légèreté d'un long. DateTime est un type valeur, (par opposition aux types références) tout comme les types primitifs. Donc, quand tu travailles sur des DateTime, tu n'as aucune allocation dans le tas, aucun comptage de références/GC à faire, juste des appels de ses méthodes. Là où java doit se taper de l'allocation dynamique à chaque opération si le type est immuable, .Net évite ce gouffre à performances pour ces types valeurs non-primitifs.

En java, cela est impossible: Tous les types non-primitifs sont des types référence.

[adiGuba]

Je pense que ça doit être pareil en Java et en C#, si tu te retrouves à utiliser goto, c'est déjà que tu fais quelque chose de faux.

Tout à fait. Mais ce que je voulais dire c'est que l'utilisation de goto provoque une erreur de compilation...

Maintenant si tu parles d'une redondance dans les mots-clé, je n'en vois pas des masses...à part peut être do until(){} qui fait la même chose qu'un while(){} à -1 près

Non c'est juste l'impression que cela m'a donné quand j'ai vu la liste pour la première fois... mais je ne suis pas rentré dans le détail...

Tu avais un exemple en particulier ?

Il me semble avoir vu plusieurs possibilités d'initialisation de variables locales, avec var pour déterminer le type implicitement ou des accolades pour initialiser certaines valeurs à la construction plutôt que juste après...

Je trouve cela assez confus...

À première vue, DateTime (comme bien d'autres) peut ressembler à une classe ordinaire : Ça a des variables (généralement peu, DateTime ne contient qu'un grand entier de 64 bits) et des méthodes.
... Mais ça a toute la légèreté d'un long. DateTime est un type valeur, (par opposition aux types références) tout comme les types primitifs. Donc, quand tu travailles sur des DateTime, tu n'as aucune allocation dans le tas, aucun comptage de références/GC à faire, juste des appels de ses méthodes.

Je n'ai peut-être pas compris toutes les subtilités que cela implique, mais en utilisant une classe wrapper contenant un long on obtient grosso-modo le même résultat (on alloue juste un objet qui manipule un long).

Là où java doit se taper de l'allocation dynamique à chaque opération si le type est immuable, .Net évite ce gouffre à performances pour ces types valeurs non-primitifs.

Heu... L'immuabilité c'est autre chose ! Et c'est d'ailleurs un concept également présent dans .NET (et là je suis presque sûr de ne pas me tromper).


a++

[Keihilin]

Tout à fait. Mais ce que je voulais dire c'est que l'utilisation de goto provoque une erreur de compilation...

Ah non, en C# ça compile...hélas.

Il me semble avoir vu plusieurs possibilités d'initialisation de variables locales, avec var pour déterminer le type implicitement ou des accolades pour initialiser certaines valeurs à la construction plutôt que juste après...

Le var est une nouveauté de la version 3.5 qui découle de LINQ...Et j'ai eu une mauvaise impression de retour en arrière face à ça
Je sais que plusieurs "facilités" d'écriture ont été ajoutées en 3.5, mais je ne me suis pas encore penché en détails sur ce point.

Heu... L'immuabilité c'est autre chose ! Et c'est d'ailleurs un concept également présent dans .NET (et là je suis presque sûr de ne pas me tromper).

Tout à fait, les string sont immuables en .Net

[LLB]

Mais cela apporte les mêmes fonctionnalités in fine

Ah, tu peux voir les generics via l'introspection ? ...

Et quand je lis que

It is illegal to define generic types that are directly or indirectly derived from class Throwable .

je me rends compte que leurs implémentation des generics (ou plutôt leur non-implémentation) est relativement bancale.

Et quand je vois que la VM Java se contente de faire des casts et des tests à l'exécution, ça confirme mon impression : ce n'est que du vent, du sucre syntaxique. Dans .NET, les generics ont vraiment apporté beaucoup, notamment quand on veut utiliser différents langages.


Je viens de lire ici un certain nombre de remarques sur le goto, le nombre de mots-clés en C#, etc. C'est quoi le rapport avec le débat .NET / Java ? .NET ne se limite heureusement pas à C# et c'est d'ailleurs ce qui en fait sa force, à mon sens.

Tout, depuis les spécifications de .NET, est conçu pour être indépendantdu langage. Il y a quelques limitations (pas de fonctions anonymes, pas de fermetures lexicales...) dans l'IL, mais elles peuvent être contournées par le compilateur du langage.

[Keihilin]

Je viens de lire ici un certain nombre de remarques sur le goto, le nombre de mots-clés en C#, etc. C'est quoi le rapport avec le débat .NET / Java ? .NET ne se limite heureusement pas à C# et c'est d'ailleurs ce qui en fait sa force, à mon sens.

.Net ne se limite pas à C# certes, mais c'est quand même le principal langage utilisé.
Concernant les quelques remarques sur le nombre de mots-clé, il ne s'agit que de comparer la "clarté" des langages.

pas de fonctions anonymes

On parle peut être de deux choses différentes, mais les méthodes anonymes existent.

[LLB]

On parle peut être de deux choses différentes, mais les méthodes anonymes existent.

Comme je l'ai dit, à ma connaissance, il n'existe ni classe, ni méthode anonyme dans l'IL de .NET. Par contre, il y en a dans C# (et certains autres langages) : à la compilation, le compilateur se charge alors de les nommer.

En revanche, je ne connais pas du tout les mécanismes internes de Java, je ne peux pas comparer.

[Keihilin]

Comme je l'ai dit, à ma connaissance, il n'existe ni classe, ni méthode anonyme dans l'IL de .NET.

Ah ok, au temps pour moi, tu parlais spécifiquement de l'IL.

[adiGuba]

Ah, tu peux voir les generics via l'introspection ? ...

En effet les Generics sont partiellement disponible via l'introspection et ils ne sont pas disponible sur les exceptions...

Et quand je vois que la VM Java se contente de faire des casts et des tests à l'exécution, ça confirme mon impression : ce n'est que du vent, du sucre syntaxique. Dans .NET, les generics ont vraiment apporté beaucoup, notamment quand on veut utiliser différents langages.

L'objectif des Generics est clairement annoncé : sécuriser le code à la compilation.

Cette implémentation permet de mettre à jour les API existantes afin qu'elles utilisent les Generics sans avoir à dupliquer les classes ou rompre la compatibilité ascendante. Cela apporte quelques restrictions et complexité en plus mais l'apport est bien appréciable et assez puissant !

Par contre je ne vois pas le rapport avec entre les Generics et le fait d'utiliser différents langages. Tu pourrais détailler cela ca m'intéresse

Je viens de lire ici un certain nombre de remarques sur le goto, le nombre de mots-clés en C#, etc. C'est quoi le rapport avec le débat .NET / Java ? .NET ne se limite heureusement pas à C# et c'est d'ailleurs ce qui en fait sa force, à mon sens.

Ce n'étais juste qu'une remarque concernant les mot-clé de C#. Si j'en ai parlé c'est que je pense qu'il s'agit du langage principal de .NET et surtout c'est le seul que je connaisse un peu...

Tout, depuis les spécifications de .NET, est conçu pour être indépendantdu langage. Il y a quelques limitations (pas de fonctions anonymes, pas de fermetures lexicales...) dans l'IL, mais elles peuvent être contournées par le compilateur du langage.

C'est exactement la même chose en ce qui concerne le bytecode Java. Il existe d'ailleurs plusieurs compilateur qui utilise d'autres langages que Java (et même du .NET).

Sa principale limitation actuellement concerne les langages de scripts et l'appel de méthode dynamique (dont le nom et les paramètres ne sont vérifiés qu'à l'exécution). Mais cela devrait être intégré dans Java 7 (JSR-292).

En revanche, je ne connais pas du tout les mécanismes internes de Java, je ne peux pas comparer.

C'est le même principe : une classe est automatiquement généré par le compilateur...


a++

[Médinoc]

Je n'ai peut-être pas compris toutes les subtilités que cela implique, mais en utilisant une classe wrapper contenant un long on obtient grosso-modo le même résultat (on alloue juste un objet qui manipule un long).

C'est le mot "alloue" qui fait toute la différence: Un type valeur n'a pas besoin d'allocation dynamique, couteuse.

Heu... L'immuabilité c'est autre chose ! Et c'est d'ailleurs un concept également présent dans .NET (et là je suis presque sûr de ne pas me tromper).

Naturellement l'immuabilité est présente en .Net, mais cela n'enlève rien au fait que les types référence immuables nécessitent une allocation dynamique à chaque modification. L'immuabilité met en évidence le coût en performance de l'absence de types valeur (un DateTime, bien qu'aussi immuable qu'un type valeur puisse l'être, ne nécessite jamais la moindre allocation dynamique).

[adiGuba]

C'est le mot "alloue" qui fait toute la différence: Un type valeur n'a pas besoin d'allocation dynamique, couteuse.

Une remarque : l'allocation dynamique n'est pas aussi couteuse dans un environnement managé avec un GC que dans du code natif avec gestion manuelle l'allocation d'un objet n'implique pas forcément une allocation de mémoire auprès du système, puisque dans la plupart des cas le GC puisera directement dans son heap...

Naturellement l'immuabilité est présente en .Net, mais cela n'enlève rien au fait que les types référence immuables nécessitent une allocation dynamique à chaque modification. L'immuabilité met en évidence le coût en performance de l'absence de types valeur (un DateTime, bien qu'aussi immuable qu'un type valeur puisse l'être, ne nécessite jamais la moindre allocation dynamique).

Je comprend mieux la relation avec la notion d'immuabilité !
Cela semble intéressant en effet mais mis à part dans des cas extrêmes je ne sais pas si l'impact est si important que cela...

a++

[LLB]

.Net ne se limite pas à C# certes, mais c'est quand même le principal langage utilisé.

Et ?

Le principal avantage de .NET, pour moi, est sa philosophie : dès son fondement, il a été conçu pour être indépendant du langage. Le but est d'offrir une plateforme de développement uniforme, quel que soit le langage que l'on utilise, et quel que soit son domaine (programmation web serveur, programmation web client (Silverlight...), applications traditionnelles...), et quel que soit l'OS (même si tout n'est pas encore parfait, c'est plutôt correct). Cela favorise grandement la réutilisation du code et n'enferme pas les programmeurs dans un seul paradigme.

Ca m'intéresserait beaucoup d'avoir l'avis de quelqu'un ayant déjà écrit un compilateur visant la VM Java, ou de quelqu'un utilisant régulièrement un langage du style Scala. Je ne suis pas convaincu que l'on retrouve le même confort qu'avec les langages .NET.

Par contre je ne vois pas le rapport avec entre les Generics et le fait d'utiliser différents langages. Tu pourrais détailler cela ca m'intéresse

Je manque de connaissances en Java pour être sûr de moi (d'où ma question ci-dessus). Mais vu que l'introspection sur les generics est limitée, comment se passe le mélange entre langages ? Des informations de types étant supprimées, n'y a-t-il pas un problème qui se pose ?

Dans .NET, les compilateurs utilisent l'introspection sur les différentes bibliothèques pour retrouver les informations de typage, et donc pour faire vérifier le typage à la compilation. Dans Java, si on utilise une classe déjà compilée, le compilateur peut-il vraiment tout vérifier ?

C'est exactement la même chose en ce qui concerne le bytecode Java. Il existe d'ailleurs plusieurs compilateur qui utilise d'autres langages que Java

Je sais, mais Java n'a pas été conçu dans cette optique là. Il n'y a qu'à voir l'ambigüité avec le mot "Java". Microsoft développe plusieurs langages pour .NET (C#, VB, J#, C++, F#...). Microsoft participe activement à la programmation fonctionnelle : cf ILX et Abstract IL (pour aider les langages fonctionnels à générer de l'IL), cf F# (et les travaux de Don Syme), cf les travaux sur Haskell (Simon P. Jones...)...

D'un point de vue extérieur, j'ai l'impression que Sun ne soutient que le langage Java et n'imagine rien d'autre que la POO. Les langages autres que Java visant la plateforme Java m'ont toujours semblé anecdotiques. Mais je peux me tromper... Cela dit, quels langages visant Java sont réellement utilisés ?

Concernant les quelques remarques sur le nombre de mots-clé, il ne s'agit que de comparer la "clarté" des langages.

C'est bien là le problème. Il y a un autre débat C# contre Java.

Il n'y a pas lieu de comparer la clarté entre les langages ici. Personnellement, j'utilise F#, qui ressemble assez peu à C#/Java. Et si tu veux comparer F# contre Java, je te propose de participer à / regarder les "défis" proposés dans le forum prog fonctionnelle. Mais bon, on ne va pas s'amuser à comparer la syntaxe de tous les langages de .NET/Java...

[Keihilin]

Et ?

Et tu as raison, ce genre de remarques auraient plus leur place dans le débat C# vs Java.
Cela dit, il est difficile de dissocier .Net de C# et les deux débats convergent forcément sur certains points.

Il n'y a pas lieu de comparer la clarté entre les langages ici. Personnellement, j'utilise F#, qui ressemble assez peu à C#/Java. Et si tu veux comparer F# contre Java, je te propose de participer à / regarder les "défis" proposés dans le forum prog fonctionnelle.

Je regarde ce forum d'un oeil intéressé assez régulièrement, merci.

[adiGuba]

Je manque de connaissances en Java pour être sûr de moi (d'où ma question ci-dessus). Mais vu que l'introspection sur les generics est limitée, comment se passe le mélange entre langages ? Des informations de types étant supprimées, n'y a-t-il pas un problème qui se pose ?

Dans .NET, les compilateurs utilisent l'introspection sur les différentes bibliothèques pour retrouver les informations de typage, et donc pour faire vérifier le typage à la compilation. Dans Java, si on utilise une classe déjà compilée, le compilateur peut-il vraiment tout vérifier ?

Les informations sur les Generics sont bien présent dans les classes une fois compilées, ce n'est que le paramétrage utilisé lors de la déclaration qui est perdu.

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
class MaClasse<T extends Number> {
	private T value;
 
	public void setValue(T value) {
		this.value = value;
	}
 
	public T getValue() {
		return this.value;
	}
}

Via la reflection tu peux récupérer toutes les infos des Generics (T extends Number dans ce cas) le compilateur a tout ce qu'il a besoin pour faire ses vérifications...

Mais par contre tu ne peux pas différencier deux instances utilisant un paramétrage différent :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	MaClasse<?> object1 = new MaClasse<Integer>();
	MaClasse<?> object2 = new MaClasse<Double>();

Impossible via l'API de reflection de déterminer que object2 utilise des Double...

Je sais, mais Java n'a pas été conçu dans cette optique là. Il n'y a qu'à voir l'ambigüité avec le mot "Java". Microsoft développe plusieurs langages pour .NET (C#, VB, J#, C++, F#...). Microsoft participe activement à la programmation fonctionnelle : cf ILX et Abstract IL (pour aider les langages fonctionnels à générer de l'IL), cf F# (et les travaux de Don Syme), cf les travaux sur Haskell (Simon P. Jones...)...

D'un point de vue extérieur, j'ai l'impression que Sun ne soutient que le langage Java et n'imagine rien d'autre que la POO. Les langages autres que Java visant la plateforme Java m'ont toujours semblé anecdotiques. Mais je peux me tromper... Cela dit, quels langages visant Java sont réellement utilisés ?

Java a aussi été conçus dans cette optique, mais Sun n'a jamais cherché à introduire d'autre langage en laissant cela à d'autre, ce qui n'a jamais été fait à grande ampleur. Sun n'a certainement pas les même moyens que Microsoft pour développer autant de langage c'est sûr.
On peut noter toutefois l'arrivée de JavaFX (un langage plus orienté "présentation") et des projets de recherche (comme Fortress un langage de calcul scientifique visant à "remplacer" Fortran), mais Java reste LE langage de la JVM

Je suis tout à fait d'accord avec toi sur le fait que c'est très minoritaire sur la plateforme Java (et encore plus lorsqu'on fait la comparaison avec la plateforme .NET), et que le mot "Java" est vraiment très ambigue (mais Sun est un champion pour les ambigüités, que ce soit sur les noms ou sur les numéros de version )

Mais bon, on ne va pas s'amuser à comparer la syntaxe de tous les langages de .NET/Java...

En effet tu as tout à fait raison ces remarques sortaient complètement du sujet

a++

[RiiiDD]

Je viens de lire 20 pages de ce topic intéressant (donc pas la totalité), et je ne vois personne évoquer des questions de coûts.

Dès qu'on parle de .net (et la je parle plus précisément d'asp.net) la problématique coût intervient.

Ma question est la suivante, pensez vous qu'en .net (asp) les coût soient supérieur ? Si oui lesquels ?

Serveur Web (IIS ?)
Est ce possible de faire tourner un IIS sous linux avec mono ?
Y a t'il un serveur web gratuit asp.net ?
quand bien même IIS sous window était la seul solution, par rapport au prix d'un projet "standard", ce ne sont pas les 500 euros qui sont un gros frein.


A part le serveur web, je vois peut être les problèmatiques de composants avancés (genre flexgrid ou outil de reporting) qui sont gratuit en java et pas en .net. Qu'en pensez vous ?

[Keihilin]

Dès qu'on parle de .net (et la je parle plus précisément d'asp.net) la problématique coût intervient.

Ma question est la suivante, pensez vous qu'en .net (asp) les coût soient supérieur ? Si oui lesquels ?

1er point : l'IDE

La différence de coût entre une solution Java et une solution .Net se situe, à mon avis, principalement à ce niveau. Même si il existe des alternatives gratuites comme les version Express ou SharpDevelop, en environnement professionnel Visual Studio reste incontournable; et Visual Studio est loin d'être gratuit.
Je ne me lancerai pas dans un débat Visual Studio vs Eclipse, mais je ne pense pas qu'il existe un IDE gratuit aussi puissant que VS.

SharpDevelop est une alternative viable, mais ne disposant pas des même moyens, cet outil à toujours un temps de retard sur VS et n'est pas encore à son niveau en terme de confort d'utilisation.

2e point : l'OS

Une solution Java n'est pas forcément destinée à tourner sur du Linux, donc la licence MS peut entrer dans les coûts autant en .Net qu'en Java.

D'autre part, il est tout à fait possible de faire tourner .Net sur du Linux via Mono. C'est stable.

3e point : Reporting et autres outils

Il y a des équivalents gratuits et des solutions payantes dans les deux mondes, aussi bien du côté des outils de reporting que des composants avancés.

[kasnej]

Bonjour,

Je vais bientôt commencer dans un projet un peut costeau: un logiciel pour la gestion de scolarité d'une université.
cette application vas etre alimenté d'une ou plusieurs BD de differentes types.
un site internet va etre alimenté de la base de l'applivation.
la bande passante du site est de 10GB par mois avec 10 000 visiteurs par mois
C en realité un systeme extarnet internet.
donc je voulais savoir quelle plateforme est plus convenable a ce type d'application?

Merci pour votre aide.