On 09/10/2012 21:02, Dan Xu wrote:
:
There are no code changes when moving them from Win32FileSystem to
WinNTFileSystem.
Thanks for confirming, that makes it a lot easier to review.
I've looked through the changes and it looks that you've done a very
thorough job, thank you! The only thing
JEP 162 [1] captures a number of things that we can do in preparation
for future modularization of the platform. One of these items is
deprecating the Java SE APIs that are problematic for our modularization
efforts. Thankfully the list is very short as this is deprecation is in
anticipation
looks fine Alan and in line with the other work we have done
Best
Lance
On Oct 10, 2012, at 7:19 AM, Alan Bateman wrote:
JEP 162 [1] captures a number of things that we can do in preparation for
future modularization of the platform. One of these items is deprecating the
Java SE APIs that
A reviewer is needed for:
6282196 There should be Math.mod(number, modulo) methods
The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
Thanks, Roger
On 10 October 2012 15:22, Roger Riggs roger.ri...@oracle.com wrote:
A reviewer is needed for:
6282196 There should be Math.mod(number, modulo) methods
The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
Just to note that floorMod(long, int) is not present. This is often
useful as
Need a reviewer for a simple typo in the DriverManager javadoc
new-host-2:sql lanceandersen$ hg diff
diff -r 036c55976cef src/share/classes/java/sql/DriverManager.java
--- a/src/share/classes/java/sql/DriverManager.java Tue Oct 09 08:58:27
2012 -0400
+++
On 10/10/2012 16:08, Lance Andersen - Oracle wrote:
Need a reviewer for a simple typo in the DriverManager javadoc
new-host-2:sql lanceandersen$ hg diff
diff -r 036c55976cef src/share/classes/java/sql/DriverManager.java
--- a/src/share/classes/java/sql/DriverManager.java Tue Oct 09 08:58:27
Changeset: 3c4be36de073
Author:lancea
Date: 2012-10-10 11:15 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c4be36de073
8000687: Correct javadoc typo for getLogWriter and setLogWriter
Reviewed-by: alanb
! src/share/classes/java/sql/DriverManager.java
One edge case: the spec for floorDiv implies that
floorDiv(Integer.MIN_VALUE, -1) should be Integer.MAX_VALUE but I
believe the code produces Integer.MIN_VALUE. EIther the spec or the
code should be fixed.
Éamonn
2012/10/10 Roger Riggs roger.ri...@oracle.com:
A reviewer is needed for:
The change looks good.
Mandy
On 10/10/2012 4:19 AM, Alan Bateman wrote:
JEP 162 [1] captures a number of things that we can do in preparation
for future modularization of the platform. One of these items is
deprecating the Java SE APIs that are problematic for our
modularization efforts.
A standard/public API for Base64 encoding and decoding has been long
overdue. JDK8 has a JEP [1] for this particular request.
Here is the draft proposal to add a public Base64 utility class for JDK8.
http://cr.openjdk.java.net/~sherman/4235519/webrev
This class basically provides 4 variants
On 10 Oct 2012, at 18:11, Mandy Chung mandy.ch...@oracle.com wrote:
The change looks good.
+1
-Chris
Mandy
On 10/10/2012 4:19 AM, Alan Bateman wrote:
JEP 162 [1] captures a number of things that we can do in preparation for
future modularization of the platform. One of these items
Changeset: 6455182d2797
Author:alanb
Date: 2012-10-10 20:47 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6455182d2797
7192274: Deprecate LogManager addPropertyChangeListener and
removePropertyChangeLister methods
Reviewed-by: mchung, lancea, chegar
!
Hi, Sherman.
I'm glad to see this coming in. As you said, long overdue.
I'm curious. What are the plans are to encourage migration from the JDK
private and unsupported sun.misc.BASE64{En,DE}coder classes? Compile-time
warning? Documentation? Something else?
Thanks,
iris
-Original
Hello,
On 10/10/2012 1:03 PM, Iris Clark wrote:
Hi, Sherman.
I'm glad to see this coming in. As you said, long overdue.
I'm curious. What are the plans are to encourage migration from the JDK
private and unsupported sun.misc.BASE64{En,DE}coder classes? Compile-time
warning?
Hi,
Looking for a reviewer for the removal of the following non-used fields in
SyncFactory
private static String default_provider
private static Level rsLevel
private static Object logSync
private static java.io.PrintWriter logWriter
Best
Lance
new-host-2:spi lanceandersen$ hg
Looks good to me.
Mandy
On 10/10/2012 2:06 PM, Lance Andersen - Oracle wrote:
Hi,
Looking for a reviewer for the removal of the following non-used fields in
SyncFactory
private static String default_provider
private static Level rsLevel
private static Object logSync
private
Changeset: 25e14ad23cef
Author:jjg
Date: 2012-10-10 16:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25e14ad23cef
8000665: fix internal API comments on javadoc files
Reviewed-by: darcy
!
Changeset: 560d4a5d14e6
Author:jjg
Date: 2012-10-10 18:08 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/560d4a5d14e6
8000743: docencoding not available to stylesheet
Reviewed-by: jjg
Contributed-by: jvisw...@linux.vnet.ibm.com
!
Changeset: 6517bf8e50d0
Author:jjg
Date: 2012-10-10 18:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6517bf8e50d0
8000418: javadoc should used a standard generated by javadoc string
Reviewed-by: bpatel
!
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax (atom != 0 || sp sl)) {
Maybe atom != 0 is not necessary?
2. Is it necessary to explicitly mention in the spec that there is no
CrLf at the end of a MIME encoded string?
3. The test
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax (atom != 0 || sp sl)) {
Maybe atom != 0 is not necessary?
The logic here is that if we reached the last atom (atom == 0), but if there
is still
There is no plan yet. The sun.misc.BASE64En/Decoder should already
trigger a compiler
warning for it's a sun private API. @Deprecated annotation might be a
good fit.
-Sherman
On 10/10/12 1:40 PM, Joe Darcy wrote:
Hello,
On 10/10/2012 1:03 PM, Iris Clark wrote:
Hi, Sherman.
I'm glad to see
On 10/11/2012 11:09 AM, Xueming Shen wrote:
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax (atom != 0 || sp sl)) {
Maybe atom != 0 is not necessary?
The logic here is that if we reached the
On 10/10/12 8:16 PM, Weijun Wang wrote:
On 10/11/2012 11:09 AM, Xueming Shen wrote:
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax (atom != 0 || sp
sl)) {
Maybe atom != 0 is not necessary?
On 10/11/2012 11:32 AM, Xueming Shen wrote:
On 10/10/12 8:16 PM, Weijun Wang wrote:
On 10/11/2012 11:09 AM, Xueming Shen wrote:
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281 if (linepos == linemax (atom != 0 || sp
On 10/10/12 8:39 PM, Weijun Wang wrote:
On 10/11/2012 11:32 AM, Xueming Shen wrote:
On 10/10/12 8:16 PM, Weijun Wang wrote:
On 10/11/2012 11:09 AM, Xueming Shen wrote:
On 10/10/12 6:51 PM, Weijun Wang wrote:
Several questions:
1. In encode0(byte[] src, byte[] dst)
281
27 matches
Mail list logo
