Actually, Java is a compiled/interpreted language. See the links below. This is the best classification for the Java language, in my opinion. Read [_this thread_|http://forums.sun.com/thread.jspa?threadID=5320643&start=0&tstart=0] and give your opinion, too! You are very welcome in this interesting discussion. The more I participate in this forum, the more I learn. The more you participate the more you learn, too! Thank you very much for this forum, Sun!
[_CLDC HotSpot Implementation Architecture Guide Chapter 10_|http://java.sun.com/javame/reference/docs/cldc-hi-2.0-web/doc/architecture/html/VFP.html]
+The 1.1.3 release of CLDC HotSpot Implementation included limited VFP support. This feature was supported only when running in interpreted mode. In this release, full vector floating point support is provided when the virtual machine is running in compiled mode.+
[_Java Virtual Machines_|http://java.sun.com/j2se/1.4.2/docs/guide/vm/index.html]
+Adaptive compiler - Applications are launched using a standard interpreter, but the code is then analyzed as it runs to detect performance bottlenecks, or "hot spots". The Java HotSpot VMs compile those performance-critical portions of the code for a boost in performance, while avoiding unnecessary compilation of seldom-used code (most of the program). The Java HotSpot VMs also usesthe adaptive compiler to decide, on the fly, how best to optimize compiled code with techniques such as in-lining. The runtime analysis performed by the compiler allows it to eliminate guesswork in determining which optimizations will yield the largest performance benefit.+
[_CLDC HotSpot Implementation Architecture Guide Chapter 4_|http://java.sun.com/javame/reference/docs/cldc-hi-2.0-web/doc/architecture/html/DynamicCompiler.html]
+Two different compilers are contained in the CLDC HotSpot Implementation virtual machine: an adaptive, just-in-time (JIT) compiler and an ahead-of-time compiler. The JIT compiler is an adaptive compiler, because it uses data gathered at runtime to decide which methods to compile. Only the methods that execute most frequently are compiled. The other methods are interpreted by the virtual machine.+
[_Java Tuning White Paper_|http://java.sun.com/performance/reference/whitepapers/tuning.html]
+One of the reasons that it's challenging to measure Java performance is that it changes over time. At startup, the JVM typically spends some time "warming up". Depending on the JVM implementation, it may spend some time in interpreted mode while it is profiled to find the 'hot' methods. When a method gets sufficiently hot, it may be compiled and optimized into native code.+
[_Frequently Asked Questions About the Java HotSpot VM_|http://java.sun.com/docs/hotspot/HotSpotFAQ.html]
+Remember how HotSpot works. It starts by running your program with an interpreter. When it discovers that some method is "hot" -- that is, executed a lot, either because it is called a lot or because it contains loops that loop a lot -- it sends that method off to be compiled. After that one of two things will happen, either the next time the method is called the compiled version will be invoked (instead of the interpreted version) or the currently long running loop will be replaced, while still running, with the compiled method. The latter is known as "on stack replacement", or OSR.+
[_Java Technology Fundamentals Newsletter Index - Making Sense of the Java Classes & Tools: Collection Interfaces, What's New in the Java SE 6 Platform Beta 2, and More_|http://java.sun.com/mailers/newsletters/fundamentals/2006/July06.html]
+Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high- performance, multithreaded, dynamic language.+
[_Introduction to scripting in Java, Part 1_|http://www.javaworld.com/javaworld/jw-07-2007/jw-07-awscripting1.html?page=2]
+Many of today's interpreted languages are not interpreted purely. Rather, they use a hybrid compiler-interpreter approach, as shown in Figure 1.3.+
+In this model, the source code is first compiled to some intermediate code (such as Java bytecode), which is then interpreted. This intermediate code is usually designed to be very compact (it has been compressed and optimized). Also, this language is not tied to any specific machine. It is designed for some kind of virtual machine, which could be implemented in software. Basically, the virtual machine represents some kind of processor, whereas this intermediate code (bytecode) could be seen as a machine language for this processor.+
+This hybrid approach is a compromise between pure interpreted and compiled languages, due to the following characteristics:+ Because the bytecode is optimized and compact, interpreting overhead is minimized compared with purely interpreted languages. The platform independence of interpreted languages is inherited from purely interpreted languages because the intermediate code could be executed on any host with a suitable virtual machine. Lately, just-in-time compiler technology has been introduced, which allows developers to compile bytecode to machine-specific code to gain performance similar to compiled languages. I mention this technology throughout the book, where applicable.
[_Compiled versus interpreted languages_|http://publib.boulder.ibm.com/infocenter/zoslnctr/v1r7/index.jsp?topic=/com.ibm.zappldev.doc/zappldev_85.html] Assembler, COBOL, PL/I, C/C++ are all translated by running the source code through a compiler. This results in very efficient code that can be executed any number of times. The overhead for the translation is incurred just once, when the source is compiled; thereafter, it need only be loaded and executed. Interpreted languages, in contrast, must be parsed, interpreted, and executed each time the program is run, thereby greatly adding to the cost of running the program. For this reason, interpreted programs are usually less efficient than compiled programs.
+Some programming languages, such as REXX and Java, can be either interpreted or compiled.+