Hi Lance,
On 13/03/2019 3:30 am, Lance Andersen wrote:
Hi all,
Please review this addition to the ProblemList.txt as this tests times out
from time to time
$ hg diff test/jdk/ProblemList.txt
diff -r 687e10fefa11 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Mon Mar 11 13:37:56
+1
Cheers,
-Joe
On 3/12/2019 5:01 PM, Lance Andersen wrote:
Hi all
Please review the fix for 8220253, to address the javadoc header issues [1] in
java.sql.rowset
The webrev can be found at:
http://cr.openjdk.java.net/~lancea/8220253/webrev.00/
Best
Lance
[1]
Hi all
Please review the fix for 8220253, to address the javadoc header issues [1] in
java.sql.rowset
The webrev can be found at:
http://cr.openjdk.java.net/~lancea/8220253/webrev.00/
Best
Lance
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html
Hello!
Just an observation.
If there were two new subtypes of Iterable introduced: IterableOnce and
IterableMultipleTimes, then all existing Iterables could be retrofitted
to implement one of these.
It wouldn't *automatically* solve the problem of 3rd party API, which
accepts an Iterable
Due to how Iterable is specified now it does not promise multiple iterations,
but due to how most (all that I know of except DirectoryStream or some 3rd
party) Iterables are implemented now, the common expectation is that it does.
By implementing more Iterable(s) that don't support multiple
Hi Stephen,
My slight concern is that the terminal operation is hidden and not
immediately visible, which could be surprising. I do note that streams
throw a clear exception if a terminal operation is called a second
time which mitigates this to some degree.
Yes, this is certainly a
Hi Andy,
Looks good.
Thanks,
Alexander
On 3/12/2019 9:46 AM, Andy Herrick 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).
[1] https://bugs.openjdk.java.net/browse/JDK-8220505
[2]
Hi Remi,
Stream.iterator() can be really really slow, it uses a pull semantics while
the whole Stream push values. When designing it, the lambda EG saw it as an
"escape hatch" in order to interropt with a legacy code than require an
Iterator and not more.
If Stream.iterator() is slow, then
+1
-Brent
On 3/12/19 10:30 AM, Lance Andersen wrote:
Hi all,
Please review this addition to the ProblemList.txt as this tests times out
from time to time
$ hg diff test/jdk/ProblemList.txt
diff -r 687e10fefa11 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Mon Mar 11 13:37:56
Due to how Iterable is specified now it does not promise multiple
iterations, but due to how most (all that I know of except
DirectoryStream or some 3rd party) Iterables are implemented now, the
common expectation is that it does. By implementing more Iterable(s)
that don't support
On 3/12/19 5:04 PM, Brian Goetz wrote:
No. You have the LSP backwards (though this is easy to do.)
IterableOnce means "*must throw* on subsequent use"; under this spec,
an arbitrary Iterable is most certainly *not* an IterableOnce, and
therefore an LSP violation.
It sounds like you are
Hi all,
Please review this addition to the ProblemList.txt as this tests times out
from time to time
$ hg diff test/jdk/ProblemList.txt
diff -r 687e10fefa11 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Mon Mar 11 13:37:56 2019 -0400
+++ b/test/jdk/ProblemList.txt Tue Mar 12
Thanks Daniel,
yes, the method naming ship has sailed.
On 03/12/2019 11:44 AM, Daniel Fuchs wrote:
Looks good to me Roger.
It's kind of unfortunate that the process output
is returned by a method named getInputStream(),
even though I understand that's a mirror effect...
best regards,
--
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).
[1] https://bugs.openjdk.java.net/browse/JDK-8220505
[2] http://cr.openjdk.java.net/~herrick/8220505/
/Andy
No. You have the LSP backwards (though this is easy to do.)
IterableOnce means "*must throw* on subsequent use"; under this spec, an
arbitrary Iterable is most certainly *not* an IterableOnce, and
therefore an LSP violation.
It sounds like you are suggesting that we instead spec
Hi,
Please find below a simple fix for
8219197: ThreadGroup.enumerate() may return wrong value
http://cr.openjdk.java.net/~dfuchs/webrev_8219197/webrev.00/
This is a bug in the implementation of the recursion,
as enumerate(list, n, recurse) should never have returned
a value < n.
The test
Looks good to me Roger.
It's kind of unfortunate that the process output
is returned by a method named getInputStream(),
even though I understand that's a mirror effect...
best regards,
-- daniel
On 12/03/2019 15:32, Roger Riggs wrote:
Please review a doc fix to refer to the correct method
Hi Peter,
> 56 private static final String MESSAGE_PLACEHOLDER =
> "NPE_MESSAGE_PLACEHOLDER";
> Here, the initializer of that constant should create a private instance
> of String:
...
> private static final String MESSAGE_PLACEHOLDER = new String();
Ok, I understand.
> 81
Please review a doc fix to refer to the correct method reading from the
process.
diff --git a/src/java.base/share/classes/java/lang/ProcessBuilder.java
b/src/java.base/share/classes/java/lang/ProcessBuilder.java
--- a/src/java.base/share/classes/java/lang/ProcessBuilder.java
+++
On 3/8/2019 3:47 PM, Lukas Eder wrote:
Hello,
I've recently learned about JDK 12's new String::transform method:
https://bugs.openjdk.java.net/browse/JDK-8203703
Obviously, this is useful. And obviously, this would be far more useful as
a general pattern than just something for String. E.g.
Yes expect the next EA by next week.
/Andy
On 3/12/2019 3:40 AM, Lennart Börjeson wrote:
OK.
May I hope that a fix for this will make its way to the early-access
build soon?
(While I can build from source myself, it is much more convenient to
use an EA in our CI cluster.)
/Lennart
11
- Mail original -
> De: "Peter Levart"
> À: "John Rose" , "Tagir Valeev"
> Cc: "core-libs-dev"
> Envoyé: Mardi 12 Mars 2019 11:29:22
> Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams
> Hi John,
>
> On 3/12/19 12:07 AM, John Rose wrote:
>>> public static
Hi Gary,
On 12/03/2019 12:16, Gary Adams wrote:
Doesn't the generated javadoc include an h2 for Class LogManager?
That would make the h3 for LogManager Configuration the correct nesting
level,
even though it does not appear in the individual source file.
No, it used to, but now it doesn't.
Doesn't the generated javadoc include an h2 for Class LogManager?
That would make the h3 for LogManager Configuration the correct nesting
level,
even though it does not appear in the individual source file.
On 3/12/19, 8:06 AM, Daniel Fuchs wrote:
Hi,
Please find below a trivial doc fix
+1
--
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPhone
> On Mar 12, 2019, at 8:06 AM, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a trivial doc fix for:
>
Hi,
Please find below a trivial doc fix for:
8220262: fix headings in java.logging
https://bugs.openjdk.java.net/browse/JDK-8220262
The change is just:
- * LogManager Configuration
+ * LogManager Configuration
full patch below.
best regards,
-- daniel
Hi John,
On 3/12/19 12:07 AM, John Rose wrote:
public static void main(String[] args) {
for(int i : range(0, 100)) {
System.out.println(i);
}
}
It correctly compiles and prints numbers from 0 to 99. As IntStream
extends BaseStream and BaseStream> defines Iterator iterator(), it would
Hi,
On 3/11/19 5:29 PM, Joe Darcy wrote:
Hello,
Always surprising how much discussion an (apparently) simple
refactoring can generate!
Thanks to Tagir for spotting this issue.
For completeness, the two-argument forms of requireNonNull which takes
a Supplier is not applicable to preserve
OK.
May I hope that a fix for this will make its way to the early-access build soon?
(While I can build from source myself, it is much more convenient to use an EA
in our CI cluster.)
/Lennart
> 11 mars 2019 kl. 18:04 skrev Andy Herrick :
>
> Although we plan to remove the mac-app-store
29 matches
Mail list logo