Guest-Speaker (SPK): SPK-jaz and SPK-rohaly

SPK-jaz: Hello and welcome to the Code Clinic. My name is John Zukowski with the MageLang Institute (http://www.magelang.com). I'm here with Tim Rohaly (rohaly) also from MageLang. We're here to answer questions you have about Java-related topics, and to help you work out the bugs in any code you may have.

deanh: Hi, I am having a problem with native methods and packages. I have written a Registry manipulation class that works as long as the class files and the .DLL are in the same directory. The minute I put the Registry class in a package, I can't get to the native methods. The PATH environment variable is set and the .DLL is there. Can I put native methods in a package and import them, or does every thing need to live in the same place?

SPK-jaz: I presume you are using loadLibrary to load the .DLL file?

deanh: Yes I am. I know that the .DLL is loading because when I change the name, I get the expected runtime exceptions. I have tried both System.loadLibrary and Runtime.loadLibrary.

SPK-jaz: I'm trying to dig up the appropriate source to check. Have you tried putting the .DLL file in a subdirectory of the same name as the package?

deanh: Not in a subdirectory, but in the package directory itself. Currently there is only one class in the package. The symptom seems to indicate that the VM is not searching in the same places as the system does.

SPK-jaz: The regular source says it does the searching in a system-dependent way. I'm checking the native source that does the actual check. Have you gotten this source from Sun and looked into it? Anyone can get it. You just have to sign an appropriate agreement above the normal JDK one.

deanh: No, good point.

SPK-jaz: I thought I would share my findings:

In Runtime.loadLibary, it builds a temporary file name to load with the native buildLibName method. It looks like this appends each PATH entry with the library name and .DLL (for DOS/Windows) As such, it seems like the .DLL should not go into the package directory, but somewhere in the PATH. As CLASSPATH and PATH are for different things, this seems like the correct behavior. Are you getting something else to happen?

deanh: The error that comes back is: java.lang.UnsatisfiedLinkError: getNumSubKeys(native method)

SPK-jaz: But, didn't you say you were placing the .DLL in the package subdirectory, not a directory in the PATH?

deanh: Yes, I have put the .DLL in the path and in the subdirectory--neither seems to make any difference. If I mangle the .DLL name I get:
java.lang.UnsatisfiedLinkError: no JavaSNativeRegistry in shared library path.

This leads me to believe that the library is being loaded, or maybe I am just too close to the problem right now. The place I originally installed the .DLL was in the WinNT/System32 directory.

SPK-jaz: Let me make sure I understand the specific problem you are having. Basically you want to load a .DLL. When your Java class that loads the native library is in the default package, the library loads fine. If you move the Java class into a "package" the library stops loading.

deanh: That is correct.

SPK-jaz: The .DLL file is located somewhere in the PATH.

deanh: Correct again.

SPK-jaz: Which class is getNumSubKeys?

deanh: getNumSubKeys is the native method in the .DLL that is called from the JavaRegistry class

SPK-jaz: When moving a class between packages, it is necessary to regenerate the native language stubs. Once the class is moved, regenerating the stubs, and the .dll (using the new method names in the native code), everything will work fine.

chuckie: Hi (and thanks). I am working on an display applet and server-side application that generates some images. So far I have been using HTTPreferences to access the images. However, I would like to convert to RMI. To do this, the Image class must be Serializable. My understanding is that it is/will be, but this doesn't appear to be the case at this time. Will the Image class be made Serializable? If so, when (what release)? If not, or if a long way down the road, what would be a useful approach that would work with RMI?

SPK-rohaly: You're right that Image is not Serializable, so it can't be passed by value over RMI. As far as I know, there is no plan to make it Serializable in the near future. The JFC's have an Icon class that is essentially a Serializable Image, with methods to convert between the two. So that would be one option. Another would be to put the Image into a byte array and send the byte array through RMI.

bieber: I'm looking for a way to display animated GIFs from JDK 1.1. Is this supported? Is there a class or third-party product that will allow me to display animated GIFs in a Java application? Thanks.

SPK-rohaly: Yes, you can use animated GIFs the same way you use regular GIFs. This is a feature present in JDK 1.1, but not in JDK 1.0.

kdlitwak: I have a fundamental JDBC question/problem (and I haven't been able to get any help on newsgroups). I am trying to work through the online JDBC tutorial on the JDC site. I dowloaded the testdb.mdb database, set up my Access ODBC driver with "mage" as the data source, compiled and ran the CreateJOltData.java program, and got a failure to connect. That suggests to me that I have a basic environment problem, but I can't figure out what it is. In fact, the Java book I have that disucsses JDBC says that for the setup like this, you're on your own. What would cause getConnect() to fail? I'm on Win95 uisng JDK 1.1.3. Thanks.

SPK-rohaly: We should be able to help. We wrote that tutorial! What version of the ODBC driver are you using? Is the database on the same machine as your Java program? Did you try the JDBCTest program to make sure the datasource was configured properly?

kdlitwak: I'm not sure what version of ODBC it is. It is the ODBC32 Access driver and I got it about a year ago with the PC. Where do I look for a version number? The database is on the same PC as the program. I don't know what JDBCTest is. I guess I need to know!

SPK-rohaly: Running JDBCTest is described in exercise number two of the online JDBC course. JDBCTest will let you test to see that you have set up your ODBC datasource properly. This is the first step you should take, before you try to connect with your own Java code.

SPK-jaz: If you go to http://www.microsoft.com/kb/articles/q159/6/74.htm, you can get the latest ODBC drivers, in case you are dated.

kdlitwak: Okay, let me try that and I'll be back! Thanks.

SPK-rohaly: Another thing to try is to look at the solution of the exercise in the online training. The solution should compile and run for you. If it does, then the problem is with your code. If it doesn't, then the problem is with your ODBC setup.

dan-f: Hi there...I'm talking from Israel and I work on a localized Hebrew Windows 95 system. I have a problem with Hebrew writing in text components. As you may know, Hebrew is written from right to left. In Hebrew Windows, I can switch between Hebrew and English by pressing <CTRL+Right Shift> (for Hebrew) and <CTRL+Left Shift> for English. If Windows is in Hebrew mode, I can write in all the editors in Hebrew, and the writing order is right to left. When I use JDK 1.02, there is no problem and I can write from right to left. When I use JDK 1.1, I cannot change to Hebrew mode on text components, and even if I succeed in changing the mode (if I move to some other windows application) when I return to the Java text component, I see non-English characters, and the writing remains left to right. I would be greatful if someone can help me, because I cannot write Hebrew Java applications.

SPK-jaz: While I am not familiar with this specific problem, it seems to be logged as bug 4086029. As it is an open bug, it seems Sun is aware of the problem and working on correcting it. May I suggest you VOTE on this in the Bug Parade at the JDC to get it fixed quicker than others.

SPK-rohaly: There should be no problem adding standard AWT components to an internal frame. If you look at the SwingSet demo, in the file "InternalWindowPanel," you will see how they do it.

From your description, it sounds like you are doing the right thing. My suggestion would be to look at the SwingSet code to see if there is something you missed.

<servlet: I've looked through that code, and I can't see that I'm doing anything different--except I'm using an applet and they are using a JFrame.

SPK-jaz: 0.5.1 seems to start getting Swing working in Applets. However, it still doesn't seem to be perfected. Some pieces work and some don't.

SPK-rohaly: Yes.

<servlet: Is there anyway to get around it? Sign the applet, etc.? Will this always be a problem?

SPK-rohaly: I get the same exception when trying to run the SwingSetApplet. Even when setting appletviewer to have unrestricted access. I am not using Windows, so this seems to be a problem with the SwingSet rather than with a particular JDK or system setup. It is possibly a bug.

SPK-jaz: The Swing stuff doesn't work in applets yet. Signing the applet should work. Although, once the Swing team gets this to work, it won't be necessary to sign applets.

Judith seems to be having problems... Her question has to do with the entry of dates into a text field.

From Judith: My question has to do with data entry of dates. The users want to enter them in YYYYMMDD format, but with SimpleDateFormat, I have to have some sort of delimiter, like yyyy.MM.dd. The users do NOT want to type in "1997.10.23." How can one give the users flexibility of entry of dates, and yet easily convert it to a Java Date or, in this case, an Oracle or Sybase date?

To Judith: It seems like SimpleDateFormat is not an option for you, without delimiters. If you know they will always enter in text as YYYYMMDD, you can parse the input yourself and use the java.sql.Date constructor to create a Date. You can try to use SimpleDateFormat first, then if that fails to give you a Date, manually parse. That would help a little in the sense that if they use an understood format, you won't have to always parse. The DateFormat stuff works best if you know which format the user is entering it in.

Regarding the part about a generalized date input mechanism, I suspect someone has one out there in Java land. Let me do a quick search for one to see if I can find one...

wirth: I am trying to get a checkmark (Unicode \u2713) to show up in a text area. I have created a character to store the Unicode number, then appended the char to my text area. It shows up as a question mark, which I think means the text area cannot recognize the character. I can get the check to show up in a graphic with the .drawChars() method, so I know the problem is not that my platform (Win95) doesn't show this character. Should it be displaying in the text area, or am I trying to do the impossible? :)

SPK-rohaly: Although Java makes the use of Unicode possible, the actual display is still up to the underlying (heavyweight) native platform components. In particular, in order for Unicode to display properly, the font in use must support the character set, and the native component must support the use of Unicode characters. And of course, the JDK port to your platform must be free of bugs :-)

The questions mark does mean that your checkmark symbol isn't available for use by the TextArea. I don't know why. I know on my non-Windows machine, it doesn't display because there is no font with that symbol available. I don't know why it doesn't work on your machine. The reason it may work with one component and not another is because of the different underlying native components and how the Java components are mapped to them.

SPK-jaz: As there have been some Swing questions today, I thought I would mention that a new tutorial will be coming online at the Java Developer Connection. The first of two parts of a Swing tutorial should be available starting tomorrow. The first part will have info on using Swing components where you previously used AWT components. Part two will explain the Model-View-Controller architecture (and the new components available with it), as well as the pluggable look-and-feel aspect of Swing.

JoeSam: Do you think the Swing API is stable enough now to begin using it in more serious applications?

SPK-jaz: According to the Swing team, the APIs in .5(.1) are supposed to be fixed, except for the UI-related pacakges (basic and plaf, I believe). While the APIs are fixed, the capabilities aren't fully implemented. On occasion, I've run across things that weren't working yet. If you'd like to get a feel for where Swing/Java is going, try it out. However, keep in mind it isn't even beta software yet and is subject to change/crash.

SPK-jaz: Basically, what you are trying to do isn't supported in a portable way. The AWT threads can be named anything (platform/VM-specific). Why do you not want to call System.exit()?

This question was also asked at the 100% Pure Java^TM session. If you check with the log for that, you will see their answer.

kschneid: Okay, sounds hopeless. I'm interested more from a design option perspective, I don't have an existing application where this is a necessity. Thanks.

dilbert1: Catbert passed me this question to ask you folks. We have a server application that uses the JDBC APIs. The problem with porting this to different platforms is that the database driver name and/or the user name and passwords may be different. Is there a way to specify a different database driver for each Java platform that I port to, while still keeping my code 100% pure (portable)? For now I use a Properties file for platform-specific information as well as DEBUG on/off flags, etc. Is this a good way, or do you know of a better design pattern?

SPK-rohaly: I don't know about better, but I do know a different one that I have used in the past. This is to treat each different database as a different "language" and bundle the database-specific properties into a ResourceBundle. That way you can simply set the Locale to Oracle, Sybase, Informix, etc. and you will read in the correct set of driver names, SQL commands, user names, and passwords.

This still requires you to enter some information either from the command line or in a text file somewhere, but it has the advantage of separating the database-specific stuff from your portable code. The properties can be set once at start up by prompting the user during the install, for example.

ResourceBundles are nice because they can be put in a JAR with all your other .class files, and the ClassLoader can find them there, so you don't need external files.

SPK-jaz: By the way, someone wanted me to point out a white paper that IBM recently released titled: "Building High Performance Applications and Servers in Java: An Experimental Study."It is available at http://www.ibm.com/java/education/javahipr.html

As the question queue is currently empty, I thought I would offer somone a chance to share what they are doing with Java. Anyone interested?

JoeSam: Rather than share a project, I'd like to ask if there is any interest, in general, in the San Francisco shareable Java framework that IBM is working on. I thought it could be a great thing, but the contract has enough legalese to scare away most developers, including me. Comments anyone?

SPK-jaz: A question from the ever-present JoeSam. Has anyone taken a look at San Francisco? Also, since San Francisco was brought up, I thought I would mention free seminars that IBM offers on them. If you visit http://www.spc.ibm.com/events, you can check the schedule for various free offerings from IBM.

kdlitwak: I've used the San Francisco Shareable Frameworks, and I don't think you want to go that way. They wrap RMI and make it more complicated. Also, the performance is terrible. I thought my code was broken because it took 30 seconds for a dialog box (very simple one) to show up, but it turns out it was just how long it took to get an object for a handle using the Framework methods. Too much compilation at runtime. It only suppors DB2 right or POSIX files, and the performance for POSIX files is terrible.

SPK-jaz: On San Fran specifically, there is a presentation in Waltham, MA and San Mateo, CA on Nov 6 and 7.

JoeSam: Also, since deanh is back, JDBCTest is available at:
http://java.sun.com/products/
jdbc/#The JDBCTest Tool

SPK-jaz: Judith would also like to share something with dilbert/catbert...

JudithObee: Following up on dilbert1's question: we have not yet determined the best way to manage that userid/password/URL/Driver information. We are a software development house, and we distribute our software to multiple clients. Whatever mechanism that we use has to be fully compatible with a typical client's security requirements and software.

For example, putting specific info into a Java class is inappropriate, because then we would require the client to have the Java compiler, and to actually understand Java development. I have checked up on the ResourceBundle, but I don't think it will help in this situation. So far, my solution has been a text file containing the relevant stuff. I would like a better answer.

SPK-jaz: ResourceBundles can be text files (or .class files).

JudithObee: Oh, that tidbit of info did not leap out at me when I read the ResourceBundle stuff. I'll read it again with that comment in mind.

SPK-jaz: Check out PropertyResourceBundle. As long as you name the file properly, you're OK. For instance, if bundle name is "foo" the files would be foo.properties for default locale, foo_it.properties for Italian property files.

JoeSam: There is a free paper at www.taligent.com that discusses Resource Bundles in an internationalization context, but is good for other uses as well.

kdlitwak: This isn't a code-specific problem, but I'm having trouble finding a good book that gives "real," i.e., full-on examples of applets using JDBC or CGI communication. Can anyone suggest one? All the examples I've found have too any compromises for the sake of the discussion to tell me what I want to know. Thanks.

SPK-rohaly: George Reese's Database Programming with JDBC and Java published by O'Reilly is essentially a case study of a distributed application using JDBC and RMI. I wouldn't recommend it as a general-purpose JDBC book, but if you want a good detailed example of how these technologies might be used in the real world, this is one place to see that.

Well, our two hours at the Code Clinic are at an end. Thank you all for coming. As usual, the transcripts from this session will be posted on the JDC web site within a few days. Don't forget to check the schedule for future Code Clinics and other live discussion events.