< prev index next >
src/java.sql/share/classes/javax/sql/package-info.java
Print this page
rev 52981 : 8215309: Convert package.html files to package-info.java files
Reviewed-by:
*** 1,302 ****
! <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
! <html>
! <head>
! <!--
! Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.
! DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
!
! This code is free software; you can redistribute it and/or modify it
! under the terms of the GNU General Public License version 2 only, as
! published by the Free Software Foundation. Oracle designates this
! particular file as subject to the "Classpath" exception as provided
! by Oracle in the LICENSE file that accompanied this code.
!
! This code is distributed in the hope that it will be useful, but WITHOUT
! ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
! FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
! version 2 for more details (a copy is included in the LICENSE file that
! accompanied this code).
!
! You should have received a copy of the GNU General Public License version
! 2 along with this work; if not, write to the Free Software Foundation,
! Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
!
! Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
! or visit www.oracle.com if you need additional information or have any
! questions.
! -->
!
! </head>
!
!
!
! <body bgcolor="white">
!
! Provides the API for server side data source access and processing from
! the Java™ programming language.
! This package supplements the <code>java.sql</code>
! package and, as of the version 1.4 release, is included in the
! Java Platform, Standard Edition (Java SE™).
! It remains an essential part of the Java Platform, Enterprise Edition
! (Java EE™).
! <P>
! The <code>javax.sql</code> package provides for the following:
! <OL>
! <LI>The <code>DataSource</code> interface as an alternative to the
! <code>DriverManager</code> for establishing a
! connection with a data source
! <LI>Connection pooling and Statement pooling
! <LI>Distributed transactions
! <LI>Rowsets
! </OL>
! <P>
! Applications use the <code>DataSource</code> and <code>RowSet</code>
! APIs directly, but the connection pooling and distributed transaction
! APIs are used internally by the middle-tier infrastructure.
!
! <H2>Using a <code>DataSource</code> Object to Make a Connection</H2>
!
! The <code>javax.sql</code> package provides the preferred
! way to make a connection with a data source. The <code>DriverManager</code>
! class, the original mechanism, is still valid, and code using it will
! continue to run. However, the newer <code>DataSource</code> mechanism
! is preferred because it offers many advantages over the
! <code>DriverManager</code> mechanism.
! <P>
! These are the main advantages of using a <code>DataSource</code> object to
! make a connection:
! <UL>
!
! <LI>Changes can be made to a data source's properties, which means
! that it is not necessary to make changes in application code when
! something about the data source or driver changes.
! <LI>Connection and Statement pooling and distributed transactions are available
! through a <code>DataSource</code> object that is
! implemented to work with the middle-tier infrastructure.
! Connections made through the <code>DriverManager</code>
! do not have connection and statement pooling or distributed transaction
! capabilities.
! </UL>
! <P>
! Driver vendors provide <code>DataSource</code> implementations. A
! particular <code>DataSource</code> object represents a particular
! physical data source, and each connection the <code>DataSource</code> object
! creates is a connection to that physical data source.
! <P>
! A logical name for the data source is registered with a naming service that
! uses the Java Naming and Directory Interface™
! (JNDI) API, usually by a system administrator or someone performing the
! duties of a system administrator. An application can retrieve the
! <code>DataSource</code> object it wants by doing a lookup on the logical
! name that has been registered for it. The application can then use the
! <code>DataSource</code> object to create a connection to the physical data
! source it represents.
! <P>
! A <code>DataSource</code> object can be implemented to work with the
! middle tier infrastructure so that the connections it produces will be
! pooled for reuse. An application that uses such a <code>DataSource</code>
! implementation will automatically get a connection that participates in
! connection pooling.
! A <code>DataSource</code> object can also be implemented to work with the
! middle tier infrastructure so that the connections it produces can be
! used for distributed transactions without any special coding.
!
! <H2>Connection Pooling and Statement Pooling</H2>
!
! Connections made via a <code>DataSource</code>
! object that is implemented to work with a middle tier connection pool manager
! will participate in connection pooling. This can improve performance
! dramatically because creating new connections is very expensive.
! Connection pooling allows a connection to be used and reused,
! thus cutting down substantially on the number of new connections
! that need to be created.
! <P>
! Connection pooling is totally transparent. It is done automatically
! in the middle tier of a Java EE configuration, so from an application's
! viewpoint, no change in code is required. An application simply uses
! the <code>DataSource.getConnection</code> method to get the pooled
! connection and uses it the same way it uses any <code>Connection</code>
! object.
! <P>
! The classes and interfaces used for connection pooling are:
! <UL>
! <LI><code>ConnectionPoolDataSource</code>
! <LI><code>PooledConnection</code>
! <LI><code>ConnectionEvent</code>
! <LI><code>ConnectionEventListener</code>
! <LI><code>StatementEvent</code>
! <LI><code>StatementEventListener</code>
! </UL>
! The connection pool manager, a facility in the middle tier of
! a three-tier architecture, uses these classes and interfaces
! behind the scenes. When a <code>ConnectionPoolDataSource</code> object
! is called on to create a <code>PooledConnection</code> object, the
! connection pool manager will register as a <code>ConnectionEventListener</code>
! object with the new <code>PooledConnection</code> object. When the connection
! is closed or there is an error, the connection pool manager (being a listener)
! gets a notification that includes a <code>ConnectionEvent</code> object.
! <p>
! If the connection pool manager supports <code>Statement</code> pooling, for
! <code>PreparedStatements</code>, which can be determined by invoking the method
! <code>DatabaseMetaData.supportsStatementPooling</code>, the
! connection pool manager will register as a <code>StatementEventListener</code>
! object with the new <code>PooledConnection</code> object. When the
! <code>PreparedStatement</code> is closed or there is an error, the connection
! pool manager (being a listener)
! gets a notification that includes a <code>StatementEvent</code> object.
!
! <H2>Distributed Transactions</H2>
!
! As with pooled connections, connections made via a <code>DataSource</code>
! object that is implemented to work with the middle tier infrastructure
! may participate in distributed transactions. This gives an application
! the ability to involve data sources on multiple servers in a single
! transaction.
! <P>
! The classes and interfaces used for distributed transactions are:
! <UL>
! <LI><code>XADataSource</code>
! <LI><code>XAConnection</code>
! </UL>
! These interfaces are used by the transaction manager; an application does
! not use them directly.
! <P>
! The <code>XAConnection</code> interface is derived from the
! <code>PooledConnection</code> interface, so what applies to a pooled connection
! also applies to a connection that is part of a distributed transaction.
! A transaction manager in the middle tier handles everything transparently.
! The only change in application code is that an application cannot do anything
! that would interfere with the transaction manager's handling of the transaction.
! Specifically, an application cannot call the methods <code>Connection.commit</code>
! or <code>Connection.rollback</code>, and it cannot set the connection to be in
! auto-commit mode (that is, it cannot call
! <code>Connection.setAutoCommit(true)</code>).
! <P>
! An application does not need to do anything special to participate in a
! distributed transaction.
! It simply creates connections to the data sources it wants to use via
! the <code>DataSource.getConnection</code> method, just as it normally does.
! The transaction manager manages the transaction behind the scenes. The
! <code>XADataSource</code> interface creates <code>XAConnection</code> objects, and
! each <code>XAConnection</code> object creates an <code>XAResource</code> object
! that the transaction manager uses to manage the connection.
!
!
! <H2>Rowsets</H2>
! The <code>RowSet</code> interface works with various other classes and
! interfaces behind the scenes. These can be grouped into three categories.
! <OL>
! <LI>Event Notification
! <UL>
! <LI><code>RowSetListener</code><br>
! A <code>RowSet</code> object is a JavaBeans™
! component because it has properties and participates in the JavaBeans
! event notification mechanism. The <code>RowSetListener</code> interface
! is implemented by a component that wants to be notified about events that
! occur to a particular <code>RowSet</code> object. Such a component registers
! itself as a listener with a rowset via the <code>RowSet.addRowSetListener</code>
! method.
! <P>
! When the <code>RowSet</code> object changes one of its rows, changes all of
! it rows, or moves its cursor, it also notifies each listener that is registered
! with it. The listener reacts by carrying out its implementation of the
! notification method called on it.
! <LI><code>RowSetEvent</code><br>
! As part of its internal notification process, a <code>RowSet</code> object
! creates an instance of <code>RowSetEvent</code> and passes it to the listener.
! The listener can use this <code>RowSetEvent</code> object to find out which rowset
! had the event.
! </UL>
! <LI>Metadata
! <UL>
! <LI><code>RowSetMetaData</code><br>
! This interface, derived from the
! <code>ResultSetMetaData</code> interface, provides information about
! the columns in a <code>RowSet</code> object. An application can use
! <code>RowSetMetaData</code> methods to find out how many columns the
! rowset contains and what kind of data each column can contain.
! <P>
! The <code>RowSetMetaData</code> interface provides methods for
! setting the information about columns, but an application would not
! normally use these methods. When an application calls the <code>RowSet</code>
! method <code>execute</code>, the <code>RowSet</code> object will contain
! a new set of rows, and its <code>RowSetMetaData</code> object will have been
! internally updated to contain information about the new columns.
! </UL>
! <LI>The Reader/Writer Facility<br>
! A <code>RowSet</code> object that implements the <code>RowSetInternal</code>
! interface can call on the <code>RowSetReader</code> object associated with it
! to populate itself with data. It can also call on the <code>RowSetWriter</code>
! object associated with it to write any changes to its rows back to the
! data source from which it originally got the rows.
! A rowset that remains connected to its data source does not need to use a
! reader and writer because it can simply operate on the data source directly.
!
! <UL>
! <LI><code>RowSetInternal</code><br>
! By implementing the <code>RowSetInternal</code> interface, a
! <code>RowSet</code> object gets access to
! its internal state and is able to call on its reader and writer. A rowset
! keeps track of the values in its current rows and of the values that immediately
! preceded the current ones, referred to as the <i>original</i> values. A rowset
! also keeps track of (1) the parameters that have been set for its command and
! (2) the connection that was passed to it, if any. A rowset uses the
! <code>RowSetInternal</code> methods behind the scenes to get access to
! this information. An application does not normally invoke these methods directly.
!
! <LI><code>RowSetReader</code><br>
! A disconnected <code>RowSet</code> object that has implemented the
! <code>RowSetInternal</code> interface can call on its reader (the
! <code>RowSetReader</code> object associated with it) to populate it with
! data. When an application calls the <code>RowSet.execute</code> method,
! that method calls on the rowset's reader to do much of the work. Implementations
! can vary widely, but generally a reader makes a connection to the data source,
! reads data from the data source and populates the rowset with it, and closes
! the connection. A reader may also update the <code>RowSetMetaData</code> object
! for its rowset. The rowset's internal state is also updated, either by the
! reader or directly by the method <code>RowSet.execute</code>.
!
!
! <LI><code>RowSetWriter</code><br>
! A disconnected <code>RowSet</code> object that has implemented the
! <code>RowSetInternal</code> interface can call on its writer (the
! <code>RowSetWriter</code> object associated with it) to write changes
! back to the underlying data source. Implementations may vary widely, but
! generally, a writer will do the following:
!
! <UL>
! <LI>Make a connection to the data source
! <LI>Check to see whether there is a conflict, that is, whether
! a value that has been changed in the rowset has also been changed
! in the data source
! <LI>Write the new values to the data source if there is no conflict
! <LI>Close the connection
! </UL>
!
!
! </UL>
! </OL>
! <P>
! The <code>RowSet</code> interface may be implemented in any number of
! ways, and anyone may write an implementation. Developers are encouraged
! to use their imaginations in coming up with new ways to use rowsets.
!
!
! <h2>Package Specification</h2>
!
! <ul>
! <li><a href="https://jcp.org/en/jsr/detail?id=221">JDBC 4.3 Specification</a>
! </ul>
!
! <h2>Related Documentation</h2>
!
! The Java Series book published by Addison-Wesley Longman provides detailed
! information about the classes and interfaces in the <code>javax.sql</code>
! package:
!
! <ul>
! <li><a href="http://www.oracle.com/technetwork/java/index-142838.html">
! <i>JDBC™API Tutorial and Reference, Third Edition</i></a>
! </ul>
! </body>
! </html>
--- 1,294 ----
! /**
! * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
! * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
! * <p>
! * This code is free software; you can redistribute it and/or modify it
! * under the terms of the GNU General Public License version 2 only, as
! * published by the Free Software Foundation. Oracle designates this
! * particular file as subject to the "Classpath" exception as provided
! * by Oracle in the LICENSE file that accompanied this code.
! * <p>
! * This code is distributed in the hope that it will be useful, but WITHOUT
! * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
! * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
! * version 2 for more details (a copy is included in the LICENSE file that
! * accompanied this code).
! * <p>
! * You should have received a copy of the GNU General Public License version
! * 2 along with this work; if not, write to the Free Software Foundation,
! * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
! * <p>
! * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
! * or visit www.oracle.com if you need additional information or have any
! * questions.
! */
!
! /**
! * Provides the API for server side data source access and processing from
! * the Java™ programming language.
! * This package supplements the <code>java.sql</code>
! * package and, as of the version 1.4 release, is included in the
! * Java Platform, Standard Edition (Java SE™).
! * It remains an essential part of the Java Platform, Enterprise Edition
! * (Java EE™).
! * <p>
! * The <code>javax.sql</code> package provides for the following:
! * <OL>
! * <LI>The <code>DataSource</code> interface as an alternative to the
! * <code>DriverManager</code> for establishing a
! * connection with a data source
! * <LI>Connection pooling and Statement pooling
! * <LI>Distributed transactions
! * <LI>Rowsets
! * </OL>
! * <p>
! * Applications use the <code>DataSource</code> and <code>RowSet</code>
! * APIs directly, but the connection pooling and distributed transaction
! * APIs are used internally by the middle-tier infrastructure.
! *
! * <H2>Using a <code>DataSource</code> Object to Make a Connection</H2>
! * <p>
! * The <code>javax.sql</code> package provides the preferred
! * way to make a connection with a data source. The <code>DriverManager</code>
! * class, the original mechanism, is still valid, and code using it will
! * continue to run. However, the newer <code>DataSource</code> mechanism
! * is preferred because it offers many advantages over the
! * <code>DriverManager</code> mechanism.
! * <p>
! * These are the main advantages of using a <code>DataSource</code> object to
! * make a connection:
! * <UL>
! *
! * <LI>Changes can be made to a data source's properties, which means
! * that it is not necessary to make changes in application code when
! * something about the data source or driver changes.
! * <LI>Connection and Statement pooling and distributed transactions are available
! * through a <code>DataSource</code> object that is
! * implemented to work with the middle-tier infrastructure.
! * Connections made through the <code>DriverManager</code>
! * do not have connection and statement pooling or distributed transaction
! * capabilities.
! * </UL>
! * <p>
! * Driver vendors provide <code>DataSource</code> implementations. A
! * particular <code>DataSource</code> object represents a particular
! * physical data source, and each connection the <code>DataSource</code> object
! * creates is a connection to that physical data source.
! * <p>
! * A logical name for the data source is registered with a naming service that
! * uses the Java Naming and Directory Interface™
! * (JNDI) API, usually by a system administrator or someone performing the
! * duties of a system administrator. An application can retrieve the
! * <code>DataSource</code> object it wants by doing a lookup on the logical
! * name that has been registered for it. The application can then use the
! * <code>DataSource</code> object to create a connection to the physical data
! * source it represents.
! * <p>
! * A <code>DataSource</code> object can be implemented to work with the
! * middle tier infrastructure so that the connections it produces will be
! * pooled for reuse. An application that uses such a <code>DataSource</code>
! * implementation will automatically get a connection that participates in
! * connection pooling.
! * A <code>DataSource</code> object can also be implemented to work with the
! * middle tier infrastructure so that the connections it produces can be
! * used for distributed transactions without any special coding.
! *
! * <H2>Connection Pooling and Statement Pooling</H2>
! * <p>
! * Connections made via a <code>DataSource</code>
! * object that is implemented to work with a middle tier connection pool manager
! * will participate in connection pooling. This can improve performance
! * dramatically because creating new connections is very expensive.
! * Connection pooling allows a connection to be used and reused,
! * thus cutting down substantially on the number of new connections
! * that need to be created.
! * <p>
! * Connection pooling is totally transparent. It is done automatically
! * in the middle tier of a Java EE configuration, so from an application's
! * viewpoint, no change in code is required. An application simply uses
! * the <code>DataSource.getConnection</code> method to get the pooled
! * connection and uses it the same way it uses any <code>Connection</code>
! * object.
! * <p>
! * The classes and interfaces used for connection pooling are:
! * <UL>
! * <LI><code>ConnectionPoolDataSource</code>
! * <LI><code>PooledConnection</code>
! * <LI><code>ConnectionEvent</code>
! * <LI><code>ConnectionEventListener</code>
! * <LI><code>StatementEvent</code>
! * <LI><code>StatementEventListener</code>
! * </UL>
! * The connection pool manager, a facility in the middle tier of
! * a three-tier architecture, uses these classes and interfaces
! * behind the scenes. When a <code>ConnectionPoolDataSource</code> object
! * is called on to create a <code>PooledConnection</code> object, the
! * connection pool manager will register as a <code>ConnectionEventListener</code>
! * object with the new <code>PooledConnection</code> object. When the connection
! * is closed or there is an error, the connection pool manager (being a listener)
! * gets a notification that includes a <code>ConnectionEvent</code> object.
! * <p>
! * If the connection pool manager supports <code>Statement</code> pooling, for
! * <code>PreparedStatements</code>, which can be determined by invoking the method
! * <code>DatabaseMetaData.supportsStatementPooling</code>, the
! * connection pool manager will register as a <code>StatementEventListener</code>
! * object with the new <code>PooledConnection</code> object. When the
! * <code>PreparedStatement</code> is closed or there is an error, the connection
! * pool manager (being a listener)
! * gets a notification that includes a <code>StatementEvent</code> object.
! *
! * <H2>Distributed Transactions</H2>
! * <p>
! * As with pooled connections, connections made via a <code>DataSource</code>
! * object that is implemented to work with the middle tier infrastructure
! * may participate in distributed transactions. This gives an application
! * the ability to involve data sources on multiple servers in a single
! * transaction.
! * <p>
! * The classes and interfaces used for distributed transactions are:
! * <UL>
! * <LI><code>XADataSource</code>
! * <LI><code>XAConnection</code>
! * </UL>
! * These interfaces are used by the transaction manager; an application does
! * not use them directly.
! * <p>
! * The <code>XAConnection</code> interface is derived from the
! * <code>PooledConnection</code> interface, so what applies to a pooled connection
! * also applies to a connection that is part of a distributed transaction.
! * A transaction manager in the middle tier handles everything transparently.
! * The only change in application code is that an application cannot do anything
! * that would interfere with the transaction manager's handling of the transaction.
! * Specifically, an application cannot call the methods <code>Connection.commit</code>
! * or <code>Connection.rollback</code>, and it cannot set the connection to be in
! * auto-commit mode (that is, it cannot call
! * <code>Connection.setAutoCommit(true)</code>).
! * <p>
! * An application does not need to do anything special to participate in a
! * distributed transaction.
! * It simply creates connections to the data sources it wants to use via
! * the <code>DataSource.getConnection</code> method, just as it normally does.
! * The transaction manager manages the transaction behind the scenes. The
! * <code>XADataSource</code> interface creates <code>XAConnection</code> objects, and
! * each <code>XAConnection</code> object creates an <code>XAResource</code> object
! * that the transaction manager uses to manage the connection.
! *
! *
! * <H2>Rowsets</H2>
! * The <code>RowSet</code> interface works with various other classes and
! * interfaces behind the scenes. These can be grouped into three categories.
! * <OL>
! * <LI>Event Notification
! * <UL>
! * <LI><code>RowSetListener</code><br>
! * A <code>RowSet</code> object is a JavaBeans™
! * component because it has properties and participates in the JavaBeans
! * event notification mechanism. The <code>RowSetListener</code> interface
! * is implemented by a component that wants to be notified about events that
! * occur to a particular <code>RowSet</code> object. Such a component registers
! * itself as a listener with a rowset via the <code>RowSet.addRowSetListener</code>
! * method.
! * <p>
! * When the <code>RowSet</code> object changes one of its rows, changes all of
! * it rows, or moves its cursor, it also notifies each listener that is registered
! * with it. The listener reacts by carrying out its implementation of the
! * notification method called on it.
! * <LI><code>RowSetEvent</code><br>
! * As part of its internal notification process, a <code>RowSet</code> object
! * creates an instance of <code>RowSetEvent</code> and passes it to the listener.
! * The listener can use this <code>RowSetEvent</code> object to find out which rowset
! * had the event.
! * </UL>
! * <LI>Metadata
! * <UL>
! * <LI><code>RowSetMetaData</code><br>
! * This interface, derived from the
! * <code>ResultSetMetaData</code> interface, provides information about
! * the columns in a <code>RowSet</code> object. An application can use
! * <code>RowSetMetaData</code> methods to find out how many columns the
! * rowset contains and what kind of data each column can contain.
! * <p>
! * The <code>RowSetMetaData</code> interface provides methods for
! * setting the information about columns, but an application would not
! * normally use these methods. When an application calls the <code>RowSet</code>
! * method <code>execute</code>, the <code>RowSet</code> object will contain
! * a new set of rows, and its <code>RowSetMetaData</code> object will have been
! * internally updated to contain information about the new columns.
! * </UL>
! * <LI>The Reader/Writer Facility<br>
! * A <code>RowSet</code> object that implements the <code>RowSetInternal</code>
! * interface can call on the <code>RowSetReader</code> object associated with it
! * to populate itself with data. It can also call on the <code>RowSetWriter</code>
! * object associated with it to write any changes to its rows back to the
! * data source from which it originally got the rows.
! * A rowset that remains connected to its data source does not need to use a
! * reader and writer because it can simply operate on the data source directly.
! *
! * <UL>
! * <LI><code>RowSetInternal</code><br>
! * By implementing the <code>RowSetInternal</code> interface, a
! * <code>RowSet</code> object gets access to
! * its internal state and is able to call on its reader and writer. A rowset
! * keeps track of the values in its current rows and of the values that immediately
! * preceded the current ones, referred to as the <i>original</i> values. A rowset
! * also keeps track of (1) the parameters that have been set for its command and
! * (2) the connection that was passed to it, if any. A rowset uses the
! * <code>RowSetInternal</code> methods behind the scenes to get access to
! * this information. An application does not normally invoke these methods directly.
! *
! * <LI><code>RowSetReader</code><br>
! * A disconnected <code>RowSet</code> object that has implemented the
! * <code>RowSetInternal</code> interface can call on its reader (the
! * <code>RowSetReader</code> object associated with it) to populate it with
! * data. When an application calls the <code>RowSet.execute</code> method,
! * that method calls on the rowset's reader to do much of the work. Implementations
! * can vary widely, but generally a reader makes a connection to the data source,
! * reads data from the data source and populates the rowset with it, and closes
! * the connection. A reader may also update the <code>RowSetMetaData</code> object
! * for its rowset. The rowset's internal state is also updated, either by the
! * reader or directly by the method <code>RowSet.execute</code>.
! *
! *
! * <LI><code>RowSetWriter</code><br>
! * A disconnected <code>RowSet</code> object that has implemented the
! * <code>RowSetInternal</code> interface can call on its writer (the
! * <code>RowSetWriter</code> object associated with it) to write changes
! * back to the underlying data source. Implementations may vary widely, but
! * generally, a writer will do the following:
! *
! * <UL>
! * <LI>Make a connection to the data source
! * <LI>Check to see whether there is a conflict, that is, whether
! * a value that has been changed in the rowset has also been changed
! * in the data source
! * <LI>Write the new values to the data source if there is no conflict
! * <LI>Close the connection
! * </UL>
! *
! *
! * </UL>
! * </OL>
! * <p>
! * The <code>RowSet</code> interface may be implemented in any number of
! * ways, and anyone may write an implementation. Developers are encouraged
! * to use their imaginations in coming up with new ways to use rowsets.
! *
! *
! * <h2>Package Specification</h2>
! *
! * <ul>
! * <li><a href="https://jcp.org/en/jsr/detail?id=221">JDBC 4.3 Specification</a>
! * </ul>
! *
! * <h2>Related Documentation</h2>
! * <p>
! * The Java Series book published by Addison-Wesley Longman provides detailed
! * information about the classes and interfaces in the <code>javax.sql</code>
! * package:
! *
! * <ul>
! * <li><a href="http://www.oracle.com/technetwork/java/index-142838.html">
! * <i>JDBC™API Tutorial and Reference, Third Edition</i></a>
! * </ul>
! */
! package javax.sql;
< prev index next >