This is a follow-on of the discussion started in this forum thread:
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=os_libraries_tools;action=display;num=1229457058

Because the pre-processor is adding import statements to various default
packages, it can cause naming conflicts with types defined in 3rd party
libraries, as happened to me several times and now with an acute example
delaying the release of my library (which works fine with Processing
outside the PDE). I think with the growing amount of 3rd party libraries
and people generally venturing more into Java territory, a cleaner, more
flexible and less error-prone solution should be found. The convenience
benefit of not having to think which default classes to import should of
course still be remaining for the average user, but the current solution
simply doesn't even allow a workaround.

The default packages imported in a wildcard approach are:

java.applet
java.awt
java.awt.image
java.awt.event
java.io
java.net
java.text
java.util
java.util.zip
java.util.regex

According to Eclipse these are the unravelled imports actually used by
PApplet and I'm sure most of them are not even needed by the average user
sketch applet itself and hence could be removed from the default imports,
keeping them as lean and mean as possible/feasible.

import java.applet.Applet;
import java.awt.Color;
import java.awt.Component;
import java.awt.Cursor;
import java.awt.Dimension;
import java.awt.FileDialog;
import java.awt.Font;
import java.awt.Frame;
import java.awt.Graphics;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Image;
import java.awt.Insets;
import java.awt.Label;
import java.awt.MediaTracker;
import java.awt.Point;
import java.awt.Rectangle;
import java.awt.SystemColor;
import java.awt.Toolkit;
import java.awt.event.ComponentAdapter;
import java.awt.event.ComponentEvent;
import java.awt.event.FocusEvent;
import java.awt.event.FocusListener;
import java.awt.event.InputEvent;
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
import java.awt.event.MouseListener;
import java.awt.event.MouseMotionListener;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.awt.image.BufferedImage;
import java.awt.image.MemoryImageSource;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.BufferedReader;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.io.UnsupportedEncodingException;
import java.lang.reflect.Array;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.MalformedURLException;
import java.net.URL;
import java.text.NumberFormat;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Calendar;
import java.util.Random;
import java.util.StringTokenizer;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.zip.GZIPInputStream;
import java.util.zip.GZIPOutputStream;
import javax.imageio.ImageIO;
import javax.swing.JFileChooser;
import javax.swing.SwingUtilities;

What do you think about this possible solution below?

As hinted on above, we could replace the package level default imports
specified in the preference with concrete qualified types. I'd also like to
propose to trim down & keep this list as short as possible, considering
most of these classes above are not directly required by the average user
and I'd reckon people working with some of the more "obscure" ones could be
expected to manually add the imports for these themselves, no?

The new entries for the default imports would then look like this (and can
be concrete types or wildcards):

preproc.imports=java.applet.*,java.awt.Frame,java.awt.Dimension,...

All what's needed then is a small change in the
PdePreProcessor.writeImports() method to remove the explicit wildcards from
there:

for (String item : defaultImports) {
out.println("import " + item+";");
}

A concrete example which is biting me with my library is a naming conflict
caused by the automatic import of java.awt.Color (due to "import
java.awt.*;") and my own Color class. However, hardly anyone using
Processing is actually making use of the AWT Color type...

Another (classic) example of a naming conflict is caused by the parallel
import of both "java.awt.*" and "java.util.*". The line below will fail
unless the "List" type is fully qualified:

List list=new ArrayList(); // fail
java.util.List list=new ArrayList() // succeed, but cumbersome

This seems reasonable, at the minimum it needs to be moved into preferences
so that it's even possible. It won't make it in for 1.0.2, but maybe I'll
do it in SVN right after the release, so that we have some time to let it
test/bake for a bit to see how it works.

Now fixed for whatever release follows 1.0.9. Sorry this took so long, it
got buried on my list while I didn't have much time to work on P5. Please
keep me posted if you run into other issues that need to be addressed (and
file new bugs for 'em), I'll be working on it more through the next couple
weeks.

fixed for 1.1, finally closing bug.