Doug Werth ([log in to unmask]) wrote:
: What really happened is that I shot myself in the foot. When I created EMPDB
: I inadvertently defined the dataset name wrong causing the DBGET to fail.
: But instead of dumping out a DBEXPLAIN style message it was issuing a JNI
: PANIC message. I incorrectly interpreted this to mean that it wasn't finding
: the TurboImage class library when in fact it was just reporting an error.
: Once I found and fixed that everything fell into place.

Well, this points out a problem in the library that has now been fixed;
the code to throw an exception had a bug in it that caused the panic.
(I guess my testing should be extended to include cases that fail so
 I can make sure the failure mechanism is working properly!).  The next
time I upload a version of the library to Jazz it will contain this fix.

<snip>

: Your tutorial indicated that it will actually get the classes faster out of
: the zip file than if they were all standalone. Is that still true?

Still true, although it's a minimal difference.  I haven't to date been
packaging the TurboIMAGE Class Library in zipped format, because I feel
like it is at least as much for tutorial purposes as for programmatic
use, and encourage people to read through the sources and see what's
going on.  You can create your own .jar file (which is now the
java-preferred extension instead of .zip, even though the formats are
identical (or at least compatible)).  For example, if you create
turboimage.jar including just the .class files -- not the documentation
and source as the 'makezip' command file does -- you can then add that
jar file name to your CLASSPATH or pass it via the -classpath variable
and have the classes loaded from the .jar file.  This would especially
be more convenient if you are redistributing an application that needs
the library and want to omit any extraneous files.

<snip>

: Thank you. I just subscribed to the sigjava list yesterday. I tend to think
: of the Interex list servers as a place for the SIG adminstration issues and
: hp3000-l/comp.sys.hp.mpe as a place for technical discussions. How do others
: view this? This issue may deserve an entirely new thread since many members
: may not have even read this far.

The original thought was that Java users were a small subset of
3000-L subscribers and it would be better to take lengthy discussions
of Java usage off the 3000-L.  As Java becomes more mainstream, we'll
no doubt see more of the discussion crop up on 3000-L.  For myself,
it's easier to have the java list because I don't always have time
to scan every message on 3000-L, but the java list traffic is small
enough that I read every message.

: Doug.
: Doug Werth                                     Beechglen Development Inc.
: [log in to unmask]                                       Cincinnati, Ohio

-----------------------------------------------------------------
Mike Yawn
Hewlett-Packard                      email       [log in to unmask]
Commercial Systems Division          Voice         (408) 447-4367
19447 Pruneridge Ave M/S 47UA        Fax           (408) 447-4441
Cupertino, CA  95014
-----------------------------------------------------------------