Home Original page

Re: Bug#559967: FTBFS [hppa]: method openConnection() in the type URL is not...

On 12/14/2009 04:58 PM, dann frazier wrote:
> On Fri, Dec 11, 2009 at 02:10:18PM +0530, Onkar Shinde wrote:
>> AFAIK, GCJ uses classpath library these days. The code from classpath
>> is being merged in GCJ. And from the status of classpath [1] it is
>> clear that java.net.URL.openConnection(java.net.Proxy) does not exist
>> in classpath implementation.
>> This can be easily tested. Try compiling following code with GCJ and
>> OpenJDK. GCJ fails to compile the code but OpenJDK works fine.
>>
>> ***************
>> import java.net.*;
>>
>> public class Hello {
>>         public static void main (String args[]){
>> 		try {
>> 			URL url = new URL("http://www.google.com";);
>> 			url.openConnection(Proxy.NO_PROXY);
>> 		} catch (Exception e) {
>> 			e.printStackTrace();
>> 		}
>>         }
>> }
>> ***************
>>
>> Hence this is a tool chain issue and not issue in package
>> libxmlrpc3-java itself. As of now there is nothing package maintainer
>> can do except disabling building of the package for all arch that use
>> GCJ as default compiler (to unblock the transition to testing).
> 
> Onkar,
>  Thanks for looking into this.
> 
> Would you mind filing a bug against the appropriate toolchain package,
> and setting a 'blocks' in the bug tracking system? This would make it
> easy to lookup the history/status of this issue next time someone
> notices it.
> 
> Also, I believe the appropriate way to avoid having this bug block
> testing migration is to request the removal of hppa binaries from
> testing. Once no hppa binaries exist in testing, we can reduce the
> severity of this issue to "important", which is not release critical.
> 
> I'd suggest *not* disabling building on gcj-archs because, presumably,
> this bug will be fixed at some point and we could then provide hppa
> binaries without updating each affected source package.

Fixing it properly will be hard, since AFAICS Classpath doesn't have support
for web proxies.  But does this package actually *need* proxy support
to work?  If not, it's easy to work around the problem with a simple patch
for the application.  I can give advice if you like.

Andrew.
Reply to: