On 30.03.2017 20:24, dean.l...@oracle.com wrote:
> I would like to go with the webrev.2 version, with asserts removed. All the
> reviewers have said they are OK with that version, and it allows more
> complete testing than the minimal version.
Okay, I'm fine with that!
Best regards,
Tobias
>
I'm still waiting for reviewer's feedback for the TEST.groups update:
jdk/internal/loader (add to jdk_lang)
jdk/internal/util (add to jdk_util_other)
jdk/internal/agent (add to jdk_management)
(Security part has been reviewed. Thank you Max!)
Thanks,
Amy
On 3/27/17 11:06 AM, Amy Lu wrote:
As noted in [1], it looks like the specification [2] already dealt with the
situation via the "possibly truncated" phrase:
"If the operation succeeds and no intervening operations on the file take
place, then the next invocation of the lastModified() method will return the
(possibly truncated)
OK, this wave is open for review again.
On Wed, Mar 29, 2017 at 12:57 PM, Martin Buchholz
wrote:
> Oops. Martin forgot to check ScheduledExecutorService, and there's some
> overlap in specs, which requires some rework.
>
> On Wed, Mar 29, 2017 at 11:43 AM, Martin Buchholz
> wrote:
>
>> First j
Hi Timo, Sherman,
Thanks for looking at this.
Sherman wrote:
This might practically put the api itself almost useless? it might be an easy
task to spot
whether or not it's a 0-width-match-possible regex when the regex is simple,
but it gets
harder and harder, if not impossible when the regex
Hello,
Please review the changes to the following issue:
https://bugs.openjdk.java.net/browse/JDK-816
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/816/webrev.00/
This is for backporting fixes for JapaneseEra related issues (8054214,
8173423). The original fixe
Actually, the assert inside getChar/putChar shouldn't affect inlining,
because C1 and C2 will use the intrinsic instead, so I'd like to use
webrev.2 as is, so I don't have to re-run all the tests.
dl
On 3/30/17 11:24 AM, dean.l...@oracle.com wrote:
I would like to go with the webrev.2 versi
I would like to go with the webrev.2 version, with asserts removed. All
the reviewers have said they are OK with that version, and it allows
more complete testing than the minimal version.
dl
On 3/23/17 12:03 PM, dean.l...@oracle.com wrote:
On 3/23/17 11:25 AM, dean.l...@oracle.com wrote:
Hello,
Please review the following change:
http://cr.openjdk.java.net/~prappo/8177738/webrev.00/
This is an attempt to resolve a group of issues related to Version-String API
and its implementation:
8177738: Runtime.Version must be a value-based class
8148822: (spec) Regex in Runtim
Hi,
I guess this somewhat contrived example also wouldn’t work?
String s = "\\b\\w+|\\G|\\B";
String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
Matcher m = Pattern.compile(s).matcher(t);
while(m.find()) {
On 03/30/2017 03:14 PM, Chris Dennis wrote:
This is indeed nice… but I presume that we all agree that the best solution
here would be to allow instantiation of an IntSummaryStatistics object in a
specific state.
Of course. I just couldn't resist the challenge of Rémi's nice math
exercise..
This is indeed nice… but I presume that we all agree that the best solution
here would be to allow instantiation of an IntSummaryStatistics object in a
specific state.
> On Mar 29, 2017, at 2:43 PM, Peter Levart wrote:
>
>
>
> On 03/29/2017 06:06 PM, Chris Dennis wrote:
>> Remi: I really hav
Ricardo,
I see that JDK-8177809[1] has been logged. The newer NIO APIs can report
back with higher time precision and it's probably best to use those.
JDK-6939260 is related to your issue also.
Returning a ms value not equal to the ms value used in the
setLastModified call does seem strange.
Looks fine Stuart.
-Chris.
> On 30 Mar 2017, at 02:20, Stuart Marks wrote:
>
> Hi all,
>
> Please review this small, non-normative textual change to j.u.Observable.
> This class, and its companion Observer interface, were deprecated earlier in
> JDK 9. Doug Lea suggested adding a link to j.u
14 matches
Mail list logo
