Description of problem: Consider this test case: import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.net.MalformedURLException; import java.net.URL; public class HttpsTest { public static void main(String[] args) { String url = "https://bugzilla.redhat.com/bugzilla"; try { BufferedReader read = new BufferedReader( new InputStreamReader(new URL(url).openStream())); } catch (MalformedURLException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } } [overholt@tophat tmp]$ javac HttpsTest.java With the Sun JVM, there is no output and the program exits normally: [overholt@tophat tmp]$ ~/tmp/jdk1.5.0_03/bin/java HttpsTest [overholt@tophat tmp]$ However, with gij (using jessie), I get: [overholt@tophat tmp]$ java HttpsTest java.io.EOFException: unexpected end of input stream at org.metastatic.jessie.provider.ContentType.read(java.io.InputStream) (Unknown Source) at org.metastatic.jessie.provider.RecordInput.readRecord() (Unknown Source) at org.metastatic.jessie.provider.RecordInput.pollClose() (Unknown Source) at org.metastatic.jessie.provider.SSLSocket.close() (Unknown Source) at gnu.java.net.protocol.http.HTTPConnection.closeConnection() (/usr/lib/libgcj.so.6.0.0) at gnu.java.net.protocol.http.Request.readResponseBody(gnu.java.net.protocol.http.Response, java.io.InputStream, boolean) (/usr/lib/libgcj.so.6.0.0) at gnu.java.net.protocol.http.Request.readResponse(gnu.java.net.LineInputStream) (/usr/lib/libgcj.so.6.0.0) at gnu.java.net.protocol.http.Request.dispatch() (/usr/lib/libgcj.so.6.0.0) at gnu.java.net.protocol.http.HTTPURLConnection.connect() (/usr/lib/libgcj.so.6.0.0) at gnu.java.net.protocol.http.HTTPURLConnection.getInputStream() (/usr/lib/libgcj.so.6.0.0) at java.net.URL.openStream() (/usr/lib/libgcj.so.6.0.0) at HttpsTest.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) Version-Release number of selected component (if applicable): java-1.4.2-gcj-compat-1.4.2.0-40jpp_55rh.i386 jessie-1.0.0-9.noarch gcc-4.0.2-8.fc4.i386 How reproducible: Always. Steps to Reproduce: See above. Actual results: Stack trace. Expected results: No stack trace. Additional info: This is preventing use of RH Bugzilla by the Eclipse Bugzilla plugin.
I suspect this is fixed in gcj 4.1. The old Request.readResponseBody was renamed to createResponseBodyStream and reworked a bit. It doesn't appear to close the underlying stream directly any more. I'm not set up to test this currently though :-(
I tested this on my combined GNU Classpath HEAD/GCJ HEAD + GNU Crypto/Jessie merge tree and I get this: $ java HttpsTest javax.net.ssl.SSLProtocolException: java.lang.Object cannot be cast to gnu.java.security.OID at gnu.javax.net.ssl.provider.Certificate.read (Certificate.java:123) at gnu.javax.net.ssl.provider.Handshake.read (Handshake.java:216) at gnu.javax.net.ssl.provider.Handshake.read (Handshake.java:110) at gnu.javax.net.ssl.provider.SSLSocket.doClientHandshake (SSLSocket.java:1519) at gnu.javax.net.ssl.provider.SSLSocket.startHandshake (SSLSocket.java:524) at gnu.java.net.protocol.http.HTTPConnection.getSocket (HTTPConnection.java:515) at gnu.java.net.protocol.http.HTTPConnection.getOutputStream (HTTPConnection.java:565) at gnu.java.net.protocol.http.Request.dispatch (Request.java:313) at gnu.java.net.protocol.http.HTTPURLConnection.connect (HTTPURLConnection.java:231) at gnu.java.net.protocol.http.HTTPURLConnection.getInputStream (HTTPURLConnection.java:490) at java.net.URL.openStream (URL.java:683) at HttpsTest.main (HttpsTest.java:13) Caused by: java.security.cert.CertificateException: java.lang.Object cannot be cast to gnu.java.security.OID at gnu.java.security.x509.X509Certificate.<init> (X509Certificate.java:176) at gnu.java.security.provider.X509CertificateFactory.generateCert (X509CertificateFactory.java:242) at gnu.java.security.provider.X509CertificateFactory.engineGenerateCertificate (X509CertificateFactory.java:89) at java.security.cert.CertificateFactory.generateCertificate (CertificateFactory.java:232) at gnu.javax.net.ssl.provider.Certificate.read (Certificate.java:115) ...11 more Caused by: java.lang.ClassCastException: java.lang.Object cannot be cast to gnu.java.security.OID at gnu.java.security.x509.X509Certificate.parse (X509Certificate.java:714) at gnu.java.security.x509.X509Certificate.<init> (X509Certificate.java:166) ...15 more
I also see the exception from comment #2. To see this with a gcc install tree, I add: security.provider.2=org.metastatic.jessie.provider.Jessie to $prefix/lib/security/classpath.security Then, I run gij like so: gij -Djava.endorsed.dirs=/usr/share/java/gcj-endorsed/ HttpsTest This assumes that you have the jessie RPM installed (so that the jessie jar is in the endorsed directory). I believe this bug was introduced here: http://lists.gnu.org/archive/html/classpath-patches/2005-07/msg00156.html I haven't looked into running the jessie test case mentioned in that report. When I add a workaround for the above, I'm back to the unexpected EOF.
Oops, never mind ... I was re-testing the wrong gij. With my patch against 4.1, I can get this to work again. So, I think this is fixed in svn. Jakub, I've CCd you since this patch should go in the gcj RPM...
It made into gcc-4.1.0-0.16 in rawhide.
Sweet, thanks. It works for me now.