| fd1674c75d7b6500168137a2213877e45e49bbd2 |
06-May-2010 |
Jesse Wilson <jessewilson@google.com> |
DO NOT MERGE: Rewrite the HTTP connection pool used by HttpURLConnection.
This started off as incremental changes, but it ended up going
far enough that it earned the "rewrite" badge.
System.getProperty() is not called for every HTTP connection.
This is slightly controversial, but the old code had to bend
over backwards to support dynamic pool changes, and it didn't
even support the case when the pool shrank but not to 0.
The new code doesn't do I/O within static synchronized blocks.
This should reduce contention described here: http://b/issue?id=2606547
Also: simpify implementation, prettier names, more focused doc.
Originally submitted to dalvik-dev.
https://android-git.corp.google.com/g/49309
Change-Id: I815c3123838b29cd2d9b39346e5c2486e1f5a2d2
et/URLConnectionTest.java
|
| f3565212d8dce6d6e037c07544840cecd7710bf5 |
30-Apr-2010 |
Elliott Hughes <enh@google.com> |
Backport the setFixedLengthStreamingMode fix to froyo.
Bug: 2643503
Change-Id: Ia42c9407ac77721d7fec3b806135d4e9912ee8ca
et/URLConnectionTest.java
|
| ec7c8c98a4094580224eb9c400249c5c0984cf29 |
25-Mar-2010 |
Elliott Hughes <enh@google.com> |
Fix java.util.Random's constructors.
Subclasses rely on having their overridden setSeed called by Random's
constructors, and the RI actually documents this behavior. (The
documentation even changed between Java 5 and Java 6 to make it _more_
explicit.)
This patch keeps that part of I6239d93bb46876ef1c4a5e155a6dc1ac6fab4eae
that improved our randomness, but reverts the attempt to fix Random's
uncouth behavior.
Also a regression test so we don't try to fix Random again in future.
Bug: 2502231
Change-Id: Ieea1009145c74eac9475c0cd5066dabad20eb114
til/AllTests.java
til/RandomTest.java
|
| fa2ad81d0b839083c711f5f0ef17030af3000f69 |
04-Mar-2010 |
Elliott Hughes <enh@google.com> |
Don't call a method that can be overridden from File's constructors.
Bug: 2486943
o/FileTest.java
|
| 59c1f5cb8bea87144b473170adb0b0dae7267937 |
03-Mar-2010 |
Elliott Hughes <enh@google.com> |
Use assertEquals rather than assertTrue/assertFalse.
ext/NormalizerTest.java
|
| 971b50675ea0c140abb326ffb75fe79442eb6eec |
02-Mar-2010 |
Elliott Hughes <enh@google.com> |
Add our home-grown Normalizer tests.
Originally https://android-git.corp.google.com/g/42517.
ext/AllTests.java
ext/NormalizerTest.java
|
| 925531bb8aff8c265342e62f4b79b5f0a848993d |
02-Feb-2010 |
Elliott Hughes <enh@google.com> |
Move a test I wrote under our wing.
I put this in amongst the harmony tests before we started our own little
tree of tests.
til/AllTests.java
til/TimeZoneTest.java
|
| 6363e0f00cc7960545161fca809733f5ad64e8d3 |
01-Feb-2010 |
Elliott Hughes <enh@google.com> |
Fix varargs warnings in libcore tests.
til/FormatterTest.java
|
| ab998708338b76b2d71f42568f46aefa2f4d7908 |
30-Jan-2010 |
Elliott Hughes <enh@google.com> |
Fix fallback in Currency.getSymbol(Locale).
If ICU doesn't have any localized symbol for a currency, we're supposed to
return the currency code, not null.
I introduced this bug in my recent changes. The Currency tests don't find it,
but DecimalFormatTest.test_setCurrencyLjava_util_Currency does, by accident.
I've added an explicit test.
til/AllTests.java
til/CurrencyTest.java
|
| 601fa0418e1f0835fd5ad7b06d3a6d2d631d667d |
29-Jan-2010 |
Elliott Hughes <enh@google.com> |
Fix a Formatter test that I checked in broken.
There's really no excuse for this with DalvikRunner, but I copy and pasted this
from a mail, and didn't run it until after it had been committed. I mean, who
puts untested code in a mail? ;-)
til/FormatterTest.java
|
| fc7f3e4e4e169f08577a37fbe02cc2a80fba77d2 |
28-Jan-2010 |
Elliott Hughes <enh@google.com> |
Fix NumberFormat's behavior with BigInteger and custom Number subclasses.
Also remove a few bits of cruft I ran across, and stop duplicating the
documentation between NumberFormat and DecimalFormat.
Bug: 2387934
ext/NumberFormatTest.java
|
| c86892dbd84eb2194b7211f184faead8c73b568b |
27-Jan-2010 |
Elliott Hughes <enh@google.com> |
Add a java.util.Formatter test suggested by egnor months ago.
...and add comments to existing tests.
til/FormatterTest.java
|
| eb5822b70b3e578dbe692a60b8a93b90a9d4df93 |
26-Jan-2010 |
Elliott Hughes <enh@google.com> |
Simplify our DecimalFormat.
Both the is-a and has-a hierarchies for our DecimalFormat implementation were
over-complicated. This patch starts to address that, and makes cloning twice
as fast (50us versus 100us), but not as fast as I'd like (<10us), and without
making much of a dent in the time it takes to create a new NumberFormat (550us
versus 600us).
The speed of cloning is important because Formatter has a hack that uses it,
and I want to change NumberFormat so that it always hands out clones... at
least until I have time to make "new NumberFormat" acceptably fast.
Also fixes DecimalFormat.applyLocalizedPattern (which used to behave as if
you'd called applyPattern).
ext/AllTests.java
ext/DecimalFormatTest.java
|
| e2036b3a340e0d687d9bbdb500658ef4585545e2 |
15-Jan-2010 |
Elliott Hughes <enh@google.com> |
Fix Formatter's behavior with %% and %n.
Yesterday's fix to the behavior with genuine null arguments didn't take into
account that we have format specifiers that don't take arguments. Fix the fix,
and add an explicit test.
til/FormatterTest.java
|
| 35df53aad66e7998cf0d7ca02e8c7a902d625fc6 |
15-Jan-2010 |
Ficus Kirkpatrick <ficus@android.com> |
Fix a NPE in java.util.Formatter.
A recent optimization to simple '%s' and '%d' formats was
failing to format null as "null". Also add a test.
til/FormatterTest.java
|
| 8ee76d4d3ee58109f859964e56d5c7f3d8c566d9 |
14-Jan-2010 |
Elliott Hughes <enh@google.com> |
Fix Date.toString.
Date.toString was using the TimeZone id ("America/Los_Angeles") rather than
the time zone short name ("PDT" or "PST", depending on time of year). The
naive fix made things 5x slower, so I improved Resources.getDisplayTimeZone
so the fixed Date.toString is only 2x slower. This could be improved further
with a faster getDisplayTimeZone.
I hoped to replace the body of Date.toString with a call to SimpleDateFormat,
but that turns out to be 40x slower. This patch also optimizes SimpleDateFormat
to bring the gap down to 8x by using Resources.getDisplayTimeZone instead of
asking for all the strings.
(Note that these improvements refer to the hopefully common case of localized
strings for the default locale. If you have the misfortune to need strings for
other locales, the new code will be more like 600x faster. At 0.5s a call on
the fastest current hardware, I hope no-one's actually doing that.
Dalvik Explorer -- available on the Market -- needs to do it when generating
summary reports, and it is indeed ridiculously slow. It uses two
SimpleDateFormat objects per locale, so it takes 1s per locale, for about 60
locales. I've tested Dalvik Explorer with this patch, and it does fix that
pathological behavior.)
Also fix a bug I introduced in https://android-git.corp.google.com/g/36242 that
meant that our zone names String[][] contained incorrect values (accidentally
concatenating each successive value in a row), found by existing tests now we
use more of those values.
Also replace a couple of "new Integer" calls with Integer.valueOf for a modest
speedup.
Also factor out some duplication.
Bug: http://code.google.com/p/android/issues/detail?id=6013
til/AllTests.java
til/DateTest.java
|
| 875da7b77d3cde1e90bc7f0382c19d65093c56ed |
11-Jan-2010 |
Elliott Hughes <enh@google.com> |
Support non-default negative patterns in NumberFormat.getIntegerInstance.
Spotted while rewriting the associated JNI recently.
ext/AllTests.java
ext/NumberFormatTest.java
|
| 8cdf9790e869778b0ed3da7f149cb7c132a0f142 |
08-Dec-2009 |
Elliott Hughes <enh@google.com> |
Take Locale into account in java.util.Formatter uppercase conversions.
(This is an RI incompatibility, but Sun accepts that the RI's behavior is a
bug.)
Bug: 2301938
til/AllTests.java
til/FormatterTest.java
|
| 7006487c694842aa4993e5ac3bf5b1a753a65f8d |
30-Nov-2009 |
Elliott Hughes <enh@google.com> |
More java.io.File improvements.
Three themes to this change: not making unnecessary native calls (like the
pointless "exists" check in canWrite), being consistent in our
treatment of the empty path, and removing unnecessary cruft from the native
code.
I'm sure there must be a better implementation for handling the empty
path (the few methods for which it *isn't* invalid should be the special
cases, not every single method), but in this patch I'm just interested
in correctness.
With this patch, we pass the jtreg empty path test (which we previously
failed) and we pass my more complete test (added to FileTest.java in this
patch).
Bug: 2281992
o/FileTest.java
|
| a171559499e05c4ab3c09a27fba41db99ea8d5bb |
21-Nov-2009 |
Elliott Hughes <enh@google.com> |
Fix java.io.File's JNI's fixed-length buffers.
I've also removed most of the duplication, simplified a lot of the
implementation, and added loads of TODOs now it's possible to see
what's going on under all the obfuscation. (The native code is
roughly half its previous size, but more functional.)
I want to stop here rather than start fixing any of the TODOs
because this change is already large enough and the history will
be clearer if unrelated changes are kept separate (easy though many
of them are).
Strictly speaking, I haven't removed all the fixed-length buffers:
the File.list implementation still uses fixed-length buffers, but
as the new TODOs point out, I think we want to rewrite that code
to better match its callers, and doing so will make the fixed-length
buffers go away. There's no point polishing code that's already
scheduled for deletion.
Add a couple of basic tests, one that assumes that if Path copes
with long paths in a couple of File's methods, it works in all of
them; another that singles out our readlink(2) wrapper because
that's the only place so far where we cope with arbitrary-length
paths moving in the opposite direction (from kernel to JNI to Java).
o/AllTests.java
o/FileTest.java
|
| 68d262d2c56fb4bb0d8253383aacaba8f36bc691 |
12-Nov-2009 |
Elliott Hughes <enh@google.com> |
Fix HttpURLConnection's chunked encoding behavior.
A third-party developer who wasn't reading to the end of the stream found that
their next connection would return junk, which turned out to be the tail of
the first response (thanks to connection recycling). Make sure we clean up
a chunked-encoding stream before allowing the connection to be reused.
Enhance our test web server to implement chunked encoding properly, with
configurable chunk sizes, rather than just responding with a single chunk.
Bug: http://code.google.com/p/android/issues/detail?id=2939
et/AllTests.java
et/URLConnectionTest.java
|
| 71684d91a50ae210cec2cb8eccdc632bc494c786 |
04-Nov-2009 |
Elliott Hughes <enh@google.com> |
CharsetDecoderICU/CharsetEncoderICU should take arrayOffset into account.
CharsetDecoderICU and CharsetEncoderICU special-case array-backed ByteBuffers
and CharBuffers for performance reasons, but they shouldn't assume that the
backing array always has offset 0.
An external user hit this while using the jAudioTagger library.
Test cases from user submission:
http://code.google.com/p/android/issues/detail?id=4237
See also: 2234697
io/charset/AllTests.java
io/charset/CharsetDecoderTest.java
|
| e6f774525980167d4324eaf1a34bef4b303bcbd3 |
31-Oct-2009 |
Elliott Hughes <enh@google.com> |
More OSNetworkSystem cleanup.
valgrind didn't like what we were doing here, specifically the way we
were setting ss_family to AF_INET if getsockopt IP_MULTICAST_IF didn't
return an AF_INET address, and ignoring the fact that the rest of
the sockaddr_storage doesn't necessarily correspond to an AF_INET address.
Linux seems to return an AF_UNSPEC address (rather than INADDR_ANY) if we
haven't set a multicast interface, so we have to do the conversion ourselves.
More disturbingly (and unfixed by this patch) we sometimes see ss_family
come back as 127 (when AF_MAX is 32 on our system). My guess is that the
kernel is just handing back bad data we gave it earlier, but I'll come back
to see about fixing multicast properly later.
I've inlined socketAddressToString into osNetworkSystem_byteArrayToIpString,
its only caller, because it's clearer that way now we've simplified the
division of error handling between the two.
I've brought getSocketLocalAddressImpl and getSocketLocalPortImpl in line
with each other and changed them to at least log errors. I've also added
a new test that fails, to demonstrate that this implementation is broken
as designed.
I've changed the name of JAVASOCKOPT_IP_MULTICAST_IF to match the Java
constant.
I've fixed the exception we throw if we're asked to convert a bad address
family's address from code that can't throw IOException --- AssertionError
doesn't have a String constructor. Really, we need to kill this code, so
I've added a TODO.
I've also made a real push to get rid of most of the SOCKERR_*-based error
reporting. (I had a transient failure with a meaningless error message
that sent me to the source to work out which errno it was actually
trying to report.)
I've changed setTTL to call setTimeToLive, and change the implementation
of the latter to pass Integer rather than Byte to the native implementation,
since that's what the native code needs anyway and native Byte support was
only for TTL.
Bug: 2225748
et/AllTests.java
et/SocketTest.java
|
| bfd74c5fa8b6b91dfc28986da159a9179916d0e6 |
27-Oct-2009 |
Elliott Hughes <enh@google.com> |
Implement ProcessBuilder.redirectErrorStream.
Also simplify and correct the security to ensure that the user can't modify
the command to be executed after the SecurityManager has approved it.
Bug: 2180063
ang/AllTests.java
ang/ProcessBuilderTest.java
|
| 24fdf6411660c1436524e45ba73f8e776dac2044 |
16-Oct-2009 |
Elliott Hughes <enh@google.com> |
Fix Float.valueOf(String) OutOfMemoryExceptions.
Apply http://issues.apache.org/jira/browse/HARMONY-6261, which was missed in
our recent luni merge.
Bug: 1957904
ang/AllTests.java
ang/FloatTest.java
|