JDBC - Perl 5 interface to Java JDBC (via Inline::Java)


Version 0.02


    use JDBC;


    my $con = JDBC->getConnection($url, "test", "test");

    my $s = $con->createStatement();

    $s->executeUpdate("create table foo (foo int, bar varchar(200), primary key (foo))");
    $s->executeUpdate("insert into foo (foo, bar) values (42,'notthis')");
    $s->executeUpdate("insert into foo (foo, bar) values (43,'notthat')");

    my $rs = $s->executeQuery("select foo, bar from foo");
    while ($rs->next) {
        my $foo = $rs->getInt(1);
        my $bar = $rs->getString(2);
        print "row: foo=$foo, bar=$bar\n";


This JDBC module provides an interface to the Java java.sql.* and javax.sql.* JDBC APIs.



The load_driver() method is used to load a driver class.


is equivalent to the Java:






The cast(), caught(), and study_classes() functions of Inline::Java are also optionally exported by the JDBC module.


Java JDBC makes use of constants defined in

  import java.sql.*;
  stmt = con.prepareStatement(PreparedStatement.SELECT);

the package can also be specified with the import which then avoids the need to prefix the constant with the class:

  import java.sql.PreparedStatement;
  stmt = con.prepareStatement(SELECT);

In Perl the corresponding code can be either:

  use JDBC;
  $stmt = $con->prepareStatement($java::sql::PrepareStatement::SELECT);

or, the rather more friendly:

  use JDBC qw(:PreparedStatement);
  $stmt = $con->prepareStatement(SELECT);

When importing a JDBC class in this way the JDBC module only imports defined scalars with all-uppercase names, and it turns them into perl constants so the $ is no longer needed.

All constants in all the java.sql and javax.sql classes can be imported in this way.


Why did I create this module?

Because it will help the design of DBI v2.

How will it help the design of DBI v2?

Well, "the plan" is to clearly separate the driver interface from the Perl DBI. The driver interface will be defined at the Parrot level and so, it's hoped, that a single set of drivers can be shared by all languages targeting Parrot.

Each language would then have their own thin 'adaptor' layered over the Parrot drivers. For Perl that'll be the Perl DBIv2.

So before getting very far designing DBI v2 there's a need to design the underlying driver interface. Java JDBC can serve as a useful role model. (Many of the annoyances of Java JDBC and actually annoyances of Java and so cease to be relevant for Parrot.)

As part of the DBI v2 work I'll probably write a "PDBC" module as a layer over this JDBC module. Then DBI v2 will target the PDBC module and the PDBC module will capture the differences between plain JDBC API and the Parrot driver API.




Tim Bunce, <>


Firstly try to determine if the problem is related to the JDBC module itself or, more likely, the underlying Inline::Java module.

Please report any bugs or feature requests for JDBC to, or through the web interface at I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

Please report any bugs or feature requests for Inline::Java to the Inline::Java mailing list.

Inline::Java's mailing list is <>. To subscribe, send an email to <>

Inline::Java's home page is


Thanks to Patrick LeBoutillier for creating Inline::Java.


Copyright 2005 Tim Bunce, all rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.