Java and IBM 6400 Line Feeds

I've got a client with several IBM 6400 line printers, and I started out printing to them with code that looks like this:

buf.append( stuff );
buf.append( "\n" );

So far, so good, until I print to a 2nd printer, which in some places double-spaces the printout, and in others, just gives line feeds. So I ask them to send me a printout of the printer config, and it shows that the printer is in Proprinter Emulation mode, which has an AUTO LF setting that is enabled. Okay, so I'm thinking I should be just sending carriage returns, and let it generate the line feeds.

No good. For whatever reason, when I just:

buf.append( stuff );
buf.append( "\r" );

to send just the CR, nothing comes out. Just to say I've tried all the combinations, I change the code to:

buf.append( stuff );
buf.append( "\r\n" );

expecting to get rid of my just-line-feed issue, but also expecting the whole report to be double-spaced, and to my surprise, it works.

My guess is that Java was doing something with the line-end characters, doing me a favor when I didn't want it to, and being explicit with \r\n turned that off? I don't know. And because both printers are some distance away from my office, I didn't bother to get the folks at the 1st printer to send me their config, so I'm still guessing that they have emulation set to something with AUTO LF disabled. Maybe next time I'm out there, I'll check...

(Oh, and yeah, looks like I just managed to squeak in my one post to this blog for the year. I've been making tech notes in Google Wave recently, so when that comes out of preview mode and integrates w/Blogger publicly, I should be reviving this blog somewhat...)

Java Woes

Yes, I'm thinking back this day to the good old days of programming. Back to my C++ days. Back when, if a piece of code that you called didn't exist or wasn't available, it gave a nice, sensible link error and refused to create your executable.

Yes, I'm in an "I hate Java" moment.

We need to connect to a DB2 database. This particular database insists on encrypted connections, and because it's an IBM database, (and because they can, I suppose), DB2 insists on having client apps use THEIR encryption algorithms. Which either means using their Java runtime entirely, or messing with the /etc/java/security/java.security file in my Sun JRE install. Yup, red flags are waving, buzzers are going off. Danger, Will Robinson, danger!

So I replace the entries in java.security with IBM's classes. At this point, everything Java on my box stops working, complaining about not finding SHA-1 and/or MD5. I mean, Eclipse won't save my source files, for crying out loud. So I put the Sun stuff back, and add the IBM stuff at the end. A sample command line program that connects to DB2 now works (as does Eclipse, once again), but the same code in Tomcat 5.5 doesn't work. Gives error of "Prime size must be multiple of 64, and can only range from 512 to 1024".

After poking around a good bit further, it finally dawns on my boss, who was also troubleshooting this, that not only do we need to specify the classes in java.security, but we also need to make 6 new jarfiles available on the classpath for Tomcat (and presumably every other Java app that uses that runtime).

Which brings me back to my pining for the good old days. The days when, if I forgot a library, I got a message saying "Dude, you forgot a library", not something completely orthogonal like the above "Prime size ..." hooey.

I'm gonna go do something that makes sense, like C++. Grrrr...

Background Threads in Tomcat

I have a task that I want to run once a minute. I have it coded as a command-line app, but getting that app to run as a Windows service is getting to be a pain. And, we also have an instance of Tomcat running on that server, so I started looking at how to get it to run within Tomcat.

This made me a bit nervous at first, as Tomcat does a lot of threaded stuff on its own, and I'd really rather not step on its toes, but after a bit of searching, I found that kicking off your own threads is a fine thing to do in Tomcat, but with a couple of caveats.

First, Tomcat lets apps ("contexts" in Tomcat lingo) be hotswapped, i.e. restarted or removed and replaced with new code, without stopping the VM. This means that you need to wire up your thread to stop when the app (sorry, "context") is stopped. You can write a servlet to watch over your thread (that can actually be the thread itself, too), and have Tomcat instantiate it, by configuring it in web.xml with "<load-on-startup />" included.

The servlet itself will extend HttpServlet (of course), and implement Runnable (if it's to have the thread code in it as well, which is handy. Then, when the destroy() method is called on your servlet, you tell your thread to stop itself (i.e. via a call to Thread.interrupt(), perhaps), as the context is going away.

I found a code sample at http://classes.eclab.byu.edu/462/demos/PrimeSearcher.java that helped, although that sample is coded to call Thread.stop(), which is now deprecated.

Anyway, I now have simple thread doing background processing, nicely cooperating with Tomcat.

Copying a File in Java

I just wrote a little monitor program. It watches one directory, and when it finds a file, copies it to a 2nd dir, processes it, and deletes it. Using Java's File object, the whole thing was simple, except for the copying part. Any reason why the standard Java libraries don't have a file copy method?

With Google's help, I found one online at Java Almanac, which was almost as handy, but why, pray tell, ... oh, never mind. Now where'd I put my Ruby book...