On 02/11/2015 08:23 PM, Stuart Marks wrote:
1.1) Change the specification of Matcher.results to reset the stream
before matching, making it consistent with the replace* methods.
I'm not sure about this. The current replaceAll/replaceFirst methods
reset the matcher before doing any matching, s
On 12/02/2015 02:08, Martin Buchholz wrote:
Roger et al,
Whichever way we go doesn't matter much.
But I continue to think that IOE is a better choice than UOE and I have
trouble seeing the motivation for the change to use UOE.
If you wanted to provide a way to tell if subprocess support was avai
On Feb 12, 2015, at 3:18 AM, Stuart Marks wrote:
> On 2/11/15 12:45 PM, Paul Sandoz wrote:
>> On Feb 11, 2015, at 8:23 PM, Stuart Marks wrote:
>> That "matches" my original thinking on the matter and is reflected in the
>> patch. It's very simple to support. If the method was named "findAll" the
On Feb 12, 2015, at 9:43 AM, Peter Levart wrote:
>
> On 02/11/2015 08:23 PM, Stuart Marks wrote:
>>> 1.1) Change the specification of Matcher.results to reset the stream before
>>> matching, making it consistent with the replace* methods.
>>
>> I'm not sure about this. The current replaceAll
Ok - thanks Lev!
David
On 12/02/2015 7:58 PM, Lev Priima wrote:
"49" is also mentioned in the paper as possible solution. I've run test
from webrev with array length 2147483644 (Integer.MAX_VALUE-4) and
TimSort passed.
Lev
On 02/11/2015 10:57 PM, David Holmes wrote:
On 12/02/2015 5:14 AM, Le
Hi Brian,
What do existing XML APIs do?
My guess from looking at your webrev APIs such as DOM allow such invalid
characters when writing and reading? If so that would seem to be more of a
fundamental issue with those APIs and not specifically with preferences.
I think there should be an error
On Feb 12, 9:57pm, [email protected] (David Holmes) wrote:
-- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
| Ok - thanks Lev!
|
| David
For posterity can someone document this, and also the value for which
Integer.MAX_VALUE-4 fails?
christos
Than you, Alan!
Will integrate this fix now.
-Aleksej
On 02/11/2015 07:45 PM, Alan Bateman wrote:
On 11/02/2015 16:20, Aleksej Efimov wrote:
Hi Alan, Miran,
If I understood correctly we can fix ">" in the next bulk update
(in early March). If it's so, can I have an approval for this fix?
Th
Christos,
Test may fail on shorter arrays(page 8 of paper). For instance, on worst
case, generated by test, it starts to fail on length 67108864.
After increasing stack size of runs to merge, Arrays.sort(T[]) works
also on maximum possible array for HotSpot JVM.
Roger, David,
I've updated th
On 3 Feb 2015, at 13:48, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
Looks like a useful addition.
Trivially, the handling of null caught my eye: "If a mapped stream is {@code
null} an empty stream is used, instead.” It look
Hi Lev,
ok, looks fine,
I'll sponsor it and push it.
Roger
On 2/12/2015 11:56 AM, Lev Priima wrote:
Christos,
Test may fail on shorter arrays(page 8 of paper). For instance, on
worst case, generated by test, it starts to fail on length 67108864.
After increasing stack size of runs to merge,
Hi Paul,
This looks good - I have noticed one copy/paste error in the javadoc
though:
OptionalInt.java:
looks like the throws clause of ifPresent and ifPresentOrElse have been
interverted:
138 * @throws NullPointerException if a value is present and
{@code action} is
139 * null, o
On Feb 12, 2015, at 3:33 PM, Chris Hegarty wrote:
> On 3 Feb 2015, at 13:48, Paul Sandoz wrote:
>
>> Hi,
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
>
> Looks like a useful addition.
>
Thanks.
> Trivially, the handling of null caught my eye: "
Thanks!
Lev
On 02/12/2015 02:53 PM, Roger Riggs wrote:
Hi Lev,
ok, looks fine,
I'll sponsor it and push it.
Roger
On 2/12/2015 11:56 AM, Lev Priima wrote:
Christos,
Test may fail on shorter arrays(page 8 of paper). For instance, on
worst case, generated by test, it starts to fail on leng
Hi Paul,
On Feb 12, 2015, at 4:37 AM, Paul Sandoz wrote:
> What do existing XML APIs do?
This is a morass and I hope that someone more apt to know it well would
comment. The U+ null control character is always illegal though I do know
that.
> My guess from looking at your webrev APIs suc
On 02/03/2015 02:48 PM, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
This patch adds a new flat mapping collector to Collectors. This can be useful
if one needs to map 0 or more items into a downstream collector.
A CCC will be file
On 02/12/2015 04:51 PM, Peter Levart wrote:
On 02/03/2015 02:48 PM, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
This patch adds a new flat mapping collector to Collectors. This can be useful
if one needs to map 0 or more items in
On Feb 12, 2015, at 4:51 PM, Peter Levart wrote:
> Hi Paul,
>
> Would the following "optimization" make any sense?
>
> public static
> Collector flatMapping(Function extends U>> mapper,
>Collector downstream) {
> BiConsumer downstreamAccumulat
On 02/12/2015 05:07 PM, Paul Sandoz wrote:
On Feb 12, 2015, at 4:51 PM, Peter Levart wrote:
Hi Paul,
Would the following "optimization" make any sense?
public static
Collector flatMapping(Function> mapper,
Collector downstream) {
BiCons
On Feb 12, 2015, at 4:37 PM, Brian Burkhalter
wrote:
> Hi Paul,
>
> On Feb 12, 2015, at 4:37 AM, Paul Sandoz wrote:
>
>> What do existing XML APIs do?
>
> This is a morass and I hope that someone more apt to know it well would
> comment. The U+ null control character is always illegal
On Feb 12, 2015, at 8:18 AM, Paul Sandoz wrote:
>> This is a morass and I hope that someone more apt to know it well would
>> comment. The U+ null control character is always illegal though I do
>> know that.
>
> Yes. IIRC XML 1.1 basically allows any character except U+.
"Note that
Hi Brian,
I think its worth the overhead of cleaning up the spec and
the backward compatibility risk is low given the XML restriction.
(Though perhaps not directly back-portable to 8 without the spec change)
Roger
On 2/12/2015 11:27 AM, Brian Burkhalter wrote:
On Feb 12, 2015, at 8:18 AM, Paul
On Feb 12, 2015, at 5:27 PM, Brian Burkhalter
wrote:
>
> On Feb 12, 2015, at 8:18 AM, Paul Sandoz wrote:
>
>>> This is a morass and I hope that someone more apt to know it well would
>>> comment. The U+ null control character is always illegal though I do
>>> know that.
>>
>> Yes. IIR
On Feb 12, 2015, at 9:29 AM, Paul Sandoz wrote:
>>> Yes, for an interoperable format potentially read by other tools having
>>> U+ is a really bad idea.
>>
>> Yep.
>>
>
> And i think that applies to plist files too.
I cannot confirm but I heard otherwise. I’ll test it.
>>> My inclinati
On Feb 12, 2015, at 3:50 PM, Daniel Fuchs wrote:
> Hi Paul,
>
> This looks good - I have noticed one copy/paste error in the javadoc
> though:
>
> OptionalInt.java:
>
> looks like the throws clause of ifPresent and ifPresentOrElse have been
> interverted:
>
> 138 * @throws NullPointerEx
On Feb 12, 4:56pm, [email protected] (Lev Priima) wrote:
-- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
| Christos,
|
| Test may fail on shorter arrays(page 8 of paper). For instance, on worst
| case, generated by test, it starts to fail on length 67108864.
|
Hi Roger,
That has been my thought all along. Dealing with the forward and backward
compatibility issues and with what might be acceptable for .plist files vs. XML
does not seem worth the overhead by comparison.
Thanks,
Brian
On Feb 12, 2015, at 9:13 AM, Roger Riggs wrote:
> I think its wor
On Feb 12, 2015, at 7:00 PM, Louis Wasserman wrote:
> How often does the case when you "have a lambda handy already" come up in
> practice? If this leads to people using this method instead of ifPresent,
> that seems wasteful.
>
A lambda bearing ifPresent is already "present" (sorry!) :-) t
I get that ifPresent is already available; I'm curious if you examined how
often there is actually an "if absent" case in practice, relative to the
"only do something if present" case.
If you don't have statistics, I could fairly easily get statistics on
Google's codebase for what usages of Guava'
On Feb 12, 2015, at 7:27 PM, Louis Wasserman wrote:
> I get that ifPresent is already available; I'm curious if you examined how
> often there is actually an "if absent" case in practice, relative to the
> "only do something if present" case.
>
> If you don't have statistics,
No, since this is
The new version looks good Paul!
-- daniel
On 2/12/15 6:50 PM, Paul Sandoz wrote:
On Feb 12, 2015, at 3:50 PM, Daniel Fuchs wrote:
Hi Paul,
This looks good - I have noticed one copy/paste error in the javadoc
though:
OptionalInt.java:
looks like the throws clause of ifPresent and ifPresen
Paul,
I retract my statement below. My webrev.00 was this one:
http://cr.openjdk.java.net/~bpb/8068373/webrev.00/
with no API changes. It follows extant style but I do not like it that much.
Please compare if you have time with the adding of the IAE to the spec.
Thanks,
Brian
On Feb 12, 2015
So I think this is the patch there appeared to be some consensus no in the
review thread:
Issue: https://bugs.openjdk.java.net/browse/JDK-8068373
Patch: http://cr.openjdk.java.net/~bpb/8068373/webrev.03/
(Yeah, I know I forgot once again to update the more recent copyright year -
will do befo
Hi Brian,
Is there a particular reason to use the String form of contains(String)
instead of indexOf(int) >= 0?
It seems more natural since the scan is for a single character.
If there is no performance difference then its does not matter.
Will there be a test?
Roger
On 2/12/2015 2:30 PM, B
New JEP Candidate: http://openjdk.java.net/jeps/238
- Mark
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are especially interesting in hearing feedback from library developers,
tool/IDE developers, and anyone doing funky stuff with cl
Hello,
Based on previous discussions this thread which used to be an RFC is now an
RFR. Thanks to Paul and Roger for comments.
Issue: https://bugs.openjdk.java.net/browse/JDK-8068373
Patch: http://cr.openjdk.java.net/~bpb/8068373/webrev.04/
Historical variants may be seen here: http://cr.open
On Feb 12, 2015, at 8:29 PM, Louis Wasserman wrote:
> I'm not sure I can share hard numbers, but the ratio of
>
> if (optional.isPresent()) {
> // non-returning statements here
> }
>
> to
>
> if (optional.isPresent()) { // or negated
> // non-returning statements here
> } else {
> //
Hi,
The Process and ProcessHandle API javadoc has been updated with the comments
and suggestions including the loose coupling of the Process from the
CompletableFutures
that are linked to process termination.
The improved implementation from Peter is incorporated and the method
descriptions
u
Hi Paul, my apology for taking so long :-)
The change looks fine.
With regarding the edge case "".split(""), I am fine with the idea of
discarding the
resulting empty string as one trailing empty string.
-Sherman
On 01/20/2015 08:17 AM, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psa
Interesting direction.
Reading carefully, the goal is actually very limited in scope, by
preventing any public API changes. It doesn't help adoption of JSR-310
for example, but will be useful for Unsafe, which is clearly a
motivating factor.
I would expect IDEs to have some considerable work to d
On 2/12/15 3:15 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
OK, overall looks pretty good. Two minor comments on Matcher.java:
1202 if (expectedCount >= 0 && expectedCount != matchOrResetCount)
1203 return tr
Hi Lev,
On 13/02/2015 2:56 AM, Lev Priima wrote:
Christos,
Test may fail on shorter arrays(page 8 of paper). For instance, on worst
case, generated by test, it starts to fail on length 67108864.
After increasing stack size of runs to merge, Arrays.sort(T[]) works
also on maximum possible array
Hi Tom,
If you are potentially messing with the (identity) hash of all Java
objects in the 32-bit case then this needs a broader discussion eg on
core-libs-dev (cc'd) as this will impact end-user code the most!
The rest seems okay but I'm still mulling over it. :)
Thanks,
David H.
On 13/02/
44 matches
Mail list logo
