Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Bridge the gap between Java and Twain

Integrate imaging devices in Java using Twain and JNI

By Hugo Scavino, JavaWorld.com, 07/26/02

  • Print
  • Feedback

Page 2 of 6

  1. The application checks for Twain's existence
  2. Twain exists
  3. The application queries the Twain subsystem for all available sources
  4. The application displays the choices in the Swing 1.4 GUI
  5. The user chooses a source
  6. The user presses an "Acquire" button
  7. The application retrieves a Java image into the application
  8. The application further processes a Java image as the requirements state


Technically the use-case will conclude when you add your application-specific requirements.

Now that we have our use-case defined, we can begin to move towards design by creating a UML (Unified Modeling Language) sequence diagram. The diagram below lets us sequentially follow the steps required to fulfill the preceding use-case. The diagram allows us to follow the messages as they touch each class and thus, clearly see how the use-case is being implemented.

Acquire image primary flow. Click on thumbnail to view full-size image.

Without the use-case and flow, we could write large cumbersome APIs that no one will use or, worse yet, come up short during construction.

We can place the above steps into an iteration plan. We finish the iteration when we accomplish all the steps. We can add more features in subsequent iterations once we evaluate feedback from the first iteration. For now, we need only the bare minimum.

When I wrote the first version of the org.scavino.jtwain library, I added almost every function that Twain exposed—not a good idea. My client wanted only the minimum, and I gave the near maximum. I could have forgone the extra code to maintain, understand, and document.

Intel JPEG Library

Our architecture first needs a reliable JPEG decoder that can convert the native Twain DIBs to a format that Java can interpret. The IJL encodes and decodes your JPEG images. In its simplest form, the IJL can convert the native Twain DIBs to JPEGs rather than the default Windows BMP (Bitmap). Since Java natively handles JPEGs and not BMPs, some subsystem must complete the conversion. Choosing which layer handles the conversion is an important decision for several reasons:

  • First, we must decide if Java GUI clients should need additional libraries like Sun Microsystems' JAI (Java Advanced Imaging) or Java native BMP classes to manipulate the BMP file format. Or should the native DLL process the image?
  • Second, if the DLL converts the images to JPEG, then the IJL DLL might have to reside in the client machine's path. Adding a DLL to the DOS path is not a trivial deployment decision.
  • Third, an additional option would link the much larger ijl15l.lib library in lieu of the smaller ijl15.lib link library. This static library increases the stack size and would ignore potential ijl15l.lib DLL upgrades from Intel. If we wanted new JPEG functionality from the ijl15.dll, we would have to rebuild and test again.


To make this exercise cleaner and less daunting, the static link library option is the best. We won't need to call the cumbersome GetProcAddress(...) method, and we have one less deployment hassle to manage.

  • Print
  • Feedback

Resources