Java Coffee Break Newsletter Vol 1, Issue 7 ISSN 1442-3790 This issue is packed full of even more Java tips, tricks, and articles for Java programmers. As a Christmas bonus, we've got articles on JDBC, RMI & CORBA, and exclusive advice to commonly asked questions from the new Java Network Programming FAQ. Enjoy! - - - - - - - - - - - - - - - - - - - - - - - - - Java Coffee Break News * Free Articles & Tutorials * Spread the christmas joy * Java Network Programming FAQ * Networking Q&A : How can I find out the current IP address for my machine? * Networking Q&A : How do I perform a hostname lookup for an IP address? * Networking Q&A : How do I get the IP address of a machine from its hostname? * General Q&A : How can I throw an exception without declaring that a method throws it? Articles * "Getting started with JDBC", offers a gentle introduction to Java database programming * "Java RMI & CORBA", compares two competing technologies 1. Free Articles & Tutorials We've got free articles and tutorials about Java that teach basic programming concepts, right through to advanced topics like networking, JavaBeans & CORBA. For more information, visit the Java Coffee Break at http://www.davidreilly.com/jcb/ 2. Spread the christmas joy T'is the season to be jolly. Whether you celebrate Christmas, Chanukah, or Kwanzaz, may your holiday season be bright and festive! And if you find yourself leaving things to the last minute like me, you'll probably want to avoid the hustle and bustle of holiday shopping. Why not consider shopping online this season? Amazon.com, one of the world's largest and most respected book and music retailers makes it easy to buy gifts for friends, collegues and loved ones. You'll also be supporting a great Java newsletter! http://www.davidreilly.com/goto.cgi?id=amazon 3. Java Network Programming FAQ This issue contains some tips from the new Java Network Programming FAQ, which answers commonly asked networking questions. If you'd like to read more, visit http://www.davidreilly.com/java/java_network_programming/ - - - - - - - - - - - - - - - - - - - - - - - - - Networking Q&A : How can I find out the current IP address for my machine? The InetAddress has a static method called getLocalHost() which will return the current address of the local machine. You can then use the getHostAddress() method to get the IP address. InetAddress local = InetAddress.getLocalHost(); // Print address System.out.println ("Local IP : " + local.getHostAddress()); - - - - - - - - - - - - - - - - - - - - - - - - - Networking Q&A : How do I perform a hostname lookup for an IP address? The InetAddress class contains a method that can return the domain name of an IP address. You need to obtain an InetAddress class, and then call its getHostName() method. This will return the hostname for that IP address. Depending on the platform, a partial or a fully qualified hostname may be returned. InetAddress inet = InetAddress.getByName("209.204.220.121"); System.out.println ("Host: " + inet.getHostName()); - - - - - - - - - - - - - - - - - - - - - - - - - Networking Q&A : How do I get the IP address of a machine from its hostname? The InetAddress class is able to resolve IP addresses for you. Obtain an instance of InetAddress for the machine, and call the getHostAddress() method, which returns a string in the xxx.xxx.xxx.xxx address form. InetAddress inet = InetAddress.getByName("www.davidreilly.com"); System.out.println ("IP : " + inet.getHostAddress()); - - - - - - - - - - - - - - - - - - - - - - - - - General Q&A : How can I throw an exception without declaring that a method throws it? Sometimes it is useful to throw exceptions, without explicitly declaring them in the throws clause of a method's signature. Any exceptions that extends java.lang.RuntimeException don't need to be declared. This means that it is safe to throw subclasses (like NullPointException), or to create your own. - - - - - - - - - - - - - - - - - - - - - - - - - "Getting started with JDBC" by David Reilly Database access, for many developers, is an essential part of the tools of software development. If you're new to Java development, you might be wondering just how Java applets and applications can connect to a database. In this article, I'll show you how to get started with JDBC, a mechanism that allows Java to talk to databases. Accessing a database in Java doesn't have to be a difficult task. Using Java Database Connectivity (JDBC) you can easily access databases in your applications and applets via special drivers. What is JDBC? Java Database Connectivity (JDBC) provides Java developers with a standard API that is used to access databases, regardless of the driver and database product. To use JDBC, you'll need at least JDK 1.1, a database, and a JDBC driver. Installing the first two should be straightforward, but finding a JDBC driver requires a little more effort. JDBC presents a uniform interface to databases - change vendors and your applications only need to change their driver. There are plenty of drivers now for JDBC that support popular databases. If you can use a JDBC driver that works specifically for your database, then that's great! If not, don't worry - Sun provides a driver that is compatible with ODBC, so you should be able to connect to any ODBC compliant database. The JDBC to ODBC bridge comes installed as part of JDK1.1, so if this is your target platform, the driver will already be installed. You'll need to create an ODBC datasource for your database, before your Java applications can access it. Connecting to a database In order to connect to a database, you need to perform some initialization first. Your JDBC driver has to be loaded by the Java Virtual Machine classloader, and your application needs to check to see that the driver was successfully loaded. We'll be using the ODBC bridge driver, but if your database vendor supplies a JDBC driver, feel free to use it instead. // Attempt to load database driver try { // Load Sun's jdbc-odbc driver Class.forName("sun.jdbc.odbc.JdbcOdbcDriver").newInstance(); } catch (ClassNotFoundException cnfe) // driver not found { System.err.println ("Unable to load database driver"); System.err.println ("Details : " + cnfe); System.exit(0); } We try to load the JdbcOdbcDriver class, and then catch the ClassNotFoundException if it is thrown. This is important, because the application might be run on a non-Sun virtual machine that doesn't include the ODBC bridge, such as Microsoft's JVM. If this occurs, the driver won't be installed, and our application should exit gracefully. Once our driver is loaded, we can connect to the database. We'll connect via the driver manager class, which selects the appropriate driver for the database we specify. In this case, we'll only be using an ODBC database, but in more complex applications, we might wish to use different drivers to connect to multiple databases. We identify our database through a URL. No, we're not doing anything on the web in this example - a URL just helps to identify our database. A JDBC URL starts with "jdbc:"  This indicates the protocol (JDBC). We also specify our database in the URL. As an example, here's the URL for an ODBC datasource called 'demo'. Our final URL looks like this : jdbc:odbc:demo To connect to the database, we create a string representation of the database. We take the name of the datasource from the command line, and attempt to connect as user "dba", whose password is "sql". // Create a URL that identifies database String url = "jdbc:odbc:" + args[0]; // Now attempt to create a database connection Connection db_connection = DriverManager.getConnection (url, "dba", "sql"); As you can see, connecting to a database doesn't take much code. The full article, and source code, is available at http://www.davidreilly.com/jcb/articles/jdbc/ - - - - - - - - - - - - - - - - - - - - - - - - - "Java RMI & CORBA" by David Reilly With the introduction of CORBA support to Java (as of version 1.2), developers now face the question of whether to continue to use remote method invocation (RMI), or make a move to CORBA. The choice is made more difficult if your applications are already written in RMI - considerable effort might have to be made to convert to CORBA. Is it worth the move? This article discusses the pros and cons, and evaluates the potential of these two technologies. What is Remote Method Invocation? Remote method invocation allows Java developers to invoke object methods, and have them execute on remote Java Virtual Machines (JVMs). Under RMI, entire objects can be passed and returned as parameters, unlike many remote procedure call based mechanisms which require parameters to be either primitive data types, or structures composed of primitive data types. That means that any Java object can be passed as a parameter - even new objects whose class has never been encountered before by the remote virtual machine. This is an exciting property, because it means that new code can be sent across a network and dynamically loaded at run-time by foreign virtual machines. Java developers have a greater freedom when designing distributed systems, and the ability to send and receive new classes is an incredible advantage. Developers don't have to work within a fixed codebase - they can submit new classes to foreign virtual machines and have them perform different tasks. When working with remote services, RMI clients can access new versions of Java services as they are made available - there's no need to distribute code to all the clients that might wish to connect. While code can be accessed from a local or remote file-system, it can also be accessed via a web server, making distribution easier. RMI also supports a registry, which allows clients to perform lookups for a particular service. The following diagram shows the interaction between different components of an RMI system. Clients that know about a service can look up its location from a registry and access the service. If a new class is required, it can be downloaded from a web server. Remote method invocation has a lot of potential, from remote processing and load sharing of CPU's to transport mechanisms for higher level tasks, such as mobile agents which execute on remote machines (Reilly, 1998). Because of the flexibility of remote method invocation, it has become an important tool for Java developers when writing distributed systems. However, there are many legacy systems written in C/C++, Ada, Fortran, Cobol, and other exotic languages. If legacy systems need to interface with your RMI systems, or your RMI systems need to interface with them, problems can occur. RMI is Java specific, and you'll need to write a bridge between older systems. Additionally, if you or your company plans on using other languages in the future, you may also find yourself in a bind because of RMI's tie to Java - one day Java itself may become a legacy platform. I don't know about you, but writing interfaces to legacy systems isn't my idea of fun programming! What is CORBA? Common Object Request Broker Architecture (CORBA) is a competing distributed systems technology that offers greater portability than remote method invocation. Unlike RMI, CORBA isn't tied to one language, and as such, can integrate with legacy systems of the past written in older languages, as well as future languages that include support for CORBA. CORBA isn't tied to a single platform (a property shared by RMI), and shows great potential for use in the future. That said, for Java developers, CORBA offers less flexibility, because it doesn't allow executable code to be sent to remote systems. CORBA services are described by an interface, written in the Interface Definition Language (IDL). IDL mappings to most popular languages are available, and mappings can be written for languages written in the future that require CORBA support. CORBA allows objects to make requests of remote objects (invoking methods), and allows data to be passed between two remote systems. Remote method invocation, on the other hand, allows Java objects to be passed and returned as parameters. This allows new classes to be passed across virtual machines for execution (mobile code). CORBA only allows primitive data types, and structures to be passed - not actual code. Under communication between CORBA clients and CORBA services, method calls are passed to Object Request Brokers (ORBs). These ORBs communicate via the Internet Inter-ORB Protocol (IIOP). IIOP transactions can take place over TCP streams, or via other protocols (such as HTTP), in the event that a client or server is behind a firewall. The following diagram shows a client and a servant communicating. The full article, and diagrams, is available at http://www.davidreilly.com/jcb/articles/rmi_corba/ - - - - - - - - - - - - - - - - - - - - - - - - - The Java Coffee Break Newsletter is only sent out to email subscribers who have requested it, and to readers of the comp.lang.java.programmer and comp.lang.java.help newsgroups. If you'd like to receive our newsletter, and get the latest Java news, tips and articles from our site, then get your FREE subscription from http://www.davidreilly.com/jcb/newsletter/subscribe.html If you are an email subscriber and no longer wish to receive the JCB Newsletter, please unsubscribe using the WWW form located at http://www.davidreilly.com/jcb/newsletter/unsubscribe.html