Why did you send this to the Swing list? Its about printing which is
handled by 2D.
Please re-send it there : 2d-...@openjdk.java.net, as I don't want to
cross-post this.
-phil.
On 11/15/2010 6:40 AM, Nico R. wrote:
Hello!
In sun.print.IPPPrintService.getIPPConnection(URL), there is a bug with
class casting: see
<URL:http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/5672a2be515a/src/solaris/classes/sun/print/IPPPrintService.java>,
lines 1556–1565 for JDK 6,
and
<URL:http://hg.openjdk.java.net/jdk7/swing/jdk/file/d449b91c56b6/src/solaris/classes/sun/print/IPPPrintService.java>,
lines 1563–1572 for JDK 7.
The buggy code is:
public static HttpURLConnection getIPPConnection(URL url) {
HttpURLConnection connection;
try {
connection = (HttpURLConnection)url.openConnection();
} catch (java.io.IOException ioe) {
return null;
}
if (!(connection instanceof HttpURLConnection)) {
return null;
}
If the call to openConnection returns a FileURLConnection (as it does on
my system), that cannot be cast to an HttpURLConnection. The instanceof
check happens too late in the code.
What to do: either
* catch a ClassCastException and return null from the catch block, or
* use a variable of type URLConnection to store the result from
openConnection(), and cast it to HttpURLConnection /after/ the block
with the instanceof check.
The problem occurs, because there are URLs like "file:/dev/null" in the
list or URLs to try. They are retrieved from
sun.print.CUPSPrinter.getAllPrinters() via
sun.print.UnixPrintServiceLookup.refreshServices().
I assume this happens for printers that were auto-detected (e.g. via
ZeroConf etc.) some time ago, but are not accessible at the moment), but
I am not sure about that.
Perhaps the CUPS system is improperly configured, but this should not
cause Java applications to throw ClassCastExceptions.
Regards
