2019/9/24 13:00:21 -0700, ulf.zi...@cosoco.de:
> Am 21.09.19 um 00:03 schrieb mark.reinh...@oracle.com:
>> To avoid this confusion, a more verbose specification might read:
>> * Returns the maximum number of $otype$s that will be produced for each
>> * $itype$ of input. This value may be u
+1. Should the @serial javadoc tag be removed?
-Chris.
> On 26 Sep 2019, at 19:27, Roger Riggs wrote:
>
> Looks fine, Joe
>
>> On 9/26/19 1:51 PM, Joe Darcy wrote:
>> Hello,
>>
>> Another part of the cleanup of library serialization usage ahead of
>> augmented javac -Xlint warnings (JDK-8160
Looks fine, Joe
On 9/26/19 1:51 PM, Joe Darcy wrote:
Hello,
Another part of the cleanup of library serialization usage ahead of
augmented javac -Xlint warnings (JDK-8160675), the non-serializable
instance fields of serializable types in the java.prefs module should
have their serial warnings
Looks good.
On 9/26/2019 5:15 AM, Kevin Rushforth wrote:
Looks good.
-- Kevin
On 9/26/2019 3:57 AM, Andy Herrick wrote:
Revised [3] to remove the change to CreateJmods.gmk since it is not
needed as the module will be resolved because it provides an
implementation of ToolProvider.
[3] http
Hello,
Another part of the cleanup of library serialization usage ahead of
augmented javac -Xlint warnings (JDK-8160675), the non-serializable
instance fields of serializable types in the java.prefs module should
have their serial warnings suppressed. The analogous issue in core libs
is JDK-8
Looks good.
Naoto
On 9/25/19 10:58 PM, Daisy Zhou wrote:
Hello,
Please help to review this patch for migrating SimpleDateFormatConstTest from
Tonga to Jtreg.
Bug:HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8231213";
https://bugs.openjdk.java.net/browse/JDK-8231213
Webrev: http
Hi Patrick,
Overall I think this looks ok.
A few minor comments
Please add 8229338 to the @bug line
I might suggest adding either a comment to the DataProvider or the test which
uses it with an overview of the parameters to make it easier and quicker for
future maintainers to know the intent.
Looks good.
-- Kevin
On 9/26/2019 3:57 AM, Andy Herrick wrote:
Revised [3] to remove the change to CreateJmods.gmk since it is not
needed as the module will be resolved because it provides an
implementation of ToolProvider.
[3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/
/Andy
Looks good.
- Alexey
On 9/26/2019 6:57 AM, Andy Herrick wrote:
Revised [3] to remove the change to CreateJmods.gmk since it is not
needed as the module will be resolved because it provides an
implementation of ToolProvider.
[3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/
/Andy
O
looks good.
/Andy
On 9/25/2019 6:30 PM, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Main class from module will be used if main class is not specified
in CLI. Main c
Revised [3] to remove the change to CreateJmods.gmk since it is not
needed as the module will be resolved because it provides an
implementation of ToolProvider.
[3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/
/Andy
On 9/25/2019 10:33 AM, Andy Herrick wrote:
Please review the jpack
Hi,
Would it be possible to have my fix for JDK-8229338 reviewed?
This a general refactoring of test/jdk/java/util/RandomAccess/Basic.java
as outlined in JDK-8229338 'clean up
test/jdk/java/util/RandomAccess/Basic.java'.
Further information on this bug can be found here:
https://bugs.open
12 matches
Mail list logo