The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a web container and a servlet. A web container is essentially the component of a web server that interacts with the servlets. The web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.

A Servlet is an object that receives requests (ServletRequest) and generates a response (ServletResponse) based on the request. The API package javax.servlet.http defines HTTP subclasses of the generic servlet (HttpServlet) request (HttpServletRequest) and response (HttpServletResponse) as well as an (HttpSession) that tracks multiple requests and responses between the web server and a client. Servlets may be packaged in a WAR file as a Web application.

Moreover, servlets can be generated automatically by JavaServer Pages (JSP), or alternately by template engines such as WebMacro. Often servlets are used in conjunction with JSPs in a pattern called “Model 2″, which is a flavor of the model-view-controller pattern.

History

The original servlet specification was created by Sun Microsystems (version 1.0 was finalized in June 1997). Starting with version 2.3, the servlet specification was developed under the Java Community Process. JSR 53 defined both the Servlet 2.3 and JavaServer Page 1.2 specifications. JSR 154 specifies the Servlet 2.4 and 2.5 specifications. As of May 10, 2006, the current version of the servlet specification is 2.5.

In his blog on java.net, Sun veteran and GlassFish lead Jim Driscoll details the history of servlet technology. James Gosling first thought of servlets in the early days of Java, but the concept did not become a product until Sun shipped the Java Web Server product. This was before what is now the Java Platform, Enterprise Edition was made into a specification.

Web containers

A Web container is a computer program that runs Web applications. Web containers are also sometimes called Web engines. Like the other Java APIs, different vendors provide their own implementation. Below is a list of some of the free web containers. (Note that ‘free’ means that commercial use is free. Some of the commercial containers, e.g. Resin and Orion, make ideal development containers and are also free to use in a server environment for non-profit organizations).

Non-commercial web containers* Java System Application Server is developed by Sun.
* Apache Tomcat (formerly Jakarta Tomcat) is an open source web container available free of charge under the Apache Software License. It is used in the official reference implementation and has a reputation for being stable.
* Jetty
* Jaminid contains a higher abstraction than servlets.
* Enhydra
* jo!
* Winstone supports specification v2.4, has a focus on minimal configuration and the ability to strip the container down to only what you need.
* tjws spec 2.4, small footprint, modular design

Above article originally from wikipedia.org. Above article is available under GNU Free Documentation License.

We intend that this specification should sufficiently document the Java Virtual Machine to make possible compatible clean-room implementations. Sun provides tests which verify the proper operation of implementations of the Java Virtual Machine. Kaffe is an example of a clean-room Java implementation. Sun retains control over the Java trademark, which it uses to certify implementation suites as fully compatible with Sun’s specification.

Execution environment

Programs intended to run on a JVM must be compiled into a standardized portable binary format, which typically comes in the form of .class files. A program may consist of many classes, in which case every class will be in a different file. For easier distribution of large programs, multiple class files may be packaged together in a .jar file. This binary is then executed by the JVM runtime which carries out emulation of the JVM instruction set by interpreting it or by applying a just-in-time compiler (JIT) such as Sun’s HotSpot. The Java byte code is stack based. Therefore interpreter JVMs usually use a stack architecture. In contrast, JIT compilers usually compile the byte code into register based machine code. Each thread has its own stack and program counter.

Bytecode verifier

The JVM verifies all bytecode before it is executed. This means that only a limited amount of bytecode sequences form valid programs, e.g. a JUMP (branch) instruction can only target an instruction within the same function. Because of this, the fact that JVM is a stack architecture does not imply a speed penalty for emulation on register based architectures when using a JIT compiler: in the face of the code-verified JVM architecture, it makes no difference to a JIT compiler whether it gets named imaginary registers or imaginary stack positions that need to be allocated to the target architecture’s registers. In fact, code verification makes the JVM different from a classic stack architecture whose efficient emulation with a JIT compiler is more complicated and typically carried out by a slower interpreter. Code verification also ensures that arbitrary bit patterns cannot get used as an address. Memory protection is achieved without the need for an MMU. Thus, JVM is an efficient way of getting memory protection on simple silicon that has no MMU.

Bytecodes

The JVM has instructions for the following groups of tasks * Load and store * Arithmetic * Type conversion * Object creation and manipulation * Operand stack management (push / pop) * Control transfer (branching) * Method invocation and return * Throwing exceptions The aim is binary compatibility. Each particular host operating system needs its own implementation of the JVM and runtime. These JVMs interpret the byte code semantically the same way, but the actual implementation may be different. More complicated than just the emulation of bytecode is compatible and efficient implementation of the Java core API which has to be mapped to each host operating system.

Secure execution of remote code

A virtual machine architecture allows very fine-grained control over the actions that code within the machine is permitted to take. This is designed to allow safe execution of untrusted code from remote sources, a model used most famously by Java applets. Applets run within a VM incorporated into a user’s browser, executing code downloaded from a remote HTTP server. The remote code runs in a highly restricted “sandbox”, which is designed to protect the user from misbehaving or malicious code. Publishers with sufficient financial resources can apply for a certificate with which to digitally sign applets as “safe”, giving them permission to break out of the sandbox and access the local file system and network, presumably under user control.

Above article originally from wikipedia.org. Above article is available under the terms of GNU Free Documentation License.

]]> http://sourcecodejava.wordpress.com/2009/11/30/jvm-java-virtual-machine/feed/ 0 thaufan http://sourcecodejava.wordpress.com/2009/11/30/java-applet/ http://sourcecodejava.wordpress.com/2009/11/30/java-applet/#comments Mon, 30 Nov 2009 05:00:21 +0000 prastyo http://sourcecodejava.wordpress.com/?p=25 ]]> A Java applet is an applet delivered in the form of Java bytecode. Java applets can run in a Web browser using a Java Virtual Machine (JVM), or in Sun’s AppletViewer, a stand alone tool to test applets. Java applets were introduced in the first version of the Java language in 1995. Java applets are usually written in the Java programming language but they can also be written in other languages that compile to Java bytecode such as Jython.

Applets are used to provide interactive features to web applications that cannot be provided by HTML. Since Java’s bytecode is platform independent, Java applets can be executed by browsers for many platforms, including Windows, Unix, Mac OS and Linux. There are open source tools like applet2app which can be used to convert an applet to a stand alone Java application/windows executable. This has the advantage of running a Java applet in offline mode without the need for internet browser software.

A Java Servlet is sometimes informally compared to be “like” a server-side applet, but it is different in its language, functions, and in each of the characteristics described here about applets.

Technical information

Java applets are executed in a sandbox by most web browsers, preventing them from accessing local data. The code of the applet is downloaded from a web server and the browser either embeds the applet into a web page or opens a new window showing the applet’s user interface. The applet can be displayed on the web page by making use of the deprecated applet HTML element or the recommended object element. This specifies the applet’s source and the applet’s location statistics.

A Java applet extends the class java.applet.Applet, or in the case of a Swing applet, javax.swing.JApplet. The class must override methods from the applet class to set up a user interface inside itself (Applet is a descendant of Panel which is a descendant of Container).

Advantages of applets

A Java applet can have any or all of the following advantages:

* it is simple to make it work on Windows, Mac OS and Linux, i.e. to make it cross platform

* the same applet can work on “all” installed versions of Java at the same time, rather than just the latest plug-in version only. However, if an applet requires a later version of the JRE the client will be forced wait during the large download.

* it runs in a sandbox, so the user does not need to trust the code, so it can work without security approval

* it is supported by most web browsers

* it will cache in most web browsers, so will be quick to load when returning to a web page

* it can have full access to the machine it is running on if the user agrees

* it can improve with use: after a first applet is run, the JVM is already running and starts quickly, benefiting regular users of Java

* it can run at a comparable (but generally slower) speed to other compiled languages such as C++

* it can be a real time application

* it can move the work from the server to the client, making a web solution more scalable with the number of users/clients

Disadvantages of applets

A Java applet is open to any of the following disadvantages:

* it requires the Java plug-in, which isn’t available by default on all web browsers

* it can’t start up until the Java Virtual Machine is running, and this may have significant startup time the first time it is used

* if it is uncached, it must be downloaded (usually over the internet), and this takes time

* it is considered more difficult to build and design a good user interface with applets than with HTML-based technologies

* if untrusted, it has severely limited access to the user’s system – in particular having no direct access to the client’s disc or clipboard

* some organizations only allow software installed by the administrators. As a result, many users cannot view applets by default.

* applets may require a specific JRE.

Compatibility issues

Sun has made a considerable effort to ensure compatibility is maintained between Java versions as they evolve. For example, Microsoft’s Internet Explorer, the most popular web browser since the late 1990s, used to ship with Microsoft’s own JVM as the default. The MSJVM had some extra non-Java features added which, if used, would prevent MSJVM applets from running on Sun’s Java (but not the other way round). Sun sued for breach of trademark, as the point of Java was that there should be no proprietary extensions and that code should work everywhere. Development of MSJVM was frozen by a legal settlement, leaving many users with an extremely outdated Java virtual machine. Later, in October 2001, MS stopped including Java with Windows, and for some years it has been left to the computer manufacturers to ship Java independently of the OS. Most new machines now ship with official Sun Java.

Some browsers (notably Firefox) do not do a good job of handling height=100% on applets which makes it difficult to make an applet fill most of the browser window (Javascript can, with difficulty, be used for this). Having the applet create its own main window is not a good solution either, as this leads to a large chance of the applet getting terminated unintentionally and leaves the browser window as a largely useless extra window.

Alternatives

Alternative technologies exist (for example, DHTML and Flash) that satisfy some of the scope of what is possible with an applet.

Another alternative to applets for client side Java is Java Web Start, which runs outside the browser. In addition to the features available to applets, a simple permissions box can give Java Web Start programs read and/or write access to specified files stored on the client, and to the client’s clipboard.

Above article originally from wikipedia.org. Above article is available under GNU Free Documentation License

Object-oriented programming’s roots reach all the way back to the 1960s, when the nascent field of software engineering had begun to discuss the idea of a software crisis. As hardware and software became increasingly complex, how could software quality be maintained? Object-oriented programming addresses this problem by strongly emphasizing modularity in software.

The Simula programming language was the first to introduce the concepts underlying object-oriented programming (objects, classes, subclasses, virtual methods, coroutines, garbage collection and discrete event simulation) as a superset of Algol. Smalltalk was the first programming language to be called “object-oriented”.

Object-oriented programming may be seen as a collection of cooperating objects, as opposed to a traditional view in which a program may be seen as a list of instructions to the computer. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine with a distinct role or responsibility.

Object-oriented programming came into existence because human consciousness, understanding and logic are highly object-oriented. By way of “objectifying” software modules, it is intended to promote greater flexibility and maintainability in programming, and is widely popular in large-scale software engineering. By virtue of its strong emphasis on modularity, object oriented code is intended to be simpler to develop and easier to understand later on, lending itself to more direct analysis, coding, and understanding of complex situations and procedures than less modular programming methods.

Fundamental conceptsA survey of computing literature, identified a number of “quarks,” or fundamental concepts, identified in the strong majority of definitions of OOP. They are:

Class
A class defines the abstract characteristics of a thing (object), including the thing’s characteristics (its attributes or properties) and the things it can do (its behaviors or methods or features). For example, the class Dog would consist of traits shared by all dogs, for example breed, fur color, and the ability to bark. Classes provide modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of the class should make sense in context. Also, the code for a class should be relatively self-contained. Collectively, the properties and methods defined by a class are called members.
Object
A particular instance of a class. The class of Dog defines all possible dogs by listing the characteristics that they can have; the object Lassie is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie has brown-and-white fur. In programmer jargon, the object Lassie is an instance of the Dog class. The set of values of the attributes of a particular object is called its state.
Method
An object’s abilities. Lassie, being a Dog, has the ability to bark. So bark() is one of Lassie’s methods. She may have other methods as well, for example sit() or eat(). Within the program, using a method should only affect one particular object; all Dogs can bark, but you need one particular dog to do the barking.
Message passing
“The process by which an object sends data to another object or asks the other object to invoke a method.”

Inheritance
In some cases, a class will have “subclasses,” more specialized versions of a class. For example, the class Dog might have sub-classes called Collie, Chihuahua, and GoldenRetriever. In this case, Lassie would be an instance of the Collie subclass. Subclasses inherit attributes and behaviors from their parent classes, and can introduce their own. Suppose the Dog class defines a method called bark() and a property called furColor. Each of its sub-classes (Collie, Chihuahua, and GoldenRetriever) will inherit these members, meaning that the programmer only needs to write the code for them once. Each subclass can alter its inherited traits. So, for example, the Collie class might specify that the default furColor for a collie is brown-and-white. The Chihuahua subclass might specify that the bark() method is high-pitched by default. Subclasses can also add new members. The Chihuahua subclass could add a method called tremble(). So an individual chihuahua instance would use a high-pitched bark() from the Chihuahua subclass, which in turn inherited the usual bark() from Dog. The chihuahua object would also have the tremble() method, but Lassie would not, because she is a Collie, not a Chihuahua. In fact, inheritance is an “is-a” relationship: Lassie is a Collie. A Collie is a Dog. Thus, Lassie inherits the members of both Collies and Dogs. When an object or class inherits its traits from more than one ancestor class, and neither of these ancestors is an ancestor of the other, then it’s called multiple inheritance.

Encapsulation
Conceals the exact details of how a particular class works from objects that use its code or send messages to it. So, for example, the Dog class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and volume). Timmy, Lassie’s friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. The reason for encapsulation is to prevent clients of an interface from depending on those parts of the implementation that are likely to change in future, thereby allowing those changes to be made more easily, that is, without changes to clients. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected or private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the protected keyword to restrict access also to classes in the same package, and C++ allows one to specify which classes may access any member.

Abstraction
Simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem. For example, Lassie the Dog may be treated as a Dog much of the time, a Collie when necessary to access Collie-specific attributes or behaviors, and as an Animal (perhaps the parent class of Dog) when counting Timmy’s pets.

Polymorphism
Polymorphism is the ability of behavior to vary based on the conditions in which the behavior is invoked, that is, two or more methods, as well as operators (such as +, -, *, among others) can fit to many different conditions. For example, if a Dog is commanded to speak() this may elicit a Bark; if a Pig is commanded to speak() this may elicit an Oink. This is expected because Pig has a particular implementation inside the speak() method. The same happens to class Dog. Considering both of them inherit speak() from Animal, this is an example of Overriding Polymorphism. Another good example is about Overloading Polymorphism, a very common one considering operators, like “+”. Once defined an operator used to add numbers, given a class Number and also given two other classes that inherits from Number, such as Integer and Double. Any programmer expects to add two instances of Double or two instances of Integer in just the same way, and more than this: Any programmer expects the same behavior to any Number. In this case, the programmer must overload the concatenation operator, “+”, by making it able to operate with both Double and Integer instances. The way it is done varies a little bit from one language to another and must be studied in more details according to the programmer interest. Most of the OOP languages support small differences in method signatures as polymorphism. it’s very useful, once it improves code readability, to enable implicit conversions to the correct handling method when apply add() method to integers, like in add(1,2), or to strings like in add(“foo”,”bar”) since the definitions of these signatures are available. In many OOP languages, such method signatures would be, respectively, very similar to add(int a, int b) and add(String a, String b). This is an example of Parametric Polymorphism. The returned type and used modifiers, of course, depend on the programmer interests and intentions.

History

The concept of objects and instances in computing had its first major breakthrough with the PDP-1 system at MIT which was the earliest example of capability based architecture. Another early example was Sketchpad made by Ivan Sutherland in 1963; however, this was an application and not a programming paradigm. Objects as programming entities were introduced in the 1960s in Simula 67, a programming language designed for making simulations, created by Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo. Such an approach was a simple extrapolation of concepts earlier used in analog programming. On analog computers, such direct mapping from real-world phenomena/objects to analog phenomena/objects (and conversely), was (and is) called ‘simulation’. Simula not only introduced the notion of classes, but also of instances of classes, which is probably the first explicit use of those notions.

The Smalltalk language, which was developed in the 1970s, introduced the term Object-oriented programming to represent the pervasive use of objects and messages as the basis for computation. Smalltalk creators were influenced by the ideas introduced in Simula 67, but Smalltalk was designed to be a fully dynamic system in which classes could be created and modified dynamically rather than simply using static ones. The ideas in Simula 67 were also used in many other languages, from derivatives of Lisp to Pascal.

Object-oriented programming developed as the dominant programming methodology during the mid-1980s, largely due to the influence of C++. Its dominance was further cemented by the rising popularity of graphical user interfaces, for which object-oriented programming is well-suited. OOP toolkits also enhanced the popularity of “event-driven programming”. Some feel that association with GUIs (real or perceived) was what propelled OOP into the programming mainstream.

OOP also became increasingly popular for developing computer games during the 1990s. As the complexity of games grew, as faster hardware became more widely available and compilers matured, more and more games and their engines were written in OOP languages. Since almost all video games feature virtual environments which contain many, often thousands of objects that interact with each other in complex ways, OOP languages are particularly suited for game development.

Object-oriented features have been added to many existing languages during that time, including Ada, BASIC, Lisp, Fortran, Pascal, and others. Adding these features to languages that were not initially designed for them often led to problems with compatibility and maintainability of code.

In the past decade Java has emerged in wide use partially because of its similarity to C++, but perhaps more importantly because of its implementation using a virtual machine that is intended to run code unchanged on many different platforms. This last feature has made it very attractive to larger development shops with heterogeneous environments. Microsoft’s .NET initiative has a similar objective and includes/supports several new languages, or variants of older ones.

Besides Java, probably the most commercially important recent object-oriented languages are Visual Basic .NET and C# designed for Microsoft’s .NET platform.

Just as procedural programming led to refinements of techniques such as structured programming, modern object-oriented software design methods include refinements such as the use of design patterns, design by contract, and modeling languages.

OOP in scripting
In recent years, object-oriented programming has become especially popular in scripting programming languages. Python and Ruby are scripting languages built on OOP principles, while Perl and PHP have been adding object oriented features since Perl 5 and PHP 4.

The Document Object Model of HTML, XHTML, and XML documents on the Internet have bindings to the popular JavaScript/ECMAScript language. JavaScript is perhaps the best known prototype-based programming language.

Problems and patterns

There are a number of programming challenges which a developer encounters regularly in object-oriented design. There are also widely accepted solutions to these problems. The best known are the design patterns codified by Gamma et al, but in a more general sense the term “design patterns” can be used to refer to any general, repeatable solution to a commonly occurring problem in software design. Some of these commonly occurring problems have implications and solutions particular to object-oriented development.

Gang of Four design patterns
Design Patterns: Elements Reusable Object-Oriented Software is an influential book published in 1995 by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, sometimes casually called the “Gang of Four.” Along with exploring the capabilities and pitfalls of object-oriented programming, it describes 23 common programming problems and patterns for solving them.

Object-orientation and databases
Both object-oriented programming and relational database management systems (RDBMSs) are extremely common in software today. Since relational databases don’t store objects directly (though some RDBMSs have object-oriented features to approximate this), there is a general need to bridge the two worlds. There are a number of widely used solutions to this problem. One of the most common is object-relational mapping, as found in libraries like Java Data Objects, and Ruby on Rails’ ActiveRecord.

There are also object databases which can be used to replace RDBMSs, but these have not been as commercially successful as RDBMSs.

Matching real world
OOP can be used to translate from real-world phenomena to program elements (and vice versa). OOP was even invented for the purpose of physical modelling in the Simula-67 programming language. However, not everyone agrees that direct real-world mapping is facilitated by OOP, or is even a worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction that a program is not a model of the world but a model of a model of some part of the world; “Reality is a cousin twice removed”.

Formal definition
There have been several attempts at formalizing the concepts used in object-oriented programming. The following concepts and constructs have been used as interpretations of OOP concepts:

coalgebraic datatypes
existential quantification and modules
recursion
records and record extensions
F-bounded polymorphism

Attempts to find a consensus definition or theory behind objects have not proven very successful, and often diverge widely. For example, some definitions focus on mental activities, and some on mere program structuring. One of the simpler definitions is that OOP is the act of using “map” data structures or arrays that can contain functions and pointers to other maps, all with some syntactic and scoping sugar on top. Inheritance can be performed by cloning the maps (sometimes called “prototyping”).

Above article originally from wikipedia.org. Above article is available under GNU Free Documentation License.

The language itself borrows much syntax from C and C++ but has a simpler object model and fewer low-level facilities. Java is only distantly related to JavaScript, though they have similar names and share a C-like syntax.

Java was started as a project called “Oak” by James Gosling in June 1991. Gosling’s goals were to implement a virtual machine and a language that had a familiar C-like notation but with greater uniformity and simplicity than C/C++. The first public implementation was Java 1.0 in 1995. It made the promise of “Write Once, Run Anywhere”, with free runtimes on popular platforms. It was fairly secure and its security was configurable, allowing for network and file access to be limited. The major web browsers soon incorporated it into their standard configurations in a secure “applet” configuration. popular quickly. New versions for large and small platforms (J2EE and J2ME) soon were designed with the advent of “Java 2″. Sun has not announced any plans for a “Java 3″.

In 1997, Sun approached the ISO/IEC JTC1 standards body and later the Ecma International to formalize Java, but it soon withdrew from the process. Java remains a proprietary de facto standard that is controlled through the Java Community Process. Sun makes most of its Java implementations available without charge, with revenue being generated by specialized products such as the Java Enterprise System. Sun distinguishes between its Software Development Kit (SDK) and Runtime Environment (JRE) which is a subset of the SDK, the primary distinction being that in the JRE the compiler is not present.

Philosophy

There were five primary goals in the creation of the Java language:

1. It should use the object-oriented programming methodology.
2. It should allow the same program to be executed on multiple operating systems.
3. It should contain built-in support for using computer networks.
4. It should be designed to execute code from remote sources securely.
5. It should be easy to use by selecting what was considered the good parts of other object-oriented languages.

To achieve the goals of networking support and remote code execution, Java programmers sometimes find it necessary to use extensions such as CORBA, Internet Communications Engine, or OSGi.

Object orientation

The first characteristic, object orientation (“OO”), refers to a method of programming and language design. Although there are many interpretations of OO, one primary distinguishing idea is to design software so that the various types of data it manipulates are combined together with their relevant operations. Thus, data and code are combined into entities called objects. An object can be thought of as a self-contained bundle of behavior (code) and state (data). The principle is to separate the things that change from the things that stay the same; often, a change to some data structure requires a corresponding change to the code that operates on that data, or vice versa. This separation into coherent objects provides a more stable foundation for a software system’s design. The intent is to make large software projects easier to manage, thus improving quality and reducing the number of failed projects.

Another primary goal of OO programming is to develop more generic objects so that software can become more reusable between projects. A generic “customer” object, for example, should have roughly the same basic set of behaviors between different software projects, especially when these projects overlap on some fundamental level as they often do in large organizations. In this sense, software objects can hopefully be seen more as pluggable components, helping the software industry build projects largely from existing and well-tested pieces, thus leading to a massive reduction in development times. Software reusability has met with mixed practical results, with two main difficulties: the design of truly generic objects is poorly understood, and a methodology for broad communication of reuse opportunities is lacking. Some open source communities want to help ease the reuse problem, by providing authors with ways to disseminate information about generally reusable objects and object libraries.

Platform independence

The second characteristic, platform independence, means that programs written in the Java language must run similarly on diverse hardware. One should be able to write a program 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. 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 compile 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.

Sun’s license for Java insists that all implementations be “compatible”. This resulted in a legal dispute with Microsoft after Sun claimed that the Microsoft implementation did not support the RMI and JNI interfaces and had added platform-specific features of their own. In response, Microsoft no longer ships Java with Windows, and in recent versions of Windows, Internet Explorer cannot support Java applets without a third-party plug-in. However, Sun and others have made available Java run-time systems at no cost for those and other versions of Windows.

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. 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.

Automatic garbage collection

One idea behind Java’s automatic memory management model is that programmers should be spared the burden of having to perform manual memory management. In some languages the programmer allocates memory to create any object stored on the heap and is responsible for later manually deallocating that memory to delete any such objects. If a programmer forgets to deallocate memory or writes code that fails to do so in a timely fashion, a memory leak can occur: the program will consume a potentially arbitrarily large amount of memory. In addition, if a region of memory is deallocated twice, the program can 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.

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 extra development time and some application complexity. 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.

Syntax

The syntax of Java is largely derived from C++. However, unlike C++, which combines the syntax for structured, generic, and object-oriented programming, Java was built from the ground up to be virtually fully object-oriented: everything in Java is an object with the exceptions of atomic datatypes (ordinal and real numbers, boolean values, and characters) and everything in Java is written inside a class.

Applet

Java applets are programs that are embedded in other applications, typically in a Web page displayed in a Web browser.

// Hello.java
import java.applet.Applet;
import java.awt.Graphics;

public class Hello extends Applet {
public void paint(Graphics gc) {
gc.drawString(“Hello, world!”, 65, 95);
}
}

This applet will simply draw the string “Hello, world!” in the rectangle within which the applet will run. This is a slightly better example of using Java’s OO features in that the class explicitly extends the basic “Applet” class, that it overrides the “paint” method and that it uses import statements.

<!– Hello.html –>
<html>
<head>
<title>Hello World Applet</title>
</head>
<body>
<applet code=”Hello” width=”200″ height=”200″>
</applet>
</body>
</html>

An applet is placed in an HTML document using the <applet> HTML element. The applet tag has three attributes set: code=”Hello” specifies the name of the Applet class and width=”200″ height=”200″ sets the pixel width and height of the applet. (Applets may also be embedded in HTML using either the object or embed element, although support for these elements by Web browsers is inconsistent.

Servlet

Java servlets are server-side Java EE components that generate responses to requests from clients.

// Hello.java
import java.io.*;
import javax.servlet.*;

public class Hello extends GenericServlet {
public void service(ServletRequest request, ServletResponse response)
throws ServletException, IOException
{
response.setContentType(“text/html”);
PrintWriter pw = response.getWriter();
pw.println(“Hello, world!”);
pw.close();
}
}

The import statements direct the Java compiler to include all of the public classes and interfaces from the java.io and javax.servlet packages in the compilation. The Hello class extends the GenericServlet class; the GenericServlet class provides the interface for the server to forward requests to the servlet and control the servlet’s lifecycle.

The Hello class overrides the service(ServletRequest, ServletResponse) method defined by the Servlet interface to provide the code for the service request handler. The service() method is passed a ServletRequest object that contains the request from the client and a ServletResponse object used to create the response returned to the client. The service() method declares that it throws the exceptions ServletException and IOException if a problem prevents it from responding to the request.

The setContentType(String) method in the response object is called to set the MIME content type of the returned data to “text/html”. The getWriter() method in the response returns a PrintWriter object that is used to write the data that is sent to the client. The println(String) method is called to write the “Hello, world!” string to the response and then the close() method is called to close the print writer, which causes the data that has been written to the stream to be returned to the client.

Swing application

Swing is the advanced graphical user interface library for the Java SE platform.

// Hello.java
import javax.swing.*;

public class Hello extends JFrame {
Hello() {
setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
add(new JLabel(“Hello, world!”));
pack();
}

public static void main(String[] args) {
new Hello().setVisible(true);
}
}

The import statement directs the Java compiler to include all of the public classes and interfaces from the javax.swing package in the compilation. The Hello class extends the JFrame class; the JFrame class implements a window with a title bar with a close control.

The Hello() constructor initializes the frame by first calling the setDefaultCloseOperation(int) method inherited from JFrame to set the default operation when the close control on the title bar is selected to WindowConstants.DISPOSE_ON_CLOSE—this causes the JFrame to be disposed of when the frame is closed (as opposed to merely hidden), which allows the JVM to exit and the program to terminate. Next a new JLabel is created for the string “Hello, world!” and the add(Component) method inherited from the Container superclass is called to add the label to the frame. The pack() method inherited from the Window superclass is called to size the window and layout its contents.

The main() method is called by the JVM when the program starts. It instantiates a new Hello frame and causes it to be displayed by calling the setVisible(boolean) method inherited from the Component superclass with the boolean parameter true. Note that once the frame is displayed, exiting the main method does not cause the program to terminate because the AWT event dispatching thread remains active until all of the Swing top-level windows have been disposed.

Look and feel

The default look and feel of GUI applications written in Java using the Swing toolkit is very different from native applications. It is possible to specify a different look and feel through the pluggable look and feel system of Swing. Clones of Windows, GTK and Motif are supplied by Sun. Apple also provides an Aqua look and feel for Mac OS X. Though prior implementations of these look and feels have been considered lacking, Swing in Java SE 6 addresses this problem by using more native widget drawing routines of the underlying platforms. Alternatively, third party toolkits such as wx4j or SWT may be used for increased integration with the native windowing system.

Lack of OO purity and facilities

Java’s primitive types are not objects. Primitive types hold their values in the stack rather than being references to values. This was a conscious decision by Java’s designers for performance reasons. Because of this, Java is not considered to be a pure object-oriented programming language. However, as of Java 5.0, autoboxing enables programmers to write as if primitive types are their wrapper classes, and freely interchange between them for improved flexibility. Java designers decided not to implement certain features present in other OO languages, including:

* multiple inheritance
* operator overloading
* class properties
* tuples

Java Runtime Environment

The Java Runtime Environment or JRE is the software required to run any application deployed on the Java Platform. End-users commonly use a JRE in software packages and Web browser plugins. Sun also distributes a superset of the JRE called the Java 2 SDK (more commonly known as the JDK), which includes development tools such as the Java compiler, Javadoc, and debugger.

Above article originally from wikipedia.org. Above article is available under GNU Free Documentation License.