> I noticed a few others nearby. It's startling that a new occurrence has crept
> it.
At least I haven't seen it on return types, like: public byte toArray() [] {
... }
> An interesting exercise would be to write a detector for this declaration
> style.
Can a language syntax/feature be
Hello Stuart,
I'm not sure whether you're aware that IntelliJ IDEA has an automatic
inspection named "C-style array declaration":
- description:
https://github.com/JetBrains/intellij-community/blob/master/plugins/InspectionGadgets/src/inspectionDescriptions/CStyleArrayDeclaration.html
- logic:
On Wed, Sep 12, 2018 at 2:33 AM, Martin Buchholz wrote:
> https://sourceware.org/ml/libc-alpha/2018-09/msg00120.
> Coincidence?
Yes :) Interesting though.
On Tue, Sep 11, 2018 at 9:04 AM, Stephen Colebourne
wrote:
> What I can say is that I think List is the better fit here, because:
> - the result is not large
If we're talking about classpath splitting ...
At Google, we continue to struggle with classpaths that have on the
order of 10,000
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_OPTIMIZATION := LOW
as those platforms will use gcc/clang with support for
Hi Severin,
On 09/11/2018 09:02 AM, Severin Gehwolf wrote:
Micro-benchmark results from running [1] for x86_64 and ppc64le are
here (-O2 is sufficient it seems):
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
More thoughts?
Thanks a lot for checking it on
https://sourceware.org/ml/libc-alpha/2018-09/msg00120.
Coincidence?
It's an errorprone warning, for "easy" removal ... __IF__ you can run
errorprone on the head sources.
I think it's
http://errorprone.info/bugpattern/MixedArrayDimensions
On Tue, Sep 11, 2018 at 2:35 PM, Brian Burkhalter
wrote:
>
> On Sep 11, 2018, at 1:23 PM, Stuart Marks wrote:
>
>>> 2. even
A meeting of the minds?
http://hg.openjdk.java.net/jdk/jdk/rev/745ce8f5efc8
Looks good!
On Tue, Sep 11, 2018 at 1:09 PM, Ivan Gerasimov
wrote:
> Hello!
>
> It's a pico-optimization.
>
> In a few places a call to Set.contains() can be merged with the following
> Set.add().
>
> BUGURL:
Hi,
Please review this change to how the platform encoding is determined on
Mac when loading agents.
Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
Additional details in the bug report:
https://bugs.openjdk.java.net/browse/JDK-8072130
Some background:
Since JDK 8,
On Sep 11, 2018, at 1:23 PM, Stuart Marks wrote:
>> 2. even if, it should not be byte b[] but byte[] b
>
> Yeah we need to clean occurrences of this anachronistic array declaration
> from the JDK. I noticed a few others nearby. It's startling that a new
> occurrence has crept it. (Or maybe
Hello Ivan,
This looks all right to me.
Thanks,
Brian
On Sep 11, 2018, at 1:09 PM, Ivan Gerasimov wrote:
> It's a pico-optimization.
>
> In a few places a call to Set.contains() can be merged with the following
> Set.add().
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210347
>
>
Hi Roger,
110 * Returns a list of path strings parsed from a string with empty
paths removed.
The Unix shell and the Java launcher's -classpath processing treat an empty path
entry as the current working directory. (I don't know what happens on Windows.)
Removing empty paths thus
2. even if, it should not be byte b[] but byte[] b
Yeah we need to clean occurrences of this anachronistic array declaration from
the JDK. I noticed a few others nearby. It's startling that a new occurrence has
crept it. (Or maybe not, perhaps it was done to conform to the nearby code.)
Any
Hello!
It's a pico-optimization.
In a few places a call to Set.contains() can be merged with the
following Set.add().
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210347
WEBREV: http://cr.openjdk.java.net/~igerasim/8210347/00/webrev/
Would you please help review the trivial fix?
--
Hi Paul,
Thank you for bringing this issue to our attention. While we agree that
this does indeed seem like an issue that should be addressed, it is
quite late in the JDK 11 schedule, and it does not appear to be a new
issue introduced in JDK 11. We will be investigating this offline and
On 9/11/18 8:14 AM, Langer, Christoph wrote:
Hi,
first of all, I suggest to use "jarDetails" instead of "jarPath" as category name. Because with this
contribution we add the notion of jar file plus line of manifest to Exceptions occurring when parsing jar manifests. And if there
were further
I think this is a cool idea. Do you have any performance numbers?
On Tue, Sep 11, 2018 at 12:52 PM Thomas Stüfe wrote:
>
> Hi all,
>
> I wanted to gauge opinions on the following issue:
>
> Runtime.exec, on Linux, uses vfork(2) by default. It gives us better
> performance compared with fork()
Hi all,
I wanted to gauge opinions on the following issue:
Runtime.exec, on Linux, uses vfork(2) by default. It gives us better
performance compared with fork() and robustness in constrained memory
situations.
But as we know vfork() can be dangerous if used incorrectly. In the
child process
Hi Martin, Alan,
On Sun, Sep 9, 2018 at 2:34 AM, Martin Buchholz wrote:
>
>
> On Wed, Sep 5, 2018 at 11:43 AM, Thomas Stüfe
> wrote:
>>
>> On Wed, Sep 5, 2018 at 6:43 PM, Martin Buchholz
>> wrote:
>>
>> > So before the readdir loop we should set errno to 0. Then when readdir
>> > returns
Looks good, thanks!
/Erik
On 2018-09-11 09: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
Hi all,
May I please have reviews for this small fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8210549
patch (full):
http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-instead-of-close/webrev.00/webrev/
patch (minimal alternative):
2018/9/11 4:50:49 -0700, chris.hega...@oracle.com:
>> On 11 Sep 2018, at 10:24, Alan Bateman wrote:
>> On 10/09/2018 21:55, Roger Riggs wrote:
>>> Nope! there's quoting on Windows that gets short changed with that work
>>> around.
>>>
>>> Other opinions?, Suggestions?
>>
>> One suggestion is
2018/9/11 8:05:23 -0700, roger.ri...@oracle.com:
> Right, that is a description of the shell environment on Windows and how
> the java launcher behaves.
> On Windows the launcher expands wildcards when evaluating classpath from
> the environment
> and the command line args. After they are
See the comments here https://bugs.openjdk.java.net/browse/JDK-8180410
/Michael
From: core-libs-dev on behalf of
Christian Ullenboom
Sent: 11 September 2018 01:18:42
To: core-libs-dev@openjdk.java.net
Subject: ByteArrayOutputStream should not have a new
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.
How about this?
On Tue, 11 Sep 2018 at 10:25, Alan Bateman wrote:
> On 10/09/2018 21:55, Roger Riggs wrote:
> > Nope! there's quoting on Windows that gets short changed with that
> > work around.
> >
> > Other opinions?, Suggestions?
> One suggestion is reduce this down to one method that returns a stream
>
cross-posting to security-dev since this is related to SSL/TLS.
On 9/11/18 11:41 AM, Hohensee, Paul wrote:
The default value for the maximum number of entries in the SSL session cache
(which is a SoftReference cache) is infinite, and the entry timeout is 24
hours. With larger heaps, we’re
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.
/Erik
On 2018-09-11 05:02, Severin Gehwolf wrote:
On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
I see. I was not aware of
1. There is write(byte[]) already
2. even if, it should not be byte b[] but byte[] b
The default value for the maximum number of entries in the SSL session cache
(which is a SoftReference cache) is infinite, and the entry timeout is 24
hours. With larger heaps, we’re running into situations where the cache ends up
with several million entries when the 24 hours are up. They’re
Clarified.
So classpath can call this new method first and then expand * to all JAR files.
This is fine.
Thanks
Max
> On Sep 11, 2018, at 11:05 PM, Roger Riggs wrote:
>
> Hi Max,
>
> Right, that is a description of the shell environment on Windows and how the
> java launcher behaves.
> On
Hi Max,
Right, that is a description of the shell environment on Windows and how
the java launcher behaves.
On Windows the launcher expands wildcards when evaluating classpath from
the environment
and the command line args. After they are expanded the java.class.path
property is set.
The
I like splitSearchPath.
If think splitSearchPath should be a static method of java.io.File, perhaps
with another variant in java.nio.file.Files also named splitSearchPath that
returns a Stream of Path.
Rémi
- Mail original -
> De: "Alan Bateman"
> À: "Roger Riggs" , "jonathan
Hi,
What would the use case be for that?
A search path is usually just a sequence of file paths; wildcard
expansion is not includes.
Wildcards are significant only in shell contexts, though the expansion
is done by the shell on Unix and by the application on Windows; it
would add a fair
Is the wildcard character allowed in the input?
I'm thinking of the wildcard support in classpath.
--Max
> On Sep 11, 2018, at 2:16 AM, Roger Riggs wrote:
>
> Please review the API and implementation of an API to parse Path strings.
> Two methods are added to java.nio.file.Paths to parse a
On 11/09/2018 14:09, Roger Riggs wrote:
Streams are fine and easy to get from a List; but overall are a much
higher overhead than the list itself.
And they can't be stored or re-used. Which would mean re-parsing the
string again.
I think returning Stream will provide the most flexibility. The
> On 11 Sep 2018, at 14:18, Roger Riggs wrote:
>
> Hi Chris,
>
> On 9/11/18 7:50 AM, Chris Hegarty wrote:
>>> On 11 Sep 2018, at 10:24, Alan Bateman wrote:
>>>
>>> On 10/09/2018 21:55, Roger Riggs wrote:
Nope! there's quoting on Windows that gets short changed with that work
Hi Chris,
On 9/11/18 7:50 AM, Chris Hegarty wrote:
On 11 Sep 2018, at 10:24, Alan Bateman wrote:
On 10/09/2018 21:55, Roger Riggs wrote:
Nope! there's quoting on Windows that gets short changed with that work around.
Other opinions?, Suggestions?
One suggestion is reduce this down to one
Hi Alan,
On 9/11/18 5:24 AM, Alan Bateman wrote:
On 10/09/2018 21:55, Roger Riggs wrote:
Nope! there's quoting on Windows that gets short changed with that
work around.
Other opinions?, Suggestions?
One suggestion is reduce this down to one method that returns a stream
rather than a
Hi,
first of all, I suggest to use "jarDetails" instead of "jarPath" as category
name. Because with this contribution we add the notion of jar file plus line of
manifest to Exceptions occurring when parsing jar manifests. And if there were
further Exception details to be added in the area of
On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
> I see. I was not aware of that issue, but we clearly need to file a bug
> for it and fix it. In this case I think it's fine to us the macro however.
OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
On 11/09/2018 12:15, Chris Hegarty wrote:
On 11 Sep 2018, at 09:50, vyom tewari wrote:
Hi Chris,Daniel,
Please find the latest patch(
http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).
Thanks Vyom, Reviewed.
Agreed.
best regards,
-- daniel
-Chris.
> On 11 Sep 2018, at 10:24, Alan Bateman wrote:
>
> On 10/09/2018 21:55, Roger Riggs wrote:
>> Nope! there's quoting on Windows that gets short changed with that work
>> around.
>>
>> Other opinions?, Suggestions?
> One suggestion is reduce this down to one method that returns a stream
> I don't have a strong opinion on making Manifest.jarFilename final
Hi, just making it final leads to compile errors anyway.
Best regards, Matthias
> -Original Message-
> From: Weijun Wang
> Sent: Dienstag, 11. September 2018 13:04
> To: Baesken, Matthias
> Cc: Langer, Christoph ;
> On 11 Sep 2018, at 09:50, vyom tewari wrote:
>
> Hi Chris,Daniel,
>
> Please find the latest patch(
> http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).
Thanks Vyom, Reviewed.
-Chris.
Attributes.java:
- Line 377: Too long, add a break.
Otherwise fine.
I don't have a strong opinion on making Manifest.jarFilename final or a
different property name.
Thanks
Max
> On Sep 11, 2018, at 5:07 PM, Baesken, Matthias
> wrote:
>
> Hello, please check the new webrev :
>
>
On 11/09/2018 01:05, Xueming Shen wrote:
:
Alan, now reading the win version canonicalize(...), remind me what's
the real purpose of doing
FindFirstFile/FindClose() here? the API appears to suggest it is used
to find the first match if there
is/are wildcards but we actually have
On 10/09/2018 21:55, Roger Riggs wrote:
Nope! there's quoting on Windows that gets short changed with that
work around.
Other opinions?, Suggestions?
One suggestion is reduce this down to one method that returns a stream
rather than a collection. It could work lazily if you want. Something
Hello, please check the new webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/
I kept the jarPath category name .
Best regards, Matthias
> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 10. September 2018 21:30
> To: Weijun Wang ; Baesken, Matthias
>
>
Hi Chris,Daniel,
Please find the latest patch(
http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).
I did the additional cleanup(removed redundant null check) as you suggested.
Thanks,
Vyom
On Monday 10 September 2018 09:03 PM, Daniel Fuchs wrote:
On 10/09/2018 15:53, vyom
51 matches
Mail list logo
