On 9/12/18 2:16 PM, mark.reinh...@oracle.com wrote:
To make this trivial enhancement I first had to fix some broken tests,
so there are two issues and two webrevs here.
8210669: Some launcher tests assume a pre-JDK 9 run-time image layout
Two launcher tests, ExecutionEnvironment.java and
Hi Calvin,
I believe I was thinking of keeping the "getPrefixed" as an
implementation details and
instead exporting a "A" version of winFileHandleOpen() back then. But I
don't have a
strong opinion on this one, so your approach looks fine.
No, I don't have a better idea for now to avoid those
Hello,
On 9/12/2018 1:16 AM, Severin Gehwolf wrote:
On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
But I don't understand why the optimization setting is being tied to the
availability of the -ffp-contract flag?
In configure we perform a check for gcc or clang whether that flag is
supp
Correction ...
On 13/09/2018 8:31 AM, David Holmes wrote:
On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
But I don't understand why the optimization setting is being tied to the
availability of the -ffp-contract flag?
In configure we perf
Hi Joe,
The change seems reasonable
> On Sep 12, 2018, at 2:11 PM, Joe Wang wrote:
>
> Hi,
>
> Please review a patch for a situation where a surrogate pair is at the edge
> of a buffer. What the existing impl did was to report it as an error. This
> patch fixes it by caching the high surrog
Hi Sherman,
Thanks for your review.
Please refer to my reply below...
On 9/10/18, 5:05 PM, Xueming Shen wrote:
On 9/10/18, 11:42 AM, Calvin Cheung wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8190737
webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
Please review this ch
On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
But I don't understand why the optimization setting is being tied to the
availability of the -ffp-contract flag?
In configure we perform a check for gcc or clang whether that flag is
supported.
2018/9/12 14:16:00 -0700, mark.reinh...@oracle.com:
> ...
>
> 8210670: Accept double-dash VM-name options at launch time
>
> Per JEP 293 (Guidelines for JDK Command-Line Tool Options) [2], enhance
> the Java launcher so that `--server` is accepted to select the server VM,
> in addition to `
On 9/11/18 10:36 PM, Michael Rasmussen wrote:
Can a language syntax/feature be deprecated to produce a warning in javac?
Perhaps this one should.
We haven't reached the point of formally deprecating language features, but
certain features like this one (and others) are certainly frowned upo
To make this trivial enhancement I first had to fix some broken tests,
so there are two issues and two webrevs here.
8210669: Some launcher tests assume a pre-JDK 9 run-time image layout
Two launcher tests, ExecutionEnvironment.java and Test7029048.java (in
test/jdk/tools/launcher), still ass
Cool, I didn't know that IntelliJ IDEA has such an inspection, but I'm not
surprised.
Perhaps a volunteer can run this inspection over parts of the JDK code base and
see what comes up, and possibly propose some patches. :-)
s'marks
On 9/11/18 10:34 PM, Tomasz Linkowski wrote:
Hello Stuart,
Thanks very much for investigating. We're aware that the cache size can be set
by the user, but many of our users haven't done so because it hasn't been
necessary, and boom.
Paul
On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan"
wrote:
Hi Paul,
Thank you for bring
Hi,
Please review a patch for a situation where a surrogate pair is at the
edge of a buffer. What the existing impl did was to report it as an
error. This patch fixes it by caching the high surrogate and prints it
out along with the low surrogate. Similar issue exists also in the CDATA
sectio
On 9/12/18 9:31 AM, Peter Levart wrote:
On 09/12/2018 04:30 PM, Roger Riggs wrote:
Hi Stuart,
The implementation retains the previous handling of empty path
elements for URLClassPath
in the implementation. The spec for the new methods is explicit
about dropping empty elements.
For a l
Looks good.
/Erik
On 2018-09-12 10:33, naoto.s...@oracle.com wrote:
Hi Magnus, Erik,
Thank you for your comments. I updated the webrev according to your
suggestions:
http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
As to the duplicated "common" in the dependency, yes that's a separate
It's hard to get the ZipEntry API right to perfectly handle these
platform specific
"file system attributes" especially given the potential performance and
security
concern.
I would assume zipfs might be a better place to handle this if "really"
desired,
in which already has the base to han
Hi Magnus, Erik,
Thank you for your comments. I updated the webrev according to your
suggestions:
http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
As to the duplicated "common" in the dependency, yes that's a separate
issue. Since it's obvious, I included the fix with this changeset (it
Hi
What is the status of this issue [1]? It addresses some long-standing issues
with Java's Unicode support on Windows and was contributed by a team of
Microsoft engineers. However, it seems to have gone dormant right before the
finish line, and I can't really figure out who's waiting for whom
On 09/12/2018 04:30 PM, Roger Riggs wrote:
Hi Stuart,
The implementation retains the previous handling of empty path
elements for URLClassPath
in the implementation. The spec for the new methods is explicit about
dropping empty elements.
For a library API, it is inadvisable to support im
In principle I support making system specific extensions to the ZIP
spec more supported, as other zip implementations do. There is long
standing tension between Java trying to be highly portable and
providing access to the data you need. It's already the case that
some implementation bits are not
On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
Some comm
On Wed, Sep 12, 2018 at 8:16 AM, David Lloyd wrote:
> Seems worthwhile though, given vfork's now-10-year-old obsolescence.
> It looks like Linux is the only platform still using vfork for
> ProcessImpl in OpenJDK.
I'm fine with switching to posix_spawn on Linux as long as we don't
reintroduce th
On Wed, Sep 12, 2018 at 7:33 AM, David Lloyd wrote:
>> The child process is created using vfork(2) instead of fork(2) when [...]
>> file_actions is NULL and the spawn-flags element of the attributes object
>> pointed to by attrp does not contain POSIX_SPAWN_SETSIGMASK,
>> POSIX_SPAWN_SETSIGDEF,
On Wed, Sep 12, 2018 at 9:58 AM Roger Riggs wrote:
>
> Hi David,
>
> How does your proposal differ from the current posix_spawn and
> jspawnhelper MODE_POSIX_SPAWN
> implementation available on Solaris and AIX?
Reading through the code, it ends up being pretty much identical
AFAICT; if I understa
Hi David,
How does your proposal differ from the current posix_spawn and
jspawnhelper MODE_POSIX_SPAWN
implementation available on Solaris and AIX?
This area is sensitive enough that it would be prudent to implement it
as a new mode in ProcessImpl/ProcessImpl; retaining the existing options.
C
Hi all,
I'm currently revisiting a long standing shortcoming of the java.util.zip (and
java.util.jar) implementation.
The lack is that in the current implementation, Unix mode bits (e.g. rwx) are
not stored/read from zip or jar files and the jar tool has no capabilities to
store/preserve the m
On Wed, Sep 12, 2018 at 9:21 AM Martin Buchholz wrote:
>
> I agree that your proposal makes the implementation more robust, so if
> you are willing to implement it and it doesn't cost too much, then I
> would support it. The current implementation doesn't seem to cause
> trouble in practice, or a
Hi Stuart,
The implementation retains the previous handling of empty path elements
for URLClassPath
in the implementation. The spec for the new methods is explicit about
dropping empty elements.
For a library API, it is inadvisable to support implicit context such as
the current working dir
Hi,
My original intention was to provide minimal support for parsing a
property value
and handling OS specific behaviors (quoting).
java.nio.file.Paths is a bit of backwater (now that Path.of was added)
and its factories are dedicated to handling Paths.
I considered a new type representing
I agree that your proposal makes the implementation more robust, so if
you are willing to implement it and it doesn't cost too much, then I
would support it. The current implementation doesn't seem to cause
trouble in practice, or at least we don't see any bug reports.
When you benchmark with ope
Hi Andrew,
On 09/12/2018 12:51 AM, Gustavo Romero wrote:
Maybe Andrew can enlight us.
I was not sure if 'enlight us' was the correct form here, so I did some search
and I found with horror today that 'enlighten us' can also be considered an
insult (!?).
That's really not the case here. So if
In 2018, we can assume everyone has implemented FD_CLOEXEC.
Back in 1970, 20 file descriptors was enough for any program, but
today they're effectively unlimited, so futilely closing _SC_OPEN_MAX
descriptors has become unreasonable (as you say). OTOH, there is
still no standard way of ensuring al
On Wed, Sep 12, 2018 at 2:04 AM Thomas Stüfe wrote:
> Hi David,
>
> On Tue, Sep 11, 2018 at 8:29 PM, David Lloyd wrote:
> > I think this is a cool idea.
>
> Thanks. I think I did not come up with it though, I think the
> technique was known already.
>
> > Do you have any performance numbers?
>
>
On Wed, Sep 12, 2018 at 5:46 AM, Thomas Stüfe wrote:
> On Wed, Sep 12, 2018 at 2:30 PM, Martin Buchholz wrote:
> Btw, should I retry the readdir() on EINTR?
If I read
http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html
correctly, then readdir should never fail with EINTR
On Wed, Sep 12, 2018 at 2:30 PM, Martin Buchholz wrote:
> The reference
> from_fd + 2
> needs updating since it assumes two file descriptors have already been closed?
Good catch, I will fix that.
Btw, should I retry the readdir() on EINTR?
..Thomas
>
> On Tue, Sep 11, 2018 at 10:27 AM, Thomas
The reference
from_fd + 2
needs updating since it assumes two file descriptors have already been closed?
On Tue, Sep 11, 2018 at 10:27 AM, Thomas Stüfe wrote:
> Hi all,
>
> May I please have reviews for this small fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210549
>
> patch (full):
>
Thank you Christoph :)
On Wed, Sep 12, 2018 at 1:47 PM, Langer, Christoph
wrote:
> Hi Thomas,
>
> I like the full patch 😊 +1
>
> Best regards
> Christoph
>
>> -Original Message-
>> From: core-libs-dev On Behalf
>> Of Thomas Stüfe
>> Sent: Dienstag, 11. September 2018 19:27
>> To: Java Co
Hi Thomas,
I like the full patch 😊 +1
Best regards
Christoph
> -Original Message-
> From: core-libs-dev On Behalf
> Of Thomas Stüfe
> Sent: Dienstag, 11. September 2018 19:27
> To: Java Core Libs
> Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
> FD_CLOEXEC instead
Looks good to me.
> -Original Message-
> From: Baesken, Matthias
> Sent: Mittwoch, 12. September 2018 11:27
> To: Sean Mullan ; Langer, Christoph
> ; Weijun Wang
> Cc: security-...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Subject: RE: [RFR] 8205525 : Improve exception messages d
On 2018-09-11 18:14, Severin Gehwolf wrote:
Hi Erik,
Thanks for the review!
On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
Hello Severin,
Even if using the macro, I still think you need to add a condition on
the compiler types where the switch can be reasonably expected to exist.
Ho
On 2018-09-12 12:19, Magnus Ihse Bursie wrote:
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
Oh, and
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
Some comments:
In make/copy/Copy-java.base.gmk:
+ifneq (
Hello I changed it to jar , also added some minor adjustments suggested by
Christoph .
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.12/
Regards, Matthias
> -Original Message-
> From: Sean Mullan
> Sent: Dienstag, 11. September 2018 20:44
> To: Langer, Christoph ; Baesken, Ma
On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
> But I don't understand why the optimization setting is being tied to the
> availability of the -ffp-contract flag?
In configure we perform a check for gcc or clang whether that flag is
supported. If it is, it would be non-empty exactly havi
Hi Severin,
On 12/09/2018 5:48 PM, Severin Gehwolf wrote:
Hi David,
On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
Hi Severin,
Sorry I'm a bit confused now.
Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
HIGH. But now it will be LOW due to:
45 ifneq ($(FD
On Tue, 2018-09-11 at 10:30 -0700, Erik Joelsson wrote:
> Looks good, thanks!
Thanks for the review, Erik.
We've ran JCK 11 on this patch which passed on our end. I'll wait a few
more days whether there are objections and then push it.
Thanks,
Severin
> /Erik
>
>
> On 2018-09-11 09:14, Severi
Hi David,
On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
> Hi Severin,
>
> Sorry I'm a bit confused now.
>
> Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
> HIGH. But now it will be LOW due to:
>
>45 ifneq ($(FDLIBM_CFLAGS), )
>46 BUILD_LIBFDLIBM_OPTI
test/jdk/java/util/ServiceLoader/basic/basic.sh
Please review this patch to refactor above shell script test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8209772
webrev: http://cr.openjdk.java.net/~amlu/8209772/webrev.00/
Thanks,
Amy
Hi David,
On Tue, Sep 11, 2018 at 8:29 PM, David Lloyd wrote:
> I think this is a cool idea.
Thanks. I think I did not come up with it though, I think the
technique was known already.
> Do you have any performance numbers?
Sure:
small program, just spawning off /bin/true a 1000 times, measure
49 matches
Mail list logo
