1

I am aware that a JDBC RowSet instance can be created with a Connection object passed to its constructor, eg.:

Connection con = MyDAO.getConnection();
JdbcRowSet jrs = new JdbcRowSetImpl(con);

Two questions:

  • My Java SE 7 complains every single time I build my project that contains any uses of JdbcRowSetImpl. It says that JdbcRowSetImpl is a vendor specific implementation and that it may be removed from a future version of the JDK. I find this odd if only because the Java Tutorial continues to use JdbcRowSetImpl in its JDBC section. Does Oracle really intend for the factory RowSet implementations to be phased out of the JDK? If not, is there a way to stop the warning messages?

Here's one of the warnings. It occurs when I try to use a JdbcRowSet constructor in the code or when I try to import the package

C:\Users\Ribose\Documents\NetBeansProjects\CensusAssistant\src\org\kls\md\censusassistant\db\DB.java:170:
 warning: JdbcRowSetImpl is internal proprietary API and may be removed in a future release
            jrs = new JdbcRowSetImpl(con);

I am building with NetBeans IDE 7.3. The RDBMS is HSQLDB 2.2.9. I have the latest JDK SE 7.

  • Let's say that I already have an instance of JdbcRowSet. Although it is not connected, I already have a Connection object, but no access to the authentication credentials, i.e. I have the object, but no user_id or password needed to make a new Connection.

Am I able to use the existing Connection object with the existing JdbcRowSet instance? The only thing I have found is that the constructor for JdbcRowSetImpl can take a Connection object, but I want to use the Connection without having to construct a new RowSet object. Is this possible?

scottb
  • 9,908
  • 3
  • 40
  • 56

1 Answers1

5

The class com.sun.rowset.JdbcRowSetImpl is a Sun specific implementation of a JDBC interface, and serves as the default, in the case no other provider implementation exists. The class has actually been around since JDK 1.2, so you can say with a degree of certainty that it will continue to stay around, but its not a guarantee. This is the case with all com.sun.* packages in general - they represent internal implementations that should not directly be referred too or instantiated.

Is it a bad practice to use Sun's proprietary Java classes?

Having said that, unlike other dynamic libraries [SAX, DOM, JAXB etc], there was no real good way of instantiating JDBC row sets without creating a provider specific instance, until Java 7, where you can now use a factory to create a provider specific instance, without explicit binding in your code:

final JDBCRowSet rowSet = RowSetProvider.newFactory().createJdbcRowSet();

This code scans the class path for appropriate providers, and instantiates first a RowSetFactory, then a JDBCRowSet, using the provider classes found (note that it will fall back to the default Sun implementation if no other provider is located). This is the preferred way of creating a JDBC row set going forward, from Java 7 onwards.

Am I able to use the existing Connection object with the existing JdbcRowSet instance?

Not without avoiding the internal proprietary API message no. As I said, the JDBCRowSetImpl class in all likeliness will continue to remain around. Infact the Java 7 documentation pretty much alludes as much:

The reference implementation of the JdbcRowSet interface, JdbcRowSetImpl, provides an implementation of the default constructor. A new instance is initialized with default values, which can be set with new values as needed

So if your willing to ignore the compiler warnings, you can use the default implementation to create a row set with an existing connection.

Community
  • 1
  • 1
Perception
  • 79,279
  • 19
  • 185
  • 195
  • Thanks. That was helpful ... I'll use the factory mechanism. The reason I want to know about the Connection object is because I'd like to reuse it. After each RowSet operation, I iterate the result set to generate a list of objects, and then I close() it. I am concerned about the performance implications for a standalone embedded db app where the database connection is repeatedly opened and closed. I'd much rather leave it open for the lifetime of the app, if I could ... and then close it on exit. – scottb Apr 08 '13 at 01:11