Please to note first off, that I am NOT looking for "an object with members." I mean, what is a class? A file with extension ".class". What is stored therein, how is it stored, and what do the commands "javac Foo.java" and "java Foo" do? Again, I am not looking for "compile, run." I mean what do they do. Likewise, what does new Foo() do? Just Curiosity.
I've heard it takes forever to grow a woman from the ground
when you write a java program, it's text file which cannot be understood by the OS, be it Unix or whatever. Your OS understands only system calls. Who translates your text code to sequences of system calls which make sense to OS? JVM. How? I'm not sure, if you have interest you can have a look into the thousends of classes which come with JDK. But then the JVM has to understand your text code first. How? By compiling your text code into byte code. How to compile text code into byte code? I'm afraid you'd better read some books on this subject to get a clear picture. In one word, you can view the class file as a bridge bwteen the file which can be understood by human being and sequences of micro processes which can be excecuted by the underlying OS. The command javac asks the java compiler to compile your .java file into java byte code according to the compiling rules; The command java calls the jvm to call the OS to use some resources ( CPU cycles, memory....) to get your work done. new Foo() allocates some physical memory for an instance of the type Foo. Is this information enough or you want more detailed explaination?
Regards, Ellen [ April 22, 2004: Message edited by: Ellen Zhao ]
Hi, I've read the question and I'm also unclear on the whole FOO thing. What exaxtly is it? What people use in examples only or does it call something up or what. I've seen a few people use this but I have never seen it referred to in my text book so I have no idea.
Ellen was right in her description. Simply put, bytecode is an intermediate representation of your program. This is what the word means. Think of it as being similar to C/C++ and assembly. Assembly is an intermediate representation of the C/C++ program. The difference is, the underlying OS understands assembly, it does not understand bytecode. If you want to look at bytecode, read this: bytecode
Joined: Sep 17, 2002
Joseph, First of all, let's be clear of some facts: 1. From 1960's to now, computers are not getting any smarter, rather, just more and more complex. 2. What does a computer compute? Actual value like 10 in the equation 1+9=10 and the address where the 1, 9 and 10 reside. In the good old days, programmers could happily say "put the 1 into register #1 and 9 into register #2 and add the content in register #1 and #2 and put the result into register #3 and then return the content in register #3." to computers in assembly languages, which are appealing to chips. Since there were not too many different chips then, it was not too difficult for programmers to work around smoothly. But, it's inrealistic today. Business logic are gaining more and more weight in big applications the world cannot expect every programmer thinking in Church-Turing logic and can talk to chips directly. That's why high-level languages like Basic, C and Java were born. But the computers are not getting smarter, they only understand the low level machine instructions. Compiler's mission is to translate the human-being frindly high-level language into machine code. In a language every built-in operations have their unique codes in this language. Let's assume 1 for + and 2 or - and 3 for * and so on. You write +|-|*|/ in your source code and what's in .class file then? Binary representation of the code of the operations: 0001|0010|0011|.... (Of course the operations are not limited in arithmetic ones ); Since most programs are loaded into memory dynamically, in the .class file there must be also information for loaders and linkers, for the CPU to caculate the address of related values involved in the program. For your question " What is stored therein?", my understanding is three type of things: 1. binary representation of the values; 2. binary representation of the operation code; 3. binary representation of the addressing information. and, your source code talks to jvm, jvm talks to os, os talks to hardware. The .class files are only understood by the jvm. And jvm does the dirty work of translating the java byte code into machine language which the OS understands. So-called "platform-independence" of java actually means, the format of the byte code is standardized, Sun and other vendors have done the JVM --> OS layer for you. If you try to run a .class file on a new chip for which the JVM --> OS layer ( or JVM --> hardware layer for embedded system) hasn't been implemented, it won't run. Anyway, the .class files make your life much easier.
This kind of thing is fascinating and open to several interpretations depending on just how detailed you want to get. For most compiled languages you get this: source code -> compiler -> machine code -> linker -> an EXE Then the OS can load machine code into memory and actually give away control of the CPU to machine code instructions in memory.
For Java, the javac compiler does this: source code -> javac -> byte code (file extension .class) The OS cannot load a class file and make it run because it is not machine code for the particular computer. You can think of the class file as machine code for a computer that does not exist. The JVM is a "virtual machine" which knows how to load and execute byte code. The OS can point the CPU at some native code and let it fly, but the JVM cannot ask the CPU to run byte code. Instead, the JVM looks at each byte code instruction and decides how to make the real computer do the job. When you say something like "int i = 1" the JVM gets a chunk of memory big enough for an int, builds a little table that tells it "i" is at the addres it just got, and puts 1 into that address. For every Java instruction you write the compiler generates a few byte code instructions. For each of those the JVM "interprets" the byte code instruction into a few real operations. To confuse things, some JVMs can convert most byte code to machine code and give the machine code to the CPU to run. The extra conversion effort pays off big time if the code is executed over and over. You'll see Hot Spot or JIT for Just In Time compiling. The JVM analyses what is being executed most and compiles the hot spots. Why not just compile everyting to machine code in the first place? That would take the JVM out of the picture entirely. One goal of Java was to "write once run anywhere" which means you can take exactly the same class files - byte code - to any JVM on any OS and run it without recompiling. The JVM does more work, you do less. Nice.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
This leaves the other question: what does "new Foo()" do? This expression is translated by javac into bytecode. At execution time, the jvm calls the "new" operator, which uses a special "class object" called Foo.class which has everything necessary to create an object of class Foo. Foo.class was also created by javac. The "new" operator allocates enough memory on the heap to hold one Foo object. "new" then lays out the object and loads jvm tables with the member information. Starting at Foo's top superclass, java.lang.Object, the variable initializers and instance initializers are called in the order they appear in the source code. Then, one or more constructors at that level are called. The process repeats at the next level down until the Foo object is completely initialized. Finally, "new" returns a reference to the newly created Foo object to be used in the rest of the statement that contained the expression "new Foo()". You can examine the bytecode in any class file using the javap command. [ April 24, 2004: Message edited by: Mike Gershman ]
Here's another analogy that i like. I speak english, and only english. my computer speaks chinese, and only chinese. so i can write a paper in english, but that does my computer no good at all. it can't read it. in the past, i would use a compiler to tranlate my english into chinese. ok, life is good. but now, i want to send my paper to italy. and france. and Germany... i now need to get a bunch of translators in my office, and every time i write something, give it to the correct translator, remember which customer uses what language.... uggghhh... and we're not even talking about separate translators for different dialects, using the correct idiom for each country/region... well, i just found out about a company that specialized in translating stuff. they're calls Sun. they have put a translator in EVERY COUNTRY in the world. All of their translators speak the local language FLUENTLY, but they only can translate from Esperanto. So, all i have to do is write my paper in english, translate it to Esperanto, and send THE EXACT SAME FILE TO ALL MY TRANSLATORS. This is what Java does. i write my program in Java (english). when you type "javac myCode.java", it gets converted to bytecode (Esperanto). i send THAT file to all the translators around the world (the JVM), which can translate it to the local dialect (chinese, german, french, etc). so when you type "javac myCode.java", you are saying "translate this file, written in the java language, into bytecode". that is your myCode.class file. then, when you say "java myCode", you are saying "translate this into the native language of the machine, and run these directions". that's what code is - a list of directions or actions for the computer to take. does that help?
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors