6
votes

Le CLR est-il incompatible avec Java (langue)?

Je me suis demandé pendant un moment sur la faisabilité de la course Java sur le CLR.

Après avoir vu une question précédente ici, je me rends compte qu'il y a plusieurs différences entre la plate-forme Sun Java et le guitage .NET qui ferait la compilation croisée impossible dans tous les cas les plus triviaux. P>

qui étant dit, n'est-ce pas une langue complète? Ne pouviez-vous pas écrire un JVM en IL? Bien sûr, la réponse est oui, mais pourquoi même aller aussi loin? P>

Ma question est la suivante: p>

est la CLR (comme une plate-forme) incompatible avec Java en tant que langue (pas plate-forme)? h3>

Quelle quantité de Java devrait être convertie ou cassée afin de le faire en forme? h3>

Certes, cette em> pourrait être compilé pour le CLR + .NET: P>

import System.*;

public class HelloWorldExample
{
    public static void main(String args[])
    {
        Console.WriteLine("Hello World !");
    }
}

java clr

8 commentaires

Cela ne semble pas être une question de Stackoverflow à moins que ce soit le wiki communautaire.

@Pointy: Où mettriez-vous une telle question, alors? Peut-être un site dédié à répondre à des problèmes de programmation hautement techniques?

en.wikipedia.org/wiki/j_sharp

Ne serait-il pas préférable d'avoir C # compiler pour courir sur JVM?

@Kirk, bien tenant compte que J # utilise une approche hybride qui peut réellement exécuter Java Bytecode, je dirais que c'est plus géré un JVM géré qu'une implémentation CLR .NET. Bon point, tho.

@Pointy Community Wiki n'est plus.

@NullUSeException Whoa quoi? Ai-je manqué quelque chose?

@Pointy Vous ne pouvez plus poster de questions comme cw plus.

3 Réponses :

0
votes

Une recherche rapide révèle ikvm et le projet en cours ja.net .

Cela dit, je pouvais voir la valeur dans l'autre sens.

1 commentaires

Ce sont des bibliothèques JVMS / Class, plutôt que des compilateurs Java. À droite? Ou suis-je me confondre?

-3
votes

Oui, mais étant donné que Java est beaucoup plus largement utilisé et plus standard ... ne le voudriez-vous pas l'inverse, c'est-à-dire Compiler C # à Java Bytecode? La réponse est bien sûr qu'il est possible d'écrire un compilateur Java qui émettra partecode pour CLR ou un compilateur C # qui émettra Java Bytecode. La sciure, cependant, est que vous auriez besoin de fournir une implémentation personnalisée de la bibliothèque / bibliothèques standard qui rappellerait la bibliothèque ou les bibliothèques pour cette plate-forme. Et compte tenu de la taille des deux API qui constitueraient une entreprise assez importante. Cela nécessiterait probablement une équipe assez grande pour le faire dans un délai raisonnable. Je suggérerais de commencer un projet OpenSource si vous avez l'intention de le faire, bien que cant que C # / CLR est un Microsoft-ism, je ne suis pas sûr de la façon dont l'enthousiasme peut être généré.

7 commentaires

Qu'y a-t-il avec le vote Down? Quelqu'un en colère que c # / CLR est propriétaire?

Je dirais que c'est à peine l'affaire compte tenu de l'état actuel du projet mono et du fait que l'Oracle poursuit Google sur Java.

Je suppose que les bowvotes sont parce que vous vous êtes moqué de la question au lieu de le répondre.

@Gabe, j'ai répondu à la question. Il n'y a aucune raison pour laquelle il ne serait pas possible de créer un C # à JVM ou Java au compilateur CLR.

L'OP a demandé "est le CLR incompatible avec Java (en tant que langue)?" et vous avez répondu "oui" (la réponse correcte est "non") puis a écrit 150 mots expliquant pourquoi il ne voudrait pas même s'il avait déjà dit "je me rendrais compte qu'il y ait assez de différences ... ça ferait de la croix -Commiler impossible dans tous les cas les plus triviaux. "

@Gabe, oh, je vois la cause de la confusion ... J'ai répondu à sa dernière question, qui était "ne pouvait-il pas écrire une JVM?"

Michael: Je pense que la plupart des gens ont pris "ne pouvais-tu pas écrire de jvm?" Comme une question rhétorique parce qu'il l'a suivi de "bien sûr, la réponse est oui".

6
votes

Le CLR a été conçu avec l'hypothèse que les gens devraient pouvoir transmettre à .NET de Java en pouvant compiler leur code source Java largement non modifié. Ainsi, les choses de Java, vous pourriez envisager d'être problématique dans une exécution (comme des tableaux de covariant) sont incluses comme caractéristiques du CLR.

Le projet J # implémente assez de la bibliothèque standard Java que la plupart des applications Java compileront avec des modifications minimales. Notez que J # peut charger JVM Bytecodes pour la compatibilité, mais J # Source compile toujours à CLR Bytecodes.

3 commentaires

"En pouvant compiler leur code source Java largement non modifié" - avez-vous une référence pour cela? Si c'est vrai, ils n'ont pas fait un travail très impressionnant.

@DavidMoles: C'était il y a plus de 10 ans, alors je ne saurais pas où commencer à regarder. Voir blogs.msdn.com/b/ericlippert/archive/2007/10/17/... , cependant: "Il a été ajouté au CLR parce que Java l'exige et les concepteurs CLR souhaitent pouvoir être capable pour soutenir les langages comme des langues de Java. " Y a-t-il une caractéristique particulière de JVM non pris en charge par CLR que vous avez à l'esprit?

Toutes mes excuses - je viens de réaliser que j'ai mal interprété votre déclaration initiale; Je pensais c #, pas CLR. Je dirais toujours que la plupart des programmes Java non triviaux vont dépendre trop sur les bibliothèques standard pour vous éloigner de les recompiler, mais je prends votre point de vue.