Typical Java Application Build Process

Question

Being new to Java, I can't understand the whole build process from source to hardware specific binaries. I mainly use Eclipse for java and would like to know that all conversions come from source code (.java) to binary, that all files are linked using some kind of linker, preprocessor, etc.

Understand if you can point me to some link that details the Java build process. I have already looked for this forum, but have not received any detailed information.

thanks

Edited by:

To be more precise, I'm looking for the Java equivalent of the following build process in C: I walked a lot, but didn't get it! A figure like the one below is optional (although preferable), but if you can write "n" the sequential / parallel steps associated with the complete Java build process, it will really be appreciated. Although most of the information provided by @Tom Anderson is very useful to me.

Answer 1

The first thing to understand is that your question contains an erroneous assumption. You are asking about the “complete build process from source to hardware-specific binaries” - but the normal Java build process never creates architecture-specific binaries. It reaches an architecture-independent bytecode and then stops. Of course, it is true that in most cases this bytecode will be translated into native code that will be executed, but this step occurs at run time, inside the JVM, completely in memory and does not include the creation of binary files - it is not part of the process assembly.

There are exceptions: compilers such as GCJ can create their own binaries, but this is rarely done.

So, the only significant step that happens as part of the build process is compilation. The compiler reads the source code, performs the usual parsing and resolution steps, and emits bytecode. This process is not indicated in any way; as usual, the language specification defines what the elements of the language are and what they mean, but not how to compile them. What is indicated in the output format: the bytecode is packed in the form of class files , one for each class, which, in turn, can be grouped together in jar files for ease of distribution.

When class files are to be executed, additional steps are possible before execution. They are reasonably well specified in the chapter Download, Layout, and Initialization in the JVM Specification. But, as I said, they are not part of the assembly process.

There are several other steps that can occur during the build process, usually before compilation: dependencies can be resolved and downloaded, resources can be copied and converted between character sets, and code can be generated. But none of them is standard, that's all that is added to the main compilation process by various building tools.

Answer 2

There are some interesting articles you can check out if you want to find out what is going on behind the scenes.

http://www.codeproject.com/Articles/30422/How-the-Java-Virtual-Machine-JVM-Works

This is one of them, it has a good explanation of how all the parts interact to run your code.

The main idea is that bytecode is created from your Java files to run in a virtual machine, which makes your Java code (more or less ...) independent of the OS and the platform on which you run it.

A JVM specific to this environment is then responsible for translating this bytecode into actual instructions for the particular architecture on which your code is running.

This is the core of the Write Once, Run Everywhere mantra, which Java has. Although the mantra does not always hold on ... this is still true as a whole.