Software/Package Used: Machines (VMS), Exist For Most Operating Systems, Including Unix, The Macintosh Os
Software/Package Used: Machines (VMS), Exist For Most Operating Systems, Including Unix, The Macintosh Os
The original and reference implementation Java compilers, virtual machines, and class
libraries were developed by Sun from 1995. As of May 2007, in compliance with the
specifications of the Java Community Process, Sun relicensed most of its Java technologies
under the GNU General Public License. Others have also developed alternative
implementations of these Sun technologies, such as the GNU Compiler for Java, GNU
Classpath, and Dalvik.
Principles of Java
There were five primary goals in the creation of the Java language:
Java Platform
One characteristic of Java is portability, which means that computer programs written in the
Java language must run similarly on any supported hardware/operating-system platform. This
is achieved by compiling the Java language code to an intermediate representation called Java
bytecode, instead of directly to platform-specific machine code. Java bytecode instructions
are analogous to machine code, but are intended to be interpreted by a virtual machine (VM)
written specifically for the host hardware. End-users commonly use a Java Runtime
Environment (JRE) installed on their own machine for standalone Java applications, or in a
Web browser for Java applets.
A major benefit of using bytecode is porting. However, the overhead of interpretation means
that interpreted programs almost always run more slowly than programs compiled to native
executables would. Just-in-Time compilers were introduced from an early stage that compile
bytecodes to machine code during runtime. Over the years, this JVM built-in feature has been
optimized to a point where the JVM's performance competes with natively compiled C code.
Implementations
Sun Microsystems officially licenses the Java Standard Edition platform for Linux, Mac OS
X,and Solaris. Although in the past Sun has licensed Java to Microsoft, the license has
expired and has not been renewed. Through a network of third-party vendors and
licensees,[24] alternative Java environments are available for these and other platforms.
Sun's trademark license for usage of the Java brand insists that all implementations be
"compatible". This resulted in a legal dispute with Microsoft after Sun claimed that the
Microsoft implementation did not support RMI or JNI and had added platform-specific
features of their own. Sun sued in 1997, and in 2001 won a settlement of US$20 million, as
well as a court order enforcing the terms of the license from Sun.As a result, Microsoft no
longer ships Java with Windows, and in recent versions of Windows, Internet
Explorer cannot support Java applets without a third-party plugin. Sun, and others, have made
available free Java run-time systems for those and other versions of Windows.
Platform-independent Java is essential to the Java EE strategy, and an even more rigorous
validation is required to certify an implementation. This environment enables portable server-
side applications, such as Web services, Java Servlets, and Enterprise JavaBeans, as well as
with embedded systems based on OSGi, using Embedded Java environments. Through the
new GlassFish project, Sun is working to create a fully functional, unified open
source implementation of the Java EE technologies.
Sun also distributes a superset of the JRE called the Java Development Kit (commonly
known as the JDK), which includes development tools such as the Java
compiler, Javadoc, Jar, and debugger.
Performance
Programs written in Java have a reputation for being slower and requiring more memory than
those written in C.However, Java programs' execution speed improved significantly with the
introduction of Just-in-time compilation in 1997/1998 for Java 1.1,the addition of language
features supporting better code analysis (such as inner classes, StringBuffer class, optional
assertions, etc.), and optimizations in the Java Virtual Machine itself, such
as HotSpot becoming the default for Sun's JVM in 2000.
To boost even further the speed performances that can be achieved using the Java language,
Systronix made JStik, a microcontroller based on the aJile Systems line of embeddedJava
processors. In addition, the widely used ARM family of CPUs has hardware support for
executing Java bytecode through its Jazelle option.
One of the ideas behind Java's automatic memory management model is that programmers
can be spared the burden of having to perform manual memory management. In some
languages, memory for the creation of objects is implicitly allocated on the stack, or
explicitly allocated and deallocated from the heap. In the latter case the responsibility of
managing memory resides with the programmer. If the program does not deallocate an object,
a memory leak occurs. If the program attempts to access or deallocate memory that has
already been deallocated, the result is undefined and difficult to predict, and the program is
likely to become unstable and/or crash. This can be partially remedied by the use of smart
pointers, but these add overhead and complexity. Note that garbage collection does not
prevent "logical" memory leaks, i.e. those where the memory is still referenced but never
used.
Garbage collection may happen at any time. Ideally, it will occur when a program is idle. It is
guaranteed to be triggered if there is insufficient free memory on the heap to allocate a new
object; this can cause a program to stall momentarily. Explicit memory management is not
possible in Java.
Java does not support C/C++ style pointer arithmetic, where object addresses and unsigned
integers (usually long integers) can be used interchangeably. This allows the garbage
collector to relocate referenced objects and ensures type safety and security.
As in C++ and some other object-oriented languages, variables of Java's primitive data
types are not objects. Values of primitive types are either stored directly in fields (for objects)
or on the stack (for methods) rather than on the heap, as commonly true for objects (but
see Escape analysis). This was a conscious decision by Java's designers for performance
reasons. Because of this, Java was not considered to be a pure object-oriented programming
language. However, as of Java 5.0, autoboxing enables programmers to proceed as if
primitive types were instances of their wrapper class.