Diantre. Je ne suis pas futurologue ! Cela relève déjà de la gageure en temps normal, mais alors en informatique, ça devient de la mystification. Plus précisément, cela doit faire l'objet d'une étude appronfondie, celle-là même que vous avez dû mener. Ce que je peux proposer dans une réponse de forum tient donc du point de vue, rien de plus sérieux.
Je suis intéressé par votre proposition d'alternatives à Java/ Tomcat pour une application de gestion commerciale.
En fait, je n'ai rien proposé. J'écris des logiciels pour le domaine de la recherche, donc nos besoins sont assez différents de celle de la gestion d'entreprise.
Comme je l'ai dit, le monde Java est extrêmement prisé des entreprises car presque toutes les technologies modernes y sont représentées et qu'il est plus facile d'y trouver des développeurs que dans d'autres environnements. Maintenant, cela restera toujours "une machine dans une machine" et cela pose problème. C'est lent et lourd, les JVM ne sont pas déployées par défaut sur les ordinateurs du grand public ni sous Windows, ni sous Linux, la communication avec l'environnement existe mais l'intégration beaucoup moins et surtout le déploiement en entreprise d'un truc style J2EE est tentaculaire !
C'est une centrale nucléaire et le problème est le même pour toutes les technos un tant soit peu ambitieuses : c'est très efficace tant qu'il y a des gens compétents et motivés pour le faire, après cela pose problème. Le passage à l'an 2000 a conduit les grandes compagnies à rappeler les cobolistes retraités pour une revue de code. Est-ce que les systèmes complexes actuels seront stables pendant 20 ans, et est-ce qu'au bout de cette période, il sera aisé de s'y replonger pour en préparer la migration, comme vous l'avez fait aujourd'hui ?
Coté utilisateur, je préconise -dans l'absolu- quelque chose qui soit stable, rapide, et peu gourmand en ressources système et en espace disque. Evidemment, ça demande de briser beaucoup de couches d'abstraction bâties au fil du temps et, parfois, de contourner le modèle objet. Ca demande beaucoup de compétences, du temps, et ce n'est plus économiquement intéressant. N'empêche que si Java est très utilisé en milieu professionnel, je n'ai encore jamais vu un logiciel grand public vendu en rayon qui soit écrit dans ce langage.
Je pense d'autre part que les applications basées sur des masques de saisie et des adresses de page peuvent être presque directement transcrites, pour ce qui est de l'interface utilisateur, vers du web/css sans technologie associée coté client (même pas du Javascript). Cela a l'avantage de fonctionner partout sans déploiement particulier (le navigateur web, lui, est désormais présent partout). Par contre, faire une migration pour conserver le même mode opérationnel, ce n'est pas forcément intéressant.
Personnellement, je me retrouve bien dans le C/C++, qui permettent d'écrire des applications au plus bas niveau possible et en minimisant les dépendances à des ressources externes.
A titre indicatif, j'ai réalisé une grosse application CGI standalone en C++ uniquement. Il est clair que cela a de quoi faire bondir la majorité des webmestres qui me lisent et que c'est généralement inadapté pour la plupart des solutions développées sur le web. Il n'en reste pas moins qu'aujourd'hui, le déploiement de cette application de 35000 lignes, c'est un seul fichier binaire. En pesant le pour et le contre, il était plus simple pour moi de gérer mon propre système de session et de manipuler directement l'interface CGI avec des "out <<" plutôt que d'instancier un objet déjà écrit et d'appeler une méthode du sixième niveau en ayant bien pris soin de ne rien avoir émis avant, comme en PHP par exemple. Point de vue empreinte en mémoire et temps d'exécution, l'application est imbattable.
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 5.
Diantre. Je ne suis pas futurologue ! Cela relève déjà de la gageure en temps normal, mais alors en informatique, ça devient de la mystification. Plus précisément, cela doit faire l'objet d'une étude appronfondie, celle-là même que vous avez dû mener. Ce que je peux proposer dans une réponse de forum tient donc du point de vue, rien de plus sérieux.
En fait, je n'ai rien proposé. J'écris des logiciels pour le domaine de la recherche, donc nos besoins sont assez différents de celle de la gestion d'entreprise.
Comme je l'ai dit, le monde Java est extrêmement prisé des entreprises car presque toutes les technologies modernes y sont représentées et qu'il est plus facile d'y trouver des développeurs que dans d'autres environnements. Maintenant, cela restera toujours "une machine dans une machine" et cela pose problème. C'est lent et lourd, les JVM ne sont pas déployées par défaut sur les ordinateurs du grand public ni sous Windows, ni sous Linux, la communication avec l'environnement existe mais l'intégration beaucoup moins et surtout le déploiement en entreprise d'un truc style J2EE est tentaculaire !
C'est une centrale nucléaire et le problème est le même pour toutes les technos un tant soit peu ambitieuses : c'est très efficace tant qu'il y a des gens compétents et motivés pour le faire, après cela pose problème. Le passage à l'an 2000 a conduit les grandes compagnies à rappeler les cobolistes retraités pour une revue de code. Est-ce que les systèmes complexes actuels seront stables pendant 20 ans, et est-ce qu'au bout de cette période, il sera aisé de s'y replonger pour en préparer la migration, comme vous l'avez fait aujourd'hui ?
Coté utilisateur, je préconise -dans l'absolu- quelque chose qui soit stable, rapide, et peu gourmand en ressources système et en espace disque. Evidemment, ça demande de briser beaucoup de couches d'abstraction bâties au fil du temps et, parfois, de contourner le modèle objet. Ca demande beaucoup de compétences, du temps, et ce n'est plus économiquement intéressant. N'empêche que si Java est très utilisé en milieu professionnel, je n'ai encore jamais vu un logiciel grand public vendu en rayon qui soit écrit dans ce langage.
Je pense d'autre part que les applications basées sur des masques de saisie et des adresses de page peuvent être presque directement transcrites, pour ce qui est de l'interface utilisateur, vers du web/css sans technologie associée coté client (même pas du Javascript). Cela a l'avantage de fonctionner partout sans déploiement particulier (le navigateur web, lui, est désormais présent partout). Par contre, faire une migration pour conserver le même mode opérationnel, ce n'est pas forcément intéressant.
Personnellement, je me retrouve bien dans le C/C++, qui permettent d'écrire des applications au plus bas niveau possible et en minimisant les dépendances à des ressources externes.
A titre indicatif, j'ai réalisé une grosse application CGI standalone en C++ uniquement. Il est clair que cela a de quoi faire bondir la majorité des webmestres qui me lisent et que c'est généralement inadapté pour la plupart des solutions développées sur le web. Il n'en reste pas moins qu'aujourd'hui, le déploiement de cette application de 35000 lignes, c'est un seul fichier binaire. En pesant le pour et le contre, il était plus simple pour moi de gérer mon propre système de session et de manipuler directement l'interface CGI avec des "out <<" plutôt que d'instancier un objet déjà écrit et d'appeler une méthode du sixième niveau en ayant bien pris soin de ne rien avoir émis avant, comme en PHP par exemple. Point de vue empreinte en mémoire et temps d'exécution, l'application est imbattable.
A voir au cas par cas, donc.