Hello!
Could you please consider the following very simple patch to
Collectors.counting() implementation?
diff --git a/src/java.base/share/classes/java/util/stream/Collectors.java
b/src/java.base/share/classes/java/util/stream/Collectors.java
--- a/src/java.base/share/classes/java/util/stream/Co
> On Sep 14, 2015, at 9:25 AM, Daniel Fuchs wrote:
> So with that in mind, I have slightly altered the @apiNotes:
>
> in readConfiguration():
>
> * @apiNote {@code readConfiguration} is principally useful for
> *establishing the LogManager primordial configuration.
> *
>
> On Sep 16, 2015, at 11:23 AM, Alejandro E Murillo
> wrote:
>
> Please review this change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8134365
> Webrev: http://cr.openjdk.java.net/~amurillo/9/8134365/
>
> This change modifies the toString() method of:
> test/sun/misc/Version/Version.j
On 9/16/15 4:11 PM, Xueming Shen wrote:
On 09/16/2015 04:08 PM, Stuart Marks wrote:
1) I'll push the latest webrev as it stands.
2) I'll file a separate bug to clean up Scanner's and Matcher's spliterators'
modCount checking to avoid the overflow issue.
3) I'll fix all the spliterators at
On 09/16/2015 04:08 PM, Stuart Marks wrote:
On 9/16/15 8:43 AM, Xueming Shen wrote:
I'm talking about the check "immediately" prior to the call to accept(). It
will not function after the modCount tips over to the negative int value,
because the "expectedCount >=0" check.
Consider the use sc
On 9/16/15 8:43 AM, Xueming Shen wrote:
I'm talking about the check "immediately" prior to the call to accept(). It
will not function after the modCount tips over to the negative int value,
because the "expectedCount >=0" check.
Consider the use scenario that the Scanner is on top of an endle
Why not try to fix *all* the "easy" occurrences in the repo (except for
owners who prefer to fix their own) using an automated script?
On Mon, Aug 10, 2015 at 6:39 AM, Alexander Stepanov <
alexander.v.stepa...@oracle.com> wrote:
> Hello,
>
> Could you please review the following fix:
> http://cr.
Please review this test fix so the test code only operates on processes
it spawns.
On Windows, other processes may show up as children that are not part of
the test.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-treetest-8132735/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8132735
I love both hacky regexy perl and AST-based super-correct javaey analysis,
and I welcome the competition! My hacky script knows its limits and is not
going to try to get e.g. enclosing class vs. interface correct.
On Wed, Sep 16, 2015 at 11:49 AM, joe darcy wrote:
> FWIW, for a related possible
Hi guys,
Here's the requested script checkin:
https://bugs.openjdk.java.net/browse/JDK-8136656
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/
FWIW, for a related possible future cleanup some modifiers by convention
can be omitted, such as abstract on normal interface methods. The
printModifiers method written annotation processing
http://hg.openjdk.java.net/jdk9/dev/langtools/file/286fc9270404/src/jdk.compiler/share/classes/com/sun/t
Please review this change:
Bug: https://bugs.openjdk.java.net/browse/JDK-8134365
Webrev: http://cr.openjdk.java.net/~amurillo/9/8134365/
This change modifies the toString() method of:
test/sun/misc/Version/Version.java
so that it doesn't include trailing zeros when the some version fields
ar
Peter, that Java program is awesome, but ...
the original perl seems more readable to me (!)
even if I apply some not-yet-done perl golf to it,
and it seems to me that if we're rewriting in Java we can get the benefits
of Java, i.e. correctness, which you can probably get by tapping into
javac's co
Please review these changes:
Bug: https://bugs.openjdk.java.net/browse/JDK-8087203
Webrev: http://cr.openjdk.java.net/~amurillo/9/8087203/
The actual code changes for this bug (8087203) were entered along
with the ones for 8087202. The changes here are just fixing some
javadoc comments in that t
Mostly moot, now that we have consensus on just deleting these entirely,
but my (original) code was safer because it calls putenv in fewer cases.
Who knows what /usr/dt is "supposed" to look like these days? "Common"
Desktop Environment not so "common" anymore...
On Wed, Sep 16, 2015 at 1:33 AM,
Webrev regenerated
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch
and is now the best kind of change, a pure-deletion change.
On Wed, Sep 16, 2015 at 9:00 AM, Phil Race wrote:
> That is fine by me. If any one on awt-dev knows of a reason to keep i
So although default "looks like" a modifier, technically it's not, but it
can be inferred from values of other modifiers. Method.isDefault:
public boolean isDefault() {
// Default methods are public non-abstract instance methods
// declared in an interface.
return ((ge
Hi Volker,
On 9/16/2015 2:02 AM, Volker Simonis wrote:
Hi Joe,
nice clean-up! From a maintenance point of view the the old fdlibm has
been a burden and a constant source of warnings with newer compilers.
What about the final arrays in Pow.compute (BP, DP_H, DP_L). In the
Interpreter (and even
Hi Vyom,
I will sponsor your change and push the fix for you.
I'll sync up with Rob to check that we don't step on each other's toes.
best regards,
-- daniel
On 16/09/15 16:03, Chris Hegarty wrote:
The changes look good to me Vyom.
-Chris.
On 16/09/15 10:08, Vyom Tewari wrote:
Hi All,
Ple
That is fine by me. If any one on awt-dev knows of a reason to keep it
they should speak up.
-phil.
On 9/15/15 5:09 PM, Martin Buchholz wrote:
We would be entirely happy if the environment frobbing code were to be
deleted.
Should I change my code to do that?
On Tue, Sep 15, 2015 at 3:49 PM, P
On 9/16/15 8:43 AM, Xueming Shen wrote:
On 9/15/15 9:48 PM, Stuart Marks wrote:
On 9/10/15 2:12 PM, Xueming Shen wrote:
I think it might be a "nice to have" for a "fail-fast" effort after
the the
consumer consumed/accepted the result (the second check), but isn't
it a bug
for the consumer to
On 9/15/15 9:48 PM, Stuart Marks wrote:
On 9/10/15 2:12 PM, Xueming Shen wrote:
I think it might be a "nice to have" for a "fail-fast" effort after
the the
consumer consumed/accepted the result (the second check), but isn't
it a bug
for the consumer to accept any result if there is CME condi
Hi Martin,
On 09/16/2015 02:42 AM, Martin Buchholz wrote:
Hi, Chris and Paul,
I'd like you to do a very boring code review.
This change is entirely machine generated. (the script is more interesting)
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-ord
Martin,
On 16/09/15 01:42, Martin Buchholz wrote:
Hi, Chris and Paul,
I'd like you to do a very boring code review.
This change is entirely machine generated. (the script is more interesting)
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
On 16/09/2015 12:07, Miroslav Kos wrote:
On 15/09/15 15:46, Alan Bateman wrote:
On 27/08/2015 19:26, Miroslav Kos wrote:
Hi Alan,
I added logging (at least for now) - would it work for you?
updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/
If you think the exception should
The changes look good to me Vyom.
-Chris.
On 16/09/15 10:08, Vyom Tewari wrote:
Hi All,
Please review my changes for below bug.
Bug:
JDK-8073542 : File Leak in
jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
Webrev:
http://cr.openjdk.java.net/~dfuchs/vyom/8073542/webrev.
Hi Vyom!
The change looks fine, thanks.
You've used strerr() to extract the error string, so it may be good to
coordinate your patch with the fix for JDK-8133249.
Robert (CCed) is working on it at the moment.
Sincerely yours,
Ivan
On 16.09.2015 12:08, Vyom Tewari wrote:
Hi All,
Please revi
On 2015-09-16 14:54, Alan Bateman wrote:
On 16/09/2015 01:42, Martin Buchholz wrote:
Hi, Chris and Paul,
I'd like you to do a very boring code review.
This change is entirely machine generated. (the script is more
interesting)
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifi
On 16/09/2015 01:42, Martin Buchholz wrote:
Hi, Chris and Paul,
I'd like you to do a very boring code review.
This change is entirely machine generated. (the script is more interesting)
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
https:
Hi Bernd,
In some respects “default” is easy. It can only occur on non-abstract methods
on interfaces, and declaring such methods “public” is redundant (as is the case
for abstract methods on interfaces, where also declaring “abstract” is
redundant). [*] And there are more redundant cases relat
On 15/09/15 15:46, Alan Bateman wrote:
On 27/08/2015 19:26, Miroslav Kos wrote:
Hi Alan,
I added logging (at least for now) - would it work for you?
updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/
If you think the exception shouldn't be ignored I suggest to solve
this in s
On 16 Sep 2015, at 02:42, Martin Buchholz wrote:
> Hi, Chris and Paul,
> I'd like you to do a very boring code review.
>
> This change is entirely machine generated. (the script is more interesting)
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-or
Hi All,
Please review my changes for below bug.
Bug:
JDK-8073542 : File Leak in
jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
Webrev:
http://cr.openjdk.java.net/~dfuchs/vyom/8073542/webrev.00
This change ensure that if "setsocketopt" fails we close the
corresponding fd
Hi Joe,
nice clean-up! From a maintenance point of view the the old fdlibm has
been a burden and a constant source of warnings with newer compilers.
What about the final arrays in Pow.compute (BP, DP_H, DP_L). In the
Interpreter (and even in C2 without EscapeAnalysis) this will lead to
allocation
Hi Martin,
would it be not sufficient to just test for existence of /usr/dt before the
two calls to setPathEnvironment() and leave the rest as it is? I also think
the intend would be clearer ("only call this if CDE is installed").
Kind Regards, Thomas
On Wed, Sep 16, 2015 at 12:13 AM, Martin B
35 matches
Mail list logo
