Java
From DocForge
Java is a cross-platform runtime environment and programming language from Sun Microsystems.
Java was originally meant to be a better C++ and as such provides the following features over the language:
- Almost completely object oriented approach
- Automatic garbage collection
- Multi threading as part of the language
- Compile once, run anywhere with the introduction of a intermediate bytecode and the Java Virtual Machine
Java has popularized the inclusion of large APIs as part of the language distribution.
JRE is the common abbreviation for the Java Runtime Environment.
Contents |
[edit] Uses
As a general purpose cross-platform language Java has found a wide variety of uses. The Standard Edition (SE) is relatively small and often used for desktop applications. The Enterprise Edition is designed for server applications, such as back-end servers and web applications.
Sun's Java implementations were originally closed source. They have since made the platform open source. That and other open source implementations have expanded Java's deployment in Linux distributions.
[edit] Libraries
Multiple GUI libraries exist for Java, among which AWT, Swing and SWT. To get an idea of their differences, you can look at, for example, Swing and SWT: A Tale of Two Java GUI Libraries or SWT, Swing or AWT: Which is right for you?
- Java AWT
- Full Screen in AWT Free Code
- Java Swing
- Java SWT
See also: Category:Java Libraries
[edit] JDBC
JDBC is the Java DataBase Connectivity API for the Java platform. It provides a generic interface to various databases. JDBC allows clients like web applications to interface with a myriad of relational databases like MySQL, Oracle, DB2, Sybase etc. JDBC was released as a part of JDK 1.1 by Sun Microsystems.
JDBC has the following API features that enable users to interact with relational databases:
- Statement
- PreparedStatement
- CallableStatement
[edit] Features
[edit] Platform Independence
Programs written in the Java language must run similarly on any supported hardware/operating system platform. In theory, one should be able to write a Java program once, compile it once, and run it anywhere.
This is achieved by most Java compilers by compiling the Java language code "halfway" to bytecode (specifically Java bytecode) - simplified machine instructions specific to the Java platform. The code is then run on a virtual machine (VM), a program written in native code on the host hardware that interprets and executes generic Java bytecode. (In some JVM versions, bytecode can also be compiled to native code, resulting in faster execution.) Further, standardized libraries are provided to allow access to features of the host machines (such as graphics, threading and networking) in unified ways. Note that, although there's an explicit compiling stage, at some point, the Java bytecode is interpreted or converted to native machine instructions by the JIT compiler.
There are also implementations of Java compilers that translate the Java language code to native object code, such as GCJ, removing the intermediate bytecode stage, but the output of these compilers can only be run on a single architecture.
The first implementations of the language used an interpreted virtual machine to achieve portability. These implementations produced programs that ran more slowly than programs compiled to native executables, for instance written in C or C++, so the language suffered a reputation for poor performance. More recent JVM implementations produce programs that run significantly faster than before, using multiple techniques.
The first technique is to simply compile directly into native code like a more traditional compiler, skipping bytecodes entirely. This achieves good performance, but at the expense of portability. Another technique, known as just-in-time compilation (JIT), translates the Java bytecodes into native code at the time that the program is run which results in a program that executes faster than interpreted code but also incurs compilation overhead during execution. More sophisticated VMs use dynamic recompilation, in which the VM can analyze the behavior of the running program and selectively recompile and optimize critical parts of the program. Dynamic recompilation can achieve optimizations superior to static compilation because the dynamic compiler can base optimizations on knowledge about the runtime environment and the set of loaded classes, and can identify the "hot spots" (parts of the program, often inner loops, that take up most of execution time). JIT compilation and dynamic recompilation allow Java programs to take advantage of the speed of native code without losing portability.
Portability is a technically difficult goal to achieve, and Java's success at that goal has been mixed. Although it is indeed possible to write programs for the Java platform that behave consistently across many host platforms, the large number of available platforms with small errors or inconsistencies led some to parody Sun's "Write once, run anywhere" slogan as "Write once, debug everywhere".
Platform-independent Java is however very successful with server-side applications, such as Web services, servlets, and Enterprise JavaBeans, as well as with Embedded systems based on OSGi, using Embedded Java environments.
[edit] Automatic Garbage Collection
One of the ideas behind Java's automatic memory management model is that programmers be spared the burden of having to perform manual memory management. In some languages the programmer allocates memory for the creation of objects stored on the heap and the responsibility of later deallocating that memory thus resides with the programmer. If the programmer forgets to deallocate memory or writes code that fails to do so, a memory leak occurs and the program can consume an arbitrarily large amount of memory. Additionally, if the program attempts to deallocate the region of memory more than once, the result is undefined and the program may become unstable and may crash. Finally, in non garbage collected environments, there is a certain degree of overhead and complexity of user-code to track and finalize allocations. Often developers may box themselves into certain designs to provide reasonable assurances that memory leaks will not occur.
In Java, this potential problem is avoided by automatic garbage collection. The programmer determines when objects are created, and the Java runtime is responsible for managing the object's lifecycle. The program or other objects can reference an object by holding a reference to it (which, from a low-level point of view, is its address on the heap). When no references to an object remain, the Java garbage collector automatically deletes the unreachable object, freeing memory and preventing a memory leak. Memory leaks may still occur if a programmer's code holds a reference to an object that is no longer needed—in other words, they can still occur but at higher conceptual levels.
The use of garbage collection in a language can also affect programming paradigms. If, for example, the developer assumes that the cost of memory allocation/recollection is low, they may choose to more freely construct objects instead of pre-initializing, holding and reusing them. With the small cost of potential performance penalties (inner-loop construction of large/complex objects), this facilitates thread-isolation (no need to synchronize as different threads work on different object instances) and data-hiding. The use of transient immutable value-objects minimizes side-effect programming.
Comparing Java and C++, it is possible in C++ to implement similar functionality (for example, a memory management model for specific classes can be designed in C++ to improve speed and lower memory fragmentation considerably), with the possible cost of adding comparable runtime overhead to that of Java's garbage collector, and of added development time and application complexity if one favors manual implementation over using an existing third-party library. In Java, garbage collection is built-in and virtually invisible to the developer. That is, developers may have no notion of when garbage collection will take place as it may not necessarily correlate with any actions being explicitly performed by the code they write. Depending on intended application, this can be beneficial or disadvantageous: the programmer is freed from performing low-level tasks, but at the same time loses the option of writing lower level code.
Java does not support pointer arithmetic as is supported in for example C++. This is because the garbage collector may relocate referenced objects, invalidating such pointers. Another reason that Java forbids this is that type safety and security can no longer be guaranteed if arbitrary manipulation of pointers is allowed.
