Copy Link
Add to Bookmark
Report
Java Coffee Break Newsletter Volume 1 Issue 07
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
