Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
There are several languages/runtimes atop the JVM: such as JRuby, Groovy, Jython, Clojure, Rhino, Scala, and so on…
(Or is my assumption wrong, and some of mentioned languages do not generate bytecode?)
Some of them generate bytecode. Some have a runtime system that executes as an interpreter. Some have a blend of the two. The JVM is, after all, a CPU (which just happens to not really exist) with a certain architecture and a certain set of instructions. You target it with your code generator the same way you generate object code for any CPU. (Now to be fair its instruction set is very heavily focused on Java’s capabilities and needs, but it’s still general enough to support other models. Barely.)
There are a variety of ways to generate JVM byte-code. You can handroll your own .class file generation routines (since the format and the instruction set is well-specified). You can use a number of libraries like ASM or BCEL (which is the most common approach, I think). Or you could generate Java code as your intermediate representation and then compile that with the usual Java tools.
You execute the code the same way you execute Java-compiled code: the Java runtime loads the generated .class files and starts running. This is all part of the specification as well.