Sinon, la JVM fait tourner du ByteCode. Rien n'empêche de développer un nouveau langage qui se compile en ByteCode, et d'ailleurs ça existe déjà (Jython).
Mais la machine virtuelle n'a pas été conçue pour supporter plein de langage, c'est plus un effet de bord... techiquement, tu pourrais produire du bytecode java depuis n'importe quel langage, pratiquement certains produiront de bien meilleurs résultats...
Si il n'y a pas plus de langages sur la plate-forme J2EE, c'est à mon avis parce que cela ne présente pas beaucoup d'intérêt. Pas plus que sur .Net d'ailleurs. Faire du VB.Net ou du C# n'est pas à proprement parler une alternative technique, tout au mieux un choix esthétique de seconde importance. C'est pas parce que t'as fait du VB que tu vas pondre du code objet propre en VB.Net...
D'accord avec toi... mais l'intêret réside surtout dans le fait de pouvoir utiliser un composant développer en n'importe quel langage avec n'importe quel langage, et que le tout soit correctement supporté (pas de lourd coût de marshalling, comme on le connait sous Win32 avec les ActiveX, debugging facile entre langage, etc...). Prendre VB et C# n'est à mon avis pas l'idéal... prends plutôt C++ et C#... un "nouvel arrivant" va utiliser C# plus "facile" syntaxiquement... un autre gardera C++... le tout restera cohérent et en principe performant.
Enfin, tes problèmes de portabilité, je veux bien croire qu'il y en a, mais je n'en ai jamais souffert. Pas besoin de les minimiser : ils sont effectivement minimes.
Euh, j'ai du faire une app java linux/windows (pas trop de problème) et ... macosx (avec la jvm de webobject) et là... boum! plein de petits détails... un autre problème aussi: les différences d'une jvm à l'autre... tomcat se ramassse la gueule avec la 1.4 avec la 1.3 ça passe très bien... un bête code de drag and drop ne donne pas le même résultat selon l'os.... etc... En bref, ça existe bel et bien... et comme c'est toujours le cas pour ce genre de problème: ils ne sont pas minimes si tu les subits, et ils sont inexistant si tu n'en es pas la victime.
[^] # Re: Benchmark J2EE vs dotNET
Posté par tene . En réponse à la dépêche Benchmark J2EE vs dotNET. Évalué à 1.
Mais la machine virtuelle n'a pas été conçue pour supporter plein de langage, c'est plus un effet de bord... techiquement, tu pourrais produire du bytecode java depuis n'importe quel langage, pratiquement certains produiront de bien meilleurs résultats...
Si il n'y a pas plus de langages sur la plate-forme J2EE, c'est à mon avis parce que cela ne présente pas beaucoup d'intérêt. Pas plus que sur .Net d'ailleurs. Faire du VB.Net ou du C# n'est pas à proprement parler une alternative technique, tout au mieux un choix esthétique de seconde importance. C'est pas parce que t'as fait du VB que tu vas pondre du code objet propre en VB.Net...
D'accord avec toi... mais l'intêret réside surtout dans le fait de pouvoir utiliser un composant développer en n'importe quel langage avec n'importe quel langage, et que le tout soit correctement supporté (pas de lourd coût de marshalling, comme on le connait sous Win32 avec les ActiveX, debugging facile entre langage, etc...). Prendre VB et C# n'est à mon avis pas l'idéal... prends plutôt C++ et C#... un "nouvel arrivant" va utiliser C# plus "facile" syntaxiquement... un autre gardera C++... le tout restera cohérent et en principe performant.
Enfin, tes problèmes de portabilité, je veux bien croire qu'il y en a, mais je n'en ai jamais souffert. Pas besoin de les minimiser : ils sont effectivement minimes.
Euh, j'ai du faire une app java linux/windows (pas trop de problème) et ... macosx (avec la jvm de webobject) et là... boum! plein de petits détails... un autre problème aussi: les différences d'une jvm à l'autre... tomcat se ramassse la gueule avec la 1.4 avec la 1.3 ça passe très bien... un bête code de drag and drop ne donne pas le même résultat selon l'os.... etc... En bref, ça existe bel et bien... et comme c'est toujours le cas pour ce genre de problème: ils ne sont pas minimes si tu les subits, et ils sont inexistant si tu n'en es pas la victime.