Building
eCommerce Applications Using JDeveloper
Dr.
Introduction
JDeveloper is Oracle’s Java development environment. The history of the product begins with Oracle’s purchase of JBuilder source code. The tool has since been completely rewritten and, although the products have some architectural similarities, the two products are now completely independent.
JDeveloper differs critically from other Java development tools because of its close interaction with the Oracle database via Business Components for Java (BC4J). The JDeveloper user interface components are specifically designed to take advantage of the BC4J components. A mechanism now exists to directly connect standard Java Swing components to BC4J code.
JDeveloper is evolving into Oracle’s single development tool of choice for creating applications. Its ability to easily communicate with the database through the BC4J layer makes it a logical choice for building eCommerce applications.
What is
JDeveloper Good For?
JDeveloper can be used for a variety of purposes, most obviously to create applications. In this capacity, JDeveloper directly competes with Oracle Developer Forms, Visual Basic, Power Builder and other popular Oracle development environments.
JDeveloper can also be used for other purposes. At its root, JDeveloper is a Java development tool and can support any effort where Java code needs to be written. Of great interest to those building eCommerce applications is the question: How well does JDeveloper support the creation of Java Server Pages (JSPs)? JSPs represent an “inside out” way of creating servlets. Servlets are equivalent to applets running under a client browser with the difference that servlets run on a middle tier, delivering HTML images to the browser. Previously, the underlying code to create servlets was very difficult to write so JSPs were created.
JSPs entail creating a set of tags that look much closer to HTML which are then converted to something similar to Java and then back to HTML. Java Server Pages are now considered the primary mechanism for building Internet applications. Using JSPs means primarily working with the HTML language. Here, JDeveloper support for HTML is minimal. In the JDeveloper 9i release, a new mini-install platform called UIX will be included for HTML.
The Vision –
9i release and beyond
Up through version 3.2, JDeveloper aspired to, and mostly achieved, the objective of being a leading Java development tool with clearly the best integration with Oracle databases for client/server applications. However, support for JSPs has been fairly limited up until now. This capability has been significantly enhanced in the 9i version. Currently, the direction in which JDeveloper is going with respect to JSP support is primarily functional rather than trying to make beautiful web pages.
Oracle perceives (correctly, in my opinion) that it can provide the most value to developers by enabling them to deliver Developer Forms-quality applications over the Internet as JSPs. Oracle will try to enhance the JSP editing capability of JDeveloper in order to provide this functionality. However, it is recognized that for high-quality graphics, developers should still use one of the more mature products in this area such as Microsoft’s Front Page or Macromedia’s Dreamweaver.
The big news is that, in the long run, JDeveloper will strive to be a sole Oracle design and development environment. The product will ultimately integrate and support all previous functionality from Designer, Developer and even such maintenance products as SQL Navigator or TOAD. An example of movement in this direction is the inclusion of a built-in Profiler in the JDeveloper 9i release, which allows developers to monitor applications performance statistics to help identify problems such as memory leakage.
New Features
in JDeveloper 9i
Much of what is delivered in the 9i release is an attempt to stake out new ground for areas to be supported over the long-term. Two dramatic examples of this direction include UML Class diagrams and Activity modeling.
Some may remember Oracle’s past foray into UML class diagramming, namely the Object Database Designer (ODD), which was released in conjunction with Oracle8. The goal was to provide a mechanism for specifying Oracle8 objects from the object extensions. This time, UML diagrams are primarily showing up in order to graphically design BC4J components. The functionality is still very limited in this version but it is worthwhile to work with it and provide feedback to Oracle about its usefulness and ways to improve it. The UML Class Modeler can also be used to model Java classes, although it is unclear how much value this functionality will provide.
The Activity Modeler is essentially a bolted-in version of the Oracle Workflow product, which is currently of questionable usefulness.
A fine-grain version control feature similar to that contained in Oracle Designer has been added. This is an area of the product, which, if used at all, should be used with great care. Most Designer users have found these features overly complex and not worth the significant learning curve to effectively implement them.
Our first examinations of the JDeveloper 9i release indicate that it has been completely rewritten from C++ to Java. The user interface is much cleaner than in earlier versions. Some of the generator routines have been tuned, but due to the Java rewrite, most of the product runs somewhat slower. Performance can be enhanced by using a modern, high-end PC with a 1GHz processor.
The BC4J Tester has been improved. You can now see the BC4J objects in the BC4J Tester object navigator.
Release 9i represents a nice maturation of the tool with a more user-friendly interface. However, there are enough differences from v. 3.2 that earlier users will need a few days to get accustomed to the changes. If you are contemplating using JDeveloper for application development, the tool is ready for production use. For JSP development, the product is less mature.
Learning the
New Environment
For those new to the Oracle and Java environments, be prepared for a huge learning curve. Not only will you be learning a new object-oriented language (Java) with new syntax and a new way of coding, in order to take advantage of the BC4J component of JDeveloper, you will also need to learn something about XML, JDBC and JavaScript. There are some features built into the tool to reduce the need for expertise in these areas but some understanding of how to use them will be required for successful application development and deployment.
For JSPs, in addition to learning how to build applications, developers will need knowledge of application servers, firewalls, JavaScript and one of the popular HTML editors (FrontPage, Dreamweaver). This is a much larger and more complex environment in which to build than was the case with client/server Developer applications.
While working on the JDeveloper 3 Handbook, I spent a long time trying to learn the ins and outs of the tool. At this point, my best advice is to install both versions 3.2 and 9i. Go through the hands-on tutorials from the Handbook in order to learn the concepts using version 3.2 but build the actual applications in the 9i version.
Java Server
Pages (JSPs)
The question that remains to be answered is how to safely deploy applications over the Internet so that customers can interact remotely, safely, and securely from any web browser, anywhere in the world. What is needed to implement this goal?
To build e-commerce applications you will build a BC4J project and generate Java Server Pages (JSPs). The applications will reside on an application server such as Apache Internet Server or Oracle9i Application Server. Due to firewall issues discussed earlier, these applications cannot consist of purely Java code. They must generate JSPs, which are really simple HTML code constructed dynamically by calling Java routines on the application server.
JDeveloper has limited visual editing capabilities to work with HTML pages. To build serious e-commerce or internal applications, a separate HTML product is highly recommended. The most popular alternatives are Microsoft FrontPage or Macromedia's Dreamweaver. Although you can gain some efficiency from these tools, any HTML editor will do. If you want additional client-side functionality (such as complex data validation) within your applications, you will need to extend your HTML pages using JavaScript.
How Do JSPs
Work?
A JSP is an extension of servlet technology. A servlet is a program stored and run on the web application server that accepts requests from a client browser through an HTTP data stream (posted data or URL) and constructs an HTML page by querying the database and outputting the HTML tags mixed with data from the queries. The program constructs the entire page dynamically in a similar way to a Common Gateway Interface (CGI) program.
The advantage of servlets over CGI programs is that they only require a new thread, not an entirely new process as CGI programs require. This is a significant resource savings for the application server. In addition, servlets are cached, unlike CGI output, and this provides performance benefits such as allowing the database connections to stay open. Servlets are coded entirely in Java and are therefore portable and do not need a CGI language such as Perl.
JSPs are variations on the servlet idea. They have both a dynamic and static element to them. This allows the developer to fix the parts of the application that do not change (for example, the <HTML> tag at the beginning and </HTML> tag at the end of the page). Other parts of the page that would not change would be all the static links and boilerplate graphics and text. A servlet has to generate these each time the program is run, whereas a JSP program represents the static tags exactly as it will be output. In reality, JSPs are converted to servlets when they are run, but the cleanliness of the JSP code is well worth choosing the JSP style over the servlet style. For example, for each static tag that is built into a JSP, a println() statement would be required in a servlet. Here is an example of the default JSP code that JDeveloper creates when you select JSP from the Object Gallery:
<%@ page
contentType="text/html;charset=WINDOWS-1252"%>
<HTML>
<HEAD>
<META
HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=WINDOWS-1252">
<META NAME="GENERATOR" CONTENT="Oracle
JDeveloper">
<TITLE>
Hello
World
</TITLE>
</HEAD>
<BODY>
<H2>The
following output is from JSP code:</H2><P>
<% out.println("Hello World");
%></P>
</BODY>
</HTML>
This sample mixes standard HTML tags (“< >”) and JSP tags (“<% %>”). The file extension .jsp indicates to the web server that the page requested is a JSP file. The web server passes the interpretation of the page to a JSP container that runs in a JVM on the server. The JSP container passes the HTML tags back as is and interprets the JSP-specific tags, some of which may create additional HTML-formatted output. The container then sends the entire page back to the browser.
The first time a JSP page is accessed, it creates a Java file and compiles that file into a bytecode in a .class file. For subsequent accesses, the .class file is cached on the server so that this compilation is not required unless the code is changed. The JSP container runs the .class file in its JVM session. The Java and class files are generated dynamically from the JSP source code file. The BC4J layer sits on the application server and communicates with the database as in the other models. Figure 1 shows the main elements of the JSP runtime architecture.
Figure 1: JSP architecture
Advantages of
JSPs
An advantage of the JSP solution is that each page loads quickly. JSPs send out plain HTML and are therefore small, compact, and universally readable in any browser. They transmit easily over the Internet. However, this ease of transfer is accompanied by limited functionality. The style of having to scroll through dozens of screens, making option selections on each one, is a familiar one for web applications. Simple functions such as deleting a record or changing the way information is sorted requires a reload of the page. You can increase the functionality of a JSP application dramatically by including JavaScript in the HTML page, but this solution requires that the JavaScript that you use be supported by the requirements of your users’ browsers.
The client requirement is much less than with Alternatives 1 and 2 because there is no JVM running on the client. There are no application files or Java runtime files stored or run on the client, which means that the client machine has fewer resource requirements and no special application installation. This automatically makes the JSP applications you develop compatible with a larger number of users. Since the solution is more efficient on the server side, you can support a large number of users.
The presentation look-and-feel of a page is embedded in HTML tags and cascading style sheets. Since the HTML tags are directly embedded in the JSP source file, you can split the development work. Creating the template look-and-feel for a page may be accomplished by a web graphics designer, while the dynamic JSP-specific sections would be developed by a Java programmer. Merging the work is just a matter of embedding one in the other. JDeveloper provides the tools to create and test the JSP code. The web designer would work in another tool as mentioned before.
Disadvantages
of JSPs
The main disadvantages of JSPs are in the added complexity of the JSP tags and architecture. In addition, there is added complexity with setting up the web server to support servlet API and the JSP container. The extra complexity is not insurmountable but is a daunting task for a shop that has not been involved with web technology. JDeveloper includes a wizard (the JSP Element Wizard) that helps the developer embed JSP tags into the code, and this helps the learning curve that accompanies learning a new language.
In addition, since the base language of the application is HTML, you experience the limitations of that language when constructing a page. However, there are some complex pages on the Web now that use only HTML as their language, so this limitation is solved by employing an imaginative web designer who has a modern HTML development tool.
The HTML limitation is also lifted somewhat because HTML can include embedded JavaScript. Although JavaScript does not have as many features as other programming languages such as Java, including JavaScript in an HTML page greatly extends the capabilities of the page. Therefore, developing robust JSP applications requires that the developer (or at least the development team) is skilled in Java, HTML, and JavaScript. For developers accustomed using a single language for all coding, this will feel like a step backwards.
There is another loss in functionality because JSP-generated HTML cannot use the rich features included in the AWT and Swing component libraries available for Java applications and applets. In addition, debugging is more difficult because the code is running on the server in the JSP container. JDeveloper offers remote debugging that assists in debugging JSP applications.
The Web Bean
Solution
JDeveloper provides a feature called web beans that helps solve the problem that JSPs cannot use AWT and Swing components. A web bean (or web-enabled Java Bean) is a bean that outputs HTML. For example, there is a web bean that creates an HTML version of the NavigationBar class found in the Swing components. Including JSP calls to these beans runs the bean on the server when the JSP is accessed. The bean contains properties that are set in the code you write that will tailor its behavior. There are also methods in each bean that you can call to alter the bean’s behavior or features. You can write beans that employ JavaScript for additional functionality.
The following is a sample tag structure that embeds the JSNavigationBar bean into a JSP file:
<jsp:useBean
class="oracle.jbo.html.databeans.JSNavigatorBar" id="deptNavBar" scope="request" >
<%
deptNavBar.setShowNavigationButtons(true);
deptNavBar.setReleaseApplicationResources(false);
deptNavBar.initialize(pageContext,
"testBeanPRJ_deptempbuscomp_DeptempbuscompModule.DeptView");
deptNavBar.render();
%>
</jsp:useBean>
Where Are
JSPs Useful?
JSPs are useful anywhere you would use standard CGI-generated or static HTML pages. Whenever you need a true Internet application that has no firewall limitations or Java requirements for the client, JSPs are indicated.
Using this method can, in no way, emulate the quality of
client-server applications. You will need to embrace a more rudimentary style of
application development that takes into consideration the limitations of HTML
applications. However, at this point in time, this is still the best alternative
for deploying Internet applications, especially applications responsible for
e-commerce.
Security
Issues to Consider
When thinking about system security, it is useful to identify the types of exposures that must be taken into consideration. Too often, the “solution” selected for handling these exposures is to do nothing. Many IT shops handle security by identifying possible exposures and designing a set of controls to protect against breaches of security.
In determining your security requirements, consider the potential impact of loss and the probability of that loss to your business. You should add sufficient security to your system to compensate for the possible loss of critical data at a cost commensurate with the value of the data being protected.
For example a costly cash register system was proposed for use in a 15-branch library network to track the account activity for fees collected over the counter. As good as the elaborate new cash register system was, the relatively few dollars in discrepancies that could be resolved by the expensive cash register system would never offset its cost.
If the cost of a security breach can be very large, then even a very expensive control that protects against that breach can be appropriate. For a bank processing wire transfers, the security measures required that each request be manually entered twice. Unfortunately, two data entry personnel coincidentally made the same error resulting in the loss of $1million. Subsequently, the bank modified its data entry procedure so that each wire transfer was independently input by three different data entry people. The monetary and political costs of these extra measures were justified by the potential risk of losing large amounts of money otherwise.
Exposures
With the widespread access to the Internet, there is a possibility that someone may attempt to interfere with business transactions. Larger enterprises may become targets for many types of security breaches.
Computer and manual controls can help prevent errors, fraud and sometimes help detect programming errors. Requiring a purchase order to be signed by a manager means that the orders were actually handled. Using approved lists for vendors purchase order items can help decrease data entry errors. Physically counting inventory may detect a purchasing system error. You should consider all controls and exposures together.
Database, application-level and accounting controls are not independent issues. A successful security strategy mandates integrates all three control types. The goal is to prevent exposures by reviewing all potential risk moderators to r assess whether or not the security measures taken are adequate.
Interception
of Data
The most obvious security exposure is theft of information. When you buy something over the Internet and provide your credit card number, you do not want anyone to see the information being transmitted.
This exposure requires some type of secure encryption so that, as the information moves from place to place, the bytes cannot be decoded if they are intercepted.
System
Hacking
Because some users accessing your system can do so through the Internet, the same Internet portal could be used to enter your system with malicious intent.
To prevent system hacking, you access to your site must be limited. This may be a complex problem to solve. You may need some applications accessible to everyone but only with limited capability. A visitor to a commercial website should be able to place an order for a product by entering the relevant information. You may want to allow customers to access their own account information. At the other end of the spectrum, your web administrator may need to access the entire system remotely and make substantial modifications remotely. Obviously, this capability should not be publicly accessible.
The Oracle server should not be visible outside of your firewall. If the server needs to be visible outside of the firewall (for remote DBA access), you will need to change all of Oracle’s default passwords. Don’t forget about SCOTT/TIGER since the SCOTT schema has resource privileges.
Keeping an audit trail is another good security measure. Employees wishing to inappropriately access company information might do so by gaining access from a remote site (such as an Internet café) to minimize the risk of being caught. You need to plan for security controls not only to prevent outsiders from damaging your system but also insiders who may have intimate knowledge of your system.
Interception/Alteration
of a Business Event
In some systems, the interception or alteration of a business event may not be a major concern. If you are a retailer, you probably have little risk that anyone would go to the trouble of intercepting and altering orders. However, credit card information or other sensitive data must be transmitted securely. If the transaction is of significant size or involves the transfer of large sums of money, the motivation to alter such a transaction is high. You must pay special attention to security measures to prevent this type of fraud.
The solution to this exposure is essentially the same as for the interception of data. Data that is encrypted to prevent interception also cannot be altered. The key to a good security plan is to have more than one control for any type of exposure. If the first control fails, there should be additional control measures for all exposures.
Overloading
Attacks
This exposure involves generating of large numbers of fraudulent transactions that crash a site. This may appear to be a difficult exposure to guard against but the only web sites damaged by this type of attack are those that do not anticipate it.
Most overloading attacks come from the same Internet Provider (IP) address. You can detect and count transactions from any one IP address. If the transactions from any one IP address exceed a certain number, access from that address can be cut off.
Security for
Your Applications
Application security revolves around issues that center on your hardware and on the communications that occur between your application and other resources. When evaluating the overall integrity of your application, you must explore how memory is utilized in your box, what happens when buffers overflow, and what privileges have been granted to applications that may be running on, or interacting with, your machine. Also, you should consider what happens to the data after your application receives it. There is a popular protocol developed by Netscape called the Secure Sockets Layer (SSL) that provides a software layer in between your browser application and the TCP/IP layers. It does little good to implement a Secure Sockets Layer transfer from your client machines, and then use an open email link across the Internet to communicate the results. A security system is like a chain—it is only as strong as its weakest link. You must consider the strength of each link in the entire chain of your data flow in order to ensure full security.
Your choice of operating system and peripheral applications can have a significant impact on overall security. For example, older-style file transfer programs (FTP) can leave big holes in your security if they are based on the older FTP protocol. Newer extensions of HTTP such as HTTPS that can be protected with SSL can often replace these older programs. It is also important to review your user accounts and the privileges that you have granted them. Since any account can ultimately be compromised, it is important to limit the system-level privileges that you grant, thus reducing the chance that you will compromise the entire system. Hardware decisions such as the prudent use of routers and firewalls can also help to isolate data paths in your network, thus giving you better protection for your critical assets.
After reviewing the security for your system, don’t forget the physical environment that surrounds your system. Everything—leaky roofs, water lines, chemical exposure, dust, temperature controls, humidity, earthquake, flooding, lighting, electrical surges, locked doors—should be considered in your security plan. At an Internet company that one of the authors worked at recently, the security experts deliberated long and hard about how protected their servers would be if someone tried to drive an armored truck through the plate glass walls of their building. It makes little difference what you include in your system assessment if anyone can walk up and gain access to your servers or if you locate your critical machines in an environment where they can be easily compromised.
Java
Security
Security issues have been a top priority in design considerations from the inception of the Java language. Traditional constructs such as pointers were eliminated to prevent Java routines from accessing other parts of memory. Flexible security mechanisms such as permission levels, digital certificates, cryptographic keys, and signed files were added. These mechanisms are used to control code and machine access, identify users, hide data, and provide additional privileges to trusted sources.
One of the traditional deployment options for Java uses a client browser to display a Java applet. Applets are very secure by design and, unless they are given special permissions, cannot interact with other system resources (such as reading or writing files). Java uses a combination of policy, security, and certification files to track and control your security preferences. You may find several sets of these files on your system, as each Java-related product might have its own set. The default security files used by Sun Microsystems follow:
· java.policy Basic policy file that stores your default permissions to access specified properties, allow thread stopping, and grant socket listening privileges.
· java.security Master security properties file that stores information about your registered Cryptography Package Providers, system-wide policy files, IdentityScope use, keystore type, and package access definitions.
· cacerts System-wide repository for trusted certificates. This file currently ships with a limited number of trusted certificates from certification authority providers, such as VeriSign.
You can find these Java security-related files in directories such as:
·
JDeveloper JDEV_HOME\java1.2\jre\lib\security
·
Oracle8i ORACLE_HOME\javavm\lib\security
· Oracle run time D:\Program Files\Oracle\jre\x.x.x\lib\security
Other security files may also exist on your system depending upon which client tools and applications you need to support. Microsoft has its own set of security utilities designed for Internet Explorer. Whereas Sun and Netscape use .jar and .zip files to store their Java code, Microsoft uses a slightly different format called a cabinet (CAB). Microsoft also stores its public and private keys in a different way, requiring the use of additional tools to provide security across the contending technologies.
Keep in mind that, by default, Java class files are vulnerable to decompilation. In other words, it is very easy to produce source code from Java classes or jars. Most IDEs now have code obfuscators that remove all the things developers do to make source code readable (e.g. descriptive variable naming, indentation, etc.). Unfortunately, as yet, JDeveloper does not include a code obfuscator. If you want your java code to be proprietary and remain proprietary, you will need to take specific actions to protect it.
Java Applet
Permissions
Java programs can be deployed in many ways, including Java applications, applets, servlets, and Java Server Pages (JSPs). Reviewing the security tools that are used with applets and Java applications will give you a basic introduction to the principles involved in controlling the security for your Java programs whether they are deployed as Java application, applet, or JSP applications.
Traditional Java applications are designed to run in a standalone mode on a client machine and have few security restrictions or requirements. Applets, on the other hand, are designed to run on a client browser after being downloaded from the Internet. Since the Internet is essentially an open environment, applets have significantly higher security requirements. The default security level for applets prevents them from having any potentially damaging interaction with your operating system by limiting their ability to see or modify other assets on your system. For instance, they cannot read or write to the file system, or have access to system memory outside of a well-defined area.
You can change this default security behavior by using the Java security APIs or other third-party toolsets. For example, you can modify the permissions for a specific applet, giving it the ability to interact with the operating system and perform file-handling commands that are generally limited to applications. On the other hand, by packaging an application in a .jar file and specifying the appropriate permissions, you can modify the security requirements for an application until it is constrained just like an applet. Each browser has minor variations in how it handles these modified security requirements.
Note: It is important for novice Java programmers and designers to understand how database connectivity affects applets. Applets can only communicate (via TCP/IP) with the web server from which they are invoked. Therefore, you either need to put the database on the web server (this is not recommended) or delegate all database access to a servlet, JSP, Remote Method Invocation (RMI) Service, or CORBA service that is used by the applet (this is recommended).
Deployment
Issues
Workspaces and projects in JDeveloper are logical text files that act as pointers to physical objects. As you create subdirectories, each will become a nested package inside of a Java Archive (JAR). Within projects, there will be multiple nested packages.
Many projects can point to the same package. Workspaces themselves are not deployed. With BC4J projects, you may want to create BC4J workspaces to allow you to use the BC4J projects in different applications. This means that there will be an original BC4J project and workspace and an application that references the original BC4J project.
When you deploy the application, be sure to deploy your original objects first into a JAR. This JAR is attached as a library to the application as shown in Figure 2.
Figure 2: Accessing Java Libraries
This can be done after deploying the BC4J project by pointing at it in the Object Navigator and selecting the following from the menu: Project/Deploy/New Development Profile. This will provide access to the Development Profile Wizard.
File
Locations for Deployment
When actually writing a BC4J program, you are using Java code from many sources since, in Java, everything is a class. Buttons, fields, etc. are all stored in library classes in various places invisible to the developer building the application. When deploying on a machine that does not have the entire JDeveloper environment, you need to find and copy all of the pieces being accessed into a deployment directory in order to deliver the completed application. There are three steps in this process:
1. Determine what and where the necessary components (JAR files) are. Using the Deployment Wizard Project Tab, click the Advanced button and check the option “General scripts for setting the class path in a command shell.” This will create a profile.bat in your specified deployment directory and produce a set path class demand with a semi-colon delimited list of the JAR files.
2. Copy the JAR files into a deployment directory. Using the information in the path statement, use Windows Explorer to find and copy the appropriate files into your deployment directory.
3. Modify the application’s profile (a class path variable) so that the JVM will be able to find the JARs when called. Modify the profile.bat file to point to the one deployment directory. NOTE: A slightly different mechanism must be used for deploying JSPs, which is beyond the scope of this paper.
Conclusions
JDeveloper is fully capable of building very complex applications that go well beyond the capabilities of products like Oracle Developer Forms. However, be aware that this is a newer, less mature environment where you will encounter some significant growing pains.
There are dozens of issued similar to those mentioned here, each one of which will require significant research to resolve. In all fairness, for experienced Forms developers, recall trying to make Forms do something new for the first time. It is the same process in JDeveloper. Using this new tool will provide a much more sophisticated development environment, capable of supporting both client/server and Internet applications. However, don’t expect the transition to be easy, cheap or painless.
References
The following sources have been helpful in understanding the development environment surrounding the creation of applications using JDeveloper.
Effective JavaTM Programming Language
Guide (The JavaTM) Series)
by Joshua
Bloch, Addison Wesley Professional, 2001, ISBN: 0201310058
Java 2: The Complete
Reference
(Osborne Complete Reference Series)
by
Herbert Schildt McGraw-Hill Professional Publishing, 2000, ISBN: 0072130849
The JavaTM Tutorial: A Short Course on
the Basics (The JavaTM Series)
by Mary
Campione, Kathy
Walrath, Alison
Huml, Addison-Wesley Pub
Co; 2000, ISBN: 0201703939
Oracle JDeveloper 3
Handbook, by Dr.
Refactoring: Improving the Design of Existing Code, by Martin Fowler, Addison-Wesley Pub Co., ISBN: 0201485672.