Java Sound Resources: Contact: Question Guidelines

In your emails, address the list, not individuals.

Do include a detailed description, of expected vs. actual behavior. Explain in detail how to reproduce your problem. Also, starting with an Executive Summary, and giving meaningful subjects will help you to get a quick reply.

Often, if a program isn't working as desired, an exception is thrown. Knowing exactly which exception is thrown, and where it is thrown, can be the key to understanding a problem. So it's important to document exceptions in your request.

Let's have a look at how you know about occuring exceptions. Your code might looks like this:

try
{
        // action that may throw an exception
}
catch (Exception e)
{
        // DO NOTHING
}

In this case, don't dare to ask on a mailing list why your program doesn't work. You are catching exceptions, but are simply ignoring them. So you will never know if an exception has occured at all.

The slightly better example:

try
{
        // action that may throw an exception
}
catch (Exception e)
{
        System.err.println("an exception occured!");
}

Now, you know at least that there was an exception. But you still don't know which type of exception it was, nor where it was thrown. So let's step to an even better solution:

try
{
        // action that may throw an exception
}
catch (Exception e)
{
        System.err.println(e);
}

Well, not fully there, yet! Now the ultimative solution:

try
{
        // action that may throw an exception
}
catch (Exception e)
{
        e.printStackTrace();
}

Strip down your program to the minimum that is necessary to demonstrate the problem. Most recipients don't have the time to read tons of source code, just to find that the problem is a small typo. It is very common that in the process of extracting the passage that exposes the problem, you'll find the actual problem cause.

So the bottom line is: dont waste your recipients' time. Or, put the other way: THEY won't waste THEIR time. If you request a great amount of work from your recipients, it may happen that your question will be ignored silently.

Knowing the exact Java version you use can be very important. Even between sub-minor releases a bug in the Java Sound implementation may have been fixed or another one may have been introduced. So it is important to know, for instance, if you are using 1.3.1_01 or 1.3.1_02.

The best way to let your recipients know the exact Java version is to run java -version and copy the output into your e-mail. It should look similar to this:

>java -version
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

You can also get the Java version when running a program with java -showversion <class>.

The above works fine for Java applications, but for applets in browsers, getting the Java version is more difficult. For the Java Plug-in use the following procedure:

For Mozilla, you can do something similar by selecting the menu entry Tools / Web Development / Java Console.

"I'm using Windows" isn't of much help. There are Windows 95, 95b, 98, 98SE, ME, NT 3.51, NT4.0, 2000, XP, home edition, professional edition, server edition, service packs and -- I'm sure I forgot half of the variants. And each version has specific bugs. For instance, you may encounter an abnormal behaviour with Java Sound on Windows XP. But if others try to reproduce the problem on Windows 2000, there is nothing abnormal, because... it's a problem specific to Windows XP. So it's in your own interest to be precise in naming your operating system version. At least if you think that it's in your own interest that others understand your problem. :)

If you experience strange sounds, try to describe the type of anomaly (noise, stuttering) as verbose as possible. Often, the type of sound gives a hint on what went wrong. For instance, white noise is often caused by byte order problems.

Most of the points above are actually about being nice to the recipients of your question. Here are some additional, general points.

Note that using URGENT and IMPORTANT almost certainly lowers the priority many recipients give to answering such a question. Your project is urgent. However, the recipients of your question are working on projects, too. Urgent ones, of course. Try to trick them to snatch time of their urgent projects to have a look at your problem. Make their job as easy as possible and lower your voice. If you think that your project is the most urgent one in the world, at least try to not show it too obviously.

Using ALL CAPS in your email or the subject is taken by many people as impolite shouting. You don't shout in one's ear if you want to get an answer in normal voice.

Do not post an unanswered message again. If it is not answered in, say, a week, reformulate it and use these guidelines to increase the likelyness of a quick response

See also: