6.1 Java: An overview

6.1 Java: An overview

Java is a high-level, third-generation, object-oriented programming language developed by Sun. It resembles C and C++ to an extent, given that it was created to be a better C++ by James Gosling, Patrick Naughton, and Mike Sheridan as part of a so-called green project at Sun toward the end of 1990. It was originally intended for use in embedded systems included in smart consumer electronic devices such as TV set-top boxes, game consoles, and PDAs. Its original name was Oak. The hackneyed , hello world program written in Java, per Sun, would look like this:

 class hello {  public static void main(String argv()) {  System.out.println("Hello!");  }  } 

Java, as it is known now, came to be in 1995 when Sun unveiled it as a platform-independent technology for enhancing what could be done on the Web ”particularly in terms of dynamic, highly interactive Web pages with lots of animated graphics, as well as other value-added functionality from locally executed code. Netscape Navigator 2.0, released in March 1996, at that juncture the undisputed top-dog of Web browsers, included ground-breaking support for both Java and JavaScript. Java had been propelled onto the Web by two of the then most influential and respected players vis--vis the Web: Sun and Netscape. Java has not looked back since.

Though Java has a syntax modeled on that of C, it is neither C nor, as in the case of C++, a superset of C. A Java compiler will thus not accept C code, and most nontrivial C programs typically need to be significantly reengineered before they can be treated as Java applications. Knowing C or, better still, C++ will certainly shorten a programmer s learning curve when it comes to Java, though it should be stressed that familiarity with C or C++ is in no way a prerequisite for mastering Java. What truly distinguishes Java from C and C++ as well as from all prior programming languages, however, is the concept of applets ”the small, platform-independent applications that can be dynamically downloaded to a target system over the Web.

In the early days there were essentially two main types of Java programs: applications and applets. Java applications are conventional, stand-alone programs, installed and executed off a system s hard drive in the same way as applications developed with other languages ”with one distinguishing feature: Java applications can be readily ported between vastly disparate systems. Java applications, in common with applications developed with other popular languages, will typically be invoked via a command line (e.g., Windows Run prompt) instruction. Java applications, as with other applications, will normally also have unfettered access to the host system s resources (e.g., data files) ”though it is important to note that Java software does not support, in any way, the concept of pointers. Consequently, at least in theory, Java programs can be considered to be more secure and well-behaved than most others in that they cannot access arbitrary addresses in memory ”always keeping in mind that unauthorized and unintended memory access is one of the major causes of application or system crashes (or hangs ).

Applets, though similar to applications, are not considered to run in stand-alone mode. Instead, an applet is a program that runs within a Web browser or an applet viewer and, moreover, has strictly limited access to host resources, in particular any kinds of files. An applet, as such, is meant to be nonmalicious, at all costs. This intentional restricted access to host resources precludes the danger of applets being used to propagate viruses or worms. The ongoing popularity of Java applets owes much to this applets are benign claim and reputation. In today s security-conscious culture, Java would already be dead and buried if there were even the slightest suspicion that Java applets could be used maliciously. Microsoft, for one, would have gone all out to make sure of that! But Java applets, which in the main typically run within the confines of Web browsers, including Microsoft s Internet Explorer (IE), are considered by most to be safe ”though one always has the option of disabling Java applet execution by a browser.

In the context of applets, there used to be the concept of a Java sandbox. Applets could play only within the strict and highly controlled confines of the sandbox, and the safeguards in place ensured that applets could not pry, prod, or poke. To start with, an applet could not even communicate with another server, other than the one that had originally downloaded it to its present target system. Though the scope of what an applet can now do has been slowly extended through the use of Java SecurityManager objects, it is still safe to say that applets cannot easily misbehave, particularly when it comes to reading and writing files. Even if authorized to do so, an applet will typically request explicit permission each and every time it wants to access a host file.

6.1.1 Virtual machines, containers, and developer kits

Java applications, as well as Java applets, were said to execute on Java Virtual Machines (JVMs). A Java VM was a virtual platform that executed the instructions that were generated by a Java compiler. A JVM is thus a run-time (or execution) environment. JVMs are implemented on various computing platforms ”in particular, Web browsers and all popular operating systems, ranging from mainframe z/OS to the Mac OS with all flavors of UNIX, Linux, and Windows being more than adequately catered to in some way or another. Sun generally provides JVMs for Solaris, contemporary Windows releases, and one or more versions of Linux, while the JVMs for other platforms are developed by other entities (e.g., IBM, Apple) with vested interest in a particular platform. Figure 6.3 shows a screen shot of Microsoft IE 6.0 s Internet Options, which refer to Microsoft s version of the VM for running Java.

click to expand
Figure 6.3: Screen shot of the Internet Options for Microsoft s Internet Explorer (IE) 6.0 showing the reference to Microsoft s version of the virtual machine for running Java ” including mention of a JIT compiler.

The ongoing acrimony between Microsoft and the Java camp, as discussed at the start of Chapter 3, is likely to result in Microsoft refusing to include a JVM in future releases of Windows as well as IE (though even now the JVM for IE 6 is only installed the first time it has to render a Web page that invokes a Java applet). This is not a show-stopper in any way, since JVMs for all releases of Windows, starting with Windows 98, are readily and freely available for download from java.sun.com and www.java.com.

The concept of a JVM is still very much an integral part of the Java landscape. Today, with the so-called Java 2 technology and in particular Java 2 Enterprise Edition (J2EE), the term container is preferred ”where a container is a Java execution environment replete with a number of key built-in services such as database access, directory and naming, messaging, transaction management, and CORBA interoperability. The term Java 2 Runtime Environment (J2RE) is also sometimes used to describe a JVM in the context of Java 2. It is the availability of JVMs (or containers or J2REs in the case of Java 2) on all major platforms that makes it possible for Java to have its trademark portability. It goes without saying but is still worth mentioning just to be on the safe side that it would not be possible to execute a Java application or applet on a platform that did not contain the appropriate JVM (or container).

Java s JVM-based platform independence is realized through the use of an intermediary pseudocode known as bytecode. A Java compiler, in marked contrast to other compilers, does not convert Java code to a specific, directly executable machine code. Instead, Java compilers turn all Java code into Java-dictated, platform-neutral bytecode (i.e., the bytecode corresponding to a Java program is always the same, irrespective of which platform it was compiled on or which platform it is going to be executed on). JVMs in general will interpret this bytecode to execute the Java program ” whether it be an application or applet. Figure 6.4 illustrates the Java concept of first compiling code into bytecode and then having that bytecode interpreted by JVMs on different platforms.

click to expand
Figure 6.4: The cross-platform portability of Java is realized by first having all Java programs compiled into a platform-independent bytecode and then using interpreters within the Java virtual machine on a specific platform to interpret the bytecode.

Interpreting involves processing a line of code each time it has to be executed, even if that line of code had been previously processed . BASIC, highly popular with PC users during the 1980s, similar to Java, was typically interpreted. List-processing LISP and object-oriented SmallTalk are other well-known examples of interpreted, as opposed to compiled, languages. Interpreting code can be inefficient and result in less-than -optimum performance, since the original code is continually being reprocessed line by line without any use being made of previously processed code. With interpreted code, Java would sometimes run into situations where its performance would be characterized as being sluggish . To avoid this, various JVM implementers, led by Sun and IBM, developed so-called Just-in-Time (JIT) Java compilers.

When JIT is available with a JVM, it obviates the need for the JVM to interpret Java code. Instead, the JIT takes the previously produced bytecode and recompiles it into a native machine code that can be directly executed by the platform on which the JVM is implemented. A JIT thus takes platform-independent bytecode and makes it platform specific. Since Java is a highly object-oriented, dynamic language, it is not typically possible to compile all of a Java program until the various object-based classes within it are invoked. Hence, the term just-in-time , since JIT compilers compile the necessary Java code as and when the various classes are invoked. Having a JIT compiler on a JVM does not preclude the JVM from still being able to interpret bytecode. Thus, it is possible to have scenarios in which a JVM interprets some Java programs while relying on a JIT compiler to produce natively executable code of other Java programs.

In the 1996 to 1998 time frame, JVMs and Java compilers were made available via what used to be referred to as the Java Developer Kit (JDK). There were different JDKs for each of the platforms that supported Java, with Sun initially supplying JDKs for Sun Solaris, Windows 95, Windows NT, and the Mac. IBM, for example, had a JDK for mainframe OS/390 V1 and V2 by late 1998. A JDK, at a minimum, consisted of:

  1. A JVM for that particular platform

  2. A Java compiler to convert Java applications and applets to byte-code

  3. A set of standard foundation Java class libraries (including the source code) to facilitate the development of new Java applications and applets

  4. An applet viewer to preview and run applets in case an applet-enabled Web browser is not available

  5. A debugger for testing and fixing new Java code

JITs were optional and were only available with some JDKs. Sun came up with the term Java 2 in December 1998. Java 2 corresponded to a new level of the Java specification, which was referred to as Java 2 Platform, Standard Edition V1.2. The JDK corresponding to this 1.2 version of Java was called JDK 1.2. However, with the introduction of the overarching umbrella term Java 2 to describe the latest Java technology, JDK 1.2 became renamed Java 2 Software Developer Kit, Standard Edition (J2SDK) V1.2. Since then the term SDK , as in J2SE 1.4.2 SDK, has superseded the use of the term JDK . In today s Microsoft world, .NET Framework is the .NET equivalent of a Java JDK.

6.1.2 The basic Java argot

Given the impetus of all the major players with a vested interest in Java, as well as its pivotal and pioneering role in helping make the Web that much more dynamic and interactive, Java has expanded and evolved significantly faster than any prior programming methodology. This rapid growth has, as is to be expected, resulted in a rich and varied array of Java- related terms and concepts. This section attempts to address the most important of these so as to provide readers with enough navigational aids to be able to chart a meaningful path through contemporary Java technology.

Anybody involved with Web page development would invariably encounter the term JavaScript and possibly even JScript . Despite the similarity in their names , JavaScript is not a direct offshoot of Java. While Java and JavaScript, to be fair, are not as distinct as chalk is from cheese, their relationship is akin to that of cheese to cheesecake. For a start, JavaScript was not developed by Sun. Instead it was created by Netscape. Though JavaScript, like Java, is object oriented, it is at best a smaller and much simpler version of Java. Unlike Java, with JavaScript it is not possible to have stand-alone applications. Instead, JavaScript, which always remains in text form, only works inside an HTML-based document. JavaScript is enacted in text form by a Web browser as it is rendering standard HTML.

Unlike Java, which is always first compiled into bytecode, there is never a compilation step with JavaScript. Rather, JavaScript, which will be contained within an HTML document, is interpreted by a Web browser. Hence, Java-Script is not executed by a JVM. Neither is there any other virtual machine associated with JavaScript. JavaScript in many ways is a Java-inspired scripting extension to HTML. Despite these differences, both Java and JavaScript can be used more or less interchangeably to add dynamism , the so-called events, to a Web page. Java, however, is more powerful and extensible, whereas JavaScript is simpler to master and easier to use. Within this context, JScript is a Microsoft version of JavaScript for Internet Explorer.

In addition to JavaScript, the Java programming space now also includes servlets, JavaBeans, Enterprise JavaBeans (EJBs), and JavaServer Pages (JSPs). All of these, in marked contrast to JavaScript, are direct derivatives of Java. These technologies were also developed under the auspices of Sun. Java servlets provide Web developers with a relatively easy-to-use, Java-based mechanism for extending Web server functionality and for creating back-end connections for integrating business logic from existing business applications into new Web-based applications. A servlet is essentially a server-side applet ”albeit without a user interface. As with applets, servlets are downloaded on demand when invoked. Consistent with the Java creed, they are meant to work on any platform with any Web server.

In this respect, note that an absence of a user interface was also one of the original criteria associated with Web services until IBM postulated the concept of WSRP. Suffice to say, servlets are an ideal means for implementing Java Web services. They can also be used to create complex, platform-and server-independent applications, which could rely on Web services for some of their functionality. Servlets, per the new Java terminology, run within the context of Java containers (i.e., JVMs replete with key services). Containers for running servlets are readily available for all relevant platforms, including Microsoft s widely used IIS Web server. The freely available, open -software Apache Tomcat, for one, is a highly proven and popular container for running servlets that works with most commercial Web servers. In addition, all major Java application servers (e.g., IBM s WebSphere, BEA s WebLogic, and so on) support servlets, since they are a strategic means for developing new Web applications.

JSPs are built on top of servlets. They are somewhat analogous to the now relatively common Microsoft Active Server Pages (ASPs). The big difference is that ASPs are Microsoft IIS “centric, whereas JSPs are meant to work with any Web server. The underlying rationale for JSPs is to neatly demarcate HTML from servlet code. It enables Web developers to keep HTML separate from servlets. It is thus a technology to simplify and expedite the creation of dynamic Web content, particularly in the context of developing new Web-based applications. Given that they are built on top of servlet technology, JSPs are now often positioned as the strategic way to develop Java-based, platform-neutral, server-side applications.

JSP decouples the user-interface aspects of Web applications from those of content generation. It thus enables Web developers to change the presentation layout of a Web page or the contents of that Web page independently of each other. This separation, as should be readily appreciated, greatly simplifies the design and maintenance of complex Web applications that deal with lots of Web pages. This separation is realized through the use of XML-like tags, which typically start with <% and end with %> . These tags are used to encapsulate the content-generating program logic of a particular page and keep it separate from the HTML. In addition, these tags can be used to invoke object-based, server-side, application logic ”in particular, JavaBeans. Behind the scenes, the program logic part of a JSP is often converted to a servlet by the container that has to run it. This makes JSP processing even more efficient and expedites end-user response times.

JavaBeans are Java s powerful component architecture for designing and exploiting reusable, platform-independent software components. The JavaBeans specification defines a set of standard software APIs for the overall Java platform. It is thus the component architecture recommended for use when developing client-side Java applications or applets. JavaBeans components , often referred to as beans, can be developed and manipulated by using visual development methodology ”such as the Bean Builder tool available with the Java platform.

As a component methodology, beans can be gainfully used to develop any frequently used software entity, whether it be something as relatively simple as a button for a Web page or something more sophisticated such as a database access mechanism. JavaBeans were developed to ensure ready interoperability with Microsoft s ActiveX component architecture. Interoperability with ActiveX and other component schemes is realized through the use of bridges.

Enterprise JavaBeans are server-side, reusable beans ideally suited for implementing middleware business logic for n -tier (and, in particular, data, business logic, and client layer “oriented 3- tier ) application scenarios. EJBs take the component model of JavaBeans to the next level, so to speak, by providing a built-in, automated repertoire of server-side services. EJBs are considered to reside and run in EJB-ready containers. These containers include a standard set of EJB-related services, which include database connectivity, security, transaction management, messaging, persistence (i.e., maintenance of certain data or relationships), and concurrency (i.e., performing multiple parallel tasks ). The major Java application servers include comprehensive support for EJBs. Applications developed with EJBs, in addition to being platform independent, are normally expected to be scalable, transactional, and secure for concurrent use by multiple users.

An EJB consists of three major components:

  1. Bean class

  2. Home interface

  3. Remote interface

The bean class is what is used to implement the business logic that will be performed by an EJB. The home interface can then be used by clients to find, create, and delete instances of that EJB. Clients access the business logic of an EJB via the remote interface. There are four distinct types of EJBs: stateless session EJBs, stateful session EJBs, entity EJBs, and message-driven EJBs. The first two differ in terms of whether they are session oriented or asynchronous when it comes to transaction processing. Entity EJBs are typically used to provide an object-oriented view of database records. They can also be used to represent data accessible via existing legacy applications. Message-driven EJBs, as indicated by the name, are used in Java Message Service (JMS) “based message processing scenarios.

An overriding goal of the new EJB V2.1 specification, which was finalized in June 2003, was to position EJBs as an optimum technology for developing, deploying, and consuming Web services. Thus, it is now possible to implement a Web service as stateless session EJB. It is also now possible for EJBs to invoke and use external Web services. There is also support for WSDL.

Two other important Java programming “related terms that one is likely to encounter are AWT and Swing. Both of these refer to the user-interface aspects of Java software. AWT, which, according to Sun, stands for Abstract Windows Toolkit (though there are other variants such as Advanced Windows Toolkit), is a standard library of user interface development “related classes. AWT includes components that can be used by applets or applications for displaying and using presentation-related constructs such as buttons , menus , and scroll bars. Swing, whose official name is Project Swing, is another standard library of classes that can be used by applets or applications to create and manage sophisticated GUIs. With Swing a developer can opt for a platform-dependent look and feel or elect to have a consistent look and feel across all platforms.

Java-centric distributed computing, where necessary across disparate platforms, is facilitated by RMI ”Java s Remote Method Invocation methodology. With RMI, programmers can readily and safely invoke Java objects on remote systems ”across a network or the Web. RMI eliminates the distinction between local and remote Java objects. With RMI it is possible to access a remote object as easily as it is to access a local one.

Web Services[c] Theory and Practice
Web Services[c] Theory and Practice
ISBN: 1555582826
Year: 2006
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net