A Little History
When I was in college, I developed a fascination for computer languages. I took every course I could that covered languages that I had not already learned. It was great. I learned procedural languages, object-oriented languages, interpreted languages, compiled languages, declarative languages, and every combination in between. One of the first courses I took was an introduction to Pascal, which surprisingly taught me two key concepts that are essential to understanding Java and the JVM.
The first concept is that almost all programming languages can be implemented as either compiled languages or interpreted languages. Compilers take an entire program and translate it from one computer language to another. Compilers often make multiple passes through the code looking for ways to optimize the newly generated code for either speed or size, which are usually mutually exclusive. Interpreters, on the other hand, look at the source language one statement at a time, translate it into the target language, and then execute the statement in the target language. The key here is that compilers translate all the code before execution, and interpreters translate on demand. Compilers tend to be more robust because they look at all of your code at once and can find obvious errors. Interpreters are often faster for development because compilation can be time-consuming.
The second thing I learned in my Introduction to Pascal course was that virtual machines exist. For this particular class, we were using the UCSD Pascal compiler. This compiler translated Pascal into a language called pseudo-code, or p-Code. Then, an application known as a p-Code machine, which was essentially an interpreter, would be invoked on the p-Code generated by the compiler to execute it. So the advantage, even back then in the academic world, was that in order to run your Pascal program on a new operating system, all you had to do was implement a p-Code machine for your operating system. Now this next part to this day still makes my head hurt a little to think about. The reason that you only had to port the p-Code machine to your new operating system is that the UCSD Pascal compiler was written using UCSD Pascal, so all you had to do was to copy the p-Code from the existing UCSD Pascal compiler over to your new operating system and then execute it using your p-Code machine. So the UCSD Pascal p-Code Machine was the predecessor of our current JVM.
What Is a Virtual Machine?
In order to understand a virtual machine, let's first talk about what a machine is. In general, think of a machine as the hardware and the machine instruction set that runs the hardware. In the most traditional sense, this is all about the CPU and the instruction set supported by it. Pieces of machine language (a.k.a. binary codes) are handed to the CPU for processing one at a time. So a virtual machine is indistinguishable from a non-virtual machine from an interface perspective, but a virtual machine can be implemented in any number of ways. In most cases, a virtual machine is a software layer sitting on top of a hardware layer that at runtime translates the virtual machine code into machine code. It is worth noting that this does not have to be the case; the virtual machine could be directly supported by the hardware.
What Is the Java Virtual Machine?
The Java Virtual Machine (JVM) is just a specific instance of the more general virtual machine described above. A Java compiler is used to generate JVM instructions, which are commonly called Java byte code. Java byte code can then be fed into a JVM for execution. You can obtain the complete specification for how to implement a JVM from Sun Microsystems. For a specification, it is both very readable and concise. It is probably something that most Java programmers should make a least one pass through every now and then as it gives you some great insights into what is going on under the hood. Here is an excerpt from chapter 3, The Structure of the Java Virtual Machine:
"To implement the Java Virtual Machine correctly, you need only be able to read the class file format and correctly perform the operations specified therein. Implementation details that are not part of the Java Virtual Machine's specification would unnecessarily constrain the creativity of implementors. For example, the memory layout of run-time data areas, the garbage-collection algorithm used, and any internal optimization of the Java Virtual Machine instructions (for example, translating them into machine code) are left to the discretion of the implementor."
So, at the simplest level, we have Java source files (.java files) which we run a Java compiler against to create Java byte code (.class files). Our Java byte code can be grouped in various ways, such as .jar or .zip files to keep them organized. We can then feed .class or groups of .class files into our JVM for execution. Several interesting things should be noted at this point. First, note that we should be able to use any Java compiler that complies to Sun's spec to create our Java byte code and that we should be able to use any JVM to execute our Java byte code. Doing this should not affect the overall logic or execution of our program. Second, note that even though it is called Java byte code, there is no direct knowledge of the Java programming language contained in Java byte code. In theory, you could just write the Java byte code from scratch. This would be kind of like being a Java assembly programmer. Or as a colleague of mine recently pointed out, you could write a Java byte code compiler for another language that took that language's source code and translated it into Java byte code. So it is interesting to note that the "Java" in Java Virtual Machine refers to the Java byte code and not the Java language itself.
How Are JVMs Created?
JVMs are created by people like you or by people who work for people like you. Essentially, anybody can create a JVM; it just takes some time and skill. As I mentioned, Sun Microsystems publishes the entire JVM spec and actively supports all developers working on implementations. After all, you are helping them achieve their overall strategy of "Java Everywhere." The one drawback about creating a JVM is that--unlike a compiler, which can be written in the language that it is compiling--a JVM has to be written in a language that compiles to native machine code on the target platform. Well, you can't always write Java code.
Conclusion
Virtual machines have been around since the days of UCSD Pascal and its p-Code machine. Virtual machines are powerful abstractions that allow us to port applications, including compilers, from one platform to another with as little effort as possible. The JVM is just a specific type of a more general virtual machine and actually has more to do with Java byte code than with Java source code. Sun Microsystems provides the entire specification for creating a JVM and actively supports and promotes developers in their endeavors to create JVM's on new platforms.
Author's Note
The line between compilers and interpreters has blurred a lot since my early academic days. It used to be that a language such as BASIC or LISP was always interpreted and was thus labeled as an interpreted language. However, language designers are now realizing that, for the most part, whether a language is interpreted or compiled is an implementation detail and not a attribute of the language itself. Currently, you can write a LISP program and run it through an interpreter while developing and then through a compiler for deployment, thus taking advantage of the best of both worlds. However, some languages lend themselves to one implementation over the other. It would be very difficult to implement a compiler for a language that can modify its own source code on the fly; however, this is rather trivial with interpreted implementations.
Michael J. Floyd is an extreme programmer and the Software Engineering Manager for DivXNetworks. He is also a consultant for San Diego State University and can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online