On 23/05/2017 00:15, Stuart Marks wrote:
I think this is sufficient. People who care about this case will have
to rewrite their code using Files.readAttributes instead of
File.lastModified.
or Files.getLastModifiedTime if only this timestamp is needed.
-Alan
Hi all,
This RFR addresses a javadoc bug dating back to Java SE 6/JDBC 4.0 for
DatabaseMetadata.getRowIdLifetime which refers to an int being returned but in
actuality an enum is returned. The javadoc no aligns with the PDF JDBC spec.
The CCC has been approved.
——
$ hg diff
dif
Hi Lance,
Should one of those @code's be @link so it is easy to get to the ROWID
javadoc?
Otherwise, looks fine,
Roger
On 5/23/2017 7:21 AM, Lance Andersen wrote:
Hi all,
This RFR addresses a javadoc bug dating back to Java SE 6/JDBC 4.0 for
DatabaseMetadata.getRowIdLifetime which refer
Hi Brian,
I don't think you need to mention the absolute value.
+ * file does not exist or if an I/O error occurs; the value may
+ * be negative indicating the number of milliseconds before the
epoch
Roger
On 5/22/2017 6:55 PM, Brian Burkhalter wrote:
On May 22, 2
+1
Roger
On 5/22/2017 7:20 PM, Brian Burkhalter wrote:
On reflection, so to speak, I think I have to agree with you. I’ll leave the
issue open for the time being but unless a compelling alternative solution
arises should probably resolve it as “Won’t Fix.”
Thanks for the careful commentary.
Or perhaps per Alan’s comments below change the current wording
Where it is required to distinguish an I/O exception from the case where 0L is
returned, or where several attributes of the same file are required at the same
time, or where the time of last access or the creation time are required,
Hi Roger,
So I guess this might be satisfy your and Stuart’s comments:
--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -932,7 +932,9 @@
* @return A long value representing the time the file was
* last modified, measure
+1
-Joe
On 5/23/2017 6:56 AM, Roger Riggs wrote:
Hi Lance,
Should one of those @code's be @link so it is easy to get to the ROWID
javadoc?
Otherwise, looks fine,
Roger
On 5/23/2017 7:21 AM, Lance Andersen wrote:
Hi all,
This RFR addresses a javadoc bug dating back to Java SE 6/JDBC 4.0
Hi, Hamlin
That looks pretty good. A couple comments:
* If I'm not mistaken, main/othervm/policy=... is sufficient to enable
the default security manager, and specifying "-Djava.security.manager"
is unnecessary.
* Please add 8180732 to the @bug tag
You will also need approval from a JDK 10
Hi,
Please review an update to the JAXP Java SE 9 API javadocs.
JBS: https://bugs.openjdk.java.net/browse/JDK-8180349
webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8180349/webrev/
There's a lot of format changes while converting to package-info.java,
but only minor (wording) changes to the o
Hi,
Security.java: 25-27: Style conventions call for " * " on every line in
comment blocks.
On 5/23/2017 12:53 PM, Brent Christian wrote:
Hi, Hamlin
That looks pretty good. A couple comments:
* If I'm not mistaken, main/othervm/policy=... is sufficient to enable
the default security manag
Hi Roger,
> On May 23, 2017, at 9:56 AM, Roger Riggs wrote:
>
> Hi Lance,
>
> Should one of those @code's be @link so it is easy to get to the ROWID
> javadoc?
I could or add an @see.
I will tweak it before I push
thank you.
>
> Otherwise, looks fine,
>
> Roger
>
>
> On 5/23/2017 7:21
For issue [1] I wrote a test [2] which subsumes the test in the issue report
and ran it on the usual platforms via a regression job including the core
java.io tests and I did not observe the reported failure. Therefore this issue
can simply be resolved as “Cannot Reproduce.” I am wondering howev
Hi Brian,
The bug number does help trace the original/stimulus for the test;
you can push the new test as subtask.
line 36: I would probably add a comment with the readable time.
Its nice to know when that if someone had to debug the time on file.
And it's worth a couple of extra characters to
On 5/23/17 8:21 AM, Brian Burkhalter wrote:
So I guess this might be satisfy your and Stuart’s comments:
--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -932,7 +932,9 @@
* @return A long value representing the time the file was
On 5/23/17 8:03 AM, Brian Burkhalter wrote:
Or perhaps per Alan’s comments below change the current wording
Where it is required to distinguish an I/O exception from the case where 0L is
returned, or where several attributes of the same file are required at the same
time, or where the time o
Hi Joe,
Looks good, a few minor editorial suggestions:
javax/transform/sax/package-info.java:
- line 28: I don't think the '-' belongs after SAX2 in the first
sentence.
javax/transform/dom/package-info.java:
line 28: ditto it is more readable without the '-'.
javax/stream/package-info.ja
Hi Roger,
On May 23, 2017, at 1:02 PM, Roger Riggs wrote:
> The bug number does help trace the original/stimulus for the test;
> you can push the new test as subtask.
So the new test would have the sub-task issue ID in its @bug tag and the main
issue would be resolved CNR?
> line 36: I would
On May 23, 2017, at 1:34 PM, Stuart Marks wrote:
> Yes, this could be another non-normative change. You might even consider
> merging it with the other bug (JDK-6791812), and possibly even labeling it as
> @apiNote.
>
> As for the wording itself, I think the sentiment is correct, but it's try
Hi Joe,
Looks good overall and one comment below on top of Roger’s:
> On May 23, 2017, at 4:38 PM, Roger Riggs wrote:
>
> Hi Joe,
>
> Looks good, a few minor editorial suggestions:
>
> javax/transform/sax/package-info.java:
> - line 28: I don't think the '-' belongs after SAX2 in the first s
RFR thread re-directed from RFC thread [1].
Create a sub-task [2] of [3] to create a test for the problem described in the
main issue. The webrev [4] is with respect to the fix for the sub-task [2]. The
“@bug” tag in [2] has the issue ID of [3] which itself will be manually
resolved as “Cannot
This discussion has now transitioned to an RFR [1]
Thanks,
Brian
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047841.html
On May 23, 2017, at 2:08 PM, Brian Burkhalter
wrote:
> Hi Roger,
>
> On May 23, 2017, at 1:02 PM, Roger Riggs wrote:
>
>> The bug number does help
On 5/23/2017 3:05 PM, Lance Andersen wrote:
Hi Joe,
Looks good overall and one comment below on top of Roger’s:
On May 23, 2017, at 4:38 PM, Roger Riggs wrote:
Hi Joe,
Looks good, a few minor editorial suggestions:
javax/transform/sax/package-info.java:
- line 28: I don't think the '-'
http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html
> 81 lines changed: 37 ins; 23 del; 21 mod;
Hi all,
could you please review the fix which improves and refactors
DoPrivAccompliceTest.java test?
the test had several issues:
- it did not fail if the java spawned by JavaToolUti
24 matches
Mail list logo
