Java References.*

Hello Friends,

I was trying to generate unordered lists from database through java code in JSP. I am facing difficulties to generate subcategories in

list.

I have a table with Menu Items :

code:
  
cat_id | parent_id | title
-------------------------
1 | 0 | Solutions
2 | 0 | Products
3 | 1 | Web
4 | 1 | Development
5 | 2 | Softies
6 | 2 | PHP Book
-------------------------  


I want to list get the out put in the form as below :
code:
 
Solutions
  Web
  Development
Products
  Softies 
  PHP Book  


What i have written is :

code:
 public String generateMenuHTML(String id) throws SQLException {
  String html, cId, pId;
  pdb = new Pdb();
  rset = pdb.executeQuery("select ID,PARENT_ID,TITLE,URL,SORT,ICON from menu");
  
  html = "
";
 
  while(rset.next())
  {
  cId = rset.getString("id");
  System.out.println(cId);
  pId =rset.getString("PARENT_ID");
  html = html + "
• " + rset.getString("title") + "";
    if (pId.equalsIgnoreCase("1"))
    {
    System.out.println(pId);
    html = html + generateMenuHTML(cId);
    }
    html = html + "
";
   
   
  }  
  rset.close();
  html = html + "
";
  return html;
 }
   


Could you please help me where i am wrong.. how should i join the tables? any idea? Could you please help me how to retrieve sub categories and get the output in :




• 
  
  
  
  
  




Please help me if you can.. Thanks a lot!

Rgds,
Sutanuj Majumder.

Java Diagrams

Data Base Connectivity......(1)

Java Data Base Connectivity

JDBC has been part of the Java Standard Edition since the release of JDK 1.1. The JDBC classes are contained in the Java package java.sql. Starting with version 3.0, JDBC has been developed under the Java Community Process. JSR 54 specifies JDBC 3.0 (included in J2SE 1.4), JSR 114 specifies the JDBC Rowset additions, and JSR 221 is the specification of JDBC 4.0 (included in Java SE 6).[6]

JDBC allows multiple implementations to exist and be used by the same application. The API provides a mechanism for dynamically loading the correct Java packages and registering them with the JDBC Driver Manager. The Driver Manager is used as a connection factory for creating JDBC connections.

JDBC connections support creating and executing statements. These may be update statements such as SQL's CREATE, INSERT, UPDATE and DELETE, or they may be query statements such as SELECT. Additionally, stored procedures may be invoked through a JDBC connection. JDBC represents statements using one of the following classes:
Statement – the statement is sent to the database server each and every time.
PreparedStatement – the statement is cached and then the execution path is pre determined on the database server allowing it to be executed multiple times in an efficient manner.
CallableStatement – used for executing stored procedures on the database.

Update statements such as INSERT, UPDATE and DELETE return an update count that indicates how many rows were affected in the database. These statements do not return any other information.

Query statements return a JDBC row result set. The row result set is used to walk over the result set. Individual columns in a row are retrieved either by name or by column number. There may be any number of rows in the result set. The row result set has metadata that describes the names of the columns and their types.

There is an extension to the basic JDBC API in the javax.sql

Example

The method Class.forName(String) is used to load the JDBC driver class. The line below causes the JDBC driver from some jdbc vendor to be loaded into the application. (Some JVMs also require the class to be instantiated with .newInstance().)
Class.forName( "com.somejdbcvendor.TheirJdbcDriver" );

In JDBC 4.0, it's no longer necessary to explicitly load JDBC drivers using Class.forName(). See JDBC 4.0 Enhancements in Java SE 6

When a Driver class is loaded, it creates an instance of itself and registers it with the DriverManager. This can be done by including the needed code in the driver class's static block. e.g. DriverManager.registerDriver(Driver driver)

Now when a connection is needed, one of the DriverManager.getConnection() methods is used to create a JDBC connection.
Connection conn = DriverManager.getConnection(
  "jdbc:somejdbcvendor:other data needed by some jdbc vendor",
  "myLogin",
  "myPassword" );

The URL used is dependent upon the particular JDBC driver. It will always begin with the "jdbc:" protocol, but the rest is up to the particular vendor. Once a connection is established, a statement must be created.
Statement stmt = conn.createStatement();
try {
  stmt.executeUpdate( "INSERT INTO MyTable( name ) VALUES ( 'my name' ) " );
} finally {
  //It's important to close the statement when you are done with it
  stmt.close();
}

Note that Connections, Statements, and ResultSets often tie up operating system resources such as sockets or file descriptors. In the case of Connections to remote database servers, further resources are tied up on the server, e.g., cursors for currently open ResultSets. It is vital to close() any JDBC object as soon as it has played its part; garbage collection should not be relied upon. Forgetting to close() things properly results in spurious errors and misbehaviour. The above try-finally construct is a recommended code pattern to use with JDBC objects.

Data is retrieved from the database using a database query mechanism. The example below shows creating a statement and executing a query.
Statement stmt = conn.createStatement();
try {
  ResultSet rs = stmt.executeQuery( "SELECT * FROM MyTable" );
  try {
  while ( rs.next() ) {
  int numColumns = rs.getMetaData().getColumnCount();
  for ( int i = 1 ; i <= numColumns ; i++ ) {
  // Column numbers start at 1.
  // Also there are many methods on the result set to return
  // the column as a particular type. Refer to the Sun documentation
  // for the list of valid conversions.
  System.out.println( "COLUMN " + i + " = " + rs.getObject(i) );
  }
  }
  } finally {
  rs.close();
  }
} finally {
  stmt.close();
}

Typically, however, it would be rare for a seasoned Java programmer to code in such a fashion. The usual practice would be to abstract the database logic into an entirely different class and to pass preprocessed strings (perhaps derived themselves from a further abstracted class) containing SQL statements and the connection to the required methods. Abstracting the data model from the application code makes it more likely that changes to the application and data model can be made independently.

An example of a PreparedStatement query. Using conn and class from first example.
PreparedStatement ps = conn.prepareStatement( "SELECT i.*, j.* FROM Omega i, Zappa j WHERE i.name = ? AND j.num = ?" );
try {
  // In the SQL statement being prepared, each question mark is a placeholder
  // that must be replaced with a value you provide through a "set" method invocation.
  // The following two method calls replace the two placeholders; the first is
  // replaced by a string value, and the second by an integer value.
  ps.setString(1, "Poor Yorick");
  ps.setInt(2, 8008);
 
  // The ResultSet, rs, conveys the result of executing the SQL statement.
  // Each time you call rs.next(), an internal row pointer, or cursor,
  // is advanced to the next row of the result. The cursor initially is
  // positioned before the first row.
  ResultSet rs = ps.executeQuery();
  try {
  while ( rs.next() ) {
  int numColumns = rs.getMetaData().getColumnCount();
  for ( int i = 1 ; i <= numColumns ; i++ ) {
  // Column numbers start at 1.
  // Also there are many methods on the result set to return
  // the column as a particular type. Refer to the Sun documentation
  // for the list of valid conversions.
  System.out.println( "COLUMN " + i + " = " + rs.getObject(i) );
  } // for
  } // while
  } finally {
  rs.close();
  }
} finally {
  ps.close();
} // try
JDBC has been part of the Java Standard Edition since the release of JDK 1.1. The JDBC classes are contained in the Java package java.sql. Starting with version 3.0, JDBC has been developed under the Java Community Process. JSR 54 specifies JDBC 3.0 (included in J2SE 1.4), JSR 114 specifies the JDBC Rowset additions, and JSR 221 is the specification of JDBC 4.0 (included in Java SE 6).[6]

JDBC allows multiple implementations to exist and be used by the same application. The API provides a mechanism for dynamically loading the correct Java packages and registering them with the JDBC Driver Manager. The Driver Manager is used as a connection factory for creating JDBC connections.

JDBC connections support creating and executing statements. These may be update statements such as SQL's CREATE, INSERT, UPDATE and DELETE, or they may be query statements such as SELECT. Additionally, stored procedures may be invoked through a JDBC connection. JDBC represents statements using one of the following classes:
Statement – the statement is sent to the database server each and every time.
PreparedStatement – the statement is cached and then the execution path is pre determined on the database server allowing it to be executed multiple times in an efficient manner.
CallableStatement – used for executing stored procedures on the database.

Update statements such as INSERT, UPDATE and DELETE return an update count that indicates how many rows were affected in the database. These statements do not return any other information.

Query statements return a JDBC row result set. The row result set is used to walk over the result set. Individual columns in a row are retrieved either by name or by column number. There may be any number of rows in the result set. The row result set has metadata that describes the names of the columns and their types.

There is an extension to the basic JDBC API in the javax.sql


Example

The method Class.forName(String) is used to load the JDBC driver class. The line below causes the JDBC driver from some jdbc vendor to be loaded into the application. (Some JVMs also require the class to be instantiated with .newInstance().)
Class.forName( "com.somejdbcvendor.TheirJdbcDriver" );

In JDBC 4.0, it's no longer necessary to explicitly load JDBC drivers using Class.forName(). See JDBC 4.0 Enhancements in Java SE 6

When a Driver class is loaded, it creates an instance of itself and registers it with the DriverManager. This can be done by including the needed code in the driver class's static block. e.g. DriverManager.registerDriver(Driver driver)

Now when a connection is needed, one of the DriverManager.getConnection() methods is used to create a JDBC connection.
Connection conn = DriverManager.getConnection(
  "jdbc:somejdbcvendor:other data needed by some jdbc vendor",
  "myLogin",
  "myPassword" );

The URL used is dependent upon the particular JDBC driver. It will always begin with the "jdbc:" protocol, but the rest is up to the particular vendor. Once a connection is established, a statement must be created.
Statement stmt = conn.createStatement();
try {
  stmt.executeUpdate( "INSERT INTO MyTable( name ) VALUES ( 'my name' ) " );
} finally {
  //It's important to close the statement when you are done with it
  stmt.close();
}

Note that Connections, Statements, and ResultSets often tie up operating system resources such as sockets or file descriptors. In the case of Connections to remote database servers, further resources are tied up on the server, e.g., cursors for currently open ResultSets. It is vital to close() any JDBC object as soon as it has played its part; garbage collection should not be relied upon. Forgetting to close() things properly results in spurious errors and misbehaviour. The above try-finally construct is a recommended code pattern to use with JDBC objects.

Data is retrieved from the database using a database query mechanism. The example below shows creating a statement and executing a query.
Statement stmt = conn.createStatement();
try {
  ResultSet rs = stmt.executeQuery( "SELECT * FROM MyTable" );
  try {
  while ( rs.next() ) {
  int numColumns = rs.getMetaData().getColumnCount();
  for ( int i = 1 ; i <= numColumns ; i++ ) {
  // Column numbers start at 1.
  // Also there are many methods on the result set to return
  // the column as a particular type. Refer to the Sun documentation
  // for the list of valid conversions.
  System.out.println( "COLUMN " + i + " = " + rs.getObject(i) );
  }
  }
  } finally {
  rs.close();
  }
} finally {
  stmt.close();
}

Typically, however, it would be rare for a seasoned Java programmer to code in such a fashion. The usual practice would be to abstract the database logic into an entirely different class and to pass preprocessed strings (perhaps derived themselves from a further abstracted class) containing SQL statements and the connection to the required methods. Abstracting the data model from the application code makes it more likely that changes to the application and data model can be made independently.

An example of a PreparedStatement query. Using conn and class from first example.
PreparedStatement ps = conn.prepareStatement( "SELECT i.*, j.* FROM Omega i, Zappa j WHERE i.name = ? AND j.num = ?" );
try {
  // In the SQL statement being prepared, each question mark is a placeholder
  // that must be replaced with a value you provide through a "set" method invocation.
  // The following two method calls replace the two placeholders; the first is
  // replaced by a string value, and the second by an integer value.
  ps.setString(1, "Poor Yorick");
  ps.setInt(2, 8008);
 
  // The ResultSet, rs, conveys the result of executing the SQL statement.
  // Each time you call rs.next(), an internal row pointer, or cursor,
  // is advanced to the next row of the result. The cursor initially is
  // positioned before the first row.
  ResultSet rs = ps.executeQuery();
  try {
  while ( rs.next() ) {
  int numColumns = rs.getMetaData().getColumnCount();
  for ( int i = 1 ; i <= numColumns ; i++ ) {
  // Column numbers start at 1.
  // Also there are many methods on the result set to return
  // the column as a particular type. Refer to the Sun documentation
  // for the list of valid conversions.
  System.out.println( "COLUMN " + i + " = " + rs.getObject(i) );
  } // for
  } // while
  } finally {
  rs.close();
  }
} finally {
  ps.close();
} // try

More About Java

One characteristic of Java is portability, which means that computer programs written in the Java language must run similarly on any supported hardware/operating-system platform. One should be able to write a program once, compile it once, and run it anywhere.

This is achieved by compiling the Java language code, not to machine code but to Java bytecode – instructions analogous to machine code but intended to be interpreted by a virtual machine (VM) written specifically for the host hardware. End-users commonly use a JRE installed on their own machine, or in a Web browser.

Standardized libraries provide a generic way to access host specific features such as graphics, threading and networking. In some JVM versions, bytecode can be compiled to native code, either before or during program execution, resulting in faster execution.

A major benefit of using bytecode is Porting. However, the overhead of interpretation means that interpreted programs almost always run more slowly than programs compiled to native executables would, and Java suffered a reputation for poor performance. This gap has been narrowed by a number of optimisation techniques introduced in the more recent JVM implementations.

One such technique, known as (just-in-time compilation)JIT, translates Java bytecode into native code the first time that code is executed, then caches it. This results in a program that starts and executes faster than pure interpreted code can, at the cost of introducing occasional compilation overhead during execution. More sophisticated VMs also use dynamic recompilation, in which the VM analyzes the behavior of the running program and selectively recompiles and optimizes parts of the program. Dynamic recompilation can achieve optimizations superior to static compilation because the dynamic compiler can base optimizations on knowledge about the runtime environment and the set of loaded classes, and can identify hot spots - parts of the program, often inner loops, that take up the most execution time. JIT compilation and dynamic recompilation allow Java programs to approach the speed of native code without losing portability.

Another technique, commonly known as static compilation, or ahead-of-time (AOT) compilation, is to compile directly into native code like a more traditional compiler. Static Java compilers translate the Java source or bytecode to native object code. This achieves good performance compared to interpretation, at the expense of portability; the output of these compilers can only be run on a single architecture. AOT could give Java something like performance, yet it is still not portable since there are no compiler directives, and all the pointers are indirect with no way to micro manage garbage collection.

Java's performance has improved substantially since the early versions, and performance of JIT compilers relative to native compilers has in some tests been shown to be quite similar.[11][12] The performance of the compilers does not necessarily indicate the performance of the compiled code; only careful testing can reveal the true performance issues in any system.

One of the unique advantages of the concept of a runtime engine is that errors (exceptions) should not 'crash' the system. Moreover, in runtime engine environments such as Java there exist tools that attach to the runtime engine and every time that an exception of interest occurs they record debugging information that existed in memory at the time the exception was thrown (stack and heap values). These Automated Exception Handling tools provide 'root-cause' information for exceptions in Java programs that run in production, testing or development environments.

History Of Java

James Gosling initiated the Java language project in June 1991 for use in one of his many set-top box projects.[4] The language, initially called Oak after an oak tree that stood outside Gosling's office, also went by the name Green and ended up later renamed as Java, from a list of random words.[5] Gosling aimed to implement a virtual machine and a language that had a familiar C/C++ style of notation.[6]

Sun released the first public implementation as Java 1.0 in 1996. It promised "Write Once, Run Anywhere" (WORA), providing no-cost run-times on popular platforms. Fairly secure and featuring configurable security, it allowed network- and file-access restrictions. Major web browsers soon incorporated the ability to run secure Java applets within web pages, and Java quickly became popular. With the advent of Java 2 (released initially as J2SE 1.2 in December 1998), new versions had multiple configurations built for different types of platforms. For example, J2EE targeted enterprise applications and the greatly stripped-down version J2ME for mobile applications. J2SE designated the Standard Edition. In 2006, for marketing purposes, Sun renamed new J2 versions as Java EE, Java ME, and Java SE, respectively.

In 1997, Sun Microsystems approached the ISO/IEC JTC1 standards body and later the Ecma International to formalize Java, but it soon withdrew from the process.[7] Java remains a de facto standard, controlled through the Java Community Process.[8] At one time, Sun made most of its Java implementations available without charge, despite their proprietary software status. Sun generated revenue from Java through the selling of licenses for specialized products such as the Java Enterprise System. Sun distinguishes between its Software Development Kit (SDK) and Runtime Environment (JRE) (a subset of the SDK); the primary distinction involves the JRE's lack of the compiler, utility programs, and many necessary header files.

On 13 November 2006, Sun released much of Java as free and open source software under the terms of the GNU General Public License (GPL). On 8 May 2007 Sun finished the process, making all of Java's core code free and open-source, aside from a small portion of code to which Sun did not hold the copyright.[9]