Il peut y avoir le même problème avec Java en fait. Pour une entreprise qui a misée sur le JDK d'IBM avec Websphere et si les applications utilisent des extensions de Websphere (tous les packages com.ibm...)Envoyé par benwit
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Il peut y avoir le même problème avec Java en fait. Pour une entreprise qui a misée sur le JDK d'IBM avec Websphere et si les applications utilisent des extensions de Websphere (tous les packages com.ibm...)
Je ne répondrai à aucune question technique en privé
Effectivement ! mais c'est plus une exception à mon sens car dans ce cas, on crée un lien avec un produit. Si on utilise directement les drivers jdbc d'une base de donnée, on se lie également à un éditeur et on ne sait pas ce que l'avenir nous réserve. Ce n'est pas pour rien que pour rester dans l'esprit initial de Java, il est conseillé d'utiliser les standards (spécifications) qui permettent de changer son implémentation ... (je ne connais pas .Net pour savoir s'il y a des équivalents ?)
Le code C++ fait il y a 10 ans lors de mes études avec des outils Windows, impossible de l'exécuter actuellement (il manque toujours une dll, un ocx ou des incompatibilités ... avec les nouveaux IDE) Alors que le code Java fait à la même époque tourne toujours. Bien sûr, on peut mettre ça sur le compte de mon incompétence (j'ai peut être loupé un truc à l'époque) mais pour moi, cela illustre quand même deux philosophie différentes. Je n'oppose pas les langages car du C ANSI se compile toujours mais le fait de se lier ou non avec des produits à durée de vie limitée. Notez que je préfère les bons fichiers txt / xml au format .doc pour les mêmes raisons
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
Je pensais à un problème différent.
Pour des applications Web déployées sur plusieurs serveurs d'applications (par exemple 4 ou 5) avec du Load Balancing et qui effectuent des tâches longues. Pour avoir un système résistant au panne, il est très souvent nécessaire de mettre en place deux choses :
- des caches distribués entre les JVM
- l'utilisation de scheduler Websphere réparti entre les JVM (si un serveur tombe, les serveurs d'application se mettent d'accord pour relancer la tâche sur un serveur encore vivant) + gestion de lock distribué entre les serveurs sur chaque tâche
Malheureusement, il n'y a pas de solution standard à ce problème.
Websphere offre des classes comme DistributedMap, Scheduler... qui sont liées à Websphere.
Je ne répondrai à aucune question technique en privé
Je comprend ton problème mais reconnais que dans ton exemple, on sort de l'esprit initial de la portabilité de Java ?
Il serait intéressant qu'un spécialiste .Net nous indique s'il existe des équivalents pour .Net ? Quels serveurs d'applications ? Quels produits pour le load balancing en .Net ?
Si c'est le cas, il serait intéressant que Millie nous parle du choix Java vs .Net dans son exemple.
Sinon, on comprend donc le choix de java (What else ?)
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
En fait, il y a le problème pour n'importe quelle application Java EE distribuée sur plusieurs serveurs d'applications pour des tâches un peu longue. Websphere offre une solution pas très sexy, mais en standard, il n'y a pas vraiment de solution pour l'instant apparement.
Pour .NET, je pourrais pas dire, je connais pas du tout. Mais ça serait intéressant de savoir s'il existe ce type de fonctionnalité (load balancing, cache distribué, résistance aux pannes...)
Je ne répondrai à aucune question technique en privé
Et bien la licence dexexpress pour la citer me donne accès au code source, cependant je ne l'ai pas encore ouvert pour être honnête. Si jamais leur société s'arrête d'ici 5-6 ans, aurais-je le courage, la volonté et les moyens financiers de m'intéresser à ce code et le faire évoluer?
Je pense franchement que non, car cela me reviendra au moins au même de repartir sur de nouvelles bases, sans compter que si je me développe mon propre framework sur la base de ce code, ce sera à moi seul de le faire évoluer, d'effectuer les migrations technologiques. Une tâche qui devra se faire en plus de mon développement *productif*, et pendant ce temps, mes concurrents se focaliseront sur leur propre application, tout en bénéficiant des MAJ de leur outil.
Est-ce que l'un d'entre vous peut jurer que son application fonctionnera dans 10 ans? Est-ce que nous sommes plus à l'abri en utilisant du java, du .Net, de l'open source ou du propriétaire? Je tiens d'un ami, ex collègue de l'école d'ingénieur qui travaillait chez une entreprise de télécommunication en Suisse, ils ont un large panel de serveurs d'application différents, des versions et des JRE bien spécifiques et sitôt que les applications sont hors de leur environnement respectif (version du serveur d'app + version JRE), elle ne fonctionnent plus.
Si déjà un simple passage d'une version à une autre d'une JRE, d'un framework .Net ou d'un serveur d'application présente un risque potentiel d'anomalie, que dire d'une véritable évolution?
Il en est de même pour les bases de données Open Source, si leur développement s'arrête, pensez vous que les entreprises les utilisant seront en mesure d'engager des personnes pour les maintenir? Il y a bien plus de chance qu'elles effectuent une migration.
Tu as raisons sur de nombreux points communs Java/.Net :
Qu'advient t'il d'une librairie abandonnée ? même si son code source est disponible ? (que dire de celle dont ce n'est pas le cas)
Que penser des frameworks "personnels" ? S'ils ont pleins d'avantages, les maintenir est une lourde tâche.
En toute honnêteté, en utilisant uniquement les standards Java, en suivant l'évolution des produits (tomcat, jvm, ...) pour éviter de passer d'une version 1.x à 10.x, en évitant des librairies très propriétaires, en ayant des tests unitaires le plus complet possible pour vérifier les régressions éventuelles, je pense que oui.Est-ce que l'un d'entre vous peut jurer que son application fonctionnera dans 10 ans?
Pour ton exemple des bases de données "open source", si elles ne sont plus maintenues, l'intérêt de l'approche de sun (une spécification, des implémentations) nous met à l'abri de ce genre de problème en facilitant la migration.
Bon, c'est vrai que dans le cas de SQL Server, si l'éditeur se casse la gueule, l'outillage .Net sera dans la même barque
C'est pourquoi je pense que la "démarche" full Microsoft se défend !
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
Salute,
Bon je n'ai pas tout lu mais je voulais en fait souligner un point qui me parrait important, j'ai lu beaucoup de "Quoi .NET n'est pas portable? Regarde Mono..."
Ca c'est unpeu maigre, car mono n'est pas un produit Microsoft, c'est un produit libre maintenu par des bénévoles, donc en gros mono aura toujours un retard par rapport au framework de chez crosoft...
Alors pour ma part, non .NET n'est en aucun cas portable.
C'est fait pour ne pas marcher ailleurs point
Compil your life guy!
The Aures Project
Je me permet d'apporter un petit grain de sel sur les EDI Java et DotNet, pour ma part je trouve NetBeans aussi bien que Visual Studio, mieux par certains coté et moins par d'autres. Chacun a ses avantages et inconvénients.
Pour mat part j'aime les deux langages et je pense que l'on peut arriver au même résultat avec les deux.
Je mettrais un point en plus à Java pour la techno JNLP (java web start) juste parce que cà simplifie énormément le déploiement. Apres je ne crois pas qu'il éxiste d'équivalent en DotNet.
PS : j'espere que mes soft fonctionneront encore dans 10 ans, cependant, je miserais plutot sur 5 ans.
" Je préfère comprendre les gens qui ne me comprennent pas "
cours vite le dire à toutes les entreprises qui ont choisie java, tu leurs éviteras de perdre du temps, de l'argent...
tu deviendra riche
.NET est portable. Les spécifications ont été écrites pour être indépendantes de la plateforme. Les spécifications sont publiques. Microsoft fournit une implémentation pour différentes plateformes (Windows, XBox et d'autres). Alors oui, Mono a du retard par rapport à la version Microsoft, mais est-ce un gros problème ? Non, puisque Mono n'est pas à la traine par rapport aux concurrents (Java, etc.), au contraire dirais-je même. Même pour quelqu'un développant uniquement sous Unix, Mono est une solution acceptable, et des entreprises sérieuses le font d'ailleurs. Enfin, Mono n'est pas développé par des bénévoles, le soir, quand ils n'ont rien d'autres à faire ; les développeurs Mono sont payés par Novell (je ne sais pas s'ils le sont tous, mais une bonne partie, oui).
.NET est conçu pour être portable. Si tu regardes bien : F#, IronRuby et IronPython sont développés par des personnes de chez Microsoft. Et pourtant, ça tourne nativement sous Mono. Alors, question portabilité, on a vu pire, et ton argument "fait pour ne pas marcher ailleurs" tombe en miette.
J'imagine que tu n'as jamais essayé Mono.
Pour les entreprises possédant des serveurs ou des postes de travail linux (unix?), je dirais que cela peut être un gros problème. Elles n'ont pas une garantie proche de 100% que leur applicatif va fonctionner aussi bien sous linux/mono que sous windows/mono.
Dans le cas présent, le problème n'est pas de savoir si mono est en avance sur les concurrents de la plateforme .Net mais bel et bien par rapport à l'implémentation "officielle" de microsoft. Je pense que quelqu'un qui a déjà fait le choix de la plateform .Net n'est pas intéressé de savoir mono est en avance sur java(ou autre), par contre savoir qu'est-ce qui ne va pas fonctionner sous mono cela va plus l'intéresser et va forcément influencer sur le choix du système d'exploitation de production.
Mais cette portabilité n'est pas la même, ici il s'agit de portabilité des langages sur la plateforme DotNet, non et la portabilité de la plateforme elle-même?
En tout cas, il n'y a pas de doute sur le sujet, cette plateforme a été conçue pour intégrer facilement de nouveau langage.
Je serais curieux de te voir argumenter cela !
a++
Mono est portable, on peut développer avec Mono sous Windows et j'imagine qu'il n'y a pas beaucoup de différence avec la version Mono sous Unix. À moins d'écrire en dur "c:\windows\.." dans le code ou d'utiliser une API spécifique à Windows.
Par ailleurs, il existe un outil qui permet de tester un fichier binaire et qui indique s'il utilise des fonctions non implémentées dans Mono.
Non, quand on commence un développement, on compare les différentes options que l'on a. On peut se demander s'il vaut mieux développer en Java, ou .NET ou utiliser un autre langage. Dès lors que l'on a choisi .NET et que l'on souhaite une portabilité Unix, il n'y a pas beaucoup d'autre choix que Mono. On fait donc avec.Dans le cas présent, le problème n'est pas de savoir si mono est en avance sur les concurrents de la plateforme .Net mais bel et bien par rapport à l'implémentation "officielle" de microsoft.
Il s'agit de logiciels écrits pour .NET. C'est du bytecode .NET écrit sous Windows qui est exécuté avec Mono sous Unix. Cela prouve bien que le bytecode est portable, même quand c'est développé par Microsoft. Cela prouve que les logiciels conçus sous Windows pour MS .NET sont portables (quand on ne fait pas n'importe quoi). F# étant un compilateur, on remarque aussi que le code généré par F# s'exécute aussi bien sous Mono. Il n'y a donc pas grand-chose à reprocher à Mono.Mais cette portabilité n'est pas la même, ici il s'agit de portabilité des langages sur la plateforme DotNet, non et la portabilité de la plateforme elle-même?
Quant à la portabilité de Mono lui même : http://www.mono-project.com/Supported_Platforms
C'est presque le même débat que MS .NET / Java, à quelques détails près.Je serais curieux de te voir argumenter cela !
On peut commencer par l'implémentation des generics, la récursivité terminale, et continuer avec les langages disponibles (C# Linq inclus, F#, IronPython, IronRuby, Phalanger (PHP), VB 8). Il y a d'autres langages sur le site de Mono, mais je ne sais pas ce qu'ils valent (Scala, Boo, Eiffel, Java...). Je me suis déjà amusé à utiliser Mono comme une bibliothèque. Mon code C natif (compilé avec gcc) pouvait appeler des fonctions écrites en PHP et le PHP pouvait appeler mes fonctions C natives. Je ne sais pas si des implémentations de Java permettent ça. À part Java et Fortress, quels langages pour la JVM sont mûrs et développés par une entreprise fiable et pérenne ?
Click Once est (je pense) un équivalent à JNLP.
http://morpheus.developpez.com/clickonce/
Jette un coup d'oeil à Ext Gwt
On peut aussi ajouter Cal (et le framework Open Quark) qui est développé par Business Objects (ça devrait pouvoir passer comme entreprise pérenne non?)
Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager