[OpenJDK 2D-Dev] jdk6 and jdk7: wrong class cast in sun.print.IPPPrintService (in Solaris classes)

[Nico R.]

Hello!

Jennifer Godinez wrote:
> In our code we only use http in getIPPConnection so we expect
> HttpURLConnection .

This is true for the calls to getIPPConnection from the CUPSPrinter
class, but not for all calls. See below.

>  If openConection is returning FileURLConnection
> then this looks like a bug and needs further investigation.

Some investigation is below. I assume it is sufficient to reconstruct
what is happening.

>   Please
> file the bug at:
> 
> http://bugreport.sun.com/bugreport/

Unfortunately, I am not able to do this, because the bug reporting
system does not work for me. (I’ve just sent a report about this problem
using the contact form
<URL:https://developers.sun.com/contact/feedback.jsp?category=sdn&mailsubject=General%20Site%20Comment>.)

I’d appreciate it if you could report this bug instead. Here is some
further investigation:

It is not true that the code in OpenJDK always uses the "http" protocol.
It may also use a protocol reported by CUPS for a printer, as explained
by the following reverse call trace.


IPPPrintService.getIPPConnection(URL)
called by:
    CUPSPrinter.getAllPrinters()
      --> OK, always uses "http" protocol.
    CUPSPrinter.getDefaultPrinter()
      --> OK, always uses "http" protocol.

    IPPPrintService.initAttributes()
      --> uses same protocol as IPPPrintService.myURL
    IPPPrintService.isPostscript()
      --> uses same protocol as IPPPrintService.myURL


URL IPPPrintService.myURL
initialized by:
    IPPPrintService(String,URL)
      --> myURL is set to second parameter (url)

    IPPPrintService(String,String,boolean)
      --> if second parameter (uriStr) does not contain "ipp" and does
          not contain "http", then myURL will be constructed from a
          string which does not contain "http" (and may well be a "file"
          URL if the input starts with "file:")


IPPPrintService(String,String,boolean)
called by:
    UnixPrintServiceLookup.getDefaultPrintService()
      --> OK, always uses "http" URL

    UnixPrintServiceLookup.refreshServices()
      --> uses string from local variable printerURIs[]


printerURIs[] (local variable in IPPPrintService(String,String,boolean))
initialized with value from:
    CUPSPrinter.getAllPrinters()
      --> returns String[] created from values from printerNames (local
          variable)


printerNames (local variable in CUPSPrinter.getAllPrinters())
initialized from printer-uri-supported attribute values received from
CUPS


CUPS may report a "file" URL for a printer if, for example,
/var/cache/cups/remote.cache (the file may be stored somewhere else,
depending on your system/distribution/CUPS installation) contains a
reference to "file:/dev/null". This is where the "file" URL originated
on my test system.

OpenJDK should be able to handle this properly, and it seems that
someone already thought of implementing this, but introduced a bug here:

In my original mail, I wrote:
[…]
>> 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;
>>         }

As I already explained, this code does not make sense:

* if the class cast works, the block with ‘instanceof’ does not do anything;

* if the class cast does not work, a ClassCastException is thrown, and
the block with ‘instanceof’ is not executed at all.

(A non-null reference read from a local variable is always instanceof
the declared type of that variable, isn’t it?)

If my explanations were not verbose enough, please tell me what to
clarify further.

Regards
-- 
Nico