Other Languages For The Java Vm
Other Languages For The Java VmDespite what some DotNet/CommonLanguageRuntime (CLR) proponents claim, the JavaVirtualMachine supports multiple languages as well. See http://www.robert-tolksdorf.de/vmlanguages.html for the gory details.
A short list of languages that can run in the Java VM follows.
Languages for which a compiler to (or perhaps a translator to something that can be compiled to) Java bytecode (with or without extra class libraries) has been written
Can these languages interact with compiled code from each other?
Yes, by construction: they compile to Java bytecodes, that provide the ability to send arbitrary messages.
Languages for which an interpreter has been written in Java
Question to any ProgrammingLanguageExperts? out there: How difficult and/or meaningful would it be to try and compile C down to the JVM? I am speaking hypothetically, of course.
I think the problem with C is that you're going to have to simulate quite a bit of the machine-level coziness that C has (esp. pointers and all that can be done with them) in an environment that's really quite hostile to it. A project like that would be a huge undertaking, which is probably why it hasn't happened. A C-to-JavaLanguage converter (that, of course, requires human touchups) seems more likely.
Is the JavaVirtualMachine hostile to the C paradigm, or just the JavaLanguage? I thought the VM was fairly close to any other machine architecture. I don't think that such bytecode would be a good thing, but would it be possible? (Disclaimers: Possibly BeatingaDeadHorse; IdontKnowWhatIamTalkingAbout?.)
I hope I'm not getting too far out of my element here, but I recall from my early experiences with Java that the JVM itself deals with classes and objects; they're not simulated by the compiler.
I've been thinking a bit on how to enable legacy code (C/C++) as a language for the JVM. There are lots of ugly ways to do it, and lots of slow ways, but no really good ways. The issue is that the JVM doesn't allow pointer arithmetic; that is, there are no java assembly instructions which can manipulate address locations. This really limits what you can do without just setting up a giant array to act as memory (ugly), or just emulating a known platform (for example, rewriting Bochs in the JavaLanguage; slow). -- AdamBerger
I don't think the issue is the languages themselves, but the libraries. The libraries are really the backbones of C, C++, and Java; I would expect most of the effort in porting from C/C++ to Java to be in switching or emulating library functions. Off the top of my head, I would expect a lot of effort to go into handling printf(). --WayneMack
There is a C compiler for the JVM (see the list above).
This - http://sol.pace.edu/~tilevich/c2j.html - is a link found on the above mentioned external link, described as "C2J++ is a C++ to Java translator that translates C++ code to Java code. C2J++ is based on Chris Laffra's C2J." The link on that page to C2J seems to be dead though. But clearly, someone has at least attempted this. -- HowardShawIII
Note also, gcc supposedly supports the JVM as a back-end, so it should be possible to use it to compile C, C++, Objective C, Ada, Fortran-77(!),and maybe even Java into JVM bytecodes. wrong. gcc compiles bytecodes to machine code, or java source to machine code, but only java-to-jvmbytecode actaully works
It's always possible to emulate constructs in a language (TuringEquivalency), but I imagine it would be inefficient. So a memory pointer may be converted into an index into a byte array acting as addressable memory. It wouldn't be pretty but it would work (mostly kind-of). -- RichardHenderson
I'd prefer an int[] array, because most of the data my code processes is int-sized. I've thought many times about implementing a Java interface that would actually have functions like "long getLong(int address)" and "void putShort(int address, short value)". You could back it with an int[] array and then write native methods to handle your un-aligned stores, your byte-processing, and stuff like that. It would still be slow, but maybe not too slow... -- EdwardKiser (Later: the new I/O buffer class in Java 1.4 supports exactly this kind of functionality. Maybe it's not necessary to write a new class.)
As Richard said, of course it is possible, though it may not be efficient. If you were planning to implement C->JVM compilation, you might want to study how C (and Fortran, and other non-Lisp-like languages) was implemented on the LispMachine. -- JosephDale
C pointers and pointer arithmetic can be mimicked by representing a pointer as an array and an offset. Pointer arithmetic operates on the offset. Note that the C standard leaves it undefined what happens while comparing pointers pointing into different arrays, so this implementation is feasible.
The Java VM was not designed to support all these languages. Of course anything can be turned into JVM bytecode given enough effort. That's completely different than the CommonLanguageRuntime being designed (through the CommonTypeSystem) to natively support 21 languages and call from one language into another. Does the Java VM do that? I think not. Does Sun support that? Doubtful. In their mind Java is the one true language and everything else is legacy.
Why just 21? The JVM (for all that it was never designed to do so) ended up with many more. "Natively" supports vs. "by happenstance" supports - that seems like an invidious distinction to me. I wouldn't mind "builds on the design of previous VMs to address multiple language support more efficiently". The "natively" part seems to suggest that the newer design is intrinsically better than the previous one, rather than let the users be the judges of that.
Wherever the multi-language support is mentioned, Smalltalk is among the languages listed. Does anyone have pointers to the Smalltalk version of DotNet? That's really the one I want to see.
Further, many of the languages above have no difficulty calling from one to the other. I currently am working on a piece of software written in a combination of Java, DynamicJava, and Jython, and method calls fly back and forth with no concern for language. The VM doesn't care what language it's running; any apparent boundaries are in current implementations, and not inherent in the design. -- AdamBerger
Running multiple languages on the CLR is pure marketing fluff and always has been. The CLR is designed to run C# and interop well with COM and that's all. Every other language that has been ported to the CLR has had to be modified in some way to make it more C#-like. Even VisualBasic, one of Microsoft's big cash cows, couldn't be ported to run on the CLR. VisualBasicDotNet is basically C# with a verbose syntax.
It may be worth noting that IBM's VisualAgeJava, created by ObjectTechnologyInternational, used a virtual VirtualMachine that could run against multiple bytecode sets. VisualAgeSmalltalk and VisualAgeJava therefore shared a common code repository, and the VisualAgeJava IDE was actually written in and running Smalltalk. It's a bit like the way Komodo uses a Python interpreter to run its Perl debugger and IDE. The semantics of EnvyDeveloper were neutral regarding the two bytecode sets, a method was a method, and a class was a class, whether Smalltalk or Java.
OlinShivers? has written a relevant paper entitled "Supporting dynamic languages on the Java virtual machine", available from ftp://publications.ai.mit.edu/ai-publications/1500-1999/AIM-1576.ps
JavaScript content moved to MultipleLanguagesInJavaScript
see also http://en.wikipedia.org/wiki/List_of_JVM_languages -- MarkusSrank
See EmbeddedLanguage
EditText of this page
(last edited January 23, 2013)
or FindPage with title or text search