Changeset: 8f405b65ddac
Author:weijun
Date: 2009-06-09 14:17 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8f405b65ddac
6578647: Undefined requesting URL in
java.net.Authenticator.getPasswordAuthentication()
Reviewed-by: chegar, valeriep
! src/share/classes/sun/net/www/pro
On Mon, Jun 8, 2009 at 07:08, Michael McMahon wrote:
> That's fine Martin. We can do it that way.
>
> Do you really need to #include ?
> As far as I can see clone() only requires
>
You're right. I removed #include of syscall.h.
I think I picked it up from some man page somewhere.
>
> When you
Attached is an UPDATED patch for bug 4837946, (and others) for
implementing asymptotically faster algorithms for multiplication of
large numbers in the BigInteger class:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946
This also affects other bugs:
4228681: Some BigInteger ope
2009/6/8 Doug Lea :
> It is possible to use a look-aside strategy for tiny
> HashMaps. I think one of the Apache commons maps
> does this.
FYI - Commons Collections Flat3Map:
http://commons.apache.org/collections/api-3.2/org/apache/commons/collections/map/Flat3Map.html
Stephen
Doug,
On your previous message:
1) I reverted hash function,
2) did some tuniing for MapCheck benchmark -
equals, hashCode, toString, and putAll (if argument have the same type)
now does not use entrySet() iterator which is very expensive.
Very big speedup would be to reuse Entry object,
since
Florian Weimer wrote:
Or don't use the hash structure at all and just do a sequential
search. Then the index array isn't needed at all.
It is possible to use a look-aside strategy for tiny
HashMaps. I think one of the Apache commons maps
does this. But the idea of using open-address
tables to
* Doug Lea:
> I once instrumented some of the "reference workload" usages
> and found that over half of the HashMaps/Hashtables had
> a max 3 or fewer elements during their lifetimes.
> So on average using your version will likely increase
> application footprints. It seems possible to deal with
>
A few notes on your implementation...
Alex Yakovlev wrote:
Main trick is in storing all data in 2 arrays without any HashEntry objects.
One is array of Objects with keys and values, another in a complex array
of indices.
Notice that footprint comparisons with current HashMap
are load-depen
Guy Korland wrote:
Hi,
I found out that an RMI call might never return on network
disconnection and will not throw RemoteException as expected.
The scenario is very simple:
1. Find a remote stub (the stub should be behind a router).
2. Physically disconnect the server from the LAN.
3. Invoke
Alex Yakovlev wrote:
Doug,
I've finished HashMap, HashSet, LinkedHashMap, and LinkedHashSet
porting to my approach. I run several tests I've found in
jdk/test/java/util/*
that are directly related to these classes, not sure I've found all of them.
There are a lot of tests around for HashMap
* Alan Bateman:
> Florian Weimer wrote:
>> Was the fix for Sun Alert 246387 (aka CVE-2008-5345) included in
>> OpenJDK 6b11?
>>
> Is this the alert that you are looking at:
> http://sunsolve.sun.com/search/document.do?assetkey=1-66-246387-1
Yes.
> I checked the Sun bug that is referenced (67
Florian Weimer wrote:
Was the fix for Sun Alert 246387 (aka CVE-2008-5345) included in
OpenJDK 6b11?
Is this the alert that you are looking at:
http://sunsolve.sun.com/search/document.do?assetkey=1-66-246387-1
I checked the Sun bug that is referenced (6704154) and its in the plugin
area an
* Mark Wielaard:
> On Mon, 2009-06-08 at 15:44 +0200, Florian Weimer wrote:
>> Sorry, but this is way too late to be relevant to my question (which
>> is about b11, not b14): The CVE-2008-5345 fix was not listed
>> explicitly in the b14 round of fixes, otherwise I'd have an isolated
>> patch I cou
That's fine Martin. We can do it that way.
Do you really need to #include ?
As far as I can see clone() only requires
When you allocate the clone stack for the child
the memory is byte aligned. Is this ok for Linux or should stacks
be aligned on larger boundaries?
Also, I don't follow why we n
Hi Florian,
On Mon, 2009-06-08 at 15:44 +0200, Florian Weimer wrote:
> Sorry, but this is way too late to be relevant to my question (which
> is about b11, not b14): The CVE-2008-5345 fix was not listed
> explicitly in the b14 round of fixes, otherwise I'd have an isolated
> patch I could examine.
* Mark Wielaard:
> On Mon, 2009-06-08 at 15:32 +0200, Mark Wielaard wrote:
>> Hi Florian,
>>
>> On Mon, 2009-06-08 at 15:08 +0200, Florian Weimer wrote:
>> > Was the fix for Sun Alert 246387 (aka CVE-2008-5345) included in
>> > OpenJDK 6b11?
>>
>> I believe CVE-2008-5345 is a catch all for a bun
On Mon, 2009-06-08 at 15:32 +0200, Mark Wielaard wrote:
> Hi Florian,
>
> On Mon, 2009-06-08 at 15:08 +0200, Florian Weimer wrote:
> > Was the fix for Sun Alert 246387 (aka CVE-2008-5345) included in
> > OpenJDK 6b11?
>
> I believe CVE-2008-5345 is a catch all for a bundle of security update
> pa
* Mark Wielaard:
> Hi Florian,
>
> On Mon, 2009-06-08 at 15:08 +0200, Florian Weimer wrote:
>> Was the fix for Sun Alert 246387 (aka CVE-2008-5345) included in
>> OpenJDK 6b11?
>
> I believe CVE-2008-5345 is a catch all for a bundle of security update
> patches:
> http://mail.openjdk.java.net/pipe
Hi Florian,
On Mon, 2009-06-08 at 15:08 +0200, Florian Weimer wrote:
> Was the fix for Sun Alert 246387 (aka CVE-2008-5345) included in
> OpenJDK 6b11?
I believe CVE-2008-5345 is a catch all for a bundle of security update
patches:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-March/
Was the fix for Sun Alert 246387 (aka CVE-2008-5345) included in
OpenJDK 6b11?
20 matches
Mail list logo
