Windows Service Article

A few months ago I sent one of my blog entries "Running Java Applications as a Windows Service" to the Borland Developer Network. Click here for the article.

The Java Communications API Revisited...

Several months ago I wrote an article for the Borland Developer Network site (http://bdn.borland.com) on the Java Communications API. Since that time I've received numerous emails about the article. To those who've emailed me, thanks for your kind words.

I've compiled the following FAQ based on some of your questions and my responses. If you're working with the Java Communications API, you might find this useful.

Question 1:
If I'm trying to send a character through serial port communication to another computer how can I verify that the signal was sent?

Answer:
I used an old WYSE serial terminal and a null modem cable to test the code. Then I set both the serial ports to COM2 (the serial port on my laptop). I also used a separate communications port monitor of the type used for network troubleshooting.

If you have access to another PC with a serial port, you should be able to hook it to the one you're running the program on (via some serial cables, a null modem adapter, and maybe a gender bender). On the second PC fire up a communications program like HyperTerm or Procomm and set it to communicate on the serial port you're connected to. This will allow you to send and receive data between the PCs.

Question 2:
Is your code correct?

Answer:
The code runs correctly using J2SE 1.4 on a Windows 2000/XP. I've also run it on Red Hat Linux 7.2 using the RXTX version of the comm.jar (there's a link to RXTX in the article).

If you compile my example, execute it, and it doesn't give you any exceptions, it should be working properly. You'll get exceptions if the program can't get handles for the COMn devices or if the comm.jar, win32comm.dll, or javax.comm.properties files can't be found.

Question 3:
is possible to send and receive at commands using java comm?

Answer:
Yes.

Question 4:
Does Java send any additional characters with its strings to the serial port?

Answer:
Java does not send additional characters down the port (I know this because I've tested it with a port monitor). It sends what your program sends.

Question 5:
Does Java send the strings in ASCII values to the port?

Answer:
As far as data encoding is concerned, unless you specify something different, you'll be sending data in the default encoding of your hardware.

Question 6:
I am trying to send serial data using a usb to serial converter since my laptop does not have a serial port. Problem is, in Windows device manager, the usb to serial converter shows up as "Prolific USB-to-Serial Comm Port (COM4)", but running ComControl.java returns:

COM4 null
msg1 - javax.comm.NoSuchPortException

Any suggestions?

Answer:
I tried the usb to serial port converter that I have (it is a Targus PA090) and it worked properly. On the PA090, the serial port cannot run faster than 9600 baud. You may want to check the baud settings on yours. You may also want to experiment with the stop bits, parity, etc. The PA090 also has a serial port reset button. If your converter has one, try resetting it. Check for the latest drivers also.

Question 7:
I've tried running your code and I'm getting a "javax.comm.NoSuchPortException" message. Any clues?

Answer:
First, check your PC to see if the COMn ports you are using have been defined. Next, check the location of win32com.dll and javax.comm.properties. They are required for the comm API to work properly in a Windows environment. Usually the javax.comm.properites file is the culprit. It needs to be located in the classpath of your java program.

More Than Java Development

Sorry I haven't posted in a while. I have been busy with a Great Plains implementation. Follow the link for an article about Great Plains that mentions my company. When It Rains...

More on my thoughts about Microsoft Great Plains and VBA later.

Java Quick Tip of the Day: Reading non-Http Input Into a Servlet

Have you ever wanted to read something other than the results of a get or a post into a servlet? It's not as difficult as you think. It's really just a matter of using the getInputStream() method of the HttpServletRequest object.

Let's take a look at the following example:

public void doPost(HttpServletRequest request,
  HttpServletResponse response)
  throws ServletException, IOException {
 doGet(request, response);
 }
 public void doGet(HttpServletRequest request,
  HttpServletResponse response)
  throws ServletException, IOException {
 BufferedInputStream is = 
   new BufferedInputStream(request.getInputStream());
 InputStreamReader isr = new InputStreamReader(is);
 int character;
 StringBuffer process = new StringBuffer();
 while((character = isr.read()) != -1)
 { process.append((char)character);
  }
 System.out.println(process);
 }
catch...

Looking at the code, notice that the first thing we're doing is calling the doGet() method from the doPost() method. We do this as a simple way to redirect all incoming data to the same code. We then create a BufferedInputStream object is from the request.getInputStream() method. From is we've created an InputStreamReader object isr in order to read the inputstream. Next we create a StringBuffer object process and fill it with the characters we read from the inputstream...for those of you who've used inputstreams this code should look very familar. Finally we do something with process.

Why would you ever want to do this? One example of of using this technique is when you want to turn a servlet into a webservice. I'm currently working on a how-to article on this subject. Look for it shortly.

IT Strategy and IT Spending

First, let me apologize in advance for spelling mistakes I make this morning. I am writing this from my BlackBerry. I'm watching an early morning storm out over the Gulf of Mexico...glad that I'm not on a boat somewhere in the middle of it. But I digress...

In the 80's and 90's no one would dare create an IT strategy without including double digit percentage increases in IT spending. While this approach may have led to some pretty nice systems, it did little to help companies' bottom lines...more likely increased IT spending hurt bottom line profits.

Today we have to take a different approach. I like to look at it as a stewardship approach. We have to carefully consider how we utilize our most scare resource-cash. We in IT have to manage it and decide when and how to best deploy it.

Our corporate executives and boards want better margins...translation: less IT spending on needless upgrades and infrastructure and a closer look at IT spending as it relates to profits.

Fortunately for us (IT execs) the industry trend is lower overall technology costs. But, lower costs are not enough. We must also deal with vendors who want to sell us uneccesary products and services. And, in some cases, we have to deal with execs who want the latest in technology regardless of the cost.

My advice: stand firm. Don't deploy technology for technology's sake. Renogotiate existing contracts. Become vendor agnostic. And, don't let vendors and well meaning execs drive YOUR IT costs.