mais vas pas dire qu'en Java on réinvente à chaque fois la roue
J'ai pas dis à chaque fois. Me faites pas dire ce que je n'ai pas dis ;)
une API qui est pour l'instant plus grande que celle de la plateforme.net
Je suis d'accord, celà est due en partie à la vieillesse de la plateforme Java et justement au fait qu'il faille parfois "réinventer" la roue en Java. DirectX, même si ce n'est pas une priorité, c'était juste un exemple d'API difficilement exploitable en Java, pourtant on peut imaginer qu'une équipe de développement puisse avoir recour à cette techno, propriétaire mais performante. Quand on développe en Java, on s'arrange pour faire avec ce qui est dispo sur cette plateforme, comme tu le soulignes, il y a beaucoup d'API qui ont été portés, cetains étant de simple wrapper JNI (auquel cas c'est comme en .NET, mais en beaucoup moins élégant et pratique) et on ne réinvente pas la roue, mais dans d'autres cas il faut tout recoder.
Je vais prendre l'exemple tout bête du "port" de Quake2 sur la plateforme Java (l'exemple vaut ce qu'il vaut, il faut regarder le point de vue technique) : ils se sont fait chier à refaire un moteur complet (bref réinventer la roue), car impossible d'utiliser l'existant : bref plusieurs mois de boulot par plusieurs programmeurs.
Un autre s'est lancé dans le portage sur .NET : hop il a passé une journée à passer le code original du moteur en C en C++ managed (histoire que ca compile en .NET) et une autre journée de tuning : zou il obtient exactement la même chose, avec une seule commande il compile soit en natif soit en managé, et il obtient les mêmes perfs que l'équipe Java.
Tu vois où je veux en venir ?
Je ne dis pas que c'est toujours le cas (tu ne réinvente pas toujorus la roue !), mais forcer de reconnaître que Java n'aide pas à réutiliser l'existant et a conduit à faire de nombreux API en Java qui existait déjà en natif : beaucoup de perte de temps, avec un avantage : la portabilité.
Moi je préfère faire de la portabilité le jour où j'en ai besoin, plutôt que de m'enmerder avec dès le début parcque je n'ai pas le choix.
Un autre exemple : Mono a vu très rapidement le jour, pourquoi ?
Parcque en très peu de temps on a pu obtenir une plateforme utilisable qui se basait sur un existant fiable : GTK, Mozilla, libxml, Qt, etc. Pas toujours très portable, bien qu'ils aient tout de même choisi leurs technos, ils ont eu rapidement quelque chose d'impressionnant et de relativement stable, en proposant à l'utilisateur des API qu'il connait. En Java je rigole encore du temps qu'il a fallut pour obtenir Swing, sans parler que cette solution est loin d'être parfaite, et question intégration, elle se contente d'essayer d'imiter l'aspect graphique de l'environnement qui l'entour... Clap clap clap. Tout celà parcqu'ils ont voulu réinventer la roue et refaire une couche graphique portable. Résultat : un truc portable, mais un qualité perdue : l'intégration.
.net te dit en fait : hey prenez la facilité !
je dirais plutôt : avec .NET faites simple et utilisez l'existant, soit à travers la simplicité d'utilisation d'API natif, soit à travers le support de nombreux langages permettant de réutiliser du code existant.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 3.
J'ai pas dis à chaque fois. Me faites pas dire ce que je n'ai pas dis ;)
une API qui est pour l'instant plus grande que celle de la plateforme.net
Je suis d'accord, celà est due en partie à la vieillesse de la plateforme Java et justement au fait qu'il faille parfois "réinventer" la roue en Java. DirectX, même si ce n'est pas une priorité, c'était juste un exemple d'API difficilement exploitable en Java, pourtant on peut imaginer qu'une équipe de développement puisse avoir recour à cette techno, propriétaire mais performante. Quand on développe en Java, on s'arrange pour faire avec ce qui est dispo sur cette plateforme, comme tu le soulignes, il y a beaucoup d'API qui ont été portés, cetains étant de simple wrapper JNI (auquel cas c'est comme en .NET, mais en beaucoup moins élégant et pratique) et on ne réinvente pas la roue, mais dans d'autres cas il faut tout recoder.
Je vais prendre l'exemple tout bête du "port" de Quake2 sur la plateforme Java (l'exemple vaut ce qu'il vaut, il faut regarder le point de vue technique) : ils se sont fait chier à refaire un moteur complet (bref réinventer la roue), car impossible d'utiliser l'existant : bref plusieurs mois de boulot par plusieurs programmeurs.
Un autre s'est lancé dans le portage sur .NET : hop il a passé une journée à passer le code original du moteur en C en C++ managed (histoire que ca compile en .NET) et une autre journée de tuning : zou il obtient exactement la même chose, avec une seule commande il compile soit en natif soit en managé, et il obtient les mêmes perfs que l'équipe Java.
Tu vois où je veux en venir ?
Je ne dis pas que c'est toujours le cas (tu ne réinvente pas toujorus la roue !), mais forcer de reconnaître que Java n'aide pas à réutiliser l'existant et a conduit à faire de nombreux API en Java qui existait déjà en natif : beaucoup de perte de temps, avec un avantage : la portabilité.
Moi je préfère faire de la portabilité le jour où j'en ai besoin, plutôt que de m'enmerder avec dès le début parcque je n'ai pas le choix.
Un autre exemple : Mono a vu très rapidement le jour, pourquoi ?
Parcque en très peu de temps on a pu obtenir une plateforme utilisable qui se basait sur un existant fiable : GTK, Mozilla, libxml, Qt, etc. Pas toujours très portable, bien qu'ils aient tout de même choisi leurs technos, ils ont eu rapidement quelque chose d'impressionnant et de relativement stable, en proposant à l'utilisateur des API qu'il connait. En Java je rigole encore du temps qu'il a fallut pour obtenir Swing, sans parler que cette solution est loin d'être parfaite, et question intégration, elle se contente d'essayer d'imiter l'aspect graphique de l'environnement qui l'entour... Clap clap clap. Tout celà parcqu'ils ont voulu réinventer la roue et refaire une couche graphique portable. Résultat : un truc portable, mais un qualité perdue : l'intégration.
.net te dit en fait : hey prenez la facilité !
je dirais plutôt : avec .NET faites simple et utilisez l'existant, soit à travers la simplicité d'utilisation d'API natif, soit à travers le support de nombreux langages permettant de réutiliser du code existant.