Was the fix for Sun Alert 246387 (aka CVE-2008-5345) included in
OpenJDK 6b11?
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/
* 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
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:
> 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
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.
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
* 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
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
* 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
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
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
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
* 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
>
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,
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
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
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
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
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
20 matches
Mail list logo
