Mainframes (often colloquially referred to as Big Iron are computers used mainly by large organizations for critical applications, typically bulk data processing such as census, industry and consumer statistics, ERP, and financial transaction processing.
The term probably originated from the early mainframes, as they were housed in enormous, room-sized metal boxes or frames. Later the term was used to distinguish high-end commercial machines from less powerful units.
Today in practice, the term usually refers to computers compatible with the IBM System/360 line, first introduced in 1965. (IBM System z10 is the latest incarnation.) Otherwise, large systems that are not based on the System/360 are referred to as either "servers" or "supercomputers". However, "server", "supercomputer" and "mainframe" are not synonymous (see client-server).
Some non-System/360-compatible systems derived from or compatible with older (pre-Web) server technology may also be considered mainframes. These include the Burroughs large systems, the UNIVAC 1100/2200 series systems, and the pre-System/360 IBM 700/7000 series. Most large-scale computer system architectures were firmly established in the 1960s and most large computers were based on architecture established during that era up until the advent of Web servers in the 1990s. (Interestingly, the first Web server running anywhere outside Switzerland ran on an IBM mainframe at Stanford University as early as 1990. See History of the World Wide Web for details.)
There were several minicomputer operating systems and architectures that arose in the 1970s and 1980s, but minicomputers are generally not considered mainframes. (UNIX arose as a minicomputer operating system; Unix has scaled up over the years to acquire some mainframe characteristics.)
Many defining characteristics of "mainframe" were established in the 1960s, but those characteristics continue to expand and evolve to the present day
Description
Modern mainframe computers have abilities not so much defined by their single task computational speed (usually defined as MIPS — Millions of Instructions Per Second) as by their redundant internal engineering and resulting high reliability and security, extensive input-output facilities, strict backward compatibility with older software, and high utilization rates to support massive throughput. These machines often run for years without interruption, with repairs and hardware upgrades taking place during normal operation.
Software upgrades are only non-disruptive when Parallel Sysplex is in place, with true workload sharing, so one system can take over another's application, while it is being refreshed. More recently, there are several IBM mainframe installations that have delivered over a decade of continuous business service as of 2007, with hardware upgrades not interrupting service.[citation needed] Mainframes are defined by high availability, one of the main reasons for their longevity, because they are typically used in applications where downtime would be costly or catastrophic. The term Reliability, Availability and Serviceability (RAS) is a defining characteristic of mainframe computers. Proper planning (and implementation) is required to exploit these features.
In the 1960s, most mainframes had no interactive interface. They accepted sets of punch cards, paper tape, and/or magnetic tape and operated solely in batch mode to support back office functions, such as customer billing. Teletype devices were also common, at least for system operators. By the early 1970s, many mainframes acquired interactive user interfaces and operated as timesharing computers, supporting hundreds or thousands of users simultaneously along with batch processing. Users gained access through specialized terminals or, later, from personal computers equipped with terminal emulation software. Many mainframes supported graphical terminals (and terminal emulation) by the 1980s (if not earlier). Nowadays most mainframes have partially or entirely phased out classic terminal access for end-users in favor of Web user interfaces. Developers and operational staff typically continue to use terminals or terminal emulators.
Historically mainframes acquired their name in part because of their substantial size and requirements for specialized heating, ventilating, air conditioning (HVAC), and electrical power. Those requirements ended by the mid-1990s with CMOS mainframe designs replacing the older bipolar technology. In a major reversal, IBM now touts its newer mainframes' ability to reduce data center energy costs for power and cooling and reduced physical space requirements compared to server farms.
Characteristics of mainframes
Nearly all mainframes have the ability to run (or host) multiple operating systems and thereby operate not as a single computer but as a number of virtual machines. In this role, a single mainframe can replace dozens or even hundreds of smaller servers. While mainframes pioneered this capability, it is now available on most families of computer system.
Mainframes can add or hot swap system capacity non disruptively and granularly. Modern mainframes, notably the IBM zSeries, System z9 and System z10 servers, offer three levels of virtualization: logical partitions (LPARs, via the PR/SM facility), virtual machines (via the z/VM operating system), and through its operating systems (notably z/OS with its key-protected address spaces and sophisticated goal-oriented workload scheduling,[clarify] but also Linux, OpenSolaris (being ported) and Java). This virtualization is so thorough, so well established, and so reliable that most IBM mainframe customers run no more than two machines: one in their primary data center, and one in their backup data center—fully active, partially active, or on standby—in case there is a catastrophe affecting the first building. All test, development, training, and production workload for all applications and all databases can run on a single machine, except for extremely large demands where the capacity of one machine might be limiting. Such a two mainframe installation can support continuous business service, avoiding both planned and unplanned outages.
Mainframes are designed to handle very high volume input and output (I/O) and emphasize throughput computing. Since the mid-1960s, mainframe designs have included several subsidiary computers (called channels or peripheral processors) which manage the I/O devices, leaving the CPU free to deal only with high-speed memory. It is common in mainframe shops to deal with massive databases and files. Giga-record or tera-record files are not unusual.[4] Compared to a typical PC, mainframes commonly have hundreds to thousands of times as much data storage online, and can access it much faster.[citation needed]
Mainframe return on investment (ROI), like any other computing platform, is dependent on its ability to scale, support mixed workloads, reduce labor costs, deliver uninterrupted service for critical business applications, and several other risk-adjusted cost factors. Some argue that the modern mainframe is not cost-effective. Hewlett-Packard and Dell unsurprisingly take that view at least at times, and so do some independent analysts. Sun Microsystems also takes that view, but beginning in 2007 promoted a partnership with IBM which largely focused on IBM support for Solaris on its System x and BladeCenter products, but also included positive comments for the company's OpenSolaris operating system being ported to IBM mainframes. The general consensus (held by Gartner[citation needed] and other independent analysts) is that the modern mainframe often has unique value and superior cost-effectiveness, especially for large scale enterprise computing. In fact, Hewlett-Packard also continues to manufacture its own mainframe (arguably), the NonStop system originally created by Tandem. Logical partitioning is now found in many UNIX-based servers, and many vendors are promoting virtualization technologies, in many ways validating the mainframe's design accomplishments while blurring the differences between the different approaches to enterprise computing.
Mainframes also have execution integrity characteristics for fault tolerant computing. z900 and z990 and System z9 and z10 servers execute each instruction twice,[citation needed] compare results, and shift workloads "in flight" to functioning processors, including spares, without any impact to applications or users. This feature, also found in HP's NonStop systems, is known as lock-stepping, because both processors take their "steps" (i.e. instructions) together. Not all applications absolutely need the assured integrity that these systems provide, but many do, such as financial transaction processing.
However, the mainframe has its disadvantage. In particular, it is most likely remote and centralized. That may not be a problem as some business has to be done centralized, e.g. accounting, stock transaction, etc. However, there are a lot of business processes that benefit from decentralized management. Also, the high costs to maintain in an absolute scale or, to put it nicer, the need of a critical mass to invest on a mainframe platform sometimes "force" processes that are relatively independent to compromise and sit in one large box under the centralized IT management. Even though one may argue certain cost saving on average, the flexibility, the user ownership, the difficulty to compromise the maintenance window, the hardship to deal with diverse clients, and also delegating IT management to a different team makes mainframe concept unpopular. A lot of IT revolution is away from the "bureau approach" implicit to mainframe solution. Instead, one opts for a more personal (PC), or departmental (mid-range), data processing. Mainframe's virtualization technology of running hundreds of OSes (like Linux) on one mainframe did not directly address these issues inherent to centralization. Instead, a lot of the mainframe's features, like multiprocessing, disk array controllers, I/O multipathing, graphics controllers, virtualization, are downscaled to less expensive platforms, rather than lower platform's technologies upscale to mainframe.
Despite these issues, the mainframe is still a viable general purpose business computer in terms of its support for a wide variety of popular operating systems, middleware, and applications suitable for certain type of organization, culture and business processes.
Market
IBM mainframes dominate the mainframe market at well over 90% market share. Unisys manufactures ClearPath mainframes, based on earlier Sperry and Burroughs product lines. Hitachi co-developed the zSeries z800 with IBM to share expenses. Hewlett-Packard sells its unique NonStop systems, which it acquired with Tandem Computers. Groupe Bull's DPS, Fujitsu-Siemens BS2000, and Fujitsu-ICL VME mainframes are still available in Europe. Fujitsu, Hitachi, and NEC (the "JCMs") still maintain nominal mainframe hardware businesses in their home Japanese market.
The amount of vendor investment in mainframe development varies with market share. Unisys, HP, Groupe Bull, Fujitsu, Hitachi, and NEC now rely primarily on commodity Intel CPUs rather than custom processors in order to reduce development expenses, and they have also cut back their mainframe software development. In contrast, IBM has its own large research and development organization designing new, homegrown CPUs, including mainframe processors, and IBM is rapidly expanding its software business, including its mainframe software portfolio, to seek additional profits.
Platform Solutions Inc., which was spun off former plug compatible mainframe vendor Amdahl Corp. in January 1999,[8] markets Itanium-based servers compatible with IBM System z. PSI and IBM are engaged in a series of lawsuits. IBM alleges that PSI violated its patents and refuses to license its software on PSI systems, while PSI alleges that IBM is violating anti-trust laws. In October of 2007, PSI has additionally filed a complaint with the EU concerning IBM anti-competitive behavior in the European mainframe market.[9] In July 2008 IBM acquired PSI and both companies dropped their lawsuits against each other.[10] The European Union, however, has not stated it has dropped its investigation.[citation needed]
History
several manufacturers produced mainframe computers from the late 1950s through the 1970s. The group of manufacturers was first known as "IBM and the Seven Dwarfs": IBM, Burroughs, UNIVAC, NCR, Control Data, Honeywell, General Electric and RCA. Later, shrinking, it was referred to as IBM and the BUNCH. IBM's dominance grew out of their 700/7000 series and, later, the development of the 360 series mainframes. The latter architecture has continued to evolve into their current zSeries/z9 mainframes which, along with the then Burroughs and now Unisys MCP-based mainframes, are among the few mainframe architectures still extant that can trace their roots to this early period. That said, while they can still run 24-bit System/360 code, the 64-bit zSeries and System z9 CMOS servers have nothing physically in common with the older systems. Notable manufacturers outside the USA were Siemens and Telefunken in Germany, ICL in the United Kingdom, and Fujitsu, Hitachi, Oki, and NEC in Japan. The Soviet Union and Warsaw Pact countries manufactured close copies of IBM mainframes during the Cold War; the Strela is an example of an independently designed Soviet computer.
Shrinking demand and tough competition caused a shakeout in the market in the early 1980s — RCA sold out to UNIVAC and GE also left; Honeywell was bought out by Bull; UNIVAC became a division of Sperry, which later merged with Burroughs to form Unisys Corporation in 1986. In 1991, AT&T briefly owned NCR. During the same period, companies found that servers based on microcomputer designs could be deployed at a fraction of the acquisition price and offer local users much greater control over their own systems given the IT policies and practices at that time. Terminals used for interacting with mainframe systems were gradually replaced by personal computers. Consequently, demand plummeted and new mainframe installations were restricted mainly to financial services and government. In the early 1990s, there was a consensus among industry analysts that the mainframe was a dying market as mainframe platforms were increasingly replaced by personal computer networks.
That trend started to turn around in the late 1990s as corporations found new uses for their existing mainframes and as the price of data networking collapsed in most parts of the world. The growth of e-business also dramatically increased the number of back-end transactions processed by mainframe software as well as the size and throughput of databases. Another factor currently increasing mainframe use is the development of the Linux operating system, which can run on many mainframe systems, typically in virtual machines. Linux allows users to take advantage of open source software combined with mainframe hardware RAS. Rapid expansion and development in emerging markets, particularly China, is also spurring major mainframe investments to solve exceptionally difficult computing problems, e.g. providing unified, extremely high volume online transaction processing databases for 1 billion consumers across multiple industries (banking, insurance, credit reporting, government services, etc.)
Mainframes vs. supercomputers
The distinction between supercomputers and mainframes is not a hard and fast one, but supercomputers generally focus on problems which are limited by calculation speed while mainframes focus on problems which are limited by input/output and reliability ("throughput computing") and on solving multiple business problems concurrently (mixed workload). The differences and similarities include:
Both types of systems offer parallel processing. Supercomputers typically expose it to the programmer in complex manners, while mainframes typically use it to run multiple tasks. One result of this difference is that adding processors to a mainframe often speeds up the entire workload transparently.
Supercomputers are optimized for complicated computations that take place largely in memory, while mainframes are optimized for comparatively simple computations involving huge amounts of external data. For example, weather forecasting is suited to supercomputers, and insurance business or payroll processing applications are more suited to mainframes.
Supercomputers are often purpose-built for one or a very few specific institutional tasks (e.g. simulation and modeling). Mainframes typically handle a wider variety of tasks (e.g. data processing, warehousing). Consequently, most supercomputers can be one-off designs, whereas mainframes typically form part of a manufacturer's standard model lineup.
Mainframes tend to have numerous ancillary service processors assisting their main central processors (for cryptographic support, I/O handling, monitoring, memory handling, etc.) so that the actual "processor count" is much higher than would otherwise be obvious. Supercomputer design tends not to include as many service processors since they don't appreciably add to raw number-crunching power.
There has been some blurring of the term "mainframe," with some PC and server vendors referring to their systems as "mainframes" or "mainframe-like." This is not widely accepted and the market generally recognizes that mainframes are genuinely and demonstrably different
Speed and performance
The CPU speed of mainframes has historically been measured in millions of instructions per second (MIPS). MIPS have been used as an oversimplified comparative rating of the speed and capacity of mainframes. The smallest System z9 IBM mainframes today run at about 26 MIPS and the largest System z10 at about 30,657 MIPS — a 1 to 1179 performance capacity ratio. IBM's Parallel Sysplex technology can join up to 32 of these systems, making them behave like a single, logical computing facility of as much as about 981,024 MIPS.
The MIPS measurement has long been known to be misleading and has often been parodied as "Meaningless Indicator of Processor Speed." The complex CPU architectures of modern mainframes have reduced the relevance of MIPS ratings to the actual number of instructions executed. Likewise, the modern "balanced performance" system designs focus both on CPU power and on I/O capacity, and virtualization capabilities make comparative measurements even more difficult. See benchmark (computing) for a brief discussion of the difficulties in benchmarking such systems. IBM has long published a set of LSPR (Large System Performance Reference) ratio tables for mainframes that take into account different types of workloads and are a more representative measurement of several categories of mainframe workloads. However, these comparisons are not available for non-IBM systems and cannot be directly used for cross-platform comparisons. It takes a fair amount of work (and maybe guesswork) for users to determine what type of workload they have and then apply only the LSPR values most relevant to them. Also, IBM does not measure all workloads on all possible configurations, so some estimates are inaccurate. Current processors can have up to 64 CPU's, but LSPR has not measured any over 32 for a single OS instance, instead partitioning the box into multiple z/OS instances in LSPR tables with 56 and 64-CPU systems.
To give some idea of real world experience, a single mainframe may execute the equivalent of 1, 5, 50, 100, or even more distributed processors' worth of business activity, however this is highly dependent on the workload. Merely counting processors to compare server platforms is extremely perilous
Tuesday, October 7, 2008
JAVA PLATFORM
Java refers to a number of computer software products and specifications from Sun Microsystems that together provide a system for developing application software and deploying it in a cross-platform environment. Java is used in a wide variety of computing platforms spanning from embedded devices and mobile phones on the low end to enterprise servers and supercomputers on the high end. Java is nearly ubiquitous in mobile phones, Web servers and enterprise applications, and while less common on desktop computers, Java applets are often used to provide improved functionality while browsing the World Wide Web.
Writing in the Java programming language is the primary way to produce code that will be deployed as Java bytecode, though there are compilers available for other languages such as JavaScript, Python and Ruby, and a native Java scripting language called Groovy. Java syntax borrows heavily from C and C++ but it eliminates certain low-level constructs such as pointers and has a very simple memory model where every object is allocated on the heap and all variables of object types are references. Memory management is handled through integrated automatic garbage collection performed by the Java Virtual Machine (JVM).
On 13 November 2006, Sun Microsystems made the bulk of its implementation of Java available under the GNU General Public License, although there are still a few parts distributed as precompiled binaries due to intellectual property restrictions
[edit] Platform
The Java platform is the name for a bundle of related programs, or platform, from Sun which allow for developing and running programs written in the Java programming language. The platform is not specific to any one processor or operating system, but rather an execution engine (called a virtual machine) and a compiler with a set of standard libraries that are implemented for various hardware and operating systems so that Java programs can run identically on all of them.
Different "editions" of the platform are available, including:
Java Card: refers to a technology that allows small Java-based applications (applets) to be run securely on smart cards and similar small memory footprint devices.
Java ME (Micro Edition): Specifies several different sets of libraries (known as profiles) for devices which are sufficiently limited that supplying the full set of Java libraries would take up unacceptably large amounts of storage.
Java SE (Standard Edition): For general purpose use on desktop PCs, servers and similar devices.
Java EE (Enterprise Edition): Java SE plus various APIs useful for multi-tier client-server enterprise applications.
As of September 2008[update], the current version of the Java Platform is specified as either 1.6.0 or 6 (both refer to the same version). Version 6 is the product version, while 1.6.0 is the developer version.
The Java Platform consists of several programs, each of which provides a distinct portion of its overall capabilities. For example, the Java compiler, which converts Java source code into Java bytecode (an intermediate language for the Java Virtual Machine (JVM)), is provided as part of the Java Development Kit (JDK). The Java Runtime Environment (JRE), complementing the JVM with a just-in-time (JIT) compiler, converts intermediate bytecode into native machine code on the fly. Also supplied are extensive libraries (pre-compiled into Java bytecode) containing reusable code, as well as numerous ways to deploy Java applications, including embedding them in a web page as an applet.
There are several other components, some available only in certain editions.
Java Virtual Machine
The heart of the Java Platform is the concept of a "virtual machine" that executes Java bytecode programs. This bytecode is the same no matter what hardware or operating system the program is running under. There is a JIT compiler within the Java Virtual Machine, or JVM. The JIT compiler translates the Java bytecode into native processor instructions at run-time and caches the native code in memory during execution.
The use of bytecode as an intermediate language permits Java programs to run on any platform that has a virtual machine available. The use of a JIT compiler means that Java applications, after a short delay during loading and once they have "warmed up" by being all or mostly JIT-compiled, tend to run about as fast as native programs. Since JRE version 1.2, Sun's JVM implementation has included a just-in-time compiler instead of an interpreter.
Although Java programs are platform independent, the code of the Java Virtual Machine (JVM) that execute these programs is not: Every supported operating platform has its own JVM.
Class libraries
In most modern operating systems, a large body of reusable code is provided to simplify the programmer's job. This code is typically provided as a set of dynamically loadable libraries that applications can call at runtime. Because the Java Platform is not dependent on any specific operating system, applications cannot rely on any of the pre-existing OS libraries. Instead, the Java Platform provides a comprehensive set of its own standard class libraries containing much of the same reusable functions commonly found in modern operating systems.
The Java class libraries serve three purposes within the Java Platform. First, like other standard code libraries, the Java libraries provide the programmer a well-known set of functions to perform common tasks, such as maintaining lists of items or performing complex string parsing. Second, the class libraries provide an abstract interface to tasks that would normally depend heavily on the hardware and operating system. Tasks such as network access and file access are often heavily intertwined with the distinctive implementations of each platform. The Java java.net and java.io libraries implement an abstraction layer in native OS code, then provide a standard interface for the Java applications to perform those tasks. Finally, when some underlying platform does not support all of the features a Java application expects, the class libraries work to gracefully handle the absent components, either by emulation to provide a substitute, or at least by providing a consistent way to check for the presence of a specific feature.
Languages
The word Java, by itself, usually refers to the Java programming language which was designed for use with the Java Platform. Programming languages are typically outside of the scope of the phrase "platform", although the Java programming language is listed as a core part of the Java platform. The language and runtime are therefore commonly considered a single unit.
Nevertheless, third parties have produced a number of compilers or interpreters which target the JVM. Some of these are for existing languages, while others are for extensions to the Java language itself. These include:
Groovy
Jython, a Python interpreter that include jythonc, a Python-to-Java bytecode compiler
Scala
JRuby, a Ruby interpreter
Rhino, a JavaScript interpreter
Kawa and SISC, both Scheme interpreters
ColdFusion, a dynamic language specialized for Web development which is compiled to Java bytecode.
Similar platforms
The success of Java and its write once, run anywhere concept has led to other similar efforts, notably the Microsoft .NET platform, appearing since 2002, which incorporates many of the successful aspects of Java. .NET in its complete form (Microsoft's implementation) is currently only fully available on Windows platforms, whereas Java is fully available on many platforms. .NET was built from the ground-up to support multiple programming languages, while the Java platform was initially built to support only the Java language (although many other languages have been made for JVM since).
.NET includes a Java-like language called Visual J# (formerly known as J++) that is not compatible with the Java specification, and the associated class library mostly dates to the old JDK 1.1 version of the language; for these reasons, it is more a transitional language to switch from Java to the Microsoft .NET platform, than a first class Microsoft .NET language. Visual J# has been discontinued with the release of Microsoft Visual Studio 2008.
Java Development Kit
The Java Development Kit (JDK) is a Sun product aimed at Java developers. Since the introduction of Java, it has been by far the most widely used Java SDK. It contains a Java compiler and a number of other important development tools as well as a full copy of the Java Runtime Environment.
History
The Java platform and language began as an internal project at Sun Microsystems in December 1990, providing an alternative to the C++/C programming languages. Engineer Patrick Naughton had become increasingly frustrated with the state of Sun's C++ and C APIs (application programming interfaces) and tools. While considering moving to NeXT, Naughton was offered a chance to work on new technology and thus the Stealth Project was started.
The Stealth Project was soon renamed to the Green Project with James Gosling and Mike Sheridan joining Naughton. Together with other engineers, they began work in a small office on Sand Hill Road in Menlo Park, California. They were attempting to develop a new technology for programming next generation smart appliances, which Sun expected to be a major new opportunity.
The team originally considered using C++, but it was rejected for several reasons. Because they were developing an embedded system with limited resources, they decided that C++ demanded too large a footprint and that its complexity led to developer errors. The language's lack of garbage collection meant that programmers had to manually manage system memory, a challenging and error-prone task. The team was also troubled by the language's lack of portable facilities for security, distributed programming, and threading. Finally, they wanted a platform that could be easily ported to all types of devices.
Bill Joy had envisioned a new language combining the best of Mesa and C. In a paper called Further, he proposed to Sun that its engineers should produce an object-oriented environment based on C++. Initially, Gosling attempted to modify and extend C++ (which he referred to as "C++ ++ --") but soon abandoned that in favor of creating an entirely new language, which he called Oak, after the tree that stood just outside his office.
By the summer of 1992, they were able to demonstrate portions of the new platform including the Green OS, the Oak language, the libraries, and the hardware. Their first attempt, demonstrated on September 3, 1992, focused on building a PDA device named Star7 which had a graphical interface and a smart agent called "Duke" to assist the user. In November of that year, the Green Project was spun off to become firstperson, a wholly owned subsidiary of Sun Microsystems, and the team relocated to Palo Alto, California. The firstperson team was interested in building highly interactive devices, and when Time Warner issued an RFP for a set-top box, firstperson changed their target and responded with a proposal for a set-top box platform. However, the cable industry felt that their platform gave too much control to the user and firstperson lost their bid to SGI. An additional deal with The 3DO Company for a set-top box also failed to materialize. Unable to generate interest within the TV industry, the company was rolled back into Sun.
Java meets the Internet
Java Web Start allows provisioning applications over the WebIn June and July 1994, after three days of brainstorming with John Gage, the Director of Science for Sun, Gosling, Joy, Naughton, Wayne Rosing, and Eric Schmidt, the team re-targeted the platform for the World Wide Web. They felt that with the advent of the first graphical web browser, Mosaic, the Internet was on its way to evolving into the same highly interactive medium that they had envisioned for cable TV. As a prototype, Naughton wrote a small browser, WebRunner, later renamed HotJava.
That year, the language was renamed Java after a trademark search revealed that Oak was used by Oak Technology, a manufacturer of video adaptor cards. The name Java was coined at a local coffee shop frequented by some of the members.[citation needed]
In October 1994, HotJava and the Java platform were demonstrated for some of the Sun executives. Java 1.0a was made available for download in 1994, but the first public release of Java and the HotJava browser was on 23 May 1995, announced by Gage at the SunWorld conference. His announcement was accompanied by a surprise announcement by Marc Andreessen, Executive Vice President of Netscape Communications Corporation, that Netscape browsers would be including Java support. On 9 January 1996, the JavaSoft group was formed by Sun Microsystems in order to develop the technology.
Version history
The Java language has undergone several changes since JDK (Java Development Kit) 1.0 was released on (January 23, 1996), as well as numerous additions of classes and packages to the standard library. Since J2SE 1.4, the evolution of the Java Language has been governed by the Java Community Process (JCP), which uses Java Specification Requests (JSRs) to propose and specify additions and changes to the Java platform. The language is specified by the Java Language Specification (JLS); changes to the JLS are managed under JSR 901.
JDK 1.1 was released on February 19, 1997. Major additions included an extensive retooling of the AWT event model, inner classes added to the language, JavaBeans and JDBC.
J2SE 1.2 (December 8, 1998) — Codename Playground. This and subsequent releases through J2SE 5.0 were rebranded Java 2 and the version name "J2SE" (Java 2 Platform, Standard Edition) replaced JDK to distinguish the base platform from J2EE (Java 2 Platform, Enterprise Edition) and J2ME (Java 2 Platform, Micro Edition). Major additions included reflection, a Collections framework, Java IDL (an IDL implementation for CORBA interoperability), and the integration of the Swing graphical API into the core classes. a Java Plug-in was released, and Sun's JVM was equipped with a JIT compiler for the first time.
J2SE 1.3 (May 8, 2000) — Codename Kestrel. Notable changes included the bundling of the HotSpot JVM (the HotSpot JVM was first released in April, 1999 for the J2SE 1.2 JVM), JavaSound, Java Naming and Directory Interface (JNDI) and Java Platform Debugger Architecture (JPDA).
J2SE 1.4 (February 6, 2002) — Codename Merlin. This was the first release of the Java platform developed under the Java Community Process as JSR 59. Major changes included regular expressions modeled after Perl, exception chaining, an integrated XML parser and XSLT processor (JAXP), and Java Web Start.
J2SE 5.0 (September 30, 2004) — Codename Tiger. Originally numbered 1.5, which is still used as the internal version number. Developed under JSR 176, Tiger added a number of significant new language features including the for-each loop, generics, autoboxing and var-args.
The current version, Java SE 6 (December 11, 2006) — Codename Mustang — is bundled with a database manager, facilitates the use of scripting languages (currently JavaScript using Mozilla's Rhino engine) with the JVM and has Visual Basic language support. As of this version, Sun replaced the name "J2SE" with Java SE and dropped the ".0" from the version number. Other major changes include scripting language support, support for pluggable annotations (JSR 269), lots of GUI improvements, including native UI enhancements to support the look and feel of Windows Vista, and improvements to the Java Platform Debugger Architecture (JPDA) & JVM Tool Interface for better monitoring and troubleshooting
Java SE 7 — Codename Dolphin. This is in the early planning stages. The Dolphin Project started up in August 2006, with release estimated in 2008. New builds including enhancements and bug fixes are released approximately weekly.
In addition to the language changes, much more dramatic changes have been made to the Java class library over the years, which has grown from a few hundred classes in JDK 1.0 to over three thousand in J2SE 5.0. Entire new APIs, such as Swing and Java2D, have been introduced, and many of the original JDK 1.0 classes and methods have been deprecated.
Usage
Desktop use
According to Sun, the Java Runtime Environment is found on over 700 million PCs. Microsoft has not bundled a Java Runtime Environment (JRE) with its operating systems since Sun Microsystems sued Microsoft for adding Windows-specific classes to the bundled Java runtime environment, and for making the new classes available through Visual J++. A Java runtime environment is bundled with Apple's Mac OS X, and many Linux distributions include the partially compatible free software package GNU Classpath.
Some Java applications are in fairly widespread desktop use, including the NetBeans and Eclipse integrated development environments, and file sharing clients such as LimeWire and Vuze. Java is also used in the MATLAB mathematics programming environment, both for rendering the user interface and as part of the core system.
Mobile devices
Java ME has become popular in mobile devices, where it competes with Symbian, BREW, and the .NET Compact Framework.
The diversity of mobile phone manufacturers has led to a need for new unified standards so programs can run on phones from different suppliers - MIDP. The first standard was MIDP 1, which assumed a small screen size, no access to audio, and a 32kB program limit. The more recent MIDP 2 allows access to audio, and up to 64kB for the program size. With handset designs improving more rapidly than the standards, some manufacturers relax some limitations in the standards, for example, maximum program size
Writing in the Java programming language is the primary way to produce code that will be deployed as Java bytecode, though there are compilers available for other languages such as JavaScript, Python and Ruby, and a native Java scripting language called Groovy. Java syntax borrows heavily from C and C++ but it eliminates certain low-level constructs such as pointers and has a very simple memory model where every object is allocated on the heap and all variables of object types are references. Memory management is handled through integrated automatic garbage collection performed by the Java Virtual Machine (JVM).
On 13 November 2006, Sun Microsystems made the bulk of its implementation of Java available under the GNU General Public License, although there are still a few parts distributed as precompiled binaries due to intellectual property restrictions
[edit] Platform
The Java platform is the name for a bundle of related programs, or platform, from Sun which allow for developing and running programs written in the Java programming language. The platform is not specific to any one processor or operating system, but rather an execution engine (called a virtual machine) and a compiler with a set of standard libraries that are implemented for various hardware and operating systems so that Java programs can run identically on all of them.
Different "editions" of the platform are available, including:
Java Card: refers to a technology that allows small Java-based applications (applets) to be run securely on smart cards and similar small memory footprint devices.
Java ME (Micro Edition): Specifies several different sets of libraries (known as profiles) for devices which are sufficiently limited that supplying the full set of Java libraries would take up unacceptably large amounts of storage.
Java SE (Standard Edition): For general purpose use on desktop PCs, servers and similar devices.
Java EE (Enterprise Edition): Java SE plus various APIs useful for multi-tier client-server enterprise applications.
As of September 2008[update], the current version of the Java Platform is specified as either 1.6.0 or 6 (both refer to the same version). Version 6 is the product version, while 1.6.0 is the developer version.
The Java Platform consists of several programs, each of which provides a distinct portion of its overall capabilities. For example, the Java compiler, which converts Java source code into Java bytecode (an intermediate language for the Java Virtual Machine (JVM)), is provided as part of the Java Development Kit (JDK). The Java Runtime Environment (JRE), complementing the JVM with a just-in-time (JIT) compiler, converts intermediate bytecode into native machine code on the fly. Also supplied are extensive libraries (pre-compiled into Java bytecode) containing reusable code, as well as numerous ways to deploy Java applications, including embedding them in a web page as an applet.
There are several other components, some available only in certain editions.
Java Virtual Machine
The heart of the Java Platform is the concept of a "virtual machine" that executes Java bytecode programs. This bytecode is the same no matter what hardware or operating system the program is running under. There is a JIT compiler within the Java Virtual Machine, or JVM. The JIT compiler translates the Java bytecode into native processor instructions at run-time and caches the native code in memory during execution.
The use of bytecode as an intermediate language permits Java programs to run on any platform that has a virtual machine available. The use of a JIT compiler means that Java applications, after a short delay during loading and once they have "warmed up" by being all or mostly JIT-compiled, tend to run about as fast as native programs. Since JRE version 1.2, Sun's JVM implementation has included a just-in-time compiler instead of an interpreter.
Although Java programs are platform independent, the code of the Java Virtual Machine (JVM) that execute these programs is not: Every supported operating platform has its own JVM.
Class libraries
In most modern operating systems, a large body of reusable code is provided to simplify the programmer's job. This code is typically provided as a set of dynamically loadable libraries that applications can call at runtime. Because the Java Platform is not dependent on any specific operating system, applications cannot rely on any of the pre-existing OS libraries. Instead, the Java Platform provides a comprehensive set of its own standard class libraries containing much of the same reusable functions commonly found in modern operating systems.
The Java class libraries serve three purposes within the Java Platform. First, like other standard code libraries, the Java libraries provide the programmer a well-known set of functions to perform common tasks, such as maintaining lists of items or performing complex string parsing. Second, the class libraries provide an abstract interface to tasks that would normally depend heavily on the hardware and operating system. Tasks such as network access and file access are often heavily intertwined with the distinctive implementations of each platform. The Java java.net and java.io libraries implement an abstraction layer in native OS code, then provide a standard interface for the Java applications to perform those tasks. Finally, when some underlying platform does not support all of the features a Java application expects, the class libraries work to gracefully handle the absent components, either by emulation to provide a substitute, or at least by providing a consistent way to check for the presence of a specific feature.
Languages
The word Java, by itself, usually refers to the Java programming language which was designed for use with the Java Platform. Programming languages are typically outside of the scope of the phrase "platform", although the Java programming language is listed as a core part of the Java platform. The language and runtime are therefore commonly considered a single unit.
Nevertheless, third parties have produced a number of compilers or interpreters which target the JVM. Some of these are for existing languages, while others are for extensions to the Java language itself. These include:
Groovy
Jython, a Python interpreter that include jythonc, a Python-to-Java bytecode compiler
Scala
JRuby, a Ruby interpreter
Rhino, a JavaScript interpreter
Kawa and SISC, both Scheme interpreters
ColdFusion, a dynamic language specialized for Web development which is compiled to Java bytecode.
Similar platforms
The success of Java and its write once, run anywhere concept has led to other similar efforts, notably the Microsoft .NET platform, appearing since 2002, which incorporates many of the successful aspects of Java. .NET in its complete form (Microsoft's implementation) is currently only fully available on Windows platforms, whereas Java is fully available on many platforms. .NET was built from the ground-up to support multiple programming languages, while the Java platform was initially built to support only the Java language (although many other languages have been made for JVM since).
.NET includes a Java-like language called Visual J# (formerly known as J++) that is not compatible with the Java specification, and the associated class library mostly dates to the old JDK 1.1 version of the language; for these reasons, it is more a transitional language to switch from Java to the Microsoft .NET platform, than a first class Microsoft .NET language. Visual J# has been discontinued with the release of Microsoft Visual Studio 2008.
Java Development Kit
The Java Development Kit (JDK) is a Sun product aimed at Java developers. Since the introduction of Java, it has been by far the most widely used Java SDK. It contains a Java compiler and a number of other important development tools as well as a full copy of the Java Runtime Environment.
History
The Java platform and language began as an internal project at Sun Microsystems in December 1990, providing an alternative to the C++/C programming languages. Engineer Patrick Naughton had become increasingly frustrated with the state of Sun's C++ and C APIs (application programming interfaces) and tools. While considering moving to NeXT, Naughton was offered a chance to work on new technology and thus the Stealth Project was started.
The Stealth Project was soon renamed to the Green Project with James Gosling and Mike Sheridan joining Naughton. Together with other engineers, they began work in a small office on Sand Hill Road in Menlo Park, California. They were attempting to develop a new technology for programming next generation smart appliances, which Sun expected to be a major new opportunity.
The team originally considered using C++, but it was rejected for several reasons. Because they were developing an embedded system with limited resources, they decided that C++ demanded too large a footprint and that its complexity led to developer errors. The language's lack of garbage collection meant that programmers had to manually manage system memory, a challenging and error-prone task. The team was also troubled by the language's lack of portable facilities for security, distributed programming, and threading. Finally, they wanted a platform that could be easily ported to all types of devices.
Bill Joy had envisioned a new language combining the best of Mesa and C. In a paper called Further, he proposed to Sun that its engineers should produce an object-oriented environment based on C++. Initially, Gosling attempted to modify and extend C++ (which he referred to as "C++ ++ --") but soon abandoned that in favor of creating an entirely new language, which he called Oak, after the tree that stood just outside his office.
By the summer of 1992, they were able to demonstrate portions of the new platform including the Green OS, the Oak language, the libraries, and the hardware. Their first attempt, demonstrated on September 3, 1992, focused on building a PDA device named Star7 which had a graphical interface and a smart agent called "Duke" to assist the user. In November of that year, the Green Project was spun off to become firstperson, a wholly owned subsidiary of Sun Microsystems, and the team relocated to Palo Alto, California. The firstperson team was interested in building highly interactive devices, and when Time Warner issued an RFP for a set-top box, firstperson changed their target and responded with a proposal for a set-top box platform. However, the cable industry felt that their platform gave too much control to the user and firstperson lost their bid to SGI. An additional deal with The 3DO Company for a set-top box also failed to materialize. Unable to generate interest within the TV industry, the company was rolled back into Sun.
Java meets the Internet
Java Web Start allows provisioning applications over the WebIn June and July 1994, after three days of brainstorming with John Gage, the Director of Science for Sun, Gosling, Joy, Naughton, Wayne Rosing, and Eric Schmidt, the team re-targeted the platform for the World Wide Web. They felt that with the advent of the first graphical web browser, Mosaic, the Internet was on its way to evolving into the same highly interactive medium that they had envisioned for cable TV. As a prototype, Naughton wrote a small browser, WebRunner, later renamed HotJava.
That year, the language was renamed Java after a trademark search revealed that Oak was used by Oak Technology, a manufacturer of video adaptor cards. The name Java was coined at a local coffee shop frequented by some of the members.[citation needed]
In October 1994, HotJava and the Java platform were demonstrated for some of the Sun executives. Java 1.0a was made available for download in 1994, but the first public release of Java and the HotJava browser was on 23 May 1995, announced by Gage at the SunWorld conference. His announcement was accompanied by a surprise announcement by Marc Andreessen, Executive Vice President of Netscape Communications Corporation, that Netscape browsers would be including Java support. On 9 January 1996, the JavaSoft group was formed by Sun Microsystems in order to develop the technology.
Version history
The Java language has undergone several changes since JDK (Java Development Kit) 1.0 was released on (January 23, 1996), as well as numerous additions of classes and packages to the standard library. Since J2SE 1.4, the evolution of the Java Language has been governed by the Java Community Process (JCP), which uses Java Specification Requests (JSRs) to propose and specify additions and changes to the Java platform. The language is specified by the Java Language Specification (JLS); changes to the JLS are managed under JSR 901.
JDK 1.1 was released on February 19, 1997. Major additions included an extensive retooling of the AWT event model, inner classes added to the language, JavaBeans and JDBC.
J2SE 1.2 (December 8, 1998) — Codename Playground. This and subsequent releases through J2SE 5.0 were rebranded Java 2 and the version name "J2SE" (Java 2 Platform, Standard Edition) replaced JDK to distinguish the base platform from J2EE (Java 2 Platform, Enterprise Edition) and J2ME (Java 2 Platform, Micro Edition). Major additions included reflection, a Collections framework, Java IDL (an IDL implementation for CORBA interoperability), and the integration of the Swing graphical API into the core classes. a Java Plug-in was released, and Sun's JVM was equipped with a JIT compiler for the first time.
J2SE 1.3 (May 8, 2000) — Codename Kestrel. Notable changes included the bundling of the HotSpot JVM (the HotSpot JVM was first released in April, 1999 for the J2SE 1.2 JVM), JavaSound, Java Naming and Directory Interface (JNDI) and Java Platform Debugger Architecture (JPDA).
J2SE 1.4 (February 6, 2002) — Codename Merlin. This was the first release of the Java platform developed under the Java Community Process as JSR 59. Major changes included regular expressions modeled after Perl, exception chaining, an integrated XML parser and XSLT processor (JAXP), and Java Web Start.
J2SE 5.0 (September 30, 2004) — Codename Tiger. Originally numbered 1.5, which is still used as the internal version number. Developed under JSR 176, Tiger added a number of significant new language features including the for-each loop, generics, autoboxing and var-args.
The current version, Java SE 6 (December 11, 2006) — Codename Mustang — is bundled with a database manager, facilitates the use of scripting languages (currently JavaScript using Mozilla's Rhino engine) with the JVM and has Visual Basic language support. As of this version, Sun replaced the name "J2SE" with Java SE and dropped the ".0" from the version number. Other major changes include scripting language support, support for pluggable annotations (JSR 269), lots of GUI improvements, including native UI enhancements to support the look and feel of Windows Vista, and improvements to the Java Platform Debugger Architecture (JPDA) & JVM Tool Interface for better monitoring and troubleshooting
Java SE 7 — Codename Dolphin. This is in the early planning stages. The Dolphin Project started up in August 2006, with release estimated in 2008. New builds including enhancements and bug fixes are released approximately weekly.
In addition to the language changes, much more dramatic changes have been made to the Java class library over the years, which has grown from a few hundred classes in JDK 1.0 to over three thousand in J2SE 5.0. Entire new APIs, such as Swing and Java2D, have been introduced, and many of the original JDK 1.0 classes and methods have been deprecated.
Usage
Desktop use
According to Sun, the Java Runtime Environment is found on over 700 million PCs. Microsoft has not bundled a Java Runtime Environment (JRE) with its operating systems since Sun Microsystems sued Microsoft for adding Windows-specific classes to the bundled Java runtime environment, and for making the new classes available through Visual J++. A Java runtime environment is bundled with Apple's Mac OS X, and many Linux distributions include the partially compatible free software package GNU Classpath.
Some Java applications are in fairly widespread desktop use, including the NetBeans and Eclipse integrated development environments, and file sharing clients such as LimeWire and Vuze. Java is also used in the MATLAB mathematics programming environment, both for rendering the user interface and as part of the core system.
Mobile devices
Java ME has become popular in mobile devices, where it competes with Symbian, BREW, and the .NET Compact Framework.
The diversity of mobile phone manufacturers has led to a need for new unified standards so programs can run on phones from different suppliers - MIDP. The first standard was MIDP 1, which assumed a small screen size, no access to audio, and a 32kB program limit. The more recent MIDP 2 allows access to audio, and up to 64kB for the program size. With handset designs improving more rapidly than the standards, some manufacturers relax some limitations in the standards, for example, maximum program size
JAVA PROGRAMMING/NETWORKING
Prior to modern networking solutions there existed workstations that were connected to a massive Mainframe computer that was solely responsible for memory management, processes and almost everything. The workstations would just render the information sent in from the Mainframe console.
But in the mid 90's, with the prices of Unix servers dropping, the trend was moving away from Mainframe computing toward Client-Server computing. This would enable rich clients to be developed on workstations while they would communicate with a centralized server, serving computers connected to it, to either communicate with other workstations also connected to it or it would request for database access or business logic stored on the server itself. The workstations were called clients.
This form of computing gave rise to the notion of the Front-end and Back-end programming. In it's hey-day, Java came up with different ways of making networking between computers possible. In this chapter, we would be looking at some of these ways. Listed below are two of the frameworks that Java uses to enable network programming. We would be exploring both of these in this chapter.
But in the mid 90's, with the prices of Unix servers dropping, the trend was moving away from Mainframe computing toward Client-Server computing. This would enable rich clients to be developed on workstations while they would communicate with a centralized server, serving computers connected to it, to either communicate with other workstations also connected to it or it would request for database access or business logic stored on the server itself. The workstations were called clients.
This form of computing gave rise to the notion of the Front-end and Back-end programming. In it's hey-day, Java came up with different ways of making networking between computers possible. In this chapter, we would be looking at some of these ways. Listed below are two of the frameworks that Java uses to enable network programming. We would be exploring both of these in this chapter.
JAVA PROGRAMMING REFLECTION
Reflection is a new concept in Java, and did not exist in classical compiled languages like C, and C++. The idea is to discover an object's attributes and its methods progrematically.
Reflection is the mechanism by which Java exposes the features of a class during runtime, allowing Java programs to enumerate and access a class' methods, fields, and constructors as objects. In other words, there are object based mirrors which reflect the Java object model, and you can use these objects to access an object's features using runtime API constructs instead of compile time language constructs.
Each object instance has a getClass() method, inherited from java.lang.Object, which returns an object with the runtime representation of that object's class; this object is an instance of the java.lang.Class This object in turn has methods which return the fields, methods, constructors, superclass, and other properties of that class.
You can use these reflection objects to access fields, invoke methods, or instantiate instances, all without having compile time dependencies on those features. The Java runtime provides the corresponding classes for reflection. Most of the Java classes which support reflection are in the java.lang.reflect package.
Reflection is most useful for performing dynamic operations with Java - operations which are not hard coded into a source program but which are determined at run time. One of the most important aspects of reflection is dynamic class loading.
Reflection is the mechanism by which Java exposes the features of a class during runtime, allowing Java programs to enumerate and access a class' methods, fields, and constructors as objects. In other words, there are object based mirrors which reflect the Java object model, and you can use these objects to access an object's features using runtime API constructs instead of compile time language constructs.
Each object instance has a getClass() method, inherited from java.lang.Object, which returns an object with the runtime representation of that object's class; this object is an instance of the java.lang.Class This object in turn has methods which return the fields, methods, constructors, superclass, and other properties of that class.
You can use these reflection objects to access fields, invoke methods, or instantiate instances, all without having compile time dependencies on those features. The Java runtime provides the corresponding classes for reflection. Most of the Java classes which support reflection are in the java.lang.reflect package.
Reflection is most useful for performing dynamic operations with Java - operations which are not hard coded into a source program but which are determined at run time. One of the most important aspects of reflection is dynamic class loading.
DESIGN PATTERN
A design pattern is not a finished design, it is a description of a solution to a common problem. A design pattern can be reused in multiple applications, and that is the main advantage of using it. It can also be seen as a template for how to solve a problem that can occur in many different situations and/or applications. It is not code reuse as it usually does not specify code, but code can be easily created from a design pattern. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
Each design pattern consist of the following part:
Problem/requirement
To create a design pattern, we need to go through a mini analysis design and may be coding to test out the solution. This section state the requirements the problem we want to solve. This is usually a common problem that will occur in more than one application.
Forces
This section state the technological boundaries, that helps and guides the creation of the solution.
Solution
This section describes how to write the code to solve the above problem. This is the design part of the design pattern. It may contain class diagrams, sequence diagrams, and or whatever is needed to describe how to code the solution.
A design pattern can be considered as block that can be placed in your design document, and you have to implement the design pattern with your application.
Using design patterns speeds up your design and helps to communicate your design to other team members.
Creational Patterns
Builder
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Factory Method
problem
We want to decide at run time what object is to be created based on some configuration or application parameter. When we write the code we do not know what class should be instantiated.
Solution
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Abstract Factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Prototype
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Structural Patterns
Adapter
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
Bridge
The Bridge Pattern is used to separate out the interface from its implementation. Doing this gives the flexibility so that both can vary independently.
Composite
Components that are individual objects and also can be collection of objects. A Composite pattern can represent both the conditions. In this pattern, one can develop tree structures for representing part-whole hierarchies.
Decorator
The decorator pattern helps to add behavior or responsibilities to an object. This is also called “Wrapper”.
Facade
A Facade pattern hides the complexities of the system and provides an interface to the client from where the client can access the system.
Dividing a system into subsystems helps reduce complexity. We need to minimize the communication and dependencies between subsystems. For this, we introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem.
Flyweight
It is a mechanism by which you can avoid creating a large number of object instances to represent the entire system. To decide if some part of a program is a candidate for using Flyweights, consider whether it is possible to remove some data from the class and make it extrinsic.
Proxy
It is used when you need to represent a complex with a simpler one. If creation of object is expensive, its creation can be postponed till the very need arises and till then, a simple object can represent it. This simple object is called the “Proxy” for the complex object.
Behavioral Patterns
Chain of Responsibility
Command
Scope
Object
Purpose
Behavioural
Intent
encapsulate the request for a service as an object
Applicability
to parameterize objects with an action to perform
to specify, queue, and execute requests at different times
for a history of requests
for multilevel undo/redo
Each design pattern consist of the following part:
Problem/requirement
To create a design pattern, we need to go through a mini analysis design and may be coding to test out the solution. This section state the requirements the problem we want to solve. This is usually a common problem that will occur in more than one application.
Forces
This section state the technological boundaries, that helps and guides the creation of the solution.
Solution
This section describes how to write the code to solve the above problem. This is the design part of the design pattern. It may contain class diagrams, sequence diagrams, and or whatever is needed to describe how to code the solution.
A design pattern can be considered as block that can be placed in your design document, and you have to implement the design pattern with your application.
Using design patterns speeds up your design and helps to communicate your design to other team members.
Creational Patterns
Builder
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Factory Method
problem
We want to decide at run time what object is to be created based on some configuration or application parameter. When we write the code we do not know what class should be instantiated.
Solution
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Abstract Factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Prototype
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Structural Patterns
Adapter
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
Bridge
The Bridge Pattern is used to separate out the interface from its implementation. Doing this gives the flexibility so that both can vary independently.
Composite
Components that are individual objects and also can be collection of objects. A Composite pattern can represent both the conditions. In this pattern, one can develop tree structures for representing part-whole hierarchies.
Decorator
The decorator pattern helps to add behavior or responsibilities to an object. This is also called “Wrapper”.
Facade
A Facade pattern hides the complexities of the system and provides an interface to the client from where the client can access the system.
Dividing a system into subsystems helps reduce complexity. We need to minimize the communication and dependencies between subsystems. For this, we introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem.
Flyweight
It is a mechanism by which you can avoid creating a large number of object instances to represent the entire system. To decide if some part of a program is a candidate for using Flyweights, consider whether it is possible to remove some data from the class and make it extrinsic.
Proxy
It is used when you need to represent a complex with a simpler one. If creation of object is expensive, its creation can be postponed till the very need arises and till then, a simple object can represent it. This simple object is called the “Proxy” for the complex object.
Behavioral Patterns
Chain of Responsibility
Command
Scope
Object
Purpose
Behavioural
Intent
encapsulate the request for a service as an object
Applicability
to parameterize objects with an action to perform
to specify, queue, and execute requests at different times
for a history of requests
for multilevel undo/redo
JAVA IDE
A Java IDE (Integrated Development Environment) is a software which enables the users to write and debug Java programmes easily. Some of them highlights keywords, some have popup menus for methods and attributes and thus help the users to do the stuff easily.
JAVA IDEsJCreator
JCreator is a simple and light weight JAVA IDE - it runs only on Windows platforms. It is very easy to install and starts quickly, as it is a native application. This is a good choice for beginners.
NetBeans
NetBeans is some what heavy IDE but helps a lot. Specially you can create Java applications for mobile devices easily with Mobility PacK in NetBeans. With Netbeans 6.0, the IDE has become one of the best available development tools, whether it be designing a Swing UI, building a mobile application, an enterprise application or using it as a platform for creating your own IDE.
Processing
Processing is an enhanced IDE. It adds some extra commands and a simplified programming model. This makes it much easier for beginners to start programming in Java. It was designed to help graphic artists learn a bit of programming without struggling too much. Processing runs on Windows, Linux and Mac platforms.
Among Other JAVA IDEs are
Eclipse
DrJava
BlueJ
jGRASP
J++
Visual J++
Visual Cafe
Zeus for Windows IDE
Kawa
JBuilder
JDeveloper (by Oracle, Freeware)
Gel
JIPE
jEdit
IntelliJ IDEA
JAVA IDEsJCreator
JCreator is a simple and light weight JAVA IDE - it runs only on Windows platforms. It is very easy to install and starts quickly, as it is a native application. This is a good choice for beginners.
NetBeans
NetBeans is some what heavy IDE but helps a lot. Specially you can create Java applications for mobile devices easily with Mobility PacK in NetBeans. With Netbeans 6.0, the IDE has become one of the best available development tools, whether it be designing a Swing UI, building a mobile application, an enterprise application or using it as a platform for creating your own IDE.
Processing
Processing is an enhanced IDE. It adds some extra commands and a simplified programming model. This makes it much easier for beginners to start programming in Java. It was designed to help graphic artists learn a bit of programming without struggling too much. Processing runs on Windows, Linux and Mac platforms.
Among Other JAVA IDEs are
Eclipse
DrJava
BlueJ
jGRASP
J++
Visual J++
Visual Cafe
Zeus for Windows IDE
Kawa
JBuilder
JDeveloper (by Oracle, Freeware)
Gel
JIPE
jEdit
IntelliJ IDEA
JAVA PROGRAMMING/EXCEPTIONS
In Java, there are two main flow of code executions.
Normal main sequential code execution, the program doing what it meant to accomplish
Exception handling code execution, the main program flow was interrupted by an error or some other condition that prevent the continuation of the normal main sequential code execution.
Exception
Exceptions are Java's way of error handling. Whenever an unexpected condition occurs, an exception can be thrown with an exception object as a parameter. It means that the normal program control flow stops and the search for a catch block begins. If that is not found at the current method level the search continues at the caller method level, until a matching catch block is found. If none is found the exception will be handled by the JVM, and usually the java program terminates.
When a catch "matching" block is found, that block will be executed, the exception object is passed to the block as a parameter. Then normal program execution continues after the catch block. See Java exception handling syntax
Exception Object
This is the object that is "thrown" as a parameter from the error, and passed to the catch block. Exception object encapsulates the information about the error's location and its nature. All Exception objects must be inherited from the java.lang.Throwable. See the UML diagram below.
Matching rule
A thrown exception object can be caught by the catch keyword and specifying the exception object's class or its super-class.
Naming convention
It is good practice to add Exception to all exception classes. Also the name of the exception should be meaningful, should represent the problem. For example CustomerNotFoundException indicate that customer was not found.
Normal main sequential code execution, the program doing what it meant to accomplish
Exception handling code execution, the main program flow was interrupted by an error or some other condition that prevent the continuation of the normal main sequential code execution.
Exception
Exceptions are Java's way of error handling. Whenever an unexpected condition occurs, an exception can be thrown with an exception object as a parameter. It means that the normal program control flow stops and the search for a catch block begins. If that is not found at the current method level the search continues at the caller method level, until a matching catch block is found. If none is found the exception will be handled by the JVM, and usually the java program terminates.
When a catch "matching" block is found, that block will be executed, the exception object is passed to the block as a parameter. Then normal program execution continues after the catch block. See Java exception handling syntax
Exception Object
This is the object that is "thrown" as a parameter from the error, and passed to the catch block. Exception object encapsulates the information about the error's location and its nature. All Exception objects must be inherited from the java.lang.Throwable. See the UML diagram below.
Matching rule
A thrown exception object can be caught by the catch keyword and specifying the exception object's class or its super-class.
Naming convention
It is good practice to add Exception to all exception classes. Also the name of the exception should be meaningful, should represent the problem. For example CustomerNotFoundException indicate that customer was not found.
LANGUAGE FUNDAMENTALS
Language Fundamentals
This section introduces the fundamental elements of the Java programming language.
When learning a new language, the first step one must take is to learn its syntax rules and keywords. Combining the two, one creates statements, Programming Blocks, Classes, Interfaces, et al.
Use packages to avoid name collisions. To hide as much information as possible use the access modifiers properly.
Create methods that do one and if possible only one thing/task. If possible have separate method that changes the object state.
In an object oriented language, programs are run with objects; however, for ease of use and for historic reasons, Java has primitive types. Primitive Data Types only store values and have no methods. Primitive Types may be thought of as Raw Data and are usually embedded attributes inside objects or used as local variables in methods. Because primitive types are not subclasses of the object superclass, each type has a Wrapper Class which is a subclass of Object, and can thus be stored in a collection or returned as an object.
Java is a strong type checking language. There are two concepts regarding types and objects. One is the object type and the other the template/class the object was created from. When an object is created, the template/class is assigned to that object which can not be changed. Types of an object however can be changed by type casting. Types of an object is associated with the object reference that referencing the object and determines what operation can be performed on the object through that object reference. Assigning the value of one object reference to a different type of object reference is called type casting.
The most often used data structure in any language is a character string. For this reason java defines a special object that is String.
To aggregate same type java objects to an array, java has a special array object for that. Both java objects and primitive types can be aggregated to arrays
This section introduces the fundamental elements of the Java programming language.
When learning a new language, the first step one must take is to learn its syntax rules and keywords. Combining the two, one creates statements, Programming Blocks, Classes, Interfaces, et al.
Use packages to avoid name collisions. To hide as much information as possible use the access modifiers properly.
Create methods that do one and if possible only one thing/task. If possible have separate method that changes the object state.
In an object oriented language, programs are run with objects; however, for ease of use and for historic reasons, Java has primitive types. Primitive Data Types only store values and have no methods. Primitive Types may be thought of as Raw Data and are usually embedded attributes inside objects or used as local variables in methods. Because primitive types are not subclasses of the object superclass, each type has a Wrapper Class which is a subclass of Object, and can thus be stored in a collection or returned as an object.
Java is a strong type checking language. There are two concepts regarding types and objects. One is the object type and the other the template/class the object was created from. When an object is created, the template/class is assigned to that object which can not be changed. Types of an object however can be changed by type casting. Types of an object is associated with the object reference that referencing the object and determines what operation can be performed on the object through that object reference. Assigning the value of one object reference to a different type of object reference is called type casting.
The most often used data structure in any language is a character string. For this reason java defines a special object that is String.
To aggregate same type java objects to an array, java has a special array object for that. Both java objects and primitive types can be aggregated to arrays
PNUTS
Pnuts is a dynamic scripting language for the Java Platform. It is designed to be used in a dual language system with the Java programming language. The goals of the Pnuts project are to provide a small, fast scripting language that has tight integration with the Java language. Pnuts uses syntax that is simple and friendly to Java developers, while also being very expressive.
Relationship to Java
Because Java and Pnuts share the same type system, Java code can easily invoke or define Pnuts functions. Likewise, Pnuts code can easily manipulate Java objects. Pnuts code can even define Java classes. Because Pnuts compiles to Java byte codes, these classes can be used by Java just like any other class. A class written in Pnuts can even later be replaced by a class written in Java with no other code changes.
History
Pnuts was originally developed in 1997 by Toyokazu Tomatsu as a testing tool for Java classes. Pnuts has since been extended, mainly focusing on essential functionality required for a Java-based scripting engine, such as a module system and bytecode compiler.
Relationship to Java
Because Java and Pnuts share the same type system, Java code can easily invoke or define Pnuts functions. Likewise, Pnuts code can easily manipulate Java objects. Pnuts code can even define Java classes. Because Pnuts compiles to Java byte codes, these classes can be used by Java just like any other class. A class written in Pnuts can even later be replaced by a class written in Java with no other code changes.
History
Pnuts was originally developed in 1997 by Toyokazu Tomatsu as a testing tool for Java classes. Pnuts has since been extended, mainly focusing on essential functionality required for a Java-based scripting engine, such as a module system and bytecode compiler.
JRUBY
JRuby is a Java implementation of the Ruby interpreter, being developed by the JRuby team.
JRuby is free software released under a three-way CPL/GPL/LGPL license.
JRuby is tightly integrated with Java to allow the embedding of the interpreter into any Java application with full two-way access between the Java and the Ruby code. (Compare Jython for the Python language.)
JRuby's lead developers are Charles Nutter , Thomas Enebo, Ola Bini and Nick Sieger . In September 2006, Sun Microsystems hired Enebo and Nutter to work on JRuby full time. In June 2007, ThoughtWorks hired Ola Bini to work on Ruby and JRuby.
History
JRuby was originally created by Jan Arne Petersen, in 2001. At that time and for several years following, the code was a direct port of the Ruby 1.6 C code. With the release of Ruby 1.8.6, an effort began to update JRuby to 1.8.6 features and semantics. Since 2001, several contributors have assisted the project, leading to the current (2008) core team of four members.
The Netbeans Ruby Pack, available since NetBeans 6.0, allows IDE development with Ruby and JRuby, as well as Ruby on Rails for the two implementations of Ruby .
JRuby 1.1 added Just-in-time compilation and Ahead-of-time compilation modes to JRuby and is faster in most cases than the current Ruby 1.8.7 reference implementation.
JRuby 1.1.1 is stated to be packaged in Fedora 9.
Since version 1.1.1, the JRuby team began to issue point releases often to address quickly issues that may be brought up by users.
Rails
JRuby has supported Ruby on Rails since version 0.9 (May 2006) , with the ability to execute RubyGems and WEBrick. Since the hiring of the two lead developers by Sun, Rails compatibility and speed have improved greatly. JRuby version 1.0 successfully passed nearly all of Rails' own test cases. Since then, developers have begun to use JRuby for Rails applications in production environments .
Multiple Virtual Machine Collaboration
On February 27, 2008, Sun Microsystems and the University of Tokyo announced a joint-research project to implement a Virtual Machine capable of executing more than one Ruby or JRuby application on one interpreter.
Dynamic Invocation on Java Virtual Machines
JSR 292 (Supporting Dynamically Typed Languages on the JavaTM Platform) propose to:
add a new invokedynamic instruction at the JVM level, to allow method invocation relying on dynamic Type checking,
to be able to change the classes and method at runtime dynamically in a production environment.
The Sun Open source project Multi Language Virtual Machine aim to prototype this JSR. The first working prototype, developed as a patch on OpenJDK, was announced and made available on end of August 2008.
The JRuby team has successfully wired dynamic invocation in their codebase, albeit in a very primitive way. Dynamic invocation will ship with the next 1.1.5 release, and will be disabled on JVMs without Dynamic invocation capabilities.
Design
Since early 2006, the current JRuby core team has endeavored to move JRuby beyond being a simple C port, to support better performance and to aid eventual compilation to Java bytecode. To support this end, the team set an ambitious goal: to be able to run Ruby on Rails unmodified using JRuby. In the process of achieving this goal, the JRuby test suite expanded to such extent that the team gained confidence in the "correctness" of JRuby. As a result, toward the end of 2006 and in the beginning of 2007, they began to commit much more complicated redesigns and refactorings of JRuby's core subsystems.
JRuby is designed to work as a mixed-mode virtual machine for Ruby, where code can be either interpreted directly, just-in-time compiled at runtime to Java bytecode, or ahead-of-time compiled to Java bytecode before execution. Until October 2007, only the interpreted mode supported all Ruby's constructs, but a full AOT/JIT compiler is available since version 1.1[18]. The compiler design allows for interpreted and compiled code to run side-by-side, as well as decompilation to reoptimize and outputting generated bytecode as Java class files.
JRuby is free software released under a three-way CPL/GPL/LGPL license.
JRuby is tightly integrated with Java to allow the embedding of the interpreter into any Java application with full two-way access between the Java and the Ruby code. (Compare Jython for the Python language.)
JRuby's lead developers are Charles Nutter , Thomas Enebo, Ola Bini and Nick Sieger . In September 2006, Sun Microsystems hired Enebo and Nutter to work on JRuby full time. In June 2007, ThoughtWorks hired Ola Bini to work on Ruby and JRuby.
History
JRuby was originally created by Jan Arne Petersen, in 2001. At that time and for several years following, the code was a direct port of the Ruby 1.6 C code. With the release of Ruby 1.8.6, an effort began to update JRuby to 1.8.6 features and semantics. Since 2001, several contributors have assisted the project, leading to the current (2008) core team of four members.
The Netbeans Ruby Pack, available since NetBeans 6.0, allows IDE development with Ruby and JRuby, as well as Ruby on Rails for the two implementations of Ruby .
JRuby 1.1 added Just-in-time compilation and Ahead-of-time compilation modes to JRuby and is faster in most cases than the current Ruby 1.8.7 reference implementation.
JRuby 1.1.1 is stated to be packaged in Fedora 9.
Since version 1.1.1, the JRuby team began to issue point releases often to address quickly issues that may be brought up by users.
Rails
JRuby has supported Ruby on Rails since version 0.9 (May 2006) , with the ability to execute RubyGems and WEBrick. Since the hiring of the two lead developers by Sun, Rails compatibility and speed have improved greatly. JRuby version 1.0 successfully passed nearly all of Rails' own test cases. Since then, developers have begun to use JRuby for Rails applications in production environments .
Multiple Virtual Machine Collaboration
On February 27, 2008, Sun Microsystems and the University of Tokyo announced a joint-research project to implement a Virtual Machine capable of executing more than one Ruby or JRuby application on one interpreter.
Dynamic Invocation on Java Virtual Machines
JSR 292 (Supporting Dynamically Typed Languages on the JavaTM Platform) propose to:
add a new invokedynamic instruction at the JVM level, to allow method invocation relying on dynamic Type checking,
to be able to change the classes and method at runtime dynamically in a production environment.
The Sun Open source project Multi Language Virtual Machine aim to prototype this JSR. The first working prototype, developed as a patch on OpenJDK, was announced and made available on end of August 2008.
The JRuby team has successfully wired dynamic invocation in their codebase, albeit in a very primitive way. Dynamic invocation will ship with the next 1.1.5 release, and will be disabled on JVMs without Dynamic invocation capabilities.
Design
Since early 2006, the current JRuby core team has endeavored to move JRuby beyond being a simple C port, to support better performance and to aid eventual compilation to Java bytecode. To support this end, the team set an ambitious goal: to be able to run Ruby on Rails unmodified using JRuby. In the process of achieving this goal, the JRuby test suite expanded to such extent that the team gained confidence in the "correctness" of JRuby. As a result, toward the end of 2006 and in the beginning of 2007, they began to commit much more complicated redesigns and refactorings of JRuby's core subsystems.
JRuby is designed to work as a mixed-mode virtual machine for Ruby, where code can be either interpreted directly, just-in-time compiled at runtime to Java bytecode, or ahead-of-time compiled to Java bytecode before execution. Until October 2007, only the interpreted mode supported all Ruby's constructs, but a full AOT/JIT compiler is available since version 1.1[18]. The compiler design allows for interpreted and compiled code to run side-by-side, as well as decompilation to reoptimize and outputting generated bytecode as Java class files.
JPHTHON
Jython, successor of JPython, is an implementation of the Python programming language written in java.
Overview
Jython programs can seamlessly import and use any Java class. Except for some standard modules, Jython programs use Java classes instead of Python modules. Jython includes almost all of the modules in the standard Python programming language distribution, lacking only some of the modules implemented originally in C. For example, a user interface in Jython would be written with Swing, AWT or SWT. Jython compiles to Java bytecode (intermediate language) either on demand or statically.
Jython also includes jythonc, a compiler that converts Python source code into Java bytecode. This allows Python programmers to write classes which can be fully utilized by a Java program.
License terms
Jython is released under a mix of three licenses: the Python Software Foundation License (v2), the Jython 2.0, 2.1 license, and the JPython 1.1.x Software License. The first two are permissive free software licenses. The third also appears to be but this is unclear because neither Free Software Foundation or Open Source Initiative have reviewed and commented on it.
History
Jim Hugunin created Jython in late 1997, and developed it until 1999. In February 1999, Barry Warsaw took over as the primary developer. In October 2000, Jython moved to SourceForge. For a long time, Samuele Pedroni did most of the work to maintain and develop Jython. To the end of 2004, Pedroni stepped down as the primary developer to concentrate his effort to PyPy, but he is still considered the authority on Jython internals. In January 2005, Brian Zimmer received a grant from the Python Software Foundation to develop Jython. In December 2005, Frank Wierzbicki succeeded Zimmer as the primary developer. During 2005, development was slow due to lack of knowledgeable developers.
On March 3, 2008, it was announced that Sun Microsystems hired Ted Leung and Frank Wierzbicki to work on Jython and Python, similar to Sun's hiring of two JRuby developers. Development progresses steadily, and Jython can now even run Django, a Python framework comparable to Ruby on Rails.
Status and roadmap
The current release is Jython-2.2.1. It includes improvements to Java integration and implements the same set of language features as CPython 2.2. CPython 2.5 is targeted for the next release.
Developments are going steady and an alpha version of the corresponding Jython 2.5 release has been available since July 2008.
Usage
Jython is one of two scripting languages (with Jacl) used in WebSphere Application Server. It is used in IBM Rational development tools, where Jython projects can be created using wizards.
Overview
Jython programs can seamlessly import and use any Java class. Except for some standard modules, Jython programs use Java classes instead of Python modules. Jython includes almost all of the modules in the standard Python programming language distribution, lacking only some of the modules implemented originally in C. For example, a user interface in Jython would be written with Swing, AWT or SWT. Jython compiles to Java bytecode (intermediate language) either on demand or statically.
Jython also includes jythonc, a compiler that converts Python source code into Java bytecode. This allows Python programmers to write classes which can be fully utilized by a Java program.
License terms
Jython is released under a mix of three licenses: the Python Software Foundation License (v2), the Jython 2.0, 2.1 license, and the JPython 1.1.x Software License. The first two are permissive free software licenses. The third also appears to be but this is unclear because neither Free Software Foundation or Open Source Initiative have reviewed and commented on it.
History
Jim Hugunin created Jython in late 1997, and developed it until 1999. In February 1999, Barry Warsaw took over as the primary developer. In October 2000, Jython moved to SourceForge. For a long time, Samuele Pedroni did most of the work to maintain and develop Jython. To the end of 2004, Pedroni stepped down as the primary developer to concentrate his effort to PyPy, but he is still considered the authority on Jython internals. In January 2005, Brian Zimmer received a grant from the Python Software Foundation to develop Jython. In December 2005, Frank Wierzbicki succeeded Zimmer as the primary developer. During 2005, development was slow due to lack of knowledgeable developers.
On March 3, 2008, it was announced that Sun Microsystems hired Ted Leung and Frank Wierzbicki to work on Jython and Python, similar to Sun's hiring of two JRuby developers. Development progresses steadily, and Jython can now even run Django, a Python framework comparable to Ruby on Rails.
Status and roadmap
The current release is Jython-2.2.1. It includes improvements to Java integration and implements the same set of language features as CPython 2.2. CPython 2.5 is targeted for the next release.
Developments are going steady and an alpha version of the corresponding Jython 2.5 release has been available since July 2008.
Usage
Jython is one of two scripting languages (with Jacl) used in WebSphere Application Server. It is used in IBM Rational development tools, where Jython projects can be created using wizards.
JAVA POSE
The Java Posse is a podcast of news, discussion, and interviews about the Java programming language and associated Java technologies. The four regular contributors are Tor Norbye (Sun Microsystems), Carl Quinn (Google), Dick Wall (Navigenics) and Joe Nuxoll (Navigenics). By January 2007, the estimated listenership was between 7,000 and 10,000 people.
The podcast was begun in September 2005 and was a successor to an earlier short-lived Java podcast produced by Wall called "JavaCast", cohosted with Brandon Werner. As of December 2007, over 150 episodes of The Java Posse have been recorded. The group has also organized the "Java Posse Roundup", an unconference held in Crested Butte, Colorado in 2007 and organized by Bruce Eckel. Sessions from the roundup have been published as episodes of the podcast
The podcast was begun in September 2005 and was a successor to an earlier short-lived Java podcast produced by Wall called "JavaCast", cohosted with Brandon Werner. As of December 2007, over 150 episodes of The Java Posse have been recorded. The group has also organized the "Java Posse Roundup", an unconference held in Crested Butte, Colorado in 2007 and organized by Bruce Eckel. Sessions from the roundup have been published as episodes of the podcast
CRITICISM OF JAVA
The Java programming language was intended to serve as a novel way to manage software complexity, though a number of criticisms have been leveled at the language.
Class path
Running a Java program originally required all third-party supporting libraries to be in the class path.
Prior to Java 6 it was necessary for each .jar or .zip archive required to be explicitly named in the class path. Java 6 provides a way around this by allowing directories listed in the class path to end in an asterisk (*), which will be expanded to the names of all files ending in .jar or .JAR within the directory. Such an entry does not, however, match .zip or .class files within that directory.
Resource management
Java performs garbage collection, so memory management is automatic, which makes allocation and deallocation errors such as memory leaks less likely and, barring errors in the VM, eliminates segmentation violations. But it does not manage all resources, such as file handles, JDBC database connections, and network connections; these must be released just as memory would need to be in C++. Leaks are particularly likely when exceptions are thrown, if try/catch/final are not used properly.
Java ensures the execution of "finalization" methods before garbage collection occurs, without guaranteeing any particular order of execution between related resources, and without guaranteeing when or even if automatic garbage collection of any given object will occur.
Conceptually, Java always allocates objects on the heap. Only the compiler may optimize this to faster stack-based allocation. In this respect Java is less flexible than C++, which allows (requires) the programmer to control where objects are allocated. In both languages, values of primitives type are allocated on the stack, and the compiler decides how to use the available registers.
Language choices
Primitives vs. objects
Java designers decided not to implement certain features present in other languages (including multiple inheritance, operator overloading, and tuples). Java permits multiple inheritance of interfaces but not of implementations.
Java's primitive types are not objects. Primitive types hold their values in the stack rather than being references to values. Because of this, Java is not considered to be a pure object-oriented programming language and this makes reflection more complicated. The motivation for primitive types being non-object oriented was performance considerations.
Java 5.0 and later supports automatic conversion (autoboxing) of primitive data types to corresponding object form wherever required. This is not without problems, however:
Special care must be taken when comparing two boxed primitive types as the boxed instances may have identity as reference objects.
When autounboxing, a null pointer exception may be thrown. Since this operation occurs implicitly (without a cast or method call), this unchecked exception may not be obvious by inspection of the line of code to an unfamiliar reader.
Boxed primitives do not allow for operator based arithmetic; either the programmer must ensure an unbox operation, or she must use member methods which does not lend itself to be read as fluently as operator based arithmetic.
Generics
When generics were added to Java 5.0, there was already a large framework of classes (many of which were already deprecated), so generics were chosen to be implemented using erasure to allow for migration compatibility and re-use of these existing classes. This limited the features that could be provided by this addition as compared to other languages.
There is a common misconception that type erasure was necessary for backwards compatibility in the sense that old code could run on a new JVM and new code could call old code. However, this was entirely possible without type erasure (i.e. with reified generics), as has been demonstrated with the addition of generics to the very similar C# programming language[citation needed]. Java 5.0 could have implemented new generic collections classes with reified generics and have those collection classes implement the non-generic collection interfaces such as IList, ISet etc.
Type erasure was only necessary because of a requirement for a temporary migration compatibility; a requirement that the collection classes be the same classes, so that code which did not insulate itself through use of interfaces (thus breaking best practices) could co-exist in the same JVM with new generic style code without the use of wrapping techniques.
Type erasure has several drawbacks:
Typecasting overhead when inserting and removing from a collection and when calling any other method of a generic type which takes a parameter of a parameterized type.
Inability to use primitive types as type parameters. Because all types must be of reference type and must be "erased" to their upper bounds, it was not possible to allow the use of primitive types. Instead Java 5.0 features autoboxing which "boxes" primitive type on insertion into collections, thus incurring extra overhead and making the code more opaque.
What looks like separate classes at development time is really a single class at runtime. Thus static (class-level) members are shared among all classes realized from the generic class.
Inability to create new instances or new arrays of types defines through a type parameter.
Disparity with arrays which means that in general the developer should never let a method return an array of a parametric type.
The type erasure process may produce clashing method signatures.
Inability to implement different realizations of the same generic interface.
Inability to use generic exceptions
Non-Virtual methods
Java provides no way to make methods non-virtual (although they can be "sealed" by using the final modifier to disallow overriding). This means that there is no way to let derived classes define a new, unrelated method with the same name. This can be a problem when a base class is designed by a different person, and a new version introduces a method with the same name and signature as some method already present in the derived class. This means that the method in the derived class will implicitly override the method in the base class, even though that was not the intent of the designers of either class. To partially accommodate for these versioning problems, Java 5.0 introduced the @Override annotation, but to preserve backwards compatibility it could not be made compulsory by default.
Single paradigm
Java is predominantly a single-paradigm language. The addition of static imports in Java 5.0 accommodates the procedural paradigm better than earlier versions of Java. It is expected that the addition of new language features like closures (or lambdas) in version 7 will allow a more functional style (but the language specification has not yet been finalised).
Exception handling
Java embraced the concept of exception specifications from C++ where they were optional, but made throws clauses mandatory for any checked exception. While this can be a benefit for small systems, there is no universal agreement that using checked exceptions is a benefit for larger systems. In particular, "higher level" code is often not interested in errors thrown by "lower level" code (eg: NamingException). The coder of the naming classes must make a choice: either force higher level code to deal with naming exceptions as checked exceptions, or allow them to "bubble up" through his own low-level code without compile-time checks.
Closure
Finally, while anonymous inner classes provide a basic form of closures, they are not complete and require referenced variables to either be class fields or declared "final". The rationale behind this is that it allows JVM implementors to choose a stack model for variable lifetimes, so that a variable scope is removed when exited, thus preventing real closures. In addition, when using - for instance - "Runnable" as a closure, one has to declare the "run" method and put the code in that: you cannot simply put some code in braces and pass it around (however the Java 7 language specification is aiming to address this with first class closures).
Floating point arithmetic
While Java's floating point arithmetic is largely based on IEEE 754 (Standard for Binary Floating-Point Arithmetic), certain features are not supported even when using the strictfp modifier, such as Exception Flags and Directed Roundings — capabilities mandated by IEEE Standard 754. Many so-called "Java gotchas" are not problems with Java per se, but problems that are inevitable whenever using floating point arithmetic.
Look and feel
look and feel of GUI applications written in Java using the Swing platform may look different from native applications. While programmers can choose to use the AWT toolkit that displays native widgets (and thus look like the operating platform), the AWT toolkit is unable to meet advanced GUI programming needs by wrapping around advanced widgets and not sacrificing portability across the various supported platforms, each of which have vastly different APIs especially for higher-level widgets. If an alternative GUI toolkit is used, such as SWT, it is possible for a Java application to have native look and feel whilst also having access to advanced widgets.
The Swing toolkit – written completely in Java – both creates the problem of having a different look and feel from native applications, and avoids the problem of being limited by native toolkit capabilities because it reimplements widgets using only the most basic drawing mechanisms that are guaranteed available on all platforms. Unfortunately, the default installations of the JRE (as of August 2006) do not use the system's "native" look and feel, instead defaulting to the built-in Metal Look and Feel. If the programmer doesn't take care to set the native look and feel, users will have applications whose appearance is vastly different from that of their native applications. Apple Computer's own optimized version of the Java Runtime, which is included within the Mac OS X distribution, by default does set the default and implements its "Aqua" look-and-feel, giving Swing applications on the Macintosh a similar appearance to native software. Even in this environment, the programmer must still do some extra work to ensure that that application looks like an Aqua one (for example, they must set system properties to ensure the menubar is rendered in the OS X menubar and not in the application window as it would be on other platforms).
Performance
Java's performance has improved substantially since the early versions, and performance of JIT compilers relative to native compilers has in some tests been shown to be quite similar. The performance of the compilers does not necessarily indicate the performance of the compiled code; only careful testing can reveal the true performance issues in any system.
In a paper written in 1999 by Lutz Prechelt it is outlined that, statistically, programmer efficiency and experience has a bearing many standard deviations greater on run-time and memory usage than language choice. This paper specifically uses Java as a basis for the comparison, due to its then bad reputation.[19] Sun Microsystems have taken considerable trouble to address these problems, and regularly produce white papers on this topic. A more recent study (2003–4) gives Java a comparable performance to C++.
General
Java bytecode can either be interpreted at run time by a virtual machine, or it can be compiled at load time or runtime into machine code which runs directly on the computer's hardware. Interpretation is slower than native execution, and compilation at load time or runtime has an initial performance penalty for the compilation.
Language constraints
There are a few language requirements which incur an unavoidable time penalty, although these features are not unique to Java. Among these are array bounds checking, run-time type checking, and virtual function indirection (although each of these can in some situations be avoided by an optimizing compiler). Also the lack of features can affect performance. For example, Java does not have arrays of structures or a true multi-dimensional array, but only an array of references to objects or further arrays. Nor does Java allow returning more than one value from a function without using an object. The net result is that Java code makes more heap allocations than some other languages.
Garbage collection
The garbage collector controls when objects are deleted from memory. Java does not allow the programmer to control when garbage collection occurs - it cannot be delayed, or exercised on a particular object. While this makes programming much simpler and reduces memory leaks, it lacks the flexibility that can, in some cases, result in a more efficient handling of memory. The programmer can call the function System.gc() as a hint that this is a suitable time to run the garbage collector, but the JVM is not obliged to honour this suggestion. Lower-level languages provide more flexibility over memory management, and while garbage collection is not part of the language specification and therefore its use is not mandated, in some cases (notably C and C++) a number of third-party garbage collectors are available.
The use of a garbage collector to automatically delete objects can add overhead compared to manual deallocation and can have a positive or negative impact on performance depending upon the garbage collector implementation and the characteristics of the application's use of objects. With the modern generational garbage collectors used in many JVMs, many applications actually experience greater performance because of faster allocation and deallocation algorithms.
Because the garbage collector may run at any time, Java is unsuitable for real time programming. In older JVM implementations, collection paused the program's own threads. The current implementation, using concurrent collection, does not need to pause the program but will typically slow its execution. This is problematic in a real-time environment because making scheduling guarantees is impossible with arbitrary interruptions, and deadlines may be missed while the garbage collector is running.
Byte code vs. native compilation
Relative performance of code produced by JIT compilers as compared to AOT compilers can be quite close, and is often a subject of debate. The JIT compilation stage may be time consuming, which is inconvenient for applications that are short-lived and/or contain large amounts of code. Once compiled to native code, however, the performance of the program can be comparable to that achieved by a native compiler, even on numerical tasks. Although Java does not support manual inlining of method calls, many JIT compilers perform this optimization at load time and can exploit information from the runtime environment to guide more effective transformations, such as profile-directed inlining. Dynamic recompilation, as provided by Sun's HotSpot JVM, can exceed the performance of the static compilation available in most other languages by exploiting information that is only available at runtime.
Hardware interfacing
Because Java was designed with an emphasis on security and portability, it does not support direct access to the machine architecture and address space. This means working directly with a specific piece of hardware such as a scanner, digital camera, audio recorder, video capture, or any hardware that requires direct memory space control (typically those pieces or hardware installed with drivers), cannot easily be accomplished with Java. An illustration of this issue is seen in version 1.0 of Java as it was not possible to access a printer because the interface code to the various printer drivers was not included in this first JVM.
Interfacing with native code
Client side or server systems that need to "talk" to the hardware must implement a hybrid solution using Java and C/C++ or assembly language via the Java Native Interface (JNI) libraries to link native code to the Java libraries. An alternate solution is to code the hardware software component in its native C/C++/assembler language and then pass the data via files, databases or a shared memory interface, although this is not an ideal solution.
Using the JNI technique introduces many possible inconsistencies such as: machine dependency, potential deadlock situations, memory allocation leaks, and possibly poor application performance, not to mention code complexity of needing to maintain two different code bases.
However, other simpler solutions have been developed since JNI. Java Native Access is comparable to .NET P/Invoke, in that no boilerplate C glue code have to be written to be able to access the native library.
Class path
Running a Java program originally required all third-party supporting libraries to be in the class path.
Prior to Java 6 it was necessary for each .jar or .zip archive required to be explicitly named in the class path. Java 6 provides a way around this by allowing directories listed in the class path to end in an asterisk (*), which will be expanded to the names of all files ending in .jar or .JAR within the directory. Such an entry does not, however, match .zip or .class files within that directory.
Resource management
Java performs garbage collection, so memory management is automatic, which makes allocation and deallocation errors such as memory leaks less likely and, barring errors in the VM, eliminates segmentation violations. But it does not manage all resources, such as file handles, JDBC database connections, and network connections; these must be released just as memory would need to be in C++. Leaks are particularly likely when exceptions are thrown, if try/catch/final are not used properly.
Java ensures the execution of "finalization" methods before garbage collection occurs, without guaranteeing any particular order of execution between related resources, and without guaranteeing when or even if automatic garbage collection of any given object will occur.
Conceptually, Java always allocates objects on the heap. Only the compiler may optimize this to faster stack-based allocation. In this respect Java is less flexible than C++, which allows (requires) the programmer to control where objects are allocated. In both languages, values of primitives type are allocated on the stack, and the compiler decides how to use the available registers.
Language choices
Primitives vs. objects
Java designers decided not to implement certain features present in other languages (including multiple inheritance, operator overloading, and tuples). Java permits multiple inheritance of interfaces but not of implementations.
Java's primitive types are not objects. Primitive types hold their values in the stack rather than being references to values. Because of this, Java is not considered to be a pure object-oriented programming language and this makes reflection more complicated. The motivation for primitive types being non-object oriented was performance considerations.
Java 5.0 and later supports automatic conversion (autoboxing) of primitive data types to corresponding object form wherever required. This is not without problems, however:
Special care must be taken when comparing two boxed primitive types as the boxed instances may have identity as reference objects.
When autounboxing, a null pointer exception may be thrown. Since this operation occurs implicitly (without a cast or method call), this unchecked exception may not be obvious by inspection of the line of code to an unfamiliar reader.
Boxed primitives do not allow for operator based arithmetic; either the programmer must ensure an unbox operation, or she must use member methods which does not lend itself to be read as fluently as operator based arithmetic.
Generics
When generics were added to Java 5.0, there was already a large framework of classes (many of which were already deprecated), so generics were chosen to be implemented using erasure to allow for migration compatibility and re-use of these existing classes. This limited the features that could be provided by this addition as compared to other languages.
There is a common misconception that type erasure was necessary for backwards compatibility in the sense that old code could run on a new JVM and new code could call old code. However, this was entirely possible without type erasure (i.e. with reified generics), as has been demonstrated with the addition of generics to the very similar C# programming language[citation needed]. Java 5.0 could have implemented new generic collections classes with reified generics and have those collection classes implement the non-generic collection interfaces such as IList, ISet etc.
Type erasure was only necessary because of a requirement for a temporary migration compatibility; a requirement that the collection classes be the same classes, so that code which did not insulate itself through use of interfaces (thus breaking best practices) could co-exist in the same JVM with new generic style code without the use of wrapping techniques.
Type erasure has several drawbacks:
Typecasting overhead when inserting and removing from a collection and when calling any other method of a generic type which takes a parameter of a parameterized type.
Inability to use primitive types as type parameters. Because all types must be of reference type and must be "erased" to their upper bounds, it was not possible to allow the use of primitive types. Instead Java 5.0 features autoboxing which "boxes" primitive type on insertion into collections, thus incurring extra overhead and making the code more opaque.
What looks like separate classes at development time is really a single class at runtime. Thus static (class-level) members are shared among all classes realized from the generic class.
Inability to create new instances or new arrays of types defines through a type parameter.
Disparity with arrays which means that in general the developer should never let a method return an array of a parametric type.
The type erasure process may produce clashing method signatures.
Inability to implement different realizations of the same generic interface.
Inability to use generic exceptions
Non-Virtual methods
Java provides no way to make methods non-virtual (although they can be "sealed" by using the final modifier to disallow overriding). This means that there is no way to let derived classes define a new, unrelated method with the same name. This can be a problem when a base class is designed by a different person, and a new version introduces a method with the same name and signature as some method already present in the derived class. This means that the method in the derived class will implicitly override the method in the base class, even though that was not the intent of the designers of either class. To partially accommodate for these versioning problems, Java 5.0 introduced the @Override annotation, but to preserve backwards compatibility it could not be made compulsory by default.
Single paradigm
Java is predominantly a single-paradigm language. The addition of static imports in Java 5.0 accommodates the procedural paradigm better than earlier versions of Java. It is expected that the addition of new language features like closures (or lambdas) in version 7 will allow a more functional style (but the language specification has not yet been finalised).
Exception handling
Java embraced the concept of exception specifications from C++ where they were optional, but made throws clauses mandatory for any checked exception. While this can be a benefit for small systems, there is no universal agreement that using checked exceptions is a benefit for larger systems. In particular, "higher level" code is often not interested in errors thrown by "lower level" code (eg: NamingException). The coder of the naming classes must make a choice: either force higher level code to deal with naming exceptions as checked exceptions, or allow them to "bubble up" through his own low-level code without compile-time checks.
Closure
Finally, while anonymous inner classes provide a basic form of closures, they are not complete and require referenced variables to either be class fields or declared "final". The rationale behind this is that it allows JVM implementors to choose a stack model for variable lifetimes, so that a variable scope is removed when exited, thus preventing real closures. In addition, when using - for instance - "Runnable" as a closure, one has to declare the "run" method and put the code in that: you cannot simply put some code in braces and pass it around (however the Java 7 language specification is aiming to address this with first class closures).
Floating point arithmetic
While Java's floating point arithmetic is largely based on IEEE 754 (Standard for Binary Floating-Point Arithmetic), certain features are not supported even when using the strictfp modifier, such as Exception Flags and Directed Roundings — capabilities mandated by IEEE Standard 754. Many so-called "Java gotchas" are not problems with Java per se, but problems that are inevitable whenever using floating point arithmetic.
Look and feel
look and feel of GUI applications written in Java using the Swing platform may look different from native applications. While programmers can choose to use the AWT toolkit that displays native widgets (and thus look like the operating platform), the AWT toolkit is unable to meet advanced GUI programming needs by wrapping around advanced widgets and not sacrificing portability across the various supported platforms, each of which have vastly different APIs especially for higher-level widgets. If an alternative GUI toolkit is used, such as SWT, it is possible for a Java application to have native look and feel whilst also having access to advanced widgets.
The Swing toolkit – written completely in Java – both creates the problem of having a different look and feel from native applications, and avoids the problem of being limited by native toolkit capabilities because it reimplements widgets using only the most basic drawing mechanisms that are guaranteed available on all platforms. Unfortunately, the default installations of the JRE (as of August 2006) do not use the system's "native" look and feel, instead defaulting to the built-in Metal Look and Feel. If the programmer doesn't take care to set the native look and feel, users will have applications whose appearance is vastly different from that of their native applications. Apple Computer's own optimized version of the Java Runtime, which is included within the Mac OS X distribution, by default does set the default and implements its "Aqua" look-and-feel, giving Swing applications on the Macintosh a similar appearance to native software. Even in this environment, the programmer must still do some extra work to ensure that that application looks like an Aqua one (for example, they must set system properties to ensure the menubar is rendered in the OS X menubar and not in the application window as it would be on other platforms).
Performance
Java's performance has improved substantially since the early versions, and performance of JIT compilers relative to native compilers has in some tests been shown to be quite similar. The performance of the compilers does not necessarily indicate the performance of the compiled code; only careful testing can reveal the true performance issues in any system.
In a paper written in 1999 by Lutz Prechelt it is outlined that, statistically, programmer efficiency and experience has a bearing many standard deviations greater on run-time and memory usage than language choice. This paper specifically uses Java as a basis for the comparison, due to its then bad reputation.[19] Sun Microsystems have taken considerable trouble to address these problems, and regularly produce white papers on this topic. A more recent study (2003–4) gives Java a comparable performance to C++.
General
Java bytecode can either be interpreted at run time by a virtual machine, or it can be compiled at load time or runtime into machine code which runs directly on the computer's hardware. Interpretation is slower than native execution, and compilation at load time or runtime has an initial performance penalty for the compilation.
Language constraints
There are a few language requirements which incur an unavoidable time penalty, although these features are not unique to Java. Among these are array bounds checking, run-time type checking, and virtual function indirection (although each of these can in some situations be avoided by an optimizing compiler). Also the lack of features can affect performance. For example, Java does not have arrays of structures or a true multi-dimensional array, but only an array of references to objects or further arrays. Nor does Java allow returning more than one value from a function without using an object. The net result is that Java code makes more heap allocations than some other languages.
Garbage collection
The garbage collector controls when objects are deleted from memory. Java does not allow the programmer to control when garbage collection occurs - it cannot be delayed, or exercised on a particular object. While this makes programming much simpler and reduces memory leaks, it lacks the flexibility that can, in some cases, result in a more efficient handling of memory. The programmer can call the function System.gc() as a hint that this is a suitable time to run the garbage collector, but the JVM is not obliged to honour this suggestion. Lower-level languages provide more flexibility over memory management, and while garbage collection is not part of the language specification and therefore its use is not mandated, in some cases (notably C and C++) a number of third-party garbage collectors are available.
The use of a garbage collector to automatically delete objects can add overhead compared to manual deallocation and can have a positive or negative impact on performance depending upon the garbage collector implementation and the characteristics of the application's use of objects. With the modern generational garbage collectors used in many JVMs, many applications actually experience greater performance because of faster allocation and deallocation algorithms.
Because the garbage collector may run at any time, Java is unsuitable for real time programming. In older JVM implementations, collection paused the program's own threads. The current implementation, using concurrent collection, does not need to pause the program but will typically slow its execution. This is problematic in a real-time environment because making scheduling guarantees is impossible with arbitrary interruptions, and deadlines may be missed while the garbage collector is running.
Byte code vs. native compilation
Relative performance of code produced by JIT compilers as compared to AOT compilers can be quite close, and is often a subject of debate. The JIT compilation stage may be time consuming, which is inconvenient for applications that are short-lived and/or contain large amounts of code. Once compiled to native code, however, the performance of the program can be comparable to that achieved by a native compiler, even on numerical tasks. Although Java does not support manual inlining of method calls, many JIT compilers perform this optimization at load time and can exploit information from the runtime environment to guide more effective transformations, such as profile-directed inlining. Dynamic recompilation, as provided by Sun's HotSpot JVM, can exceed the performance of the static compilation available in most other languages by exploiting information that is only available at runtime.
Hardware interfacing
Because Java was designed with an emphasis on security and portability, it does not support direct access to the machine architecture and address space. This means working directly with a specific piece of hardware such as a scanner, digital camera, audio recorder, video capture, or any hardware that requires direct memory space control (typically those pieces or hardware installed with drivers), cannot easily be accomplished with Java. An illustration of this issue is seen in version 1.0 of Java as it was not possible to access a printer because the interface code to the various printer drivers was not included in this first JVM.
Interfacing with native code
Client side or server systems that need to "talk" to the hardware must implement a hybrid solution using Java and C/C++ or assembly language via the Java Native Interface (JNI) libraries to link native code to the Java libraries. An alternate solution is to code the hardware software component in its native C/C++/assembler language and then pass the data via files, databases or a shared memory interface, although this is not an ideal solution.
Using the JNI technique introduces many possible inconsistencies such as: machine dependency, potential deadlock situations, memory allocation leaks, and possibly poor application performance, not to mention code complexity of needing to maintain two different code bases.
However, other simpler solutions have been developed since JNI. Java Native Access is comparable to .NET P/Invoke, in that no boilerplate C glue code have to be written to be able to access the native library.
Saturday, September 13, 2008
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 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
Sunday, September 7, 2008
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.
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.
Thursday, September 4, 2008
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.
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.
Subscribe to:
Posts (Atom)
