« Back to home

SQL0805N Package "NULLID.SQLC2H21 0X4141414141504161" was not found.

A quick FYI: IBM DB2 9.7 isn’t compatible with DB2 9.5 or 9.1 servers by default. The symptoms of the incompatibility are that some (but not all) queries result in an error which looks like: SQL0805N Package "NULLID.SQLC2H21 0X4141414141504161" was not found. The solution is that the servers must be made compatible with the newer client by adding some binding permissions. This incompatibility seems to extend to the pure Java Type IV driver as well.…

Read more »

Unicode alchemy with DB2

Recent versions of DB2 have support for Unicode, if your databases are flagged as Unicode-enabled. This is a good thing, so you may have done it without thinking too much about the consequences. After all, i18n is good, right? Unfortunately there are some major snags to be aware of. In particular, in Unicode-enabled databases the length limits in VARCHAR(n) are no longer character length limits. Instead, they are storage length limits.…

Read more »

Multi-line comments considered harmful

Recently on the ruby-core mailing list, someone asked why Ruby doesn’t have multi-line comments. I did a few searches, and didn’t find much discussion of the evils of multi-line comments. I thought it was common knowledge that they were a bad thing and a historical mistake made by Kernighan and Ritchie, but apparently not. So, here’s my opinion on the matter. Superficially, multi-line comments seem like a handy thing to have, especially if you often comment out blocks of code temporarily during development.…

Read more »

HTTP JVM: java.security.InvalidKeyException: Illegal key size

If you try to do anything using Java cryptography on an IBM Lotus Domino server, it probably won’t be long before you hit an exception like this (shown in the system console): HTTP JVM: java.security.InvalidKeyException: Illegal key size To see what the problem is, you can try running the following piece of code on the server: import lotus.domino.*; import java.security.Provider; import javax.crypto.Cipher; import java.security.Security; import java.util.HashSet; import java.util.Iterator; import java.…

Read more »

Negotiating the IBM DB2 version maze

Suppose you want to install a DB2 server, and connect to it from some client software. If you browse the IBM DB2 Software pages, you’ll soon find that there’s a bewildering array of products with confusingly similar names. For example, IBM Data Server Client and IBM Data Server Runtime Client are two different things. Fortunately, help is at hand. Paul Zikopoulos has written several articles for IBM developerWorks describing the differences between the different DB2 client and server options.…

Read more »

Web Services, SOAP, Domino, and Java 6

A while back I made a brief attempt to embark on a voyage of Web Services discovery via JAX-WS. The problem was simple enough: I had a Java program running on server A which had an object. I wanted to send that object to a Domino server running on machine B. Domino has a nifty Web Services feature these days, so it took about 2 minutes to create the SOAP-based Web Service.…

Read more »

Bitten by the specialness of Java arrays

Posted on

Suppose you have some text in Java that you want to manipulate. There are classes like StringBuffer for doing so, but let’s imagine that you choose to use a char array for some special reason. Now suppose that several pages of code later, perhaps in a different piece of code entirely, you decide to use the value of the variable. At that point, you’ve forgetten that you didn’t use a StringBuffer, so you do the usual thing and call the toString() method.…

Read more »

Java SSL/HTTPS via JSSE: Write once, run everywhere?

A common Java problem is to connect to an authenticated Web Service via HTTPS. Doing so while preserving portability can be tricky. There are a lot of helpful tutorials out on the web that say to do something like this: Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); System.setProperty("java.protocol.handler.pkgs","com.sun.net.ssl.internal.www.protocol"); final MyAuthenticator auth = new MyAuthenticator(username, password); Authenticator.setDefault(auth); try { final URL url = new URL(httpsurl); try { final HttpURLConnection urlc = (HttpURLConnection) url.openConnection(); try { // Rest of code However, if you try to deploy the code on a system using IBM’s JVM, you’ll get a rude surprise:…

Read more »

The fractious leap second debate

You might not have heard about it, but there’s a debate going on which threatens to redefine time as we measure it. I’m something of a time nerd; all the computers in our house are synchronized to atomic clocks, as are several of our regular clocks, my wristwatch, and my phone. The debate going on concerns leap seconds. To understand the importance of it, it’s necessary to understand what a leap second is.

Recording time is made difficult for us by the fact that we live on a large rotating object with high mass, in orbit around a star. We like our time measurements to correspond to the apparent observed motion of the star in our sky; in short, we like day to be light, and night to be dark. We also like to set our calendar based on the earth’s orbit around the sun, so that winter is always cold and summer is always hot.

Inconveniently, the earth does not make an exact number of rotations per year. Hence every now and again it’s necessary to have a leap year, inserting an extra day into the calendar to bring it back into sync with the earth’s orbit, so that the months don’t gradually drift against the cycle of hot and cold weather.

The problem of wanting day to be light is solved by having time zones, with different parts of the world choosing a different offset in hours so that noon is roughly when the sun is overhead.

Historically, the offsets were measured from GMT, time as measured at the Greenwich Observatory in England, calculated from the position of the sun. However, the development of atomic clocks of increasing accuracy, and telescopes of increasing power, made scientists aware of problems with this simple scheme.

Read more »

Java, JDBC and "memory leaks"

Every time Java is discussed on Slashdot, someone says that the overheads of automatic memory management aren’t worth it because Java still has memory leaks.

After further discussion, it generally turns out that they’re not talking about memory leaks; rather, they are talking about failure to free up resources in a timely manner — resource hogging. It’s a subtle distinction. In a memory leak, the system loses track of the memory, so it never gets freed during the life of the program. In the case of Java resource hogging, the Java system is still keeping track of the resources, and will eventually free them — it just doesn’t do it soon enough.

A common situation where resource hogging occurs is JDBC, querying a SQL database from a Java application or servlet environment. The problem is, JDBC query code is surprisingly tricky to get completely correct. It’s easy to write code where an exception causes active JDBC objects to be left unclosed, leading to the application being unreliable, overloading the database server, or using more memory than it needs.

MySQL and PostgreSQL are extremely liberal in what they are prepared to accept. For example, you can generally close a connection and rely on the database to implicitly close everything else, including abandoning any uncommitted transactions. This is not the case with IBM DB2, which will actually refuse to let you close a connection unless you have cleared out everything properly. So it’s not just a resource usage issue — you can also suddenly find yourself having to do a ton of debugging when your data load increases and you need to swap out your development database engine for something more scalable.

So, it pays to get your JDBC code right the first time. To illustrate the painful construction of some hopefully correct JDBC query code, I’m going to discuss the process of writing a simple example program in Eclipse.

Read more »