Java Coffee Break Newsletter Volume 2, Issue 3 http://www.davidreilly.com/jcb/ ISSN 1442-3790 ========================================================================= In this issue * Java in the news * Q&A : My version of JDK won't run classes. What should I set my classpath to? * Q&A : How can I convert my Java classes to an .EXE file for Windows? * Q&A : Why can't my applet read or write to files? * Q&A : My application/applet loads images, but they aren't drawn to the screen. What's going on? * Q&A : When should I use an InputStream, and when should I use a Reader? * Q&A : How do I connect a Reader to an InputStream? ========================================================================= In the News Here are a selection of recent news items that may be of interest to Java developers. /*/ Sun to release a standard extension for XML eXtensible Markup Language (XML) is a hot new technology. Combining the over-hyped XML, with the over-hyped Java, will be an intereting, and highly anticipated event. For more information, see http://www.javasoft.com/features/1999/03/xml.html /*/ Java coming to a television near you! Java on the TV? Sound far fetched? It could become a reality in the not too distant future, if Sun's proposed API is accepted by major digital television manufactuers. For more information on the Java TV API, see http://java.sun.com/products/javatv/index.html /*/ Java maybe hot, but Microsoft want's to be cool Speculation over Microsoft's new Java-killer, code-named "Cool", is still raging. Can Java be crushed, or will developers stay loyal. See PC Week's article on the subject, at http://www.zdnet.com/pcweek/stories/columns/0,4351,389401,00.html ========================================================================= Q&A : My version of JDK won't run classes. What should I set my classpath to? Remember always to include the current directory in your classpath. For example, on Windows systems, you might need to try jre -cp .\  MyJavaApplication ,  or java -cp .\ MyJavaApplication Make sure that you're also in the right directory (where your application and its class files are located), and not your Java installation directory (e.g. c:\jdk1.2\bin\ instead of c:\myapp\") ========================================================================= Q&A : How can I convert my Java classes to an executable .EXE file for Windows? This is a very common question asked in the comp.lang.java newsgroup. Its often useful to have an executable application when deploying your applications to a specific platform, but remember to make your .class files available for users running Unix/Macintosh/other platforms. Microsoft provide a free system development kit (SDK), for Java, which includes the jexegen tool. This will convert class files into a .EXE form. The only disadvantage is that users need a Microsoft Java Virtual Machine (JVM) installed. If your target platform is Win32, you can either redistribute the virtual machine, or raise the level of your system requirements, to include Windows 98, or Windows 95 with Internet Explorer 4. Systems matching these requirements will already have a copy of the Microsoft Java Virtual Machine installed. Note : You must specify all of the class files your application needs (except for standard java packges) as a parameter, so if you have third party libraries, you'll need to include them as well. You can use wildcards * though, and you don't need the original source code. ========================================================================= Q&A : Why can't my applet read or write to files? Applets execute under the control of a web browser. Netscape and Internet Explorer impose a security restriction, that prohibits access to the local filesystem by applets. While this may cause frustration for developers, this is an important security feature for the end-user. Without it, applets would be free to modify the contents of a user's hard-drive, or to read its contents and send this information back over a network. Digitally signed applets can request permission to access the local filesystem, but the easiest way around the problem is to read and write to remote files located on a network drive. For example, in conjunction with a CGI script or servlet, you could send HTTP requests to store and retrieve data. ========================================================================= Q&A : My application/applet loads images, but they aren't drawn to the screen. What's going on? I've encountered this problem a few times in my own applications. When you load an image (using java.awt.Toolkit.getImage), the function returns immediately, and the image is loaded asynchronously. This means that sometimes an image isn't ready to be drawn, because it hasn't yet loaded. Depending on when the image is loaded, and when it is drawn, the problem can be intermittent and hard to track down. If your application or applet MUST display the image before doing anything else, you can have it wait until the image is fully loaded. An animation applet, for example, may not have any useful work to do until the image(s) are loaded. To wait for images, you need to use the java.awt.MediaTracker class. MediaTracker allows you to register an image with the tracker, and have your application or applet wait until the image is ready. Note that this isn't limited just to applets loading images over a network - from my own experience an application it can happen loading a small (<100 bytes) image from a local filesystem. To register an image, you assign it an image number, and call the addImage method. Then you can call the waitFor(int) or waitForAll() methods. // Pass media tracker any component (such as a canvas or an applet) MediaTracker tracker = new MediaTracker( this ); // Add images tracker.addImage ( myImage1, 0); tracker.addImage ( myImage1, 1); // Wait for images try { tracker.waitForAll(); } catch (InterruptedException ie) {} Once you start the wait, your application will block until the image has loaded. Then, you can call java.awt.Graphics.drawImage to display the image to your applet or application. ========================================================================= Q&A : When should I use an InputStream, and when should I use a Reader? This can be confusing, particularly if you're already familiar with InputStream, and keep getting deprecated API warning messages. Let me simplify it for you. * If you're reading data, such as bytes of information, you are best off to use InputStreams and DataInputStream in particular. * If you're reading in text, and want to be able to call a readLine() method, its best to use Readers, and BufferedReader in particular. So what's the difference? Well, DataInputStream's readLine() method is deprecated, because of problems with this method. Readers offer an alternative - though placing a readLine() method in a BufferedReader still seems a little odd to me. Whether its buffered or not has little to do with the fact it can read lines of text - but its easy enough to live with. ========================================================================= Q&A : How do I connect a Reader to an InputStream? This is a very common question - after all, there aren't any SocketReaders, or PipedReaders. You need something to bridge the gap between a Reader, and an InputStream. That's where InputStreamReader comes into play. InputStreamReader is a reader that can be connected to any InputStream - even filtered input streams such as DataInputStream, or BufferedInputStream. Here's an example that shows InputStreamReader in action. // Connect a BufferedReader, to an InputStreamReader which is connected // to an InputStream called 'in'. BufferedReader reader = new BufferedReader ( new InputStreamReader ( in ) ); You can do the same with an OutputStream to a Writer (see OutputStreamWriter for more information). ========================================================================= The Java Coffee Break Newsletter is only sent out to email subscribers who have requested it, and to readers of the comp.lang.java.programmer and comp.lang.java.help newsgroups. If you'd like to receive our newsletter, and get the latest Java news, tips and articles from our site, then get your FREE subscription from http://www.davidreilly.com/jcb/newsletter/ If you are an email subscriber and no longer wish to receive the JCB Newsletter, please unsubscribe using the WWW form located at http://www.davidreilly.com/jcb/newsletter/unsubscribe.html