Bug#559967: FTBFS [hppa]: method openConnection() in the type URL is not...
dann frazier
dannf at debian.org
Mon Dec 14 16:58:00 UTC 2009
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.
--
dann frazier
More information about the pkg-java-maintainers
mailing list