Java code is normally distributed as bytecode, which is machine-independent pseudocode. (The same idea was previously used in UCSD-p system developed in the 70'ies.) The advantage of this is that the same application can be run in different processors and operating systems. In addition, the bytecode is often smaller than compiled application.
The disadvantage is that interpreting the code is slow compared to running compiled code.
To solve this problem, JIT compiler was developed. JIT compiler compiles the code into machine code just before the code is executed. This speeds up the execution compared to interpreter, but additional time is spent for compiling every time the program is run.
In addition, since JIT compiler must compile fast, it can not use complex optimization techniques that are used in static compilers.
Another approach is HotSpot compiling. It initially runs as interpreter, but then detects which routines are used most often and compiles only those. The advantage is that there is no initial delay due to the compiling. In addition, HotSpot compiler may do profiling during the execution and then issue stronger optimization for the most important routines. It may even gather information so that when you run the same application again and again, it will run faster and faster. More information about HotSpot compiling can be found from this article (tnx Pangea for the link).
Of course, instead of using JIT compiler, you could just use a static compiler to compile the bytecode for your machine. This allows full optimization and then you do not need to compile again every time you run the application. However, in phones and web pages, you often just execute the code (or applet) once, so JIT compiler may be a better choice.