Hi Hans,
On 3/31/2017 2:56 PM, Hans Boehm wrote:
Agree entirely with Andrew's concern. I would mostly point to the
java.lang.Reference documentation. One possible approach follows.
Add the following to the apiNote. I would add it at the beginning,
since I've rarely encountered the inheritance
Agree entirely with Andrew's concern. I would mostly point to the
java.lang.Reference documentation. One possible approach follows.
Add the following to the apiNote. I would add it at the beginning, since
I've rarely encountered the inheritance issues, and they're probably easier
to debug:
As wit
Looks good!
On Fri, Mar 31, 2017 at 11:28 AM, Stuart Marks
wrote:
>
> Hi all,
>
> Please review this small change to the spec of Iterator.forEachRemaining.
> I claim this change is non-normative, since the text to be added "other
> mutator methods of Iterator subtypes" is already covered by exis
+1
Mandy
> On Mar 31, 2017, at 11:16 AM, Xueming Shen wrote:
>
> Hi,
>
> Please help review the copyright update change for
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8177910
> webrev: http://cr.openjdk.java.net/~sherman/8177910/
>
> Thanks!
> Sherman
>
Hi all,
Please review this small change to the spec of Iterator.forEachRemaining. I
claim this change is non-normative, since the text to be added "other mutator
methods of Iterator subtypes" is already covered by existing text "modifies the
collection in any way". However, this bug arose bec
Looks good,
Roger
On 3/31/2017 2:16 PM, Xueming Shen wrote:
Hi,
Please help review the copyright update change for
issue: https://bugs.openjdk.java.net/browse/JDK-8177910
webrev: http://cr.openjdk.java.net/~sherman/8177910/
Thanks!
Sherman
Hi,
Please help review the copyright update change for
issue: https://bugs.openjdk.java.net/browse/JDK-8177910
webrev: http://cr.openjdk.java.net/~sherman/8177910/
Thanks!
Sherman
Hi Stuart,
ok, will switch to @SuppressWarnings; it will avoid the deprecation
related clutter in the javadoc.
Thanks, Roger
On 3/31/2017 1:29 PM, Stuart Marks wrote:
On 3/31/17 6:55 AM, Roger Riggs wrote:
The webrev for deprecating finalize has been updated:
- to improve the advice exi
Hi Brian,
I think it's worth fixing unless there are objections. I see Stuart's
comment about compatibility and wonder if we've any examples of such
applications.
I just put together a patch [1] for this. I'm still figuring out how
nanoseconds get recorded for macosx. stat64.st_mtimespec.tv_
There was some observation (in an off-line conversation) that since
this is being deprecated it is probably a bit late to start documenting
it with lots of advice along these and other lines ..
-phil.
On 03/31/2017 10:25 AM, Roger Riggs wrote:
Hi Hans,
Can you suggest how that would be express
On 3/31/17 6:55 AM, Roger Riggs wrote:
The webrev for deprecating finalize has been updated:
- to improve the advice existing JDK subclasses overriding finalize provides in
@deprecated javadoc,
- to expand Object.finalize() javadoc to reinforce the correct use of
super.finalize() by subclasse
Hi Hans,
Can you suggest how that would be expressed? The advice would seem to
have some complex conditions.
Would it be the case that a caller using a reference to any resource
held by a finalizable object
must use reachabilityFence to ensure that the resource can not be
cleaned up while it
On 31/03/17 18:05, Hans Boehm wrote:
> Can we add a warning that it is almost never safe to override finalize()
> without use of reachabilityFence()?
We'll have to be careful not to suggest to some people that if
you don't override finalize() then you don't need reachabilityFence().
Careful wordin
+1,
thanks, Roger
On 3/31/2017 11:12 AM, Daniel Fuchs wrote:
On 31/03/2017 14:29, Roger Riggs wrote:
Hi Daniel,
Looks fine.
(I usually prefer the two argument of Objects.requireNonNull(foo,
"foo") so
the exception identifies the invalid argument).
Oh - right - I can do that:
http://cr.
Hi,
It would be interesting to know what operating system and file system
this occurs on.
Any truncation would be due to the underlying OS and filesystem type.
Recall floppy drives, I vaguely recall that the filesystem only had per
file info to a 1 second resolution.
$.02, Roger
On 3/31/201
On 31/03/2017 14:29, Roger Riggs wrote:
Hi Daniel,
Looks fine.
(I usually prefer the two argument of Objects.requireNonNull(foo, "foo") so
the exception identifies the invalid argument).
Oh - right - I can do that:
http://cr.openjdk.java.net/~dfuchs/webrev_8177835/webrev.01
Thanks Roger!
Hi Ricardo,
Thanks for reading the specification verbiage closely. I think you have a
point. I’d like to read what others think about this.
Regards,
Brian
On Mar 31, 2017, at 1:35 AM, Ricardo Almeida wrote:
> Just to add another though...
>
> I was just double-reading the documentation and
> On Mar 31, 2017, at 5:28 AM, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a trivial fix for a JCK conformance issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8177835
> 8177835: System.LoggerFinder#getLogger or getLocalizedLogger does
> not throw NPE
>
> webrev:
> http://cr.
The webrev for deprecating finalize has been updated:
- to improve the advice existing JDK subclasses overriding finalize
provides in @deprecated javadoc,
- to expand Object.finalize() javadoc to reinforce the correct use of
super.finalize() by subclasses,
- and to remove redundant @Suppress
Hi Daniel,
Looks fine.
(I usually prefer the two argument of Objects.requireNonNull(foo, "foo") so
the exception identifies the invalid argument).
Regards, Roger
On 3/31/2017 8:28 AM, Daniel Fuchs wrote:
Hi,
Please find below a trivial fix for a JCK conformance issue:
https://bugs.openjdk.
Hi,
Please find below a trivial fix for a JCK conformance issue:
https://bugs.openjdk.java.net/browse/JDK-8177835
8177835: System.LoggerFinder#getLogger or getLocalizedLogger does
not throw NPE
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8177835/webrev.00
The issue is only appar
Hi Amy,
It looks good to me.
Thanks,
Serguei
On 3/30/17 22:42, Amy Lu wrote:
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
22 matches
Mail list logo
