Discussion :

[Gordon Fowler]

IKVM implémente Java pour .NET

IKVM est une implémentation de Java pour .NET et Mono (le pendant open source de .NET).

Il inclut :

* A Java Virtual Machine implemented in .NET
* A .NET implementation of the Java class libraries
* Tools that enable Java and .NET interoperability

Le projet vis à remplacer JRE, la machine virtuelle de Sun Microsystems.
L'intérêt du couple IKVM et .NET est de pouvoir écrire et/ou de faire tourner des applications Java.
Idéal pour les développeurs qui souhaitent importer leurs anciens codes sur la plate-forme .NET, pour, par exemple, les réutiliser.

Parmi les améliorations récentes de l'implémentation, signalons le support de plus en plus efficace des librairies graphiques Swing et AWT.

IKVM est en téléchargement libre ainsi que sa documentation.

Source : Site d'IKVM.

Lire aussi sur Develeppez :

Les tutos, faq, actu de Java
Les tutos, faq, actu de .NET

Et vous ? :

Ce genre d'implémentation vous séduit-elle ?

[Firwen]

[mode troll ON]

Manque plus qu'une implémentation C# sur la JVM

[/mode troll OFF]

[nouknouk]

je trouve l'initiative sympa.

D'une façon générale, plus il y a de passerelles entre les langages/Frameworks, mieux c'est

[gorgonite]

ne risque-t-on pas de voir le projet périclité comme Visual J++ ?

[vintz72]

Question bête : c'était censé ne pas être lourd et lent leur truc ?
Ca me parait ambitieux !

M'enfin, à voir... pour le moment, je ne vois pas l'intérêt.

N.B. En outre, ça semble être mono-plateforme (Windows...)

[nouknouk]

ne risque-t-on pas de voir le projet périclité comme Visual J++ ?

Amha, IKVM ne vise pas le même but que Visual J++ en son temps.

J'imagine que l'idée n'est pas d'imposer Java comme langage de référence dans la nébuleuse .Net : le C# est (et restera amha) LE langage prépondérant de la plateforme ; penser que le langage Java (je parle bien du langage, pas d'autre chose) pourrait le concurrencer là serait bien naïf.

Par contre, ce genre d'initiative est très intéressante pour qui voudrait migrer une appli existante de Java vers .Net sans avoir à tout réécrire d'un coup, mais plutôt en procédant par étapes.

Je vois également l'intérêt d'utiliser IKVM pour des librairies déjà existantes en Java et qui n'ont pas (encore ?) d'équivalent sur .Net

[Firwen]

ne risque-t-on pas de voir le projet périclité comme Visual J++ ?

Microsoft fait de dotnet son principal cheval de bataille, je doute qu'il ne supporte pas quelque chose qui lui apporterait le soutien de la commauté java.

[nouknouk]

N.B. En outre, ça semble être mono-plateforme (Windows...)

Première phrase du site donné en lien:

IKVM.NET is an implementation of Java for Mono and the Microsoft .NET Framework.

[gorgonite]

Amha, IKVM ne vise pas le même but que Visual J++ en son temps.

J'imagine que l'idée n'est pas d'imposer Java comme langage de référence dans la nébuleuse .Net : le C# est (et restera amha) LE langage prépondérant de la plateforme ; penser que le langage Java (je parle bien du langage, pas d'autre chose) pourrait le concurrencer là serait bien naïf.

Microsoft fait de dotnet son principal cheval de bataille, je doute qu'il ne supporte pas quelque chose qui lui apporterait le soutien de la commauté java.

je pense que vous n'avez rien compris à ce dont je parlais...
1) je n'ai pas dit que Java allait être imposé sur .Net grâce à ce projet (et d'ailleurs ce serait inutile puisque C# existe et fait mieux )
2) je n'ai pas dit non plus que le risque pour IKVM venait de Microsoft



je parlais du risque de poursuites légales de la part de Sun comme du temps de Visual J++

Par contre, ce genre d'initiative est très intéressante pour qui voudrait migrer une appli existante de Java vers .Net sans avoir à tout réécrire d'un coup, mais plutôt en procédant par étapes.

Je vois également l'intérêt d'utiliser IKVM pour des librairies déjà existantes en Java et qui n'ont pas (encore ?) d'équivalent sur .Net

+100

il est clair de permettre une interopérabilité entre des bibliothèques Java et des projets .Net devrait faciliter les migrations par la réutilisation de frameworks Java existants et à peu près débuggés dans de nouveaux projets .Net

[nouknouk]

je pense que vous n'avez rien compris à ce dont je parlais...

En même temps, tu ne nous donnais pas vraiment beaucoup d'indices

je parlais du risque de poursuites légales de la part de Sun comme du temps de Visual J++

Je n'en suis pas certain, mais je ne pense pas, car:
- Java est désormais open source
- les implémentations de JVM complètes et libres (IcedTea, ...) existent déjà et ne sont pas inquiétées par Sun.

Peut-être il resterait le risque d'utiliser la marque "java" dans la comm. du site, mais je ne vois pas d'autre source potentielle de conflits.

[gorgonite]

Je n'en suis pas certain, mais je ne pense pas, car:
- Java est désormais open source
- les implémentations de JVM complètes et libres (IcedTea, ...) existent déjà et ne sont pas inquiétées par Sun.

certes, mais cela a-t-il réellement eu un impact sur le marché ?
si Sun voit des migrations massives de Java vers .Net, grâce à la possibilité de réutiliser l'existant en Java, est-ce qu'ils vont rester aussi cools ?

[nouknouk]

est-ce qu'ils vont rester aussi cools ?

cools ou pas, il sont maintenant contraints pas leur diffusion de Java en GPL.

S'ils ont donné des droits à la commnauté, il ne peuvent pas les retirer du jour au lendemain à grand coup de procès, juste parce qu'ils ont décidé de changer de stratégie entre temps.

[gorgonite]

cools ou pas, il sont maintenant contraints pas leur diffusion de Java en GPL.

justement seul le code est GPL... mais rien que l'utilisation du mot Java pour un logiciel est soumis à d'autres contraintes

[smyley]

Sauf que avec la licence de Java on pourrai normalement créer une JVM en .NET qui respecterait l'implémentation de Java selon Sun (et c'est un peux le cas de IKVM vu qu'il permet d'exécuter du bytecode java au dessus du CLR).

Ceci dit, ce projet date au moins de 2007. Mais d'après ce que j'ai pu en voir son utilisation reste encore étrange, l'histoire d'utiliser à la fois la JVM et le CLR étant quand même hérétique ...

[nouknouk]

son utilisation reste encore étrange, l'histoire d'utiliser à la fois la JVM et le CLR étant quand même hérétique ...

Tu pourrais détailler ?

[smyley]

Avec IKVM on a une implémentation des classes Java au dessus de .NET et donc on programme dans un monde Java en utilisant des classes Java et avec la possibilité d'utiliser des assemblies .NET et quand on exécute un jar il y a exécution d'un code dans une machine virtuelle elle même exécutée dans une machine virtuelle ...

Après, quelle est le cas où l'on peut trouver une utilité dans IKVM ? Ce que j'ai vu sur ce forum c'est qu'on a par exemple une lib en java et qu'on veut à tout prix l'utiliser en C# et donc IKVM sauf que l'implémentation en .NET existe ou est faisable ... si ce n'est que pour ça, il serai quand même plus cohérent de chercher l'équivalent .NET plutôt que de passer par là.

Du coup, je ne suis pas sur qu'en production on puisse utiliser cette technologie sans problème et faire tout ce que l'on veux ...

[maitredede]

Mais d'après ce que j'ai pu en voir son utilisation reste encore étrange, l'histoire d'utiliser à la fois la JVM et le CLR étant quand même hérétique ...

Hérétique, oui pour les puristes de ces plateformes. Mais dans ce cas, les émulateurs (en tous genres) sont hérétiques aussi. Emuler une console (genre NES) sur un PC, ça peut être considéré comme hérétique. D'une manière générale : "une machine (virtuelle ou non) capable de faire tourner du code d'une autre machine".

Personnellement, je laisse l'hérétisme aux religions et à l'Histoire...

Je pense que ce projet est, comme l'as dit Nounouk, très intéressant pour la migration de projets de java vers dotnet, ou l'utilisation de librairies conçues pour Java dans dotnet.

Aujourd'hui, j'ai un cas pratique où un fournisseur n'a développé des librairies pour utiliser leur matériel qu'en C ou en Java...

[smyley]

Hérétique, oui pour les puristes de ces plateformes. Mais dans ce cas, les émulateurs (en tous genres) sont hérétiques aussi. Emuler une console (genre NES) sur un PC, ça peut être considéré comme hérétique. D'une manière générale : "une machine (virtuelle ou non) capable de faire tourner du code d'une autre machine".

Personnellement, je laisse l'hérétisme aux religions et à l'Histoire...

Le mot a peut être dépassé la pensé, il n'est pas question de religion (le C# c'est la vérité ) mais plus d'utilisation pratique.
Avoir un projet mixé à la fois avec du C# et du Java pour la même application, je ne suis pas sur que ce soit facilement maintenable. Déjà savoir si dans un projet .NET on engage en programmeur Java ou C# ... je persiste à croire que dans un projet de grande envergure c'est déjà assez compliqué de se battre par exemple avec du C#/C++ avec pourquoi pas du PHP et autres choses semblables. Rajouter aux problèmes inhérents de la plateforme .NET ou du C++ des détails concernant une JVM et la lib Java ...

Après le projet pour le projet, IKVM c'est ingénieux là n'est pas la question.

[lex2004]

Ça fait un petit bout de temps que je parcoure des articles sur IKVM; notamment sur le site du projet Mono où il est dit que Monodevelop supporte la programmation en langage Java (les binaires étant générés en CIL via IKVM). Dans l'immédiat je n'en ai pas vu l'utilité. Mais en y regardant de plus près j'ai fini par me dire que ça permettrait d'accélérer la migration de certains projets Java vers .Net et Mono. A ce jour jour, bon nombre de projets Java ont leur équivalent .Net (log4net, iText#, Spring.Net, NHibernate, NUnit, ...) mais beaucoup sont encore en cours de développement (dont le très attendu NReports). Ce principe serait d'ailleurs plus avantageux pour Mono car .Net est accompagné d'une panoplie de frameworks et d'utilitaires qui ne sont malheureusement plus disponibles hors-Windows (dixit Crystal Reports). Donc à la longue, IKVM pourrait bien finir par trouver son utilité.

Par contre, il n'est surtout pas question (pour tout développeur .Net sensé) de commencer un tout nouveau projet en langage Java espérant le migrer à la fin vers .Net via IKVM. Si les développeurs .Net avaient été séduits par la syntaxe du langage Java, J# aurait eu plus de succès . Mais l'expérience a montré que même les développeurs Java reconvertis en .Net préférent généralement C# ( ils auraient marre d'écrire des trucs du genre monTruc.setPrixHt(monTruc.getPrixUnitaire().multiply(new BigDecimal(monTruc.getQuantite()))) ). Pour être plus sérieux, si l'on décide de coder en Java, il faut le faire de bout en bout et si par contre on choisit .Net, il faut également y rester à 100% (entendons-nous, cela n'empêche pas l'échange de données et la réutilisation de code hein?)

[nouknouk]

Avoir un projet mixé à la fois avec du C# et du Java pour la même application, je ne suis pas sur que ce soit facilement maintenable. Déjà savoir si dans un projet .NET on engage en programmeur Java ou C# ... je persiste à croire que dans un projet de grande envergure c'est déjà assez compliqué de se battre par exemple avec du C#/C++ avec pourquoi pas du PHP et autres choses semblables. Rajouter aux problèmes inhérents de la plateforme .NET ou du C++ des détails concernant une JVM et la lib Java ...

On parlait d'un intérêt pour un migration ou une réutilisation de l'existant.

Evidemment, si on veut développer une appli dès le départ pour cible le .net framework, on va pas s'amuser à faire ça en Java juste pour le plaisir de se rajouter une couche de soucis !

Mais quand on a déjà eu affaire dans un contexte pro à l'évaluation du coût d'une migration de l'existant d'une plateforme vers une autre, on comprend très vite l'intérêt que peut offrir ce genre de solution.

Même idée pour réutiliser des libs dispos uniquement en Java ; le cas du driver/connecteur propriétaire uniquement dispo en Java est un excellent exemple (j'ai encore eu le cas récemment avec des cartes à puce d'authentification).

Après, c'est comme d'autre outils (GJC, ...): ça répond à des besoins occasionnels et spécifiques. Ca n'a pas vocation à être le 'must have' de tout développeur .Net et/ou Java.