Discussion :

[joho]

Je ne penses pas qu'il faille réfléchir comme ça.
Si demain l'un de ces langages n'existe plus (ce n'est pas demain la veille quand meme) ben on passera à un autre, moyennant quelques formations au pire. Ces deux langages ont des "librairies externes" à ne plus savoir qu'en faire et les 2 ont été portés par une société puis par le libre. (on n'y est pas encore pour Microsoft c'est vrai )

A titre perso je penses que de toutes façon .NET a des applications que java n'a pas et vice versa. la question c'est surtout d'arriver a savoir au mieux, lequel fait quoi et comment il le fait mieux. Ces deux langages sont portés par des philosophies différentes, voila tout.

[the-gtm]

Dans le cadre d'une entreprise, le choix de dépendre d'un éditeur est quand même important. Si tu développe sur la version X du framework Y et que l'éditeur te dit "à partir de 2009 cette version ne sera plus supporté", ou bien "nous arrêtons le support du framework" ... Tu es alors obligé de migrer ton système ou de le laisser mourir sur place.
Historiquement microsoft a beaucoup plus pratiqué ce système que sun, y a qu'à voir le cout des projet de migration de versions de windows...

[_skip]

Dans le cadre d'une entreprise, le choix de dépendre d'un éditeur est quand même important. Si tu développe sur la version X du framework Y et que l'éditeur te dit "à partir de 2009 cette version ne sera plus supporté", ou bien "nous arrêtons le support du framework" ... Tu es alors obligé de migrer ton système ou de le laisser mourir sur place.
Historiquement microsoft a beaucoup plus pratiqué ce système que sun, y a qu'à voir le cout des projet de migration de versions de windows...

Je t'invite à relire les pages précédentes du débat, les migrations de version de Java comme de .Net sont excellentes et se font quasiment sans douleurs.

[The eye]

Je t'invite à relire les pages précédentes du débat, les migrations de version de Java comme de .Net sont excellentes et se font quasiment sans douleurs.

Je confirme, j'ai déjà migré un projet du Framework 1.0 au 2.0... sans douleur

et je suis en train de migrer des nouveaux modules avec le Framework 3.5 : coût de la migration = 1/2 journées de travail... difficile de faire plus light

[the-gtm]

Oui je sais bien que d'une version à l'autre ça va, ce qui pose problème c'est le jour ou le support est arrêté. Par exemple ceux qui ont une base de code en VB6 sont un peu contraints de migrer vers autre chose.

Pour des applications desktop, c'est quand même embétant de savoir que ton framework n'est plus supporté (donc pas de correction de bugs ni de failles de sécurité, pas de garantie que ça tourne sur les nouvelles versions de windows). Conclusion : soit tu laisse le truc pourrir sur place, soit tu passe à un autre framework.

Pour Java, les outils (compilateurs, IDE etc. sont quasi tous open source) c'est quand même une garantie qu'une forme de support continuera a exister.

[heid]

Pour Java, les outils (compilateurs, IDE etc. sont quasi tous open source) c'est quand même une garantie qu'une forme de support continuera a exister.

Pas d'accord, vu la multitude de framework en Java, quand tu en choisi un c'est un peut la lotterie parce que un an ou deux après la moité n'existera plus. Open source ou non. Je vous donne en exemple la difficulté de choisir une librairie de composant JSF en jonglant avec fonctionnalité, standard, incompatibilité et avenir.

[the-gtm]

j'aurai dû préciser mais quand je disais framework, je pensais plutôt au strict minimum lié au langage : runtime et compilateur (et accessoirement IDE)

Pour donner un exemple, Java6 n'était pas supporté sur Mac, un développeur a donc fait le boulot. Il a pu le faire seul et assez rapidement parce que tout ce dont il avait besoin était open source.

Pour porter .net ailleurs que sous windows, il faut "un peu" plus d'efforts et de sueur (cf. mono)

[doccpu]

Je trouve que la gestion des exceptions dans java est d'une lourdeur démesurée face à .Net;
Il y à aussi l'accès au mode unsafe qui n'existe pas en java;
cordialement.

[joho]

Si tu parles de la déclaration des exceptions dans la signature des méthodes, cela n'est plus (tout le temps) obligatoire. Le mécanisme des exceptions se rapproche beaucoup de celui de DotNET (j'suis triste, j'aimais ces déclarations ...)

[adiGuba]

Si tu parles de la déclaration des exceptions dans la signature des méthodes, cela n'est plus (tout le temps) obligatoire.

Ah bon

Le mécanisme des exceptions se rapproche beaucoup de celui de DotNET (j'suis triste, j'aimais ces déclarations ...)

La principale différence (à ma connaissance), c'est que Java possède deux types d'exception :

• Les unchecked-exceptions, qui fonctionne de la même manière que les exceptions de .NET, c'est à dire qu'on n'est pas obligé de les déclarer ni de les traiter.
• Les checked-exceptions, qui doivent obligatoirement être déclaré ou traité, ce qui force (un peu) à faire du code propre...

Si je ne me trompe pas, le CLR de .NET supporte la notion de checked-exception mais aucun des langages ne les gèrent...

Il faut savoir qu'il y a beaucoup de débats sur les checked-exceptions du fait de l'obligation de les traiter et de tout ce que cela implique (et sauf erreurs Java est le seul "grand" langage à les intégrer).


a++

[_skip]

Les checked-exceptions, qui doivent obligatoirement être déclaré ou traité, ce qui force (un peu) à faire du code propre...

Perso je trouve que ça peut être un avantage mais que ça peut aussi assez vite devenir lourd.

Surtout lorsque le code qui lance l'exception se situe loin de celui qui la gère, on est obligé de décorer toutes les méthodes sur le chemin, et ça peut devenir gavant et assez peu clair lorsqu'il commence à y en avoir plusieurs de ces exceptions et qu'on doit toutes se les trimballer.
De plus, on a pas forcément envie, ni le besoin de s'occuper de toutes les exceptions qui peuvent survenir, et même pour certaines d'entre elles on a peut être déjà fait des tests qui assurent qu'elles ne sortiront pas.

Personnellement, j'estime ne gérer qu'environ 30% des exceptions possibles. Donc dans mon cas ce système est plus une gêne qu'autre chose.

En gros, ce que ça provoque, c'est qu'il y a plein de développeurs débutants qui mettent des *throw Exception* partout autour de leurs méthodes et cela nique totalement le concept.

[eclesia]

je ne vois pas trop ou est le probleme avec les exceptions.

soit tu les geres de facon basique :
un petit System.out....

soit tu le fait plus proprement avec un Logger.

Ou alors tu fais tout ca bien et tu remontes les exceptions Importante de classe en classe (en changeant l'exception) pour au final te faire un beau petit message d'erreur dans l'interface.

J'avais l'habitude de ne pas traiter les erreurs car elles sont plutot rares, mais depuis que je dois garantir la bonne execution du code pour toutes les situations il est vrai que le systeme d'erreur de java est impec.

[adiGuba]

En gros, ce que ça provoque, c'est qu'il y a plein de développeurs débutants qui mettent des *throw Exception* partout autour de leurs méthodes et cela nique totalement le concept.

C'est bien ce que je dis : cela génère beaucoup de débats


A l'inverse on peut trouver le problème inverse avec un débutant qui ignorerait toutes exceptions et se retrouver avec une appli qui plante au moindre petit problème...


Pour moi c'est surtout le problème d'une gestion "propre" des exceptions... ce qui n'est pas si évident que cela quel que soit le langage

a++

[_skip]

je ne vois pas trop ou est le probleme avec les exceptions.

soit tu les geres de facon basique :
un petit System.out....

J'appelle pas ça gérer une exception moi, je catche que ce que j'ai prévu de voir arriver, pour le reste, je me contente de nettoyer avec un finally.
Etre obligé ou trop fortement incité à gérer une exception ça amène à des programmes faussement robustes qui continuent de s'exécuter dans des situations que le développeur n'a pas prévues.

[FremyCompany]

J'appelle pas ça gérer une exception moi, je catche que ce que j'ai prévu de voir arriver, pour le reste, je me contente de nettoyer avec un finally.
Etre obligé ou trop fortement incité à gérer une exception ça amène à des programmes faussement robustes qui continuent de s'exécuter dans des situations que le développeur n'a pas prévues.

+1

[adiGuba]

Mais ignorer toutes les exceptions revient à faire une application pas du tout robuste...

Dans les deux cas on doit avoir une gestion "propre" des exceptions

a++

[osma_1978]

Désolé j'ai pas compris cette derniere phrase

je croix que les éditeurs des logiciels OpenSource ont ont des buts qui sont cacher deriere la gratuité de leurs logiciels
FireBird est un SGBD OpenSource et gratuit , alors il peux être améliorer par d'autre éditeurs hors la fondation Firebird ce qui est un grand bénéfice pour la fondation et un jour , FireBird peuvent être payant

[_skip]

La fondation firebird est elle aussi tenue de respecter le modèle de licence d'interbase 6 sur lequel se base son produit. Donc en gros c'est illusoire de voir apparaître une version de firebird commerciale.
En revanche et c'est déjà le cas, l'utilisation de certains outils comme IBReplicator est soumise à licence, et le support de qualité professionnelle qui est nécessaire pour certains projets se monnaie.

[Jedai]

je croix que les éditeurs des logiciels OpenSource ont ont des buts qui sont cacher deriere la gratuité de leurs logiciels

Quels buts "cachés" ? Tu penses que ces sociétés se vendent en expliquant qu'elles sont gentilles parce qu'elle font du logiciel libre/de l'open source ? Tu es bien naïf dans ce cas. Les objectifs de ces sociétés sont toujours pour une grande part mercantiles et documentés à destination de leurs actionnaires et clients.
De plus tu n'as pas l'air de bien comprendre ce que signifie logiciel libre ou open source... La plupart de ces logiciels ont une license qui rend impossible de fermer le logiciel d'un jour à l'autre. Certaines permettraient à la société de décider qu'à partir de maintenant leurs développement ne sont plus librement distribuables, mais dans tous les cas, la dernière version libre continueraient à être légalement redistribuable et modifiable par la communauté.

--
Jedaï

[adiGuba]

Cela sort un peu du débat, mais le changement de licence ne concerne pas seulement l'open-source !

Même un logiciel commercial peut changer de licence et devenir plus coûteux...

a++