JAVA VIRTUAL MACHINE

A Java Virtual Machine (JVM) is a set of computer software programs and data structures which use a virtual machine model for the execution of other computer programs and scripts. The model used by a JVM accepts a form of computer intermediate language commonly referred to as Java bytecode. This language conceptually represents the instruction set of a stack-oriented, capability architecture.

Java Virtual Machines operate on Java bytecode, which is normally (but not necessarily) generated from Java source code; a JVM can also be used to implement programming languages other than Java. For example, Ada source code can be compiled to Java bytecode, which may then be executed by a JVM. JVMs can also be released by other companies besides Sun (the developer of Java) — JVMs using the "Java" trademark may be developed by other companies as long as they adhere to the JVM specification published by Sun (and related contractual obligations).

The JVM is a crucial component of the Java Platform. Because JVMs are available for many hardware and software platforms, Java can be both middleware and a platform in its own right — hence the expression "write once, run anywhere." The use of the same bytecode for all platforms allows Java to be described as "compile once, run anywhere", as opposed to "write once, compile anywhere", which describes cross-platform compiled languages. The JVM also enables such unique features as Automated Exception Handling which provides 'root-cause' debugging information for every software error (exception) independent of the source code.

The JVM is distributed along with a set of standard class libraries which implement the Java API (Application Programming Interface). The virtual machine and API have to be consistent with each other[dubious – discuss] and are therefore bundled together as the Java Runtime Environment.
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 different files. For easier distribution of large programs, multiple class files may be packaged together in a .jar file (short for Java archive).

The JVM runtime executes .class or .jar files, emulating the JVM instruction set by interpreting it, or using a just-in-time compiler (JIT) such as Sun's HotSpot. JIT compiling, not interpreting, is used in most JVMs today to achieve greater speed. Ahead-of-time compilers that enable the developer to precompile class files into native code for a particular platform also exist.

Like most virtual machines, the Java Virtual Machine has a stack-based architecture.

The JVM, which is the instance of the JRE (Java Runtime Environment), comes into action when a Java program is executed. When execution is complete, this instance is garbage-collected. JIT is the part of the JVM that is used to speed up the execution time. JIT compiles parts of the byte code that have similar functionality at the same time, and hence reduces the amount of time needed for compilation.

Support for dynamic Languages

Although the JVM was primarily aimed at running compiled Java programs, other languages can now run on top of it, such as:

Ruby, with JRuby
JavaScript, with Rhino
Python, with Jython
Common Lisp, with Armed Bear Common Lisp
Groovy
Scala
The JVM has currently no built-in support for Dynamically typed languages: the existing JVM instruction set is statically typed. The JVM has a limited support for dynamically modifying existing classes and methods. It currently only works in a debugging environment.

Built-in support for dynamic languages is currently planned for Java 7.


Bytecode verifier
A basic philosophy of Java is that it is inherently "safe" from the standpoint that no user program can "crash" the host machine or otherwise interfere inappropriately with other operations on the host machine, and that it is possible to protect certain functions and data structures belonging to "trusted" code from access or corruption by "untrusted" code executing within the same JVM. Furthermore, common programmer errors that often lead to data corruption or unpredictable behavior such as accessing off the end of an array or using an uninitialized pointer are not allowed to occur. Several features of Java combine to provide this safety, including the class model, the garbage-collected heap, and the verifier.

The JVM verifies all bytecode before it is executed. This verification consists primarily of three types of checks:

Branches are always to valid locations
Data is always initialized and references are always type-safe
Access to "private" or "package private" data and methods is rigidly controlled.
The first two of these checks take place primarily during the "verification" step which occurs when a class is loaded and made eligible for use. The third is primarily performed dynamically, when data items or methods of a class are first accessed by another class.

The verifier permits only some bytecode sequences in valid programs, e.g. a jump (branch) instruction can only target an instruction within the same function or method. 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 a Memory management unit (MMU). Thus, JVM is an efficient way of getting memory protection on simple architectures that lack an MMU. This is analogous to managed code in Microsoft's .NET Common Language Runtime, and conceptually similar to capability architectures such as the Plessey 250, and IBM System/38.


Bytecode instructions

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
Monitor-based concurrency
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 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 restricted "sandbox", which is designed to protect the user from misbehaving or malicious code. Publishers can purchase a certificate with which to digitally sign applets as "safe", giving them permission to ask the user to break out of the sandbox and access the local file system and network...


C to bytecode compilers
From the point of view of a compiler, Java bytecode is just another processor with an instruction set for which code can be generated. The JVM was originally designed to execute programs written in the Java language. However, the JVM provides an execution environment in the form of a bytecode instruction set and a runtime system that is general enough that it can be used as the target for compilers of other languages.

Because of its close association with Java the JVM performs the runtime checks mandated by the Java specification. This can make it technically difficult to translate C code (which is much more lax with regard to runtime checking) to the JVM and expect it to run without issuing any warnings.

It can be easier to translate some language, such as C, to machine language first before converting to Java bytecode. This has been shown to be the case with NestedVM project and accompanying paper.

Compilers targeting many different languages, including Ada and COBOL, have been written

JAVA DEVELOPMENT KIT

The Java Development Kit (JDK) is a Sun Microsystems product aimed at Java developers. Since the introduction of Java, it has been by far the most widely used Java SDK. On 17 November 2006, Sun announced that it would be released under the GNU General Public License (GPL), thus making it free software. This happened in large part on 8 May 2007 and the source code was contributed to the OpenJDK.

JDK contents

The primary components of the JDK are a selection of programming tools, including:

java – The loader for Java applications. This tool is an interpreter and can interpret the class files generated by the javac compiler. Now a single launcher is used for both development and deployment. The old deployment launcher, jre, is no longer provided with Sun JDK.
javac – The compiler, which converts source code into Java bytecode
jar – The archiver, which packages related class libraries into a single JAR file. This tool also helps manage JAR files.
javadoc – The documentation generator, which automatically generates documentation from source code comments
jdb – The debugger
javap – The class file disassembler
appletviewer – This tool can be used to run and debug Java applets without a web browser.
javah – The C header and stub generator, used to write native methods
extcheck – This utility can detect JAR-file conflicts.
apt – The annotation processing tool
jhat – (Experimental) Java heap analysis tool
jstack – (Experimental) This utility prints Java stack traces of Java threads.
jstat – (Experimental) Java Virtual Machine statistics monitoring tool
jstatd – (Experimental) jstat daemon
jinfo – (Experimental) This utility gets configuration information from a running Java process or crash dump.
jmap – (Experimental) This utility outputs the memory map for Java and can print shared object memory maps or heap memory details of a given process or core dump.
idlj – The IDL-to-Java compiler. This utility generates Java bindings from a given IDL file.
policytool – The policy creation and management tool, which can determine policy for a Java runtime, specifying which permissions are available for code from various sources
VisualVM – visual tool integrating several commandline JDK tools and lightweight performance and memory profiling capabilities
The JDK also comes with a complete Java Runtime Environment, usually called a private runtime. It consists of a Java Virtual Machine and all of the class libraries that will be present in the production environment, as well as additional libraries only useful to developers, such as the internationalization libraries and the IDL libraries.

Also included are a wide selection of example programs demonstrating the use of almost all portions of the Java API.


Ambiguity between a JDK and an SDK
The JDK is a subset of what is loosely defined as a Software development kit (SDK) in the general sense. In the descriptions which accompany their recent releases for Java SE, EE, and ME, Sun acknowledge that under their terminology, the JDK forms the subset of the SDK which is responsible for the writing and running of Java programs.[citation needed] The remainder of the SDK is composed of extra software, such as Application Servers, Debuggers, and Documentation.

JAVA SCRIPT

JavaScript is a scripting language most often used for client-side web development. It was the originating dialect of the ECMAScript standard. It is a dynamic, weakly typed, prototype-based language with first-class functions. JavaScript was influenced by many languages and was designed to look like Java, but be easier for non-programmers to work with.

Although best known for its use in websites (as client-side JavaScript), JavaScript is also used to enable scripting access to objects embedded in other applications (see below).

JavaScript, despite the name, is essentially unrelated to the Java programming language, although both have the common C syntax, and JavaScript copies many Java names and naming conventions. The language was originally named "LiveScript" but was renamed in a co-marketing deal between Netscape and Sun, in exchange for Netscape bundling Sun's Java runtime with their then-dominant browser. The key design principles within JavaScript are inherited from the Self and Scheme programming languages.

"JavaScript" is a trademark of Sun Microsystems. It was used under license for technology invented and implemented by Netscape Communications and current entities such as the Mozilla Foundation.

History and naming
JavaScript was originally developed by Brendan Eich of Netscape under the name Mocha, which was later renamed to LiveScript, and finally to JavaScript. The change of name from LiveScript to JavaScript roughly coincided with Netscape adding support for Java technology in its Netscape Navigator web browser. JavaScript was first introduced and deployed in the Netscape browser version 2.0B3 in December 1995. The naming has caused confusion, giving the impression that the language is a spin-off of Java, and it has been characterized by many as a marketing ploy by Netscape to give JavaScript the cachet of what was then the hot new web-programming language.

Microsoft named its dialect of the language JScript to avoid trademark issues. JScript was first supported in Internet Explorer version 3.0, released in August 1996, and it included Y2K-compliant date functions, unlike those based on java.util.Date in JavaScript at the time. The dialects are perceived to be so similar that the terms "JavaScript" and "JScript" are often used interchangeably (including in this article). Microsoft, however, notes dozens of ways in which JScript is not ECMA compliant.

Netscape submitted JavaScript to Ecma International for standardization resulting in the standardized version named ECMAScript.


Features
Structured programming
JavaScript supports all the structured programming syntax in C (e.g., if statements, while loops, switch statements, etc.). One partial exception is scoping: C-style block-level scoping is not supported. JavaScript 1.7, however, supports block-level scoping with the let keyword. Like C, JavaScript makes a distinction between expressions and statements.


Dynamic programming
dynamic typing
As in most scripting languages, types are associated with values, not variables. For example, a variable x could be bound to a number, then later rebound to a string. JavaScript supports various ways to test the type of an object, including duck typing.
objects as associative arrays
JavaScript is heavily object-based. Objects are associative arrays, augmented with prototypes (see below). Object property names are associative array keys: obj.x = 10 and obj["x"] = 10 are equivalent, the dot notation being merely syntactic sugar. Properties and their values can be added, changed, or deleted at run-time. The properties of an object can also be enumerated via a for...in loop.
run-time evaluation
JavaScript includes an eval function that can execute statements provided as strings at run-time.

Function-level programming
first-class functions
Functions are first-class; they are objects themselves. As such, they have properties and can be passed around and interacted with like any other object.
inner functions and closures
Inner functions (functions defined within other functions) are created each time the outer function is invoked, and variables of the outer functions for that invocation continue to exist as long as the inner functions still exist, even after that invocation is finished (e.g. if the inner function was returned, it still has access to the outer function's variables) — this is the mechanism behind closures within JavaScript.

Prototype-based
prototypes
JavaScript uses prototypes instead of classes for defining object properties, including methods, and inheritance. It is possible to simulate many class-based features with prototypes in JavaScript.
functions as object constructors
Functions double as object constructors along with their typical role. Prefixing a function call with new creates a new object and calls that function with its local this keyword bound to that object for that invocation. The function's prototype property determines the new object's prototype.
functions as methods
Unlike many object-oriented languages, there is no distinction between a function definition and a method definition. Rather, the distinction occurs during function calling; a function can be called as a method. When a function is invoked as a method of an object, the function's local this keyword is bound to that object for that invocation.

Use in web pages

The primary use of JavaScript is to write functions that are embedded in or included from HTML pages and interact with the Document Object Model (DOM) of the page. Some simple examples of this usage are:

Opening or popping up a new window with programmatic control over the size, position, and attributes of the new window (i.e. whether the menus, toolbars, etc. are visible).
Validation of web form input values to make sure that they will be accepted before they are submitted to the server.
Changing images as the mouse cursor moves over them: This effect is often used to draw the user's attention to important links displayed as graphical elements.
Because JavaScript code can run locally in a user's browser (rather than on a remote server) it can respond to user actions quickly, making an application feel more responsive. Furthermore, JavaScript code can detect user actions which HTML alone cannot, such as individual keystrokes. Applications such as Gmail take advantage of this: much of the user-interface logic is written in JavaScript, and JavaScript dispatches requests for information (such as the content of an e-mail message) to the server. The wider trend of Ajax programming similarly exploits this strength.

A JavaScript engine (also known as JavaScript interpreter or JavaScript implementation) is an interpreter that interprets JavaScript source code and executes the script accordingly. The first ever JavaScript engine was created by Brendan Eich at Netscape Communications Corporation, for the Netscape Navigator web browser. The engine, code-named SpiderMonkey, is implemented in C. It has since been updated (in JavaScript 1.5) to conform to ECMA-262 Edition 3. The Rhino engine, created primarily by Norris Boyd (also at Netscape) is a JavaScript implementation in Java. Rhino, like SpiderMonkey, is ECMA-262 Edition 3 compliant.

The most common host environment for JavaScript is by far a web browser. Web browsers typically use the public API to create "host objects" responsible for reflecting the DOM into JavaScript. The web server is another common application of the engine. A JavaScript webserver would expose host objects representing an HTTP request and response objects, which a JavaScript program could then manipulate to dynamically generate web pages.

Debugging

Within JavaScript, access to a debugger becomes invaluable when developing large, non-trivial programs. Because there can be implementation differences between the various browsers (particularly within the Document Object Model) it is useful to have access to a debugger for each of the browsers a web application is being targeted at.

Currently, Internet Explorer, Firefox, Safari, and Opera all have script debuggers available for them.

Internet Explorer has three debuggers available for it: Microsoft Visual Studio is the richest of the three, closely followed by Microsoft Script Editor (a component of Microsoft Office[31]), and finally the free Microsoft Script Debugger which is far more basic than the other two. The free Microsoft Visual Web Developer Express provides a limited version of the JavaScript debugging functionality in Microsoft Visual Studio.

Web applications within Firefox can be debugged using the Firebug plug-in, or the older Venkman debugger, which also works with the Mozilla browser. Firefox also has a simpler built-in Error Console, which logs JavaScript and CSS errors and warnings.

Drosera is a debugger for the WebKit engine[32] on Macintosh and Windows[33] powering Apple's Safari.

There are also some free tools such as JSLint, a code quality tool that will scan JavaScript code looking for problems[34], as well as a non-free tool called SplineTech JavaScript HTML Debugger.[35]

Since JavaScript is interpreted, loosely-typed, and may be hosted in varying environments, each with their own compatibility differences, a programmer has to take extra care to make sure the code executes as expected in as wide a range of circumstances as possible, and that functionality degrades gracefully when it does not.

JOIN JAVA

Join Java is a programming language that extends the standard Java programming language with the Join Semantics of the Join Calculus. It was written at the University of South Australia within the Reconfigurable Computing Lab by Dr. Von Itzstein.

Language characteristics:
The Join Java extension introduces three new language constructs:

Join methods
Asynchronous methods
Order class modifiers for determining the order that patterns are matched

Concurrency expression in most popular programming languages is still quite low level and based on constructs such as semaphores and monitors, that have not changed in twenty years. Libraries that are emerging (such as the Java concurrency library JSR-166) show that programmers demand that higher-level concurrency semantics be available in mainstream languages. Communicating Sequential Processes (CSP), Calculus of Communicating Systems (CCS) and Pi have higher-level synchronization behaviours defined implicitly through the composition of events at the interfaces of concurrent processes. Join calculus, on the other hand has explicit synchronization based on a localized conjunction of events defined as reduction rules. The Join semantics appear to be more appropriate to mainstream programmers; who want explicit expressions of synchronization that do not breach the object-oriented idea of modularization. Join readily expresses the dynamic creation and destruction of processes and channels which is sympathetic to dynamic languages like Java.

The Join Java language can express virtually all published concurrency patterns without explicit recourse to low-level monitor calls. In general, Join Java programs are more concise than their Java equivalents. The overhead introduced in Join Java by the higher-level expressions derived from the Join calculus is manageable. The synchronization expressions associated with monitors (wait and notify) which are normally located in the body of methods can be replaced by Join Java expressions (the Join methods) which form part of the method signature.