Re: Review Request: 7186817 - Remove Windows 95/98/ME Support
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 I notice is that a couple of the methods that are moved don't need protected access anymore, examples are rename0, delete0, getDriveDirectory, canonicalizeWithPrefix and probably a few others. I see Ulf's suggestion to change the hashCode implementation while you are there but I agree that this should be looked at separately as the focus with this patch is removing code that isn't used anymore. -Alan
7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeListe
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 of really removing the APIs when a module system comes along. The patch proposed here is the first installation to deprecate the LogManager addPropertyChangeListener and removePropertyChangeListener methods. These methods are problematic because of the API dependency on java.beans.PropertyChangeListener (java.beans is toxic because of types in that package that are tied to Applet, AWT, and Swing). When we eventually get to remove these methods then we expect the impact will not be too significant. Mandy Chung has done a static analysis over 20,000 projects to locate usages of these methods and found only 3 so we have some useful evidence to demonstrate that they aren't used very often. For now we are just proposing to deprecate the methods and the proposed patch is here: http://cr.openjdk.java.net/~alanb/7192274/webrev/jdk.patch Thanks, Alan. [1] http://openjdk.java.net/jeps/162
Re: 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeListe
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 are problematic for our modularization efforts. Thankfully the list is very short as this is deprecation is in anticipation of really removing the APIs when a module system comes along. The patch proposed here is the first installation to deprecate the LogManager addPropertyChangeListener and removePropertyChangeListener methods. These methods are problematic because of the API dependency on java.beans.PropertyChangeListener (java.beans is toxic because of types in that package that are tied to Applet, AWT, and Swing). When we eventually get to remove these methods then we expect the impact will not be too significant. Mandy Chung has done a static analysis over 20,000 projects to locate usages of these methods and found only 3 so we have some useful evidence to demonstrate that they aren't used very often. For now we are just proposing to deprecate the methods and the proposed patch is here: http://cr.openjdk.java.net/~alanb/7192274/webrev/jdk.patch Thanks, Alan. [1] http://openjdk.java.net/jeps/162 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Reviewer needed: 6282196 There should be Math.mod(number, modulo) methods
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
Re: Reviewer needed: 6282196 There should be Math.mod(number, modulo) methods
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 the mod side generally fits in 32 bits, which means the result can fit in 32 bits. This often saves the need to call toIntExact() on the result. Stephen
Review needed for 8000687
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
+++ b/src/share/classes/java/sql/DriverManager.java Wed Oct 10 10:59:00
2012 -0400
@@ -412,7 +412,7 @@
* method throws a codejava.lang.SecurityException/code.
*
* @param out the new logging/tracing PrintStream; to disable, set to
codenull/code
- * @deprecated Use {@code setLogWriter)
+ * @deprecated Use {@code setLogWriter}
* @throws SecurityException if a security manager exists and its
*codecheckPermission/code method denies setting the log stream
*
@@ -439,7 +439,7 @@
* and all drivers.
*
* @return the logging/tracing PrintStream; if disabled, is
codenull/code
- * @deprecated Use {@code getLogWriter)
+ * @deprecated Use {@code getLogWriter}
* @see #setLogStream
*/
@Deprecated
new-host-2:sql lanceandersen$
Best
Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Re: Review needed for 8000687
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
2012 -0400
+++ b/src/share/classes/java/sql/DriverManager.java Wed Oct 10 10:59:00
2012 -0400
@@ -412,7 +412,7 @@
* method throws acodejava.lang.SecurityException/code.
*
* @param out the new logging/tracing PrintStream; to disable, set
tocodenull/code
- * @deprecated Use {@code setLogWriter)
+ * @deprecated Use {@code setLogWriter}
* @throws SecurityException if a security manager exists and its
*codecheckPermission/code method denies setting the log stream
*
@@ -439,7 +439,7 @@
* and all drivers.
*
* @return the logging/tracing PrintStream; if disabled,
iscodenull/code
- * @deprecated Use {@code getLogWriter)
+ * @deprecated Use {@code getLogWriter}
* @see #setLogStream
*/
@Deprecated
new-host-2:sql lanceandersen$
Thanks Lance, looks good to me. Also the javadoc build was warning free
a few days ago and it's nice to get back to that state.
-Alan
hg: jdk8/tl/jdk: 8000687: Correct javadoc typo for getLogWriter and setLogWriter
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
Re: Reviewer needed: 6282196 There should be Math.mod(number, modulo) methods
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: 6282196 There should be Math.mod(number, modulo) methods The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/ Thanks, Roger
Re: 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeListe
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. Thankfully the list is very short as this is deprecation is in anticipation of really removing the APIs when a module system comes along. The patch proposed here is the first installation to deprecate the LogManager addPropertyChangeListener and removePropertyChangeListener methods. These methods are problematic because of the API dependency on java.beans.PropertyChangeListener (java.beans is toxic because of types in that package that are tied to Applet, AWT, and Swing). When we eventually get to remove these methods then we expect the impact will not be too significant. Mandy Chung has done a static analysis over 20,000 projects to locate usages of these methods and found only 3 so we have some useful evidence to demonstrate that they aren't used very often. For now we are just proposing to deprecate the methods and the proposed patch is here: http://cr.openjdk.java.net/~alanb/7192274/webrev/jdk.patch Thanks, Alan. [1] http://openjdk.java.net/jeps/162
Review/comment needed for the new public java.util.Base64 class
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 of Base64 encoding scheme, (1) the default RFC 4648, which uses standard mapping, no line breaks, (2) the URL-safe RFE 4648, no line breaks, use - and _ to replace + and / for the mapping (3) the default MIME style, as in RFC 2045 (and its earlier versions), which uses standard base64 mapping, a 76 characters per line limit and uses crlf pair \r\n for line break. (4) an extend-able MIME base64, with the char-per-line and the line separator(s) specified by developer. The encoder/decoder now provides encoding and decoding for byte[], String, ByteBuffer and a pair of EncoderInputStream and DecoderOutputStrream, which we believe/hope should satisfy most of the common use cases. Additional method(s) can be added if strongly desired. We tried couple slightly different styles of design for such this simple utility class [2]. We kinda concluded that the version proposed probably provides the best balance among readability, usability and extensibility. Please help review and comment on the API and implementation. Thanks! -Sherman [1] http://openjdk.java.net/jeps/135 [2] http://cr.openjdk.java.net/~sherman/base64/
Re: 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeListe
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 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 of really removing the APIs when a module system comes along. The patch proposed here is the first installation to deprecate the LogManager addPropertyChangeListener and removePropertyChangeListener methods. These methods are problematic because of the API dependency on java.beans.PropertyChangeListener (java.beans is toxic because of types in that package that are tied to Applet, AWT, and Swing). When we eventually get to remove these methods then we expect the impact will not be too significant. Mandy Chung has done a static analysis over 20,000 projects to locate usages of these methods and found only 3 so we have some useful evidence to demonstrate that they aren't used very often. For now we are just proposing to deprecate the methods and the proposed patch is here: http://cr.openjdk.java.net/~alanb/7192274/webrev/jdk.patch Thanks, Alan. [1] http://openjdk.java.net/jeps/162
hg: jdk8/tl/jdk: 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeLister methods
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 ! src/share/classes/java/util/logging/LogManager.java
RE: Review/comment needed for the new public java.util.Base64 class
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 Message-
From: Xueming Shen
Sent: Wednesday, October 10, 2012 10:55 AM
To: core-libs-dev
Subject: Review/comment needed for the new public java.util.Base64 class
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to replace + and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions), which
uses
standard base64 mapping, a 76 characters per line limit and uses crlf
pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[], String,
ByteBuffer and a pair of EncoderInputStream and DecoderOutputStrream, which
we believe/hope should satisfy most of the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this simple
utility class [2]. We kinda concluded that the version proposed probably
provides the best balance among readability, usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
Re: Review/comment needed for the new public java.util.Base64 class
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? Documentation? Something else?
On that point, sun.misc.BASE64{En,DE}coder may present a fine
opportunity to use the @Deprecated annotation...
-Joe
Thanks,
iris
-Original Message-
From: Xueming Shen
Sent: Wednesday, October 10, 2012 10:55 AM
To: core-libs-dev
Subject: Review/comment needed for the new public java.util.Base64 class
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to replace + and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions), which
uses
standard base64 mapping, a 76 characters per line limit and uses crlf
pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[], String, ByteBuffer and a pair of
EncoderInputStream and DecoderOutputStrream, which we believe/hope should
satisfy most of the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this simple
utility class [2]. We kinda concluded that the version proposed probably provides the
best balance among readability, usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
Review Request for 8000712
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 diff SyncFactory.java diff -r 3c4be36de073 src/share/classes/javax/sql/rowset/spi/SyncFactory.java --- a/src/share/classes/javax/sql/rowset/spi/SyncFactory.java Wed Oct 10 11:15:27 2012 -0400 +++ b/src/share/classes/javax/sql/rowset/spi/SyncFactory.java Wed Oct 10 16:57:46 2012 -0400 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -229,11 +229,7 @@ * The standard resource file name. */ private static String ROWSET_PROPERTIES = rowset.properties; -/** - * The RI Optimistic Provider. - */ -private static String default_provider = -com.sun.rowset.providers.RIOptimisticProvider; + /** * Permission required to invoke setJNDIContext and setLogger */ @@ -248,24 +244,13 @@ * The codeLogger/code object to be used by the codeSyncFactory/code. */ private static volatile Logger rsLogger; -/** - * - */ -private static Level rsLevel; + /** * The registry of available codeSyncProvider/code implementations. * See section 2.0 of the class comment for codeSyncFactory/code for an * explanation of how a provider can be added to this registry. */ private static HashtableString, SyncProvider implementations; -/** - * Internal sync object used to maintain the SPI as a singleton - */ -private static Object logSync = new Object(); -/** - * Internal PrintWriter field for logging facility - */ -private static java.io.PrintWriter logWriter = null; /** * Adds the the given synchronization provider to the factory register. Guidelines new-host-2:spi lanceandersen$ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: Review Request for 8000712
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 static java.io.PrintWriter logWriter Best Lance new-host-2:spi lanceandersen$ hg diff SyncFactory.java diff -r 3c4be36de073 src/share/classes/javax/sql/rowset/spi/SyncFactory.java --- a/src/share/classes/javax/sql/rowset/spi/SyncFactory.java Wed Oct 10 11:15:27 2012 -0400 +++ b/src/share/classes/javax/sql/rowset/spi/SyncFactory.java Wed Oct 10 16:57:46 2012 -0400 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -229,11 +229,7 @@ * The standard resource file name. */ private static String ROWSET_PROPERTIES = rowset.properties; -/** - * The RI Optimistic Provider. - */ -private static String default_provider = -com.sun.rowset.providers.RIOptimisticProvider; + /** * Permission required to invoke setJNDIContext and setLogger */ @@ -248,24 +244,13 @@ * ThecodeLogger/code object to be used by thecodeSyncFactory/code. */ private static volatile Logger rsLogger; -/** - * - */ -private static Level rsLevel; + /** * The registry of availablecodeSyncProvider/code implementations. * See section 2.0 of the class comment forcodeSyncFactory/code for an * explanation of how a provider can be added to this registry. */ private static HashtableString, SyncProvider implementations; -/** - * Internal sync object used to maintain the SPI as a singleton - */ -private static Object logSync = new Object(); -/** - * Internal PrintWriter field for logging facility - */ -private static java.io.PrintWriter logWriter = null; /** * Adds the the given synchronization provider to the factory register. Guidelines new-host-2:spi lanceandersen$ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/langtools: 8000665: fix internal API comments on javadoc files
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 ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java !
hg: jdk8/tl/langtools: 8000743: docencoding not available to stylesheet
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 ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java + test/com/sun/javadoc/testDocEncoding/TestDocEncoding.java + test/com/sun/javadoc/testDocEncoding/pkg/Test.java
hg: jdk8/tl/langtools: 8000418: javadoc should used a standard generated by javadoc string
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 ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java + test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java + test/com/sun/javadoc/testGeneratedBy/pkg/MyClass.java
Re: Review/comment needed for the new public java.util.Base64 class
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 confirms decoding can correctly reverse the encoding but it
says nothing about the correctness of the encoding. Maybe we can just
use 10. Test Vectors of RFC 4648?
Thanks
Max
On 10/11/2012 01:54 AM, Xueming Shen wrote:
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to replace
+ and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions),
which uses
standard base64 mapping, a 76 characters per line limit and uses
crlf pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[], String,
ByteBuffer and a pair of EncoderInputStream and DecoderOutputStrream,
which we believe/hope should satisfy most of the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this
simple utility
class [2]. We kinda concluded that the version proposed probably provides
the best balance among readability, usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
Re: Review/comment needed for the new public java.util.Base64 class
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 byte(s) in src (sp sl), we will need to output the last
special unit,
which has one or two padding charactere '=', in this case, we still need to
output the line separator(s).
2. Is it necessary to explicitly mention in the spec that there is no
CrLf at the end of a MIME encoded string?
I'm struggling with which is the appropriate/desired behavior, output
the crlf for the last line
or not. Apache's common coder appears to append the crlf for the last
line, but our sun.misc
version does not (but sun.misc.BASE64 actually appends the line
separator if the last line
happens to have 76 characters, I would assume this is a bug though). The
current implement
tries to match the sun.misc. I'm happy to go either way.
But, as you suggested, it might be worth explicitly describing whatever
behavior we choose.
3. The test confirms decoding can correctly reverse the encoding but
it says nothing about the correctness of the encoding. Maybe we can
just use 10. Test Vectors of RFC 4648?
I do have a version of TestBase64 actually compares encoded results of
j.u.Base64,
sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe
I should
at least plug in the code for comparing with sun.misc.Base64Encoder.
Thanks!
-Sherman
On 10/11/2012 01:54 AM, Xueming Shen wrote:
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to replace
+ and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions),
which uses
standard base64 mapping, a 76 characters per line limit and uses
crlf pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[],
String,
ByteBuffer and a pair of EncoderInputStream and
DecoderOutputStrream,
which we believe/hope should satisfy most of the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this
simple utility
class [2]. We kinda concluded that the version proposed probably
provides
the best balance among readability, usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
Re: Review/comment needed for the new public java.util.Base64 class
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 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?
On that point, sun.misc.BASE64{En,DE}coder may present a fine
opportunity to use the @Deprecated annotation...
-Joe
Thanks,
iris
-Original Message-
From: Xueming Shen
Sent: Wednesday, October 10, 2012 10:55 AM
To: core-libs-dev
Subject: Review/comment needed for the new public java.util.Base64 class
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to replace
+ and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier
versions), which uses
standard base64 mapping, a 76 characters per line limit and
uses crlf pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[],
String, ByteBuffer and a pair of EncoderInputStream and
DecoderOutputStrream, which we believe/hope should satisfy most of
the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this
simple utility class [2]. We kinda concluded that the version
proposed probably provides the best balance among readability,
usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
Re: Review/comment needed for the new public java.util.Base64 class
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 last atom (atom == 0), but if
there
is still byte(s) in src (sp sl), we will need to output the last
special unit,
which has one or two padding charactere '=', in this case, we still need to
output the line separator(s).
But when atom != 0, it seems sp sl should always be true.
-Max
2. Is it necessary to explicitly mention in the spec that there is no
CrLf at the end of a MIME encoded string?
I'm struggling with which is the appropriate/desired behavior, output
the crlf for the last line
or not. Apache's common coder appears to append the crlf for the last
line, but our sun.misc
version does not (but sun.misc.BASE64 actually appends the line
separator if the last line
happens to have 76 characters, I would assume this is a bug though). The
current implement
tries to match the sun.misc. I'm happy to go either way.
But, as you suggested, it might be worth explicitly describing whatever
behavior we choose.
3. The test confirms decoding can correctly reverse the encoding but
it says nothing about the correctness of the encoding. Maybe we can
just use 10. Test Vectors of RFC 4648?
I do have a version of TestBase64 actually compares encoded results of
j.u.Base64,
sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe
I should
at least plug in the code for comparing with sun.misc.Base64Encoder.
Thanks!
-Sherman
On 10/11/2012 01:54 AM, Xueming Shen wrote:
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to replace
+ and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions),
which uses
standard base64 mapping, a 76 characters per line limit and uses
crlf pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[],
String,
ByteBuffer and a pair of EncoderInputStream and
DecoderOutputStrream,
which we believe/hope should satisfy most of the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this
simple utility
class [2]. We kinda concluded that the version proposed probably
provides
the best balance among readability, usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
Re: Review/comment needed for the new public java.util.Base64 class
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?
The logic here is that if we reached the last atom (atom == 0), but if
there
is still byte(s) in src (sp sl), we will need to output the last
special unit,
which has one or two padding charactere '=', in this case, we still
need to
output the line separator(s).
But when atom != 0, it seems sp sl should always be true.
Yes, the sp sl part only counts if atom == 0. Means if it's NOT last atom,
(atom != 0) output the line feeds, if it IS the last atom (atom == 0), only
output the line feeds if there are leftover byte (sp sl), which means the
last 4-byte unit (with one or two '=') will be after this line feed.
-Sherman
-Max
2. Is it necessary to explicitly mention in the spec that there is no
CrLf at the end of a MIME encoded string?
I'm struggling with which is the appropriate/desired behavior, output
the crlf for the last line
or not. Apache's common coder appears to append the crlf for the last
line, but our sun.misc
version does not (but sun.misc.BASE64 actually appends the line
separator if the last line
happens to have 76 characters, I would assume this is a bug though). The
current implement
tries to match the sun.misc. I'm happy to go either way.
But, as you suggested, it might be worth explicitly describing whatever
behavior we choose.
3. The test confirms decoding can correctly reverse the encoding but
it says nothing about the correctness of the encoding. Maybe we can
just use 10. Test Vectors of RFC 4648?
I do have a version of TestBase64 actually compares encoded results of
j.u.Base64,
sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe
I should
at least plug in the code for comparing with sun.misc.Base64Encoder.
Thanks!
-Sherman
On 10/11/2012 01:54 AM, Xueming Shen wrote:
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to replace
+ and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions),
which uses
standard base64 mapping, a 76 characters per line limit and
uses
crlf pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[],
String,
ByteBuffer and a pair of EncoderInputStream and
DecoderOutputStrream,
which we believe/hope should satisfy most of the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this
simple utility
class [2]. We kinda concluded that the version proposed probably
provides
the best balance among readability, usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
Re: Review/comment needed for the new public java.util.Base64 class
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
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 byte(s) in src (sp sl), we will need to output the last
special unit,
which has one or two padding charactere '=', in this case, we still
need to
output the line separator(s).
But when atom != 0, it seems sp sl should always be true.
Yes, the sp sl part only counts if atom == 0. Means if it's NOT last
atom,
(atom != 0) output the line feeds, if it IS the last atom (atom == 0), only
output the line feeds if there are leftover byte (sp sl), which means the
last 4-byte unit (with one or two '=') will be after this line feed.
So, the value of sp sl is always the same as (atom != 0 || sp sl).
That's why I said atom != 0 is not necessary.
-Max
-Sherman
-Max
2. Is it necessary to explicitly mention in the spec that there is no
CrLf at the end of a MIME encoded string?
I'm struggling with which is the appropriate/desired behavior, output
the crlf for the last line
or not. Apache's common coder appears to append the crlf for the last
line, but our sun.misc
version does not (but sun.misc.BASE64 actually appends the line
separator if the last line
happens to have 76 characters, I would assume this is a bug though). The
current implement
tries to match the sun.misc. I'm happy to go either way.
But, as you suggested, it might be worth explicitly describing whatever
behavior we choose.
3. The test confirms decoding can correctly reverse the encoding but
it says nothing about the correctness of the encoding. Maybe we can
just use 10. Test Vectors of RFC 4648?
I do have a version of TestBase64 actually compares encoded results of
j.u.Base64,
sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe
I should
at least plug in the code for comparing with sun.misc.Base64Encoder.
Thanks!
-Sherman
On 10/11/2012 01:54 AM, Xueming Shen wrote:
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to replace
+ and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions),
which uses
standard base64 mapping, a 76 characters per line limit and
uses
crlf pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[],
String,
ByteBuffer and a pair of EncoderInputStream and
DecoderOutputStrream,
which we believe/hope should satisfy most of the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this
simple utility
class [2]. We kinda concluded that the version proposed probably
provides
the best balance among readability, usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
Re: Review/comment needed for the new public java.util.Base64 class
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 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 byte(s) in src (sp sl), we will need to output the last
special unit,
which has one or two padding charactere '=', in this case, we still
need to
output the line separator(s).
But when atom != 0, it seems sp sl should always be true.
Yes, the sp sl part only counts if atom == 0. Means if it's NOT last
atom,
(atom != 0) output the line feeds, if it IS the last atom (atom ==
0), only
output the line feeds if there are leftover byte (sp sl), which
means the
last 4-byte unit (with one or two '=') will be after this line feed.
So, the value of sp sl is always the same as (atom != 0 || sp sl).
That's why I said atom != 0 is not necessary.
You're absolutely correct! Somehow I kept thinking you were saying sp
sl is not necessary:-)
not the other way around.
webrev will be updated shortly.
Thanks!
-Sherman
-Max
-Sherman
-Max
2. Is it necessary to explicitly mention in the spec that there is no
CrLf at the end of a MIME encoded string?
I'm struggling with which is the appropriate/desired behavior, output
the crlf for the last line
or not. Apache's common coder appears to append the crlf for the last
line, but our sun.misc
version does not (but sun.misc.BASE64 actually appends the line
separator if the last line
happens to have 76 characters, I would assume this is a bug
though). The
current implement
tries to match the sun.misc. I'm happy to go either way.
But, as you suggested, it might be worth explicitly describing
whatever
behavior we choose.
3. The test confirms decoding can correctly reverse the encoding but
it says nothing about the correctness of the encoding. Maybe we can
just use 10. Test Vectors of RFC 4648?
I do have a version of TestBase64 actually compares encoded results of
j.u.Base64,
sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64.
Maybe
I should
at least plug in the code for comparing with sun.misc.Base64Encoder.
Thanks!
-Sherman
On 10/11/2012 01:54 AM, Xueming Shen wrote:
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 of Base64 encoding scheme,
(1) the default RFC 4648, which uses standard mapping, no line
breaks,
(2) the URL-safe RFE 4648, no line breaks, use - and _ to
replace
+ and
/ for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier
versions),
which uses
standard base64 mapping, a 76 characters per line limit and
uses
crlf pair
\r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
specified by developer.
The encoder/decoder now provides encoding and decoding for byte[],
String,
ByteBuffer and a pair of EncoderInputStream and
DecoderOutputStrream,
which we believe/hope should satisfy most of the common use cases.
Additional
method(s) can be added if strongly desired.
We tried couple slightly different styles of design for such this
simple utility
class [2]. We kinda concluded that the version proposed probably
provides
the best balance among readability, usability and extensibility.
Please help review and comment on the API and implementation.
Thanks!
-Sherman
[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/
