In preparation for my next change, I committed this cleanup to
gnu/java/net/protocol/http/LimitedLengthInputStream.java.
2008-07-12 David Daney [EMAIL PROTECTED]
* gnu/java/net/protocol/http/LimitedLengthInputStream.java: Clean up
white space in entire file.
(handleClose): Remove
David Daney wrote:
In preparation for my next change, I committed this cleanup to
gnu/java/net/protocol/http/LimitedLengthInputStream.java.
Said change is not needed, the file is perfect as is, so I will leave it
just as the whitespace cleanup.
David Daney
the
sun/security variant and remove the gnu/java/security one.
Opinions?
Since we already have some sun.* packages, it seems fine to add more. I
would change everything over to refer to this new class and delete the
gnu/java/security one.
Just my $0.02,
David Daney
2008-06-03 Robert
to
allocate another array, we gain nothing over java.lang.StringBuilder
other than making the code more confusing. I am uncomfortable with this
change as well as the use of CPStringBuilder that makes it necessary.
Am I missing something here?
David Daney
to apply it.
Thanks,
David Daney
point to any benchmarks where this helps?
Thanks,
David Daney
David Daney wrote:
Andrew John Hughes wrote:
This adds our new non-copying variant of StringBuilder, which
I've called CPStringBuffer. It should be used internally where
we can get away with a non-synchronized non-copying string buffer.
ChangeLog:
I missed the change log part
this, but having to use reflection to invoke the
string constructor I think should be avoided.
David Daney
here. Other
than that, it seems like a good idea.
David Daney
for problems in an application. The
applications should add buffering themselves when appropriate.
David Daney
;
}
}
}
#endif
JCL_ThrowException (env, IO_EXCEPTION, strerror (errno));
}
Perhaps:
if ((errno == ENOTTY)
(fstat (fd, statBuffer) == 0)
S_ISREG (statBuffer.st_mode))
{
.
.
.
}
David Daney
is missing?
David Daney
call impl.create() from the Socket constructor?
David Daney
Regards,
Jeroen
Index: java/net/Socket.java
===
RCS file: /cvsroot/classpath/classpath/java/net/Socket.java,v
retrieving revision 1.61
diff -u -r1.61 Socket.java
--- java
'+'? The compiler converts this to String[Buffer|Builder] when it
generates the byte code. IMO this patch makes the code much more
difficult to understand with *no* improvement in efficiency.
David Daney
that there is no
difference on a benchmark that moves a lot of data through the changed
code, then I withdraw my objection.
David Daney
is that, in gcj for example, an array access is
translated in to a machine instruction that directly accesses the
desired element. Access through a java.nio.Buffer involves at least one
function call which is a much heavier weight operation.
David Daney
.
David Daney.
David Daney wrote:
Roman Kennke wrote:
Hi again,
On most free JVMs that I know of (libgcj), array accesses are much
faster than the corresponding actions on a java.nio.Buffer.
I don't think so. The normal bytebuffer is also only an array. The
accessor methods should not make much
Tom Tromey already did the heavy lifting here. This patch just tweaks
it a bit.
2006-12-21 David Daney [EMAIL PROTECTED])
* gnu/java/net/protocol/http/Headers.java: Update imports. Implement
IterableHeaders.HeaderElement.
(iterator): Make public.
* gnu/java/net/protocol/http
In the spirit of using the new generic type capability of Classpath, and
because I already did it while looking at the bug in Collecions, I offer
up this nice patch.
In two of the HTTP support classes I converted a couple of things to use
generics.
2006-12-14 David Daney [EMAIL PROTECTED
This fixes the mauve regression noted by Paul Jenner for the
java.net.URLConnection.getHeaderFields test.
A case of slightly over zealous genericization.
2006-12-13 David Daney [EMAIL PROTECTED]
* java/lang/Collections.java
(UnmodifiableEntrySet.toArray): Fix bad casts
more like an InternalError than the super-generic
RuntimeException.
David Daney
Jeroen Frijters wrote:
David Daney wrote:
Jeroen Frijters wrote:
throw new RuntimeException(error instantiating default
socket factory:
- + ex.toString());
That sounds more like an InternalError than the super-generic
of testing and if no objections are raised.
2006-12-08 David Daney [EMAIL PROTECTED]
* native/jni/java-nio/gnu_java_nio_VMChannel.c (is_non_blocking_fd):
New method.
(Java_gnu_java_nio_VMChannel_read__ILjava_nio_ByteBuffer_2): Throw
SocketTimeoutException if a blocking socket
David Daney wrote:
My new mauve test for the HTTP timeout patch I posed earlier this week
was failing miserably for me with jamvm/FC6-x86_64. I turns out the the
native socket code was slightly lacking. This patch fixes it up some.
I will commit both this patch and the HTTP timeout patch
David Daney wrote:
This patch adds the missing [get|set]ReadTimeout methods to
java.net.URLConnection. It is lightly tested, but I will create some
mauve tests for it.
If there are no objections, I will commit it after a couple more of days
of testing.
2006-12-02 David Daney [EMAIL
I just committed this:
2006-12-08 David Daney [EMAIL PROTECTED]
* NEWS: Mention URLConnection.[get|set]ReadTimeout.
I just committed this to fix my previous commit.
2006-12-08 David Daney [EMAIL PROTECTED]
* native/jni/java-nio/gnu_java_nio_VMChannel.c (is_non_blocking_fd):
Fix comment.
Index: native/jni/java-nio/gnu_java_nio_VMChannel.c
addrlen)
{
int retcode;
do
{
retcode = connect (fd, addr, addrlen);
}
while (retcode == EINTR);
return retcode;
}
Except that you should probably also check if the thread was interrupted
as the original patch does for read and write.
David Daney.
This patch adds the missing [get|set]ReadTimeout methods to
java.net.URLConnection. It is lightly tested, but I will create some
mauve tests for it.
If there are no objections, I will commit it after a couple more of days
of testing.
2006-12-02 David Daney [EMAIL PROTECTED]
* gnu
, new InetSocketAddress(remote, port));
+ }
+catch (InterruptedIOException ioe)
+ {
+// Ignore; interrupted system call.
+ }
+ }
}
How does the while loop exit?
Just wondering,
David Daney
I just committed the fix for said PR. A test for this was also added to
mauve.
2006-09-20 David Daney [EMAIL PROTECTED]
PR classpath/28661
* gnu/java/net/protocol/http/HTTPURLConnection.java (connect): Add
default content-type for POST method.
Index: gnu/java/net
.
Also I am running gcj/libgcj cross compiler and do not know how this
patch will interact with libgcj.
Well those are my concerns. I guess if things get broken by this we can
add a configure switch to manually disable it.
David Daney.
would hang (instead of immediately
returning EOF).
Earlier today I committed a mauve testcase for this problem.
Do we want to bring this into libgcj before this would be imported also?
2006-08-11 David Daney [EMAIL PROTECTED]
PR classpath/28580
* gnu/java/net/protocol/http
to me. I beleive this is the prefered idiom for clone() in
many cases. It seems that this is probably one of them, but not being
that familiar with this class I cannot say for sure.
David Daney.
strong
feelings one way or the other.
David Daney
of effort in this area.
David Daney.
] + start[sub]; i start[0] + end[sub]; i++)
+ sb.append(matchedCharIndexed.charAt(i));
+ return sb.toString();
+ }
Use StringBuilder instead of StringBuffer.
David Daney.
Wolfgang Baer wrote:
Hi David,
David Daney wrote:
Wolfgang Baer wrote:
Hi,
I wrote mauve tests for the various HttpURLConnection request properties
methods and notices some minor bugs in the new Headers implementation.
The patch fixes these and adds documentation to this class in more
putAll() is broken,
then the change should be made. But change just for change's sake I am
not so sure.
David Daney
solve the issue Christian was seeing.
Sorry about that :( Your fix is obviously correct.
David Daney.
(returning the header names in
their original case in keySet() etc).
In order for the map to be at all useful, I would have to agree.
However if we mimic Sun's brilliant implementation (as shown by
Wolfgang's testing), we can (and must) just do it the easy way.
David Daney.
David Daney wrote:
PR libgcj/26487 shows problems with our existing header handling.
I hacked up the attached patch, which needs more testing (please test it!)
The basic problem is that the headers were being held in a map which
scrambled them up if there were more than one header of the same
David Daney wrote:
PR libgcj/26487 shows problems with our existing header handling.
I hacked up the attached patch, which needs more testing (please test it!)
The basic problem is that the headers were being held in a map which
scrambled them up if there were more than one header of the same
);
! }
! else
! l.add(e.value);
The second value must be added before. The test show
that SUN always adds the last received value for a
key first.
l.add(0, e.value);
Good catch!, I will make this change.
David Daney.
Wolfgang Baer wrote:
David Daney wrote:
Wolfgang Baer wrote:
Nice to see you have removed that now useless inner Header class. This
was one
of the comments I wanted to make. I worked this day on mauve testcases
for this
rewrite.
These exposed two small bugs in Headers.java:
Index: gnu
Olivier Jolly wrote:
Chris Burdess wrote:
David Daney wrote:
With this test case (just added to mauve):
import java.net.URL;
public class URLTest {
public static void main(String []args) {
try {
URL url = new URL(http://www.foo.bar.com;);
url = new URL
David Daney wrote:
With this test case (just added to mauve):
import java.net.URL;
public class URLTest {
public static void main(String []args) {
try {
URL url = new URL(http://www.foo.bar.com;);
url = new URL(url, _urn:testing
was to just hold the headers in a list. This makes some
searching operations less efficient, but seems the best way to keep the
headers from being combined.
Let me know what you think.
2006-02-28 David Daney [EMAIL PROTECTED]
* gnu/java/net/protocol/http/HTTPURLConnection.java
As per the PR, HTTPURLConnection.getRequestProperties() was returning a
Map with Strings as values instead a Map of Lists of Strings as values.
I just committed this patch:
2006-02-27 David Daney [EMAIL PROTECTED]
PR classpath/25851
* gnu/java/net/protocol/http
David Daney wrote:
Currently we keep a HTTP keep-alive connection open forever.
Although allowed by RFC 2616, this is forbidden by several other
specifications derived from it (DLNA and UPnP). In addition to being
incompatible with these other specification, it is a waste of resources
OK today really is not my day WRT e-mail. I am going to try this one
more time.
Original Message
Subject: FYI: ChunkedInputStream.read()
Date: Thu, 16 Feb 2006 13:47:13 -0800
From: David Daney [EMAIL PROTECTED]
To: David Daney [EMAIL PROTECTED]
CC: Classpath Patches
.
Comments?
2006-02-16 David Daney [EMAIL PROTECTED]
PR classpath/26312
* gnu/java/net/protocol/http/ChunkedInputStream.java (imports): Cleaned
up.
(ChunkedInputStream): Extend InputStream.
(in): New field.
(headers): Moved to top of class
David Daney wrote:
+class GetPropertiesAction
+ implements PrivilegedAction
+{
+ public Object run()
+ {
+String ttl = System.getProperty(classpath.net.http.keepAliveTTL);
+connectionTTL = (ttl != null ttl.length() 0) ?
+ 1000 * Math.max(1
Wolfgang Baer wrote:
Hi all,
Wolfgang Baer wrote:
Hi,
David Daney wrote:
Perhaps make isError() a member of Response
Yes, I also thought of this. Its in HTTPURLConnection because there is
already a method isRedirect(Response r). Both should be moved to Response.
Committed as attached
Wolfgang Baer wrote:
David Daney wrote:
Thanks, please update: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26081
as appropriate.
If this fixes that bug (which I think it does) the changelog should be
prefixed with 'PR classpath/26081'
Sorry forgot to include this in the changelog - I have
GCC-4.1. If no objections are raised,
I will retest on the classpath HEAD before committing.
2006-02-08 David Daney [EMAIL PROTECTED]
PR classpath/26082
* gnu/java/net/protocol/http/HTTPConnection.java (pool): Changed to
type Pool.
(Pool): New inner class
this. As you can see from my PRs, this is something
that I was looking at and you just saved me a bunch of work.
David Daney
Wolfgang Baer wrote:
Hi,
David Daney wrote:
Wolfgang Baer wrote:
+String expect = getHeader(Expect);
+if (expect != null expect.equals(100-continue))
^
This *may* have to be a case insensitive compare. I think RFC2616
?
Wolfgang
I don't know what to do WRT to this spec/reference implementation
disagreement, but this entire block of code is incorrect.
Please see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26081
David Daney.
an exception because of a 4?? or 5?? status code,
getErrorStream() must contain the response body if any.
connect() should only throw an exception if there are socket level
IOExceptions.
I will update PR 26081 to reflect my new understanding.
David Daney.
that, I like the patch.
David Daney
makes me
think that this is what we should do. If this makes sense submit a
patch that does this.
David Daney
,
100-Continue);
David Daney.
recognize the
content-encoding. It seems to me that the caller might well recognize
it somehow.
How would you make this behavior compatible with java.net.*?
What exception would you throw?
What state would the connection be in after throwing?
David Daney
this code is incorrect, as it doesn't respect TTL
properly. I would like to remove it, which is what this patch does.
Comments?
I agree. The standard C library takes care of DNS caching (via nscd) on
most systems, so this extra cache would have no added benefit.
David Daney
Christian Thalinger wrote:
Hi!
While checking some FAILs in tgolem i stumbled across this common fail:
FAIL: gnu.testlet.java.net.InetSocketAddress.InetSocketAddressTest:
Error : test_Constructors failed - 1 No wildcard address returned
(number 1)
I searched a bit and i think toString()
But this is [EMAIL PROTECTED] Shouldn't this go to mauve-patches ?
David Daney.
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
security manager, the security manager's checkMemberAccess
Gary method is called with this and Member.PUBLIC
Interesting. The 1.5 text is different.
Indeed, no superclass checks. Interesting.
Perhaps the verifier checks make it unnecessary.
David Daney
parameter which would be the
exception message.
David Daney.
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Gary Benson wrote:
David Daney wrote:
Gary Benson wrote:
...I'll commit my original patch for now.
I hate to sound like I have a burr under the saddle, but does
anybody see any merit whatsoever in changing the exception text
as I suggested in my previous response to the patch?
What did
, does not imply that they do not exist.
David Daney
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
(Bad file descriptor);
+
The real error is that the file was opened read-only. A message saying
Bad file descriptor does not convey that information. If the only
reason that out can be null is that it was opened read-only, then I
think all the exception messages should reflect that.
David
I guess the subject says it all.
2005-11-18 David Daney [EMAIL PROTECTED]
* AUTHORS (David Daney): New entry.
Index: AUTHORS
===
RCS file: /cvsroot/classpath/classpath/AUTHORS,v
retrieving revision 1.30
diff -u -r1.30
this now, it uses a StringBuffer for better
performance and also only checks for occurrences of the target string
Try StringBuilder instead of StringBuffer.
David Daney
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org
?
If we do this, wouldn't it logically follow that we should make all of
swing reentrant/thread-safe?
Perhaps a better approach would be to fix the calling code.
David Daney.
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http
2005-10-21 David Daney [EMAIL PROTECTED]
* NEWS: Added entry about HttpURLConnection improvements.
Index: NEWS
===
RCS file: /cvsroot/classpath/classpath/NEWS,v
retrieving revision 1.98
retrieving revision 1.99
diff -u
Jeroen Frijters wrote:
David Daney wrote:
Jeroen Frijters wrote:
David Daney wrote:
LimitedLengthInputStream shouldn't have a finalize().
Let's consider the case where a client program did not read
the entire body of the response:
As implemented in the patch, the finalize is indeed
the redundant buffering
causes more memory and CPU resources to be used to allocate and move
data through all the buffers.
Tested with make -k check in GCJ libjava(HEAD) + mauve + jacks with no
regressions.
2005-10-12 David Daney [EMAIL PROTECTED]
PR classpath/24259
* gnu/java/net
with no
regressions. Additional ad hoc testing to verify connection re-use with
Connection: keep-alive for multiple GET and POST requests.
2005-09-29 David Daney [EMAIL PROTECTED]
PR classpath/24086, PR classpath/24091:
* gnu/java/net/protocol/http
? An io/nio/net bug perhaps?
I have been debugging some HTTP things and have found ethereal to be a
good friend. If you suspect a problem in the underlying networking
code, looking at the raw bits going over the network might be the only
way to find it.
David Daney
:-)
Sorry to rain on your parade. But all these man-hours of discussion
guarantee that this portion of the code is bug free and thus will never
be executed.
David Daney.
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http
Tom Tromey wrote:
David == David Daney [EMAIL PROTECTED] writes:
David Anthony Green wrote:
- // XXX - Ignore coding exceptions? They shouldn't really happen.
- return null;
+ // This shouldn't really happen.
+ throw new Error(e);
David Whould it be better
effect should be the same.
None of this is necessary. But we do it anyway to make the code better.
For me Boolean.TRUE reads much more cleanly than Boolean.valueOf(true).
I think it improbable that it is less efficient either.
David Daney
Chris Burdess wrote:
David Daney wrote:
gnu.java.net.LineInputStream has at least one bug in it, but think its
whole approach is incorrect.
First the bug:
len = in.available();
len = (len MIN_LENGTH) ? MIN_LENGTH : len;
I think the idea was to read all available
As approved by Tom Tromey on [EMAIL PROTECTED]
2005-09-13 David Daney [EMAIL PROTECTED]
* java/io/ByteArrayOutputStream.java: Reformated copyright notice.
(toString(int)): Pass correct parameters to String constructor.
David Daney.
Index: java/io/ByteArrayOutputStream.java
Chris Burdess wrote:
David Daney wrote:
You would probably have a better chance if you threw out all the
inetlib classes and started from scratch with a pull-based client.
What are you talking about? I am not using inetlib.
The gnu.java.net.protocol.http package is the inetlib HTTP
that is
ByteArrayOutputStream.toString.
Any non ASCII characters in the response/headers are in violation of the
RFC. So it probably does not matter what we do, what ever is
easiest/most efficient is probably best.
David Daney
___
Classpath-patches
-linux-gnu.
2005-09-12 David Daney [EMAIL PROTECTED]
* classpath/gnu/java/net/LineInputStream.java (blockReads): Removed.
(Constructor): Don't initialize blockReads.
(bufToString): New method.
(readLine): Removed block reading logic.
(indexOf): Removed.
I
, then the connection is returned to the
connection pool.
With this patch I can successfully transfer (via HTTP) content that is
much larger than my heap.
Some testing done with GCJ (HEAD) on i686-pc-linux-gnu as well as
mipsel-linux. More testing is probably needed.
2005-09-12 David Daney [EMAIL
90 matches
Mail list logo
