Copy Link
Add to Bookmark
Report
Java Coffee Break Newsletter Volume 2 Issue 03
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
