Update the PATH variable

You can run the Java 2 SDK without setting the PATH variable, or you can optionally set it as a convenience.

Should I set the PATH variable?
Set the PATH variable if you want to be able to conveniently run the Java 2 SDK executables (javac.exe, java.exe, javadoc.exe, etc.) from any directory without having to type the full path of the command. If you don't set the PATH variable, you need to specify the full path to the executable every time you run it, such as:

    C:> \j2sdk1.4.2_\bin\javac MyClass.java 

It's useful to set the PATH permanently so it will persist after rebooting.

How do I set the PATH permanently?
To set the PATH permanently, add the full path of the j2sdk1.4.2_\bin directory to the PATH variable. Typically this full path looks something like C:\j2sdk1.4.2_\bin. Set the PATH as follows, according to whether you are on Microsoft Windows NT or 98/2000/ME.

Microsoft Windows NT, 2000, and XP - To set the PATH permanently:

1. Choose Start, Settings, Control Panel, and double-click System. On Microsoft Windows NT, select the Environment tab; on Microsoft Windows 2000 select the Advanced tab and then Environment Variables. Look for "Path" in the User Variables and System Variables. If you're not sure where to add the path, add it to the right end of the "Path" in the User Variables. A typical value for PATH is:

        C:\j2sdk1.4.2_\bin
   

   Capitalization doesn't matter. Click "Set", "OK" or "Apply".

   The PATH can be a series of directories separated by semi-colons (;). Microsoft Windows looks for programs in the PATH directories in order, from left to right. You should only have one bin directory for a Java SDK in the path at a time (those following the first are ignored), so if one is already present, you can update it to j2sdk1.4.2_\bin.

2. The new path takes effect in each new Command Prompt window you open after setting the PATH variable.

Microsoft Windows 98 - To set the PATH permanently, open the AUTOEXEC.BAT file and add or change the PATH statement as follows:

1. Start the system editor. Choose "Start", "Run" and enter sysedit, then click OK. The system editor starts up with several windows showing. Go to the window that is displaying AUTOEXEC.BAT

2. Look for the PATH statement. (If you don't have one, add one.) If you're not sure where to add the path, add it to the right end of the PATH. For example, in the following PATH statement, we have added the bin directory at the right end:

   PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\J2SDK1.4.2_\BIN
   

   Capitalization doesn't matter. The PATH can be a series of directories separated by semi-colons (;). Microsoft Windows searches for programs in the PATH directories in order, from left to right. You should only have one bin directory for a Java SDK in the path at a time (those following the first are ignored), so if one is already present, you can update it to j2sdk1.4.2_.

3. To make the path take effect in the current Command Prompt window, execute the following:

         C:> c:\autoexec.bat 

   To find out the current value of your PATH, to see if it took effect, at the command prompt, type:

         C:> path 

Microsoft Windows ME - To set the PATH permanently:

From the start menu, choose programs, accessories, system tools, and system information. This brings up a window titled "Microsoft Help and Support". From here, choose the tools menu, then select the system configuration utility. Click the environment tab, select PATH and press the edit button. Now add the SDK to your path as described in step b above. After you've added the location of the SDK to your PATH, save the changes and reboot your machine when prompted.

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Network Server Options

By default, the Derby Network Server only accepts requests from the localhost on port 1527. You can modify the Network Server to:

• Listen on a port other than the default.
• Accept requests from outside the localhost.
• Run in the Java 2 Security Manager for increased security, which we strongly recommend.

For more information about these options, and more, see the Derby Server and Administration Guide.

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Stop Network Server

Stop the Network server by executing the stopNetworkServer.bat (Windows) or stopNetworkServer.ksh (UNIX) script, as shown below:

Windows: C:\> cd %DERBY_INSTALL%\bin C:\Apache\db-derby-10.4.1.3-bin\bin> setNetworkServerCP.bat C:\Apache\db-derby-10.4.1.3-bin\bin> stopNetworkServer.bat

UNIX: $ cd $DERBY_INSTALL/bin $ . setNetworkServerCP.ksh $ stopNetworkServer.ksh

The window running the NetworkServer should output a message confirming the shutdown.

Note that, as with starting the server, there is also an easier way to shut down the server. For example:

Windows: C:\> java -jar %DERBY_INSTALL%\lib\derbyrun.jar server shutdown

UNIX: $ java -jar $DERBY_INSTALL/lib/derbyrun.jar server shutdown

Run derbyrun.jar without arguments for further usage information. derbyrun.jar has been included with Derby releases since the 10.2 release series.

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Get a Network Server Connection

When executed with the derbyclient argument, the SimpleApp application creates and connects to the derbyDB database with this code:

protocol = "jdbc:derby://localhost:1527/"; ... conn = DriverManager.getConnection(protocol + "derbyDB;create=true", props);

That connection URL, fully constructed, looks like this:

jdbc:derby://localhost:1527/derbyDB;create=true

Don't shut Derby down

If you look at the SimpleApp.java code you'll notice that it only shuts Derby down if it's running in embedded mode. When connecting via the Network Server, other applications might be accessing the same database you are; so, don't shut down the databases or Derby.

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Load the Client JDBC Driver

When executed with the derbyclient argument, the SimpleApp application loads the Derby Network Client driver with this code:

driver = "org.apache.derby.jdbc.ClientDriver"; ... Class.forName(driver).newInstance();

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Test network server connection

An embedded connection URL that creates and connects to a database looks like this:

java org.apache.derby.tools.ij ij> connect 'jdbc:derby:MyDbTest;create=true';

A Derby Network Client connection URL is very close; just add //localhost:1527/ before the database name:

java org.apache.derby.tools.ij ij> connect 'jdbc:derby://localhost:1527/MyDbTest;create=true';

What is the physical location of the newly created database?

If you use the embedded driver, by default the database is created in the same directory in which ij was started up. If you use the Derby Network Client JDBC driver, by default the database is created in the directory where the Network Server was started up; in other words, in DERBY_INSTALL/bin.

Derby provides many ways to specify the actual location. For example, the connection URL below specifies a full path for the database location:

java org.apache.derby.tools.ij ij> connect 'jdbc:derby://localhost:1527//home/bill/DerbyDb/MyDbTest;create=true';

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Configure environment to use Derby Network Client JDBC driver

To use the Derby Network Client JDBC driver, set your CLASSPATH to include the jar files listed below:

• derbyclient.jar: contains the JDBC driver
• derbytools.jar: optional, provides the ij tool

You can set your CLASSPATH explicitly with the command shown below:

Windows: C:\> set CLASSPATH=%DERBY_INSTALL%\lib\derbyclient.jar;%DERBY_INSTALL%\lib\derbytools.jar;.

UNIX: $ export CLASSPATH=$DERBY_INSTALL/lib/derbyclient.jar:$DERBY_INSTALL/lib/derbytools.jar:.

You can also use the script that the Derby software distribution provides to set CLASSPATH. Change directory to the DERBY_INSTALL/bin directory, then execute the setNetworkClientCP.bat (Windows) or setNetworkClientCP.ksh (UNIX) script as shown below:

Windows: C:\Apache\db-derby-10.4.1.3-bin\bin> setNetworkClientCP.bat

UNIX: $ . setNetworkClientCP.ksh

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Start Network Server

Start the Network server by executing the startNetworkServer.bat (Windows) or startNetworkServer.ksh (UNIX) script. This will start the Network Server up on port 1527 and echo a startup message:

Windows: C:\Apache\db-derby-10.4.1.3-bin\bin> startNetworkServer.bat Security manager installed using the Basic server security policy. Apache Derby Network Server - 10.4.1.3 - (648739) started and ready to accept connections on port 1527 at 2008-04-28 17:13:13.921 GMT

UNIX: $ startNetworkServer.ksh Security manager installed using the Basic server security policy. Apache Derby Network Server - 10.4.1.3 - (648739) started and ready to accept connections on port 1527 at 2008-04-30 09:35:55.871 GMT

Messages will continue to be output to this window as the Network Server processes connection requests.

The Network Server starts Derby, so you'll find the derby.log error log in the directory where you start the Network Server.

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Derby Network Server

Introduction

As explained in the "Embedded Derby" section, an application can embed Derby, which means that the Derby engine runs in the same JVM as the application.

However, an application can also access a Derby database using the more familiar client/server mode. This is achieved via a framework that embeds Derby and handles database requests from applications, including applications running in different JVMs on the same machine or on remote machines. The Derby Network Server is such a framework. It embeds Derby and manages requests from network clients, as depicted in Figure 2.

Figure 2: Derby Network Server Architecture

This section shows how to start the Derby Network Server, configure your environment to use the Derby Network Client JDBC driver, and compile and run a simple Java application that uses the network server. The information presented here is minimal, just enough to help get new users started. For complete information, see part one of the Derby Server and Administration Guide.

Derby Network Server

First set the DERBY_INSTALL environment variable.

Configure environment

To start or stop the Network Server, set your CLASSPATH to include the jar files listed below:

• derbynet.jar: contains the code for the Derby Network Server and a reference to the engine jar file (derby.jar)
• derbytools.jar: contains Derby tools

You can set your CLASSPATH explicitly with the command shown below:

Windows: C:\> set CLASSPATH=%DERBY_INSTALL%\lib\derbytools.jar;%DERBY_INSTALL%\lib\derbynet.jar;.

UNIX: $ export CLASSPATH=$DERBY_INSTALL/lib/derbytools.jar:$DERBY_INSTALL\lib\derbynet.jar:.

You can also use the script that the Derby software distribution provides to set CLASSPATH. Change directory to the DERBY_INSTALL/bin directory, then execute setNetworkServerCP.bat (Windows) or setNetworkServerCP.ksh (UNIX), as shown below:

Windows: C:\> cd %DERBY_INSTALL%\bin C:\Apache\db-derby-10.4.1.3-bin\bin> setNetworkServerCP.bat

UNIX: $ cd $DERBY_INSTALL/bin $ . setNetworkServerCP.ksh

Start Network Server

Start the Network server by executing the startNetworkServer.bat (Windows) or startNetworkServer.ksh (UNIX) script. This will start the Network Server up on port 1527 and echo a startup message:

Windows: C:\Apache\db-derby-10.4.1.3-bin\bin> startNetworkServer.bat Security manager installed using the Basic server security policy. Apache Derby Network Server - 10.4.1.3 - (648739) started and ready to accept connections on port 1527 at 2008-04-28 17:13:13.921 GMT

UNIX: $ startNetworkServer.ksh Security manager installed using the Basic server security policy. Apache Derby Network Server - 10.4.1.3 - (648739) started and ready to accept connections on port 1527 at 2008-04-30 09:35:55.871 GMT

Messages will continue to be output to this window as the Network Server processes connection requests.

The Network Server starts Derby, so you'll find the derby.log error log in the directory where you start the Network Server.

An easier way: derbyrun.jar

Furthermore, it is much easier to start Network Server now than before, due to various jar file improvements. With the latest releases, the entire sections "Configure environment" and "Start Network Server" could actually be replaced with just one command line:

Windows: C:\Apache\db-derby-10.4.1.3-bin\lib> java -jar derbyrun.jar server start Security manager installed using the Basic server security policy. Apache Derby Network Server - 10.4.1.3 - (648739) started and ready to accept connections on port 1527 at 2008-04-28 17:13:13.921 GMT

UNIX: $ java -jar derbyrun.jar server start Security manager installed using the Basic server security policy. Apache Derby Network Server - 10.4.1.3 - (648739) started and ready to accept connections on port 1527 at 2008-04-30 09:35:55.871 GMT

Sample Application

Open a new window and set the DERBY_INSTALL environment variable.

Configure environment to use Derby Network Client JDBC driver

To use the Derby Network Client JDBC driver, set your CLASSPATH to include the jar files listed below:

• derbyclient.jar: contains the JDBC driver
• derbytools.jar: optional, provides the ij tool

You can set your CLASSPATH explicitly with the command shown below:

Windows: C:\> set CLASSPATH=%DERBY_INSTALL%\lib\derbyclient.jar;%DERBY_INSTALL%\lib\derbytools.jar;.

UNIX: $ export CLASSPATH=$DERBY_INSTALL/lib/derbyclient.jar:$DERBY_INSTALL/lib/derbytools.jar:.

You can also use the script that the Derby software distribution provides to set CLASSPATH. Change directory to the DERBY_INSTALL/bin directory, then execute the setNetworkClientCP.bat (Windows) or setNetworkClientCP.ksh (UNIX) script as shown below:

Windows: C:\Apache\db-derby-10.4.1.3-bin\bin> setNetworkClientCP.bat

UNIX: $ . setNetworkClientCP.ksh

Test network server connection with ij

An embedded connection URL that creates and connects to a database looks like this:

java org.apache.derby.tools.ij ij> connect 'jdbc:derby:MyDbTest;create=true';

A Derby Network Client connection URL is very close; just add //localhost:1527/ before the database name:

java org.apache.derby.tools.ij ij> connect 'jdbc:derby://localhost:1527/MyDbTest;create=true';

What is the physical location of the newly created database?

If you use the embedded driver, by default the database is created in the same directory in which ij was started up. If you use the Derby Network Client JDBC driver, by default the database is created in the directory where the Network Server was started up; in other words, in DERBY_INSTALL/bin.

Derby provides many ways to specify the actual location. For example, the connection URL below specifies a full path for the database location:

java org.apache.derby.tools.ij ij> connect 'jdbc:derby://localhost:1527//home/bill/DerbyDb/MyDbTest;create=true';

The Developer's Guide provides information about where Derby looks for databases:

• Connecting to databases
• Defining the system directory

Copy sample application

This section uses the same sample application that the "Embedded Derby" section uses.

By default this application runs in embedded mode. If you pass it the derbyclient argument at run time, then it will create and connect to the database using the Derby Network Client JDBC driver instead.

A quick look at the code

The SimpleApp.java application spends most of its time creating a table, inserting data into that table, and selecting the data back, demonstrating many JDBC calls as it does so. This section highlights the JDBC calls that make this specifically a client/server Derby application. The "Embedded Derby" section shows how to turn the same code into an embedded application.

Load the Client JDBC Driver

When executed with the derbyclient argument, the SimpleApp application loads the Derby Network Client driver with this code:

driver = "org.apache.derby.jdbc.ClientDriver"; ... Class.forName(driver).newInstance();

Get a Network Server Connection

When executed with the derbyclient argument, the SimpleApp application creates and connects to the derbyDB database with this code:

protocol = "jdbc:derby://localhost:1527/"; ... conn = DriverManager.getConnection(protocol + "derbyDB;create=true", props);

That connection URL, fully constructed, looks like this:

jdbc:derby://localhost:1527/derbyDB;create=true

Don't shut Derby down

If you look at the SimpleApp.java code you'll notice that it only shuts Derby down if it's running in embedded mode. When connecting via the Network Server, other applications might be accessing the same database you are; so, don't shut down the databases or Derby.

Compile Sample Application

Compile the sample application as shown below:

javac SimpleApp.java

Run Sample Application

Run the sample application like this:

java SimpleApp derbyclient

You should see the output shown below:

SimpleApp starting in derbyclient mode. Loaded the appropriate driver. Connected to and created database derbyDB Created table derbyDB Inserted 1956 Webster Inserted 1910 Union Updated 1956 Webster to 180 Grand Updated 180 Grand to 300 Lakeshore Verified the rows Dropped table derbyDB Closed result set and statement Committed transaction and closed connection SimpleApp finished

Quick question: Where is the physical location of the derbyDB database that the sample application creates?

(Answer: In the default $DERBY_INSTALL/bin location.)

Stop Network Server

Stop the Network server by executing the stopNetworkServer.bat (Windows) or stopNetworkServer.ksh (UNIX) script, as shown below:

Windows: C:\> cd %DERBY_INSTALL%\bin C:\Apache\db-derby-10.4.1.3-bin\bin> setNetworkServerCP.bat C:\Apache\db-derby-10.4.1.3-bin\bin> stopNetworkServer.bat

UNIX: $ cd $DERBY_INSTALL/bin $ . setNetworkServerCP.ksh $ stopNetworkServer.ksh

The window running the NetworkServer should output a message confirming the shutdown.

Note that, as with starting the server, there is also an easier way to shut down the server. For example:

Windows: C:\> java -jar %DERBY_INSTALL%\lib\derbyrun.jar server shutdown

UNIX: $ java -jar $DERBY_INSTALL/lib/derbyrun.jar server shutdown

Run derbyrun.jar without arguments for further usage information. derbyrun.jar has been included with Derby releases since the 10.2 release series.

Next Steps

Network Server Options

By default, the Derby Network Server only accepts requests from the localhost on port 1527. You can modify the Network Server to:

• Listen on a port other than the default.
• Accept requests from outside the localhost.
• Run in the Java 2 Security Manager for increased security, which we strongly recommend.

For more information about these options, and more, see the Derby Server and Administration Guide.

Embedded Server

Up until this point, this section has focused on how to start and stop the Network Server as an independent process.

Another option, called the "embedded server", allows an application to load the embedded JDBC driver for its own use and start the Network Server to allow remote access by applications running in other JVMs. The application that does this can access the database with either the embedded driver or the client driver.

Figure 3 depicts an application called MyEmbedSrvApp that loads the embedded driver and also starts up the Network Server. This allows other applications, such as ij or SimpleApp using the Derby Network Client, to connect to the same database via a client JDBC driver.

Figure 3: Derby Embedded Server Architecture

While it is certainly possible for MyEmbedSrvApp to use the Derby Network Client JDBC driver, it's probably better for it to use the embedded driver because Derby Network Client JDBC database requests incur the overhead of going out through the network. The embedded server architecture lets the application that embeds Derby retain the advantages of embedded access while also enabling remote access to the same database using another tool, such as ij. Thus, you end up with the best of both worlds: embedded and client/server.

You've reached the end of this Derby tutorial and should now understand how to use Derby in the embedded and Network Server frameworks.

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Embedded Derby

ntroduction

When an application accesses a Derby database using the Embedded Derby JDBC driver, the Derby engine does not run in a separate process, and there are no separate database processes to start up and shut down. Instead, the Derby database engine runs inside the same Java Virtual Machine (JVM) as the application. So, Derby becomes part of the application just like any other jar file that the application uses. Figure 1 depicts this embedded architecture.

Figure 1: Derby Embedded Architecture

This section shows how to compile and run a simple Java application using the Derby Embedded JDBC driver. The information presented is deliberately simple. For complete information, see the Derby Developer's Guide.

Set the environment

To set up the environment, follow the "Configure Embedded Derby" instructions.

Sample Application

Copy sample application

The Derby software includes a sample application called SimpleApp.java. In Derby 10.2 and above it is located in the DERBY_INSTALL/demo/programs/simple/ directory. (In Derby 10.1 it is located in the DERBY_INSTALL/demo/simple/ directory.) Copy that application into your current directory.

By default this application runs in embedded mode and does the following:

• Starts up the Derby engine
• Creates and connects to a database
• Creates a table
• Inserts data
• Updates data
• Selects data
• Drops a table
• Disconnects
• Shuts down Derby

A quick look at the code

The SimpleApp.java application spends most of its time creating a table, inserting data into that table, and selecting the data back, demonstrating many JDBC calls as it does so. This section highlights the JDBC calls that make this specifically an embedded Derby application. The "Derby Network Server" section shows how the same JDBC calls turn the same code into a client/server application.

Load the Embedded JDBC Driver

The SimpleApp application loads the Derby Embedded JDBC driver and starts Derby up with this code:

public String driver = "org.apache.derby.jdbc.EmbeddedDriver"; ... Class.forName(driver).newInstance();

Get an Embedded Connection

The SimpleApp application creates and connects to the derbyDB database with this code:

public String protocol = "jdbc:derby:"; ... conn = DriverManager.getConnection(protocol + "derbyDB;create=true", props);

That embedded connection URL, fully constructed, looks like this:

jdbc:derby:derbyDB;create=true

Shut Derby down

A clean shutdown performs a checkpoint and releases resources. If an embedded application doesn't shut down Derby, a checkpoint won't be performed. Nothing bad will happen; it just means that the next connection will be slower because Derby will run its recovery code.

Code to shut down a specific database looks like this:

DriverManager.getConnection("jdbc:derby:MyDbTest;shutdown=true");

Code to shut down all databases and the Derby engine looks like this:

DriverManager.getConnection("jdbc:derby:;shutdown=true");

The SimpleApp.java code uses the second call to shut down all databases and the engine. You might also notice that it tests for a SQL exception. A clean shutdown always throws SQL exception XJ015, which can be ignored.

Compile sample application

Compile the sample application as shown below:

javac SimpleApp.java

You can safely ignore any compile warnings that might pop up.

Run sample application

Run the sample application like this:

java SimpleApp

You should see the output shown below:

SimpleApp starting in embedded mode. Loaded the appropriate driver. Connected to and created database derbyDB Created table derbyDB Inserted 1956 Webster Inserted 1910 Union Updated 1956 Webster to 180 Grand Updated 180 Grand to 300 Lakeshore Verified the rows Dropped table derbyDB Closed result set and statement Committed transaction and closed connection Database shut down normally SimpleApp finished

If instead you see an error like the one below, it means the class path is not correctly set:

java SimpleApp SimpleApp starting in embedded mode. exception thrown: java.lang.ClassNotFoundException: org.apache.derby.jdbc.EmbeddedDriver at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at SimpleApp.go(SimpleApp.java:77) at SimpleApp.main(SimpleApp.java:61) SimpleApp finished

For help resolving class path problems, see the "Configure Embedded Derby" and "Verify Derby" instructions.

Embedded Derby supports multiple users in one JVM

Derby supports multiple connections to a given database. An example of an embedded application that manages concurrent users is a Tomcat or Geronimo application server that embeds Derby. Any number of users can execute Web applications that access a database through that Web server.

However, only one JVM may boot ("open") that database, so multiple applications running in different JVMs cannot access the same database. To understand this better, do the following.

The SimpleApp application created a database called derbyDB. In one window connect to this database with ij as shown below:

java org.apache.derby.tools.ij ij version 10.4 ij> connect 'jdbc:derby:derbyDB'; ij>

Now, in another window try to run your SimpleApp application:

java SimpleApp SimpleApp starting in embedded mode Loaded the appropriate driver ----- SQLException ----- SQL State: XJ040 Error Code: 40000 Message: Failed to start database 'derbyDB', see the next exception for details. ----- SQLException ----- SQL State: XSDB6 Error Code: 45000 Message: Another instance of Derby may have already booted the database C:\Apache\db-derby-10.4.1.3-bin\tutorial\derbyDB. SimpleApp finished

The connection that SimpleApp tries to establish fails because another application, ij, is already connected to the derbyDB database.

The problem is ij and SimpleApp are running in different JVMs and a given database can only be accessed from one JVM. The first application to connect "wins", in this case ij, and prevents other applications from connecting.

In fact, you can establish multiple connections to a given database from different JVMs. That's the topic of the next section

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

ij Basics

Introduction

ij is an interactive SQL scripting tool that comes with Derby. It can be used with the Derby Embedded JDBC driver or with a client JDBC driver, such as the Derby Network Client.

This section uses the Derby Embedded JDBC driver to introduce a few ij features. The information presented here is minimal, just enough to get you started. For a more complete introduction, see the Getting started with ij section in the Tools and Utilities Guide.

Set the environment

To set up the environment, follow the "Configure Embedded Derby" instructions.

Start up ij

Start up ij with this command:

java org.apache.derby.tools.ij

You should see the output shown below:

ij version 10.4 ij>

The error below means the class path isn't set correctly:

java org.apache.derby.tools.ij Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/derby/tools/ij

For help resolving class path problems, see the "Configure Embedded Derby" and "Verify Derby" instructions.

Create a database

To create a database, specify the create=true attribute in the connection URL. For example, the command below creates a new database called MyDbTest:

ij> connect 'jdbc:derby:MyDbTest;create=true';

Now exit ij:

ij> exit;

List the contents of your directory with ls (UNIX) or dir (Windows). On UNIX you'll see output like this:

$ ls MyDbTest derby.log

The MyDbTest directory contains the files that make up the database you just created. The derby.log file is an error log, which is helpful whenever things don't work as expected.

Connect to a database

Start up ij again and connect to the database you just created:

java org.apache.derby.tools.ij ij> connect 'jdbc:derby:MyDbTest';

We'll take a quick look at the protocol ("jdbc:derby:") and database ("MyDbTest") in this connection URL.

Protocol

Internally, ij determines by default which driver to load from the protocol ("jdbc:derby:"). In this case, it knows to load the embedded JDBC driver. We could also have specified the protocol with a property as shown below:

java -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij ij> connect 'MyDbTest';

For more information about ij startup properties see Starting ij using properties in the Tools and Utilities Guide.

Database

Connecting to the MyDbTest database in the connection URL above works because the MyDbTest database directory is in the current working directory; i.e., the directory where you started up ij.

Let's say that your current directory location is /home/bill/databases and that you decide to change your directory to a different place entirely. You can connect to the MyDbTest database by specifying the complete directory path, like this:

java org.apache.derby.tools.ij ij> connect 'jdbc:derby:/home/bill/databases/MyDbTest';

You could also specify the Derby system home for the database like this:

java org.apache.derby.tools.ij -Dderby.system.home=/home/bill/databases ij> connect 'jdbc:derby:MyDbTest';

The Developer's Guide provides information about where Derby looks for databases:

• Connecting to databases
• Defining the system directory

Execute SQL statements

Once you connect to a database, you can execute SQL statements. ij expects each statement to be terminated with a semicolon (;); for example:

ij> create table derbyDB(num int, addr varchar(40)); ij> insert into derbyDB values (1956,'Webster St.'); ij> insert into derbyDB values (1910,'Union St.'); ij> update derbyDB set num=180, addr='Grand Ave.' where num=1956; ij> select * from derbyDb;

Disconnect from a database

The disconnect command disconnects from the current database:

ij> disconnect;

Exit

The exit command quits out of ij and, in embedded mode, shuts down the Derby database:

ij> exit;

Run SQL Scripts

You can execute SQL scripts in ij as shown below:

ij> run 'my_file.sql';

You can also run SQL scripts from the command line:

java org.apache.derby.tools.ij my_file.sql

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Java Development Kit (JDK) and the Apache Derby software.

Introduction

This tutorial requires the Java Development Kit (JDK) and the Apache Derby software.

First, this section describes which JDK release is required, asks you to install it if you haven't already, then shows you how to configure and verify your installation.

Next, it shows you how to install the Apache Derby software, configure your environment to use the Derby Embedded JDBC driver, and verify your installation with the Derby sysinfo tool.

Java Development Kit (JDK)

Derby requires Java 2 Standard Edition (J2SE) 1.4.2 or higher (this tutorial was developed using JDK 1.5). Only the Java Runtime Environment (JRE) is required to run Derby, but this tutorial compiles a Java application, so it requires the Java Development Kit (JDK).

If you already have a JDK installed, verify you are configured to use it, then proceed to the Apache Derby installation section.

Install JDK

If you have not already installed a JDK, download and install it now. No specific vendor implementation is required; the only requirement is that it be certified for J2SE 1.4.2 or higher. Java's reference implementation is at http://java.sun.com/j2se/. After installing the JDK of your choice, proceed to the next section.

Configure JDK

Set the JAVA_HOME environment variable to the root location of the JDK installation directory. The examples below use C:\jdk1.5 for Windows and /opt/jdk1.5 for UNIX, but be sure to use the actual location on your system. (e.g. The default installation location used by the JDK installer might be something like C:\Program Files\Java\jdk1.5.0_06)

Windows: C:\> set JAVA_HOME=C:\jdk1.5

UNIX Korn Shell: $ export JAVA_HOME=/opt/jdk1.5

Next set the PATH environment variable to include the JDK bin directory. The PATH variable tells the operating system where to find the java interpreter and the javac compiler.

Windows: C:\> set PATH=%PATH%;%JAVA_HOME%\bin

In Windows, these envoronment variables can also be set from - right click "My Computer" -> Advanced -> Environment Variables.

UNIX Korn Shell: $ export PATH=$JAVA_HOME/bin:$PATH

Verify JDK

Use the java -version command, as shown below, to verify the installed release:

java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

The output you see may be different from what is shown above because the java -version command outputs vendor-specific information; however, if you don't see what looks like valid version information, then STOP! And don't proceed until you resolve that problem.

Apache Derby

Download Derby

Download the binary Apache Derby distribution from the Derby web site at http://db.apache.org/derby/derby_downloads.html. These tutorial instructions use version 10.4.1.3 and assume you downloaded one of the binary distribution files listed in the table below:

Operating System	Download File
Windows	db-derby-10.4.1.3-bin.zip
UNIX, Linux, and Mac	db-derby-10.4.1.3-bin.tar.gz

If a more recent release is available, download that, then substitute that version number for 10.4.1.3 in the following instructions.

Install Derby

Choose the directory into which you want to install the Derby software. You must have write permissions to this directory. The sample instructions below use C:\Apache for Windows and /opt/Apache for UNIX; be sure to use your actual location. Copy the software distribution to the location you choose, then extract it as shown below.

Windows (use your extraction tool e.g. WinZip -- these instructions use mks unzip): mkdir C:\Apache copy db-derby-10.4.1.3-bin.zip C:\Apache cd C:\Apache unzip db-derby-10.4.1.3-bin.zip

UNIX: mkdir /opt/Apache cp db-derby-10.4.1.3-bin.tar.gz /opt/Apache cd /opt/Apache tar xzvf db-derby-10.4.1.3-bin.tar.gz

In both cases, the software will now be extracted into a subdirectory named db-derby-10.4.1.3-bin.

Set DERBY_INSTALL

Set the DERBY_INSTALL variable to the location where you installed Derby. Examples are shown below, but be sure to use the actual location on your system:

Windows: C:\> set DERBY_INSTALL=C:\Apache\db-derby-10.4.1.3-bin

UNIX Korn Shell: $ export DERBY_INSTALL=/opt/Apache/db-derby-10.4.1.3-bin

Configure Embedded Derby

To use Derby in its embedded mode set your CLASSPATH to include the jar files listed below:

• derby.jar: contains the Derby engine and the Derby Embedded JDBC driver
• derbytools.jar: optional, provides the ij tool that is used by a couple of sections in this tutorial

You can set your CLASSPATH explicitly with the command shown below:

Windows: C:\> set CLASSPATH=%DERBY_INSTALL%\lib\derby.jar;%DERBY_INSTALL%\lib\derbytools.jar;.

UNIX: $ export CLASSPATH=$DERBY_INSTALL/lib/derby.jar:$DERBY_INSTALL/lib/derbytools.jar:.

Notice that multiple entries in the class path are separated by a semicolon (;) on Windows and a colon (:) on UNIX.

The Derby software provides another way to set CLASSPATH, using shell scripts (UNIX) and batch files (Windows). This tutorial shows how to set CLASSPATH explicitly and also how to use the Derby scripts to set it.

Change directory now into the DERBY_INSTALL/bin directory. The setEmbeddedCP.bat (Windows) and setEmbeddedCP.ksh (UNIX) scripts use the DERBY_INSTALL variable to set the CLASSPATH for Derby embedded usage. You can edit the script itself to set DERBY_INSTALL, or you can let the script get DERBY_INSTALL from your environment. Since you already set DERBY_INSTALL in the "Set DERBY_INSTALL" section above, you don't need to edit the script, so go ahead and execute it as shown below:

Windows: C:\> cd %DERBY_INSTALL%\bin C:\Apache\db-derby-10.4.1.3-bin\bin> setEmbeddedCP.bat

UNIX: $ cd $DERBY_INSTALL/bin $ . setEmbeddedCP.ksh

Verify Derby

Run the sysinfo command, as shown below, to output Derby system information:

java org.apache.derby.tools.sysinfo

Successful output will look something like this:

------------------ Java Information ------------------ Java Version: 1.5.0_06 Java Vendor: Sun Microsystems Inc. Java home: C:\jdk1.5 Java classpath: C:\Apache\DB-DER~1.3-B\lib\derby.jar;C:\Apache\DB-DER~1.3-B\lib\derbytools.jar; OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: user Java user home: C:\Documents and Settings\user Java user dir: C:\Apache\db-derby-10.4.1.3-bin\bin java.specification.name: Java Platform API Specification java.specification.version: 1.5 --------- Derby Information -------- JRE - JDBC: J2SE 5.0 - JDBC 3.0 [C:\Apache\db-derby-10.4.1.3-bin\lib\derby.jar] 10.4.1.3 - (648739) [C:\Apache\db-derby-10.4.1.3-bin\lib\derbytools.jar] 10.4.1.3 - (648739) ------------------------------------------------------ ----------------- Locale Information ----------------- Current Locale : [English/United States [en_US]] Found support for locale: [cs] . . . Found support for locale: [zh_TW] version: 10.4.1.3 - (648739) ------------------------------------------------------

The output on your system will probably be somewhat different from the output shown above, but it should reflect the correct location of jar files on your machine and there shouldn't be any errors. If you see an error like the one below, it means your class path is not correctly set:

$ java org.apache.derby.tools.sysinfo Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/derby/tools/sysinfo

Echo your CLASSPATH, as shown below, then double check each entry in your class path to verify that the jar file is where you expect it:

Windows: C:\> echo %CLASSPATH% C:\Apache\DB-DER~1.3-B\lib\derby.jar;C:\Apache\DB-DER~1.3-B\lib\derbytools.jar;

UNIX: $ echo $CLASSPATH /opt/Apache/db-derby-10.4.1.3-bin/lib/derby.jar:/opt/Apache/db-derby-10.4.1.3-bin/lib/derbytools.jar:

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

How to Install Java Runtime Environment (JRE) in Ubuntu 9.04 (Jaunty)

Java is an object-oriented programming language developed by Sun Microsystems in the early 1990s. Java applications are compiled to bytecode, which at runtime is either interpreted or compiled to native machine code for execution.

The language itself derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities. JavaScript, a scripting language, shares a similar name and has similar syntax, but is not directly related to Java.

Currently Ubuntu has the following Java packages

sun-java6-bin - Contains the binaries

sun-java6-demo - Contains demos and examples

sun-java6-doc - Contains the documentation

sun-java6-fonts - Contains the Lucida TrueType fonts from the JRE

sun-java6-jdk - Contains the metapackage for the JDK

sun-java6-jre - Contains the metapackage for the JRE

sun-java6-plugin - Contains the plug-in for Mozilla-based browsers

sun-java6-source - Contains source files for the JDK

Installing the Java Runtime Environment

First you need to check multiverse repository enabled or not after that open a terminal window. Since you are going to be installing the JRE and the web browser plug-in, you’ll be using the following command from a terminal

sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-fonts

Once it downloads the packages and begins the installation, you’ll get a screen that contains the Sun OS Distributor License for Java and hit Enter to continue.

You’ll see a dialog that asks you if you agree with the DLJ license terms. Select Yes, and hit Enter; the JRE will finish installing.

Testing Java Runtime Environment

You’ll want to confirm that your system is configured properly for Sun’s JRE. This is a two-step process.

First, check that the JRE is properly installed by running the following command from a terminal.

java -version

You should get similar output

Testing Java Plugin for Firefox

open Firefox and typing about:plugins in the address bar and check for java plugin

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Java 2 SDK 1.4.2 Installation Notes for Microsoft Windows

System Requirements

Software - Java 2 SDK Standard Edition, 1.4.2 is supported on i586 Intel and 100% compatible platforms running Microsoft Windows. For a list of supported operating systems and desktop managers, see System Configurations.

Hardware - Intel and 100% compatible processors are supported. A Pentium 166MHz or faster processor with at least 32 megabytes of physical RAM is required to run graphically based applications. At least 48 megabytes of RAM is recommended for applets running within a browser using the Java Plug-in. Running with less memory may cause disk swapping which has a severe effect on performance. Very large programs may require more RAM for adequate performance.

For the amount of disk space required, see Windows Disk Space Requirements.

Note -- Trying to install the Java 2 SDK on a non-supported version of Microsoft Windows or on a machine that doesn't have a sufficiently up-to-date Service Pack will cause the installer to generate this warning: "We recommend that you do not install this Java Platform for the following reasons: This Java Platform does not support the operating system or operating-system service pack on this machine."

Installation Instructions

In this procedure, you will run the self-installing executable to unpack and install the Java 2 SDK software bundle. As part of the Java 2 SDK, this installation includes the Java Plug-in and Java Web Start, as well as an option to include the public Java 2 Runtime Environment. (The Java 2 SDK also contains a private J2RE for use only by its tools.)

For issues related to Windows Installation (IFTW) and Java Update, see the Windows Installation (IFTW) and Java Update FAQ. See this note on Proxy Settings and Authentication.

Print or bookmark these instructions - After the Java 2 SDK software has been installed, you may be asked to reboot your system. To continue using these instructions after rebooting, either print this page now, bookmark it now, or use your Web browser's history function to get back to this page.

Troubleshooting - If you have any difficulties, see the Troubleshooting section at the end of this document or submit a bug report for your installation problem.

Note: For any text on this page containing the following notation, you must substitute the appropriate update version number for the notation.

For example, if you are downloading the installer for update 1.4.2_01, the following file name:

   j2sdk-1_4_2_-windows-i586.exe 

would become:

   j2sdk-1_4_2_01-windows-i586.exe 

1. Check the download file size (Optional)

If you save the self-installing executable to disk without running it from the download page at the web site, notice that its byte size is provided on the download page. Once the download has completed, check that you have downloaded the full, uncorrupted software file.

2. If 1.4.2 Beta is installed, uninstall it.

Use the Microsoft Windows Add/Remove Programs utility, accessible from the Control Panel (Start -> Settings -> Control Panel).

3. Run the Java 2 SDK installer

Note - you must have administrative permissions in order to install the Java 2 SDK on Microsoft Windows 2000 and XP.

The file j2sdk-1_4_2_-windows-i586-i.exe is the Java 2 SDK installer. If you downloaded it instead of running it directly from the web site, double-click on the installer's icon. Then follow the instructions the installer provides. The installer may ask you to reboot your computer. When done with the installation, you can delete the download file to recover disk space.

Note -- Trying to install the Java 2 SDK on a non-supported version of Microsoft Windows or on a machine that doesn't have a sufficiently up-to-date Service Pack will cause the installer to generate this warning: "We recommend that you do not install this Java Platform for the following reasons: This Java Platform does not support the operating system or operating-system service pack on this machine." See the system requirements above for information on supported configurations of Microsoft Windows.

Installed Directory Tree
The Java 2 SDK has the directory structure shown below.

j2sdk1.4.2_ ____________________|___________________ | | | | | | | | | | | | | bin lib | demo | | | | LICENSE | | | jre | | COPYRIGHT | __|__ | README.txt include | | readme.html bin lib

In addition, the Java Plug-in and Java Web Start will automatically be installed. Look for a Java Web Start icon on your desktop. There will also be an entry for Java Web Start in the Start -> Programs menu.

Java Web Start --

• Compatibility: The release of Java Web Start that comes with this SDK/JRE can be run on SDK/JRE 1.2.2 or later. It will not work with SDK/JRE 1.1.x or earlier.
• Upgrading from Previous Versions: If you have a previous release of Java Web Start, do not uninstall it. Uninstalling it will cause the download cache to be cleared, and all previously installed Java Web Start application data will have to be downloaded again. This new release will overwrite previous installations and automatically update browsers to use this new release. The configuration files and program files folder used by Java Web Start have changed, but all your settings will remain intact after the upgrade, since Java Web Start will translate your settings to the new form.
• Uninstalling 1.4.2 SDK/JRE: The only way to uninstall Java Web Start 1.4.2 is to uninstall the 1.4.2 SDK/JRE. But note that doing so will remove the 1.4.2 Java Web Start cache, which stores the Java Web Start application data. Uninstalling the SDK/JRE will not, however, remove the cache for previous releases of Java Web Start (1.0.1 and 1.2). Previous releases have separate uninstallers for Java Web Start.
• Using Java Web Start with Netscape 6.x/7.x: For Netscape 6.x/7.x users, setup the Java Web Start MIME type (JNLP) in the Edit->Preferences->Navigator->Helper Applications section. The file extension is jnlp; MIME Type is application/x-java-jnlp-file. It should be handled by the javaws executable file in your Java Web Start directory. Also note that, due to a problem with the JavaScript in Netscape 6.x/7.x, you must use the non-JavaScript version of the demos page

4. If you want to run Netscape 7.x/Mozilla 1.x with Java Plug-in, do this:

• Exit the Netscape 7.x/Mozilla 1.x browser and all Netscape 7.x/Mozilla 1.x "objects" (Messenger, Composer ...);
• If the Quick Launch feature is enabled, disable it;
• Then restart Netscape 7.x/Mozilla 1.x.

5. Update the PATH variable (Optional)

You can run the Java 2 SDK without setting the PATH variable, or you can optionally set it as a convenience.

Should I set the PATH variable?
Set the PATH variable if you want to be able to conveniently run the Java 2 SDK executables (javac.exe, java.exe, javadoc.exe, etc.) from any directory without having to type the full path of the command. If you don't set the PATH variable, you need to specify the full path to the executable every time you run it, such as:

    C:> \j2sdk1.4.2_\bin\javac MyClass.java 

It's useful to set the PATH permanently so it will persist after rebooting.

How do I set the PATH permanently?
To set the PATH permanently, add the full path of the j2sdk1.4.2_\bin directory to the PATH variable. Typically this full path looks something like C:\j2sdk1.4.2_\bin. Set the PATH as follows, according to whether you are on Microsoft Windows NT or 98/2000/ME.

Microsoft Windows NT, 2000, and XP - To set the PATH permanently:

1. Choose Start, Settings, Control Panel, and double-click System. On Microsoft Windows NT, select the Environment tab; on Microsoft Windows 2000 select the Advanced tab and then Environment Variables. Look for "Path" in the User Variables and System Variables. If you're not sure where to add the path, add it to the right end of the "Path" in the User Variables. A typical value for PATH is:

        C:\j2sdk1.4.2_\bin
   

   Capitalization doesn't matter. Click "Set", "OK" or "Apply".

   The PATH can be a series of directories separated by semi-colons (;). Microsoft Windows looks for programs in the PATH directories in order, from left to right. You should only have one bin directory for a Java SDK in the path at a time (those following the first are ignored), so if one is already present, you can update it to j2sdk1.4.2_\bin.

2. The new path takes effect in each new Command Prompt window you open after setting the PATH variable.

Microsoft Windows 98 - To set the PATH permanently, open the AUTOEXEC.BAT file and add or change the PATH statement as follows:

1. Start the system editor. Choose "Start", "Run" and enter sysedit, then click OK. The system editor starts up with several windows showing. Go to the window that is displaying AUTOEXEC.BAT

2. Look for the PATH statement. (If you don't have one, add one.) If you're not sure where to add the path, add it to the right end of the PATH. For example, in the following PATH statement, we have added the bin directory at the right end:

   PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\J2SDK1.4.2_\BIN
   

   Capitalization doesn't matter. The PATH can be a series of directories separated by semi-colons (;). Microsoft Windows searches for programs in the PATH directories in order, from left to right. You should only have one bin directory for a Java SDK in the path at a time (those following the first are ignored), so if one is already present, you can update it to j2sdk1.4.2_.

3. To make the path take effect in the current Command Prompt window, execute the following:

         C:> c:\autoexec.bat 

   To find out the current value of your PATH, to see if it took effect, at the command prompt, type:

         C:> path 

Microsoft Windows ME - To set the PATH permanently:

From the start menu, choose programs, accessories, system tools, and system information. This brings up a window titled "Microsoft Help and Support". From here, choose the tools menu, then select the system configuration utility. Click the environment tab, select PATH and press the edit button. Now add the SDK to your path as described in step b above. After you've added the location of the SDK to your PATH, save the changes and reboot your machine when prompted.

6. Start using the Java 2 SDK!

Your computer system should now be ready to use the Java 2 SDK. In this step, you'll run some simple commands to make sure it is working properly.

If you are new to developing and running programs in the Java programming language, see The Java Tutorial online for some guidance. Note especially the tutorial trails under the heading Trails Covering the Basics.

You can also download the Java 2 SDK documentation from the Java 2 SDK download page..

Uninstalling the Java 2 SDK

If you should ever want to uninstall the Java 2 SDK, use the "Add/Remove Programs" utility in the Microsoft Windows Control Panel. As an alternative method, if you still have the original installation program that you used to install the Java 2 SDK, you can double click on it to launch an uninstall program.

Location of VM Library Files (jvm.dll)

If you use the Invocation API to launch an application directly rather than using the Java application launcher, be sure to use the correct paths to invoke the Java HotSpot Client Virtual Machine (VM) or Java HotSpot Server VM, as desired. The path within the Java SDK to the Java HotSpot Client VM is:

jre/bin/client/jvm.dll (on x86)

The path to the Java HotSpot Server VM is:

jre/bin/server/jvm.dll (on x86)
jre/bin/server/jvm.dll (on IA64)

The corresponding locations in the Java 2 Runtime Environment begin with j2re1.4.2 instead of jre. The Exact VM and Classic VM are no longer part of the Java 2 SDK, and existing code that uses the Invocation API to launch an application based on old paths to the Exact or Classic VMs will not work.

Troubleshooting the Installation

Below are some tips for working around problems that are sometimes seen during or following an installation. For more troubleshooting information, see the Java FAQ.

• If Netscape 6.2.x fails to launch a 1.4.2 applet and you installed 1.4.2 after you installed 1.4 (and both are still installed), do either of the following:
  • Uninstall 1.4 before you install 1.4.2;
  • Before you install 1.4.2, open the 1.4 Java Plug-in Control Panel, select the Browser tab, and deselect Netscape 6.

• If you see the following error message about Microsoft Windows Installer 2.0:

  An error occured while downloading the file
  http://www.installengine.com/Msiengine20/instmsiw.exe.
  What would you like to do?
  

  When installing version 1.4.2 of Java 2 Runtime Environment or Java 2 SDK (using the default minimized download rather than the single executable), InstallShield requires Microsoft Windows Installer 2.0 to be on your machine; if it is not found (or an older version is found), then InstallShield automatically tries to download Microsoft Windows Installer 2.0. If your machine is not on the Internet or is behind an authenticated proxy, the installation will fail at that point.

  To proceed, simply use the Windows Offline Installer from the download page. Microsoft Windows Installer 2.0 is included in this download.

  Alternatively, you can manually download Microsoft Windows Installer 2.0 by going to microsoft.com and searching for "Windows Installer 2.0".

  Version 2.0 of Microsoft Windows Installer is included in Windows XP and Windows 2000 Service Pack 3, but not in earlier versions of Windows.

  To see which version of Microsoft Windows Installer is installed, do the following:

  1. Locate the file MSI.DLL. (Usually located in C:\WINNT\SYSTEM32 )
  2. Select the file and right-click on it.
  3. Choose "Properties" and click on the "Version" tab.

• If you get an error about one of the following during InstallShield setup:
  • Error extracting support files. A typical error message is An Installation support file could not be installed. The filename, directory or volume label syntax is incorrect.
  • Error installing Ikernel.exe (0x any number)
  • Access is denied
  • Error loading Type Library/DLL

  These errors could be caused by a known problem with InstallShield. See the InstallShield web site for a discussion of this problem with possible solutions: http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q104985

• If you see the following error message:

  The InstallShield engine (iKernel.exe) could not be launched.
  Error loading type library/DLL
  

  This message probably indicates that system file Stdole32.tlb is missing from your computer. You can obtain this file from the Microsoft web site. For Microsoft Windows 98 platforms, for example, this file is included in the DCOM98 product.

• If you see the following error message on Microsoft Windows 2000

  config.nt. The system file is not suitable for running MS-DOS
  and Microsoft Windows Applications.
  

  it indicates a problem with the %SystemRoot%\System32\COMMAND.COM file that has been seen on some installations of Microsoft Windows 2000. If you encounter this error message when you try to launch the installer, consult the Microsoft web site at:

  http://support.microsoft.com/support/kb/articles/Q142/2/71.asp 

  for information about resolving the problem.

• If you see the following error message

  corrupt cabinet file
  

  then the file you have downloaded is corrupted. (A cabinet file contains compressed application, data, resource and DLL files.) Check its file size against the expected file size listed in these instructions. If they don't match, try downloading the bundle again.

• If you see the following error message

  System Error during Decompression
  

  then you might not have enough space on the disk that contains your TEMP directory.

• If you see the following error message

  This program cannot be run in DOS mode.
  

  then do the following:
  1. Open the MS-DOS shell or Command Prompt window
     
  2. Right-click on the title bar
     
  3. Select Properties
  4. Choose the Program tab
  5. Push the Advanced button
  6. Make sure the item "Prevent MS-DOS-based programs from detecting Windows" is unchecked
  7. Select OK
  8. Select OK again
  9. Exit the MS-DOS shell
  10. Restart your computer.

• Private vs. public J2RE - Installing the Java 2 SDK installs a private Java 2 Runtime Environment and optionally a public copy. The private J2RE is required to run the tools included with the Java 2 SDK. It has no registry settings and is contained entirely in a jre directory (typically at C:\Program Files\j2sdk1.4.2\jre) whose location is known only to the SDK. On the other hand, the public J2RE can be used by other Java applications, is contained outside the SDK (typically at C:\Program Files\Java\j2re1.4.2), is registered with the Windows registry (at HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft), can be removed using Add/Remove Programs, might or might not be registered with browsers, and might or might not have java.exe copied to the Windows system directory (making it the default system Java platform or not).

• Creating source files in Notepad - In Microsoft Windows, when you create a new file in Microsoft Notepad and then save it for the first time, Notepad normally adds the .txt extension to the filename. Therefore, a file you name Test.java is saved as Test.java.txt. It's important to note that you cannot see the .txt extension unless you turn on the viewing of file extensions (in Microsoft Windows Explorer, uncheck "Hide file extensions for known file types" under Folder Options). To prevent the .txt extension, enclose the filename in quotation marks, such as "Test.java", when typing it into the Save As dialog box.

  On the other hand, Microsoft WordPad does not add a file extension if you provide one -- you must save the file as "Text Document".

• Choosing an installation path containing characters that are not part of the system code page - On Windows 2000, XP, and 2003, it is possible to name directories using characters that are not part of the system locale's code page. If such a directory is part of the installation path, then error 1722 occurs, and installation is not completed.

  To prevent this problem, make sure that the user and system locales are identical, and that the installation path only contains characters that are part of the system locale's code page. User and system locales can be set in the Regional Options or Regional Settings control panel.

  The associated bug number is 4895647.

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

How to install Java in Windows

Installing

What follows are step-by-step instructions for installing the latest versions of Java on a Windows computer.

Sun, the company behind Java, just released a new version known as Java 6 Update 10 (among other names). As I noted previously, there's no compelling reason to install this latest version, in fact, a case can be made that the prior version, Java 6 Update 7, is the better way to go. The steps involved in installing either version are the same.

The Java plug-in fails to automatically install in Firefox

In theory, the first time you try to use a Web page that requires Java it should be automatically installed. In reality, this rarely works. I just tested it under Windows XP with Firefox versions 2 and 3 and with Internet Explorer versions 6 and 7. Not once did Java auto-install (see above).

No matter, the manual installation is fairly simple. And unlike Flash, Windows users only have to install Java once.

Technically, what you download is the Java Runtime Environment (JRE). The latest JRE version is always available at www.java.com/en/download/manual.jsp. Go for the "offline" version. The prior Java version (Java 6 Update 7) is available at java.sun.com/products/archive/j2se/6u7/index.html. Click on the "Download JRE" link at the bottom of the page.

For both versions, when you run the downloaded EXE file, the installation starts with the usual license agreement.

Starting the installation of Java

Then you may be given the chance to download additional software. When I installed Java 6 Update 7, there was no additional software. But when I installed the latest version, it defaulted to also installing the Yahoo Toolbar for Firefox. No one needs the Yahoo Toolbar, so I suggest not installing it. Defensive computing means installing only the software you really need. The less software installed, the less of a bug magnet your computer is.

Additional software, unrelated to Java, may be an option.

As the software is being installed, you'll see a standard progress bar.

Java is being installed.

When it's all done, this too is clearly shown.

Java has been installed.

Old Versions

What to do with older versions of Java that may be on your computer is debatable.

My preference is to delete old software, so that malicious software can't exploit any known bugs. Others may argue to let sleeping dogs lie because there may be some software that specifically requires an old version of Java. I'll take that chance. In the worst case, you can always download an old version of Java at java.sun.com/products/archive/.

On Windows, Java uninstalls in the normal, standard manner.

This latest version of Java (6 Update 10) is going to complicate things in the future. Newer versions of Java 6 may install themselves over this version or they may not. Java can now be installed in two ways: patch-in-place and static.

If your copy of Java 6 Update 10 is "patch-in-place" then a newer version of Java 6 will remove Update 10 when it's installed. However, if your copy of Java 6 Update 10 is "static," then newer versions of Java 6 will not replace Update 10.

Either way, newer versions of Java 6 will not remove versions of Java 6 prior to Update 10. Also, when Sun gets up to Java version 7 Update 1, that will not remove any copies of Java 6 that may exist.

YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.

Recipe for Java Cookies

How to make cookies

If you've spent all day programming, it's important to make sure that you have a break and some food. If you've been jibbling about with Java too much, you may find it hard to read normal cooking instructions, so here's something you may understand in order to whip up a quick tasty treat. This is version 3 of the recipe, tried and tested by many fellow jibblers :)

A real cookie made using this recipe. See, it works!

Buy the Ingredients

All good cookies need ingredients. This may require you to go outside in order to buy them. Cookies make ideal food for programmers, as they are full of unhealthy things like butter, sugar and chocolate. Note the ordering of the ingredients, as this will become important later on.

SuperMarket sm = new SuperMarket("Sainsburys");
ArrayList basket = new ArrayList();

basket.add(sm.buy("250g all-purpose flour"));
basket.add(sm.buy("1 tsp baking soda"));
basket.add(sm.buy("1/4 tsp salt"));
basket.add(sm.buy("200g butter"));
basket.add(sm.buy("165g brown sugar"));
basket.add(sm.buy("100g white sugar"));
basket.add(sm.buy("1 tsp vanilla extract"));
basket.add(sm.buy("1 egg"));
basket.add(sm.buy("100g chocolate chips"));

Preheat oven

Unlike computers, when you press the buttons on an oven, it may take a few minutes for it to actually do what you've told it to. This is commonly referred to as "preheating" and may take a bit longer than an AMD Athlon without a heatsink. If something interrupts this process, then you're a bit shafted, as the name "cookie" implies that it must be cooked.

// Preheat oven for ten minutes at 175 deg C.
Oven oven = Oven.getInstance();
oven.setTemperature(175);

try {
   Thread.sleep(600000);  // 10 minutes.
}
catch (InterruptedException e) {
   System.out.println("No cookies today :(");
}

Combine ingredients

I cheat and use a bread maker to mix it all up within 6 minutes :)

The ingredients are no good on their own. We have to mix them up first. This is essential to ensure that one of the cookies doesn't look like a fried egg when it comes out of the oven. Try mixing everything up until you achieve a nice, consistent dough, but leave the egg and chocolate chips until last. Try not to eat too many, they'll be better in the cookies, trust me.

Cupboard cupboard = Cupboard.getInstance();

cupboard.open();
Collection bowl = cupboard.get("bowl");
cupboard.close();

Iterator it = basket.iterator();
while (it.hasNext()) {
   Ingredient ingredient = (Ingredient) it.next();

   if (ingredient == null) {
       throw new RuntimeException("Duh, you forgot an ingredient!");
   }

   bowl.add(ingredient);
   Collections.shuffle(bowl);
}

Preparing to cook

Space the dough out sensibly. Don't make the blobs too big!

Cookie dough has a tendancy to fall through the gaps in oven shelves, so here we propose the use of a revolutionary cooking device: a baking tray. This ingenious invention somehow stops the cookies falling to the bottom of the oven. You simply place blobs of the dough onto the device and after a while in the oven, they magically turn into cookies! To simplify the task of washing up, we also place a protective shield between the tray and the cookies. We call this "tin foil". There should be enough dough to make about 30 large cookies, but our oven is only large enough to hold 9 at a time. Perhaps we could use CORBA to implement a distributed cooking protocol?

cupboard.open();
Collection tinFoil = cupboard.get("greased tin foil");
Collection tray = cupboard.get("baking tray");
cupboard.close();

tray.add(tinFoil);

for (int i = 0; i < 9; i++) {
   tinFoil.add(new Cookie(bowl));
}

Ready, Steady, Cook!

Schtop! These cookies are not ready yet!

You are now ready to bake the cookies! Now, remember, unlike modern day computers, we may have to wait several minutes before this stage is completed. I'd suggest at least 10 minutes, however, it may take up to 20 minutes. Perhaps this could be used as a seed for a pseudorandom number generator? Keep checking the cookies until they look like they're done. Hint: If they start going black, you'd better start warming up the time machine.

// Stick the tray in the oven for at least 10 minutes.
oven.open();
oven.add(tray);
oven.close();

try{
   Thread.sleep(600000);  // 10 minutes.
}
catch (InterruptedException e) {
   System.out.println("Schtop! These cookies are not ready yet!");
}

After about ten minutes, we should keep checking the cookies to make sure we know when they're ready!

// Check on the progress of the cookies every minute.
boolean stillWaiting = true;
while (stillWaiting) {
   try {
       Thread.sleep(60000);  // One minute.
   }
   catch (InterruptedException e) {
       System.out.println("Stop interrupting me!");
   }
  
   // Check that all the cookies are cooked!
   stillWaiting = false;
   for (int i = 0; i < tinFoil.size(); i++) {
       Cookie cookie = (Cookie) tinFoil.get(i);
       if (!cookie.isCooked()) {
           stillWaiting = true;
           break;
       }
   }
}

// Take the tray out.
oven.open();
tray = (Collection) oven.remove(oven.indexOf(tray));
oven.close();

// Bug fix suggested by Tim Bishop.
// (We forgot to turn off the oven!)
oven.turnOff();

// Wait for things to cool down.
try {
   tray.wait(300000);  // 5 minutes.
}
catch (InterruptedException e) {
   System.out.println("Ouch! Burnt fingers!");
}

The fun begins!

A big pile of lovely soft chocolate chip cookies.

Now that you've taken the cookies out of the oven and left them for a few minutes to cool down, they are ready to eat! Don't eat too many; it may lead to a nasty coredump later on.

it = tray.iterator();
while (it.hasNext()) {
   Cookie cookie = (Cookie) it.next();
   cookie.eat();
YOU CAN USE QUICK SEARCH ENGINE IN THE TOP FOR MORE DOWNLOADS OR DETAILS.
}