On 25/09/2012 05:16, Weijun Wang wrote:
Hi Stuart
Please take a look at
http://cr.openjdk.java.net/~weijun/7200682/webrev.00/
So I am now using "java -XshowSettings:properties | grep os.arch" to
find out the arch. Not sure if there is a more formal way to do that.
An alternative might be t
Changeset: 99983a4a593b
Author:mcimadamore
Date: 2012-09-25 11:52 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99983a4a593b
7193913: Cleanup Resolve.findMethod
Summary: Refactor method lookup logic in Resolve.findMethod
Reviewed-by: jjg
! src/share/classes/com/sun/to
On Tue, 2012-09-18 at 10:39 -0400, Andrew Hughes wrote:
> This is an issue that has been with us for a while. See:
>
> https://bugs.openjdk.java.net/show_bug.cgi?id=100062
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845
>
> for some background.
> [...]
> It's not clear to me why thi
Understood.
Fixes look good.
On 24/09/2012 21:27, Valerie (Yu-Ching) Peng wrote:
Vinnie,
Thanks for the comment!
The reason that I use "<" instead of "<=" on line 150 is because that
(1024, 160) is supported by the DSAGenParameterSpec class and thus I
didn't view this as legacy value. Either in
- Original Message -
> On Tue, 2012-09-18 at 10:39 -0400, Andrew Hughes wrote:
> > This is an issue that has been with us for a while. See:
> >
> > https://bugs.openjdk.java.net/show_bug.cgi?id=100062
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188845
> >
> > for some backgro
Changeset: f0aa997ad78b
Author:valeriep
Date: 2012-09-25 11:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0aa997ad78b
7199941: test about AES/ECB mode fails
Summary: Fixed the problem of field "blockMode" not having correct value for
AES algorithms.
Reviewed-by: vinnie
Changeset: 0e5899f09dab
Author:jjg
Date: 2012-09-25 13:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e5899f09dab
7193657: provide internal ArrayUtils class to simplify common usage of arrays
in javac
Reviewed-by: mcimadamore, jjg
Contributed-by: vicent...@yahoo.es
Changeset: 99d23c0ef8ee
Author:jjg
Date: 2012-09-25 13:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99d23c0ef8ee
7196464: upgrade JavaCompiler.shouldStopPolicy to accomodate policies in face
of error and no error
Reviewed-by: mcimadamore
! src/share/classes/com/s
Hi Andrew,
You need to add a regression test for this fix.
Regards,
Christophe.
On Sep 24, 2012, at 7:01 PM, Xuelei Fan wrote:
> On 9/25/2012 9:23 AM, Brad Wetmore wrote:
>> Are there situations where we might overflow the int?
>>
> Yes, it is possible for many integer add operations. As 2^32
On 9/25/12 12:58 AM, Alan Bateman wrote:
On 25/09/2012 05:16, Weijun Wang wrote:
Hi Stuart
Please take a look at
http://cr.openjdk.java.net/~weijun/7200682/webrev.00/
So I am now using "java -XshowSettings:properties | grep os.arch" to find out
the arch. Not sure if there is a more formal
On 9/18/2012 7:39 AM, Andrew Hughes wrote:
The following simple webrev will achieve what I think is needed:
http://cr.openjdk.java.net/~andrew/100062/webrev.01/
allowing OpenJDK to be built with the unlimited rather than limited
crypto policy in place.
I got a chance to talk to Valerie, and
Hi All
Please take a look at
http://cr.openjdk.java.net/~weijun/7201053/webrev.00/
In fact, even without this code change, LoginContext would wrap the NPE
inside a LoginException so no real harm will be made. However, it's
always nice to check for null before reference a variable, and an NP
On 9/24/2012 7:01 PM, Xuelei Fan wrote:
On 9/25/2012 9:23 AM, Brad Wetmore wrote:
Are there situations where we might overflow the int?
Yes, it is possible for many integer add operations. As 2^32 is a lot
bigger than 2^24 (the biggest number TLS protocol allows), I'm not
worried too much ab
13 matches
Mail list logo
