Hi Alan,
This one caught my eye:
src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
This entire class seems to re-declare inherited methods from
DatagramSocketImpl for no obvious reason and mess up the javadoc in the
process. In many/most cases there is no need to redeclare the
On 01/10/2012 01:35, Iris Clark wrote:
Hi, Alan.
Looks fantastic!
By fixing these javadoc warnings for @throws and @param, I'm assuming that we
will be changing the generated javadoc. Are any of these changes significant
enough to warrant a ccc? Most of the changes looked fairly innocuous
On 01/10/2012 08:20, David Holmes wrote:
Hi Alan,
This one caught my eye:
src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
This entire class seems to re-declare inherited methods from
DatagramSocketImpl for no obvious reason and mess up the javadoc in
the process. In
On 1/10/2012 6:53 PM, Alan Bateman wrote:
On 01/10/2012 08:20, David Holmes wrote:
Hi Alan,
This one caught my eye:
src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
This entire class seems to re-declare inherited methods from
DatagramSocketImpl for no obvious reason and mess
On 01/10/2012 12:30, David Holmes wrote:
In that case you should fix:
102 * @param p to be sent.
-
* @param p the packet to be sent.
Okay, I'll fix up that while I'm there.
-Alan
Hi,
See here:
http://cr.openjdk.java.net/~psandoz/tl/7197642/webrev/
Thanks,
Paul.
Hi Peter,
Thanks for reporting this.
It would be helpful to know the original intent of the author, but i suspect
this is a bug (even though null is commonly used to refer to the bootstrap CL).
FWIW i cannot find any explicit cases in the JDK that relies on this behaviour
to explicitly limit
Changeset: 39cbe256c3d1
Author:alanb
Date: 2012-10-01 15:36 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1
8000269: Cleanup javadoc warnings
Reviewed-by: lancea, darcy, ulfzibis, iris, naoto, dholmes
! src/share/classes/java/io/FilePermission.java
!
Hi Paul,
It would be very strange code indeed that acted on the
ServiceConfigurationError in a way that you describe. After all, the
java.lang.Error hierarchy of throwables is reserved for things that
should be acted upon only by fixing the code, isn't it?
This is also explicitly noted in
On 01/10/2012 14:14, Paul Sandoz wrote:
Hi,
See here:
http://cr.openjdk.java.net/~psandoz/tl/7197642/webrev/
Thanks,
Paul.
If I have it right, this moves the NPE from the ServiceLoader's
iterator methods to the load* methods where the check should have been.
It's a subtle behavior change
Alan Chris,
I agree with you that the new approach is less clear than the previous
approach, but the original approach suffered from code duplication which
was the motivation for the change. However, let me propose something
else. How about /all /the methods in StringBuffer be
On Mon, Oct 1, 2012 at 2:22 PM, Jim Gish jim.g...@oracle.com wrote:
Alan Chris,
However, let me propose something else. How about /all /the methods in
StringBuffer be synchronized? Although this is not strictly necessary, it
works because reentrant synchronization is allowed.
Reentrant
12 matches
Mail list logo
