On 10/09/2018 08:19, Amy Lu wrote:
test/jdk/java/util/zip/ZipFile/deletetempjar.sh
Please review this patch to refactor above shell script test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8209930
webrev: http://cr.openjdk.java.net/~amlu/8209930/webrev.00/
This okay as a
On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
> On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
> > Is there a good
> > reason to not use -O3 -ffp-contract=off everywhere?
>
> Is there a good reason to use -O3 rather than -O2?
Not sure. I was following what JDK-8170153 did, which was
On 10/09/2018 10:13, Chris Yin wrote:
Thank you, Alan
Sure, I modified a little to remove “.” and use Path.of as you suggested to
improve file handling, minor revision as below, thanks
http://cr.openjdk.java.net/~xyin/8209773/webrev.01/
The update looks okay to me.
-Alan
Any other reviews? I'm not a committer, so I'll also need someone to
help sponsor this patch.
-Jaikiran
On 06/09/18 7:39 PM, Jaikiran Pai wrote:
> On 06/09/18 1:24 PM, Bernd Eckenfels wrote:
>> Yes you are right @apinote is aproperiate section (was confusing it with
>> implnote).
>>
>> Still
Hello are you fine with changing from file.getAbsolutePath()to
file.getName() ?
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/share/classes/java/util/jar/Manifest.java.frames.html
206 static String getErrorPosition(String filename, final int lineNumber) {
On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
> Is there a good
> reason to not use -O3 -ffp-contract=off everywhere?
Is there a good reason to use -O3 rather than -O2? -O3 can bloat the
code which can increase cache pressure, which is not always noticeable
in benchmarks but hurts real-world
On 10/09/2018 10:40, Amy Lu wrote:
Good point!
How about to resolve it later in a separate issueto-be-filed?
Okay with me.
-Alan
On 2018-09-05 15:26, Alan Bateman wrote:
On 05/09/2018 13:58, Magnus Ihse Bursie wrote:
The file sdp.conf.template is copied only when building for solaris,
but it resides in the unix source directory.
SDP is legacy now and we should probably think about removing it, esp.
with the rsocket
> I think it would be enough to drop the privileged section and just return
> "filename" as is. (without conveting to a file object).
OK, any objections on this ?
> I also agree with Sean that the common parts of the new
> src/java.base/share/classes/sun/security/util/SecurityProperties.java
test/jdk/java/util/zip/ZipFile/deletetempjar.sh
Please review this patch to refactor above shell script test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8209930
webrev: http://cr.openjdk.java.net/~amlu/8209930/webrev.00/
Thanks,
Amy
On 30/08/2018 10:06, vyom tewari wrote:
Hi Chris,
The refactored java class (RunBasic.java) looks good to me.
Looks okay to me too but the file handling could be improved, e.g. no
need to resolve path against ".", should specify the elements to Path.of
so that they use the right separator
Thank you, Alan
Sure, I modified a little to remove “.” and use Path.of as you suggested to
improve file handling, minor revision as below, thanks
http://cr.openjdk.java.net/~xyin/8209773/webrev.01/
Regards,
Chris
> On 10 Sep 2018, at 3:20 PM, Alan Bateman wrote:
>
> On 30/08/2018 10:06,
Hi Matthias,
I think it would be enough to drop the privileged section and just return
"filename" as is. (without conveting to a file object).
I also agree with Sean that the common parts of the new
src/java.base/share/classes/sun/security/util/SecurityProperties.java should be
aligned with
On 2018/9/10 3:27 PM, Alan Bateman wrote:
On 10/09/2018 08:19, Amy Lu wrote:
test/jdk/java/util/zip/ZipFile/deletetempjar.sh
Please review this patch to refactor above shell script test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8209930
webrev:
Hi Erik,
On Fri, 2018-09-07 at 10:19 -0700, Erik Joelsson wrote:
> Instead of checking for compiler version, you could simply use the
> FLAGS_COMPILER_CHECK_ARGUMENTS macro. This would apply to both gcc and
> clang. We usually prefer this over version checks (unless a version is
> just known
Hi Andrew,
On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
> On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
> > Is there a good
> > reason to not use -O3 -ffp-contract=off everywhere?
>
> Is there a good reason to use -O3 rather than -O2? -O3 can bloat the
> code which can increase cache
Vyom,
The NPE is originating from the finally block of the LdapClient
`authenticate` method. In the finally block there is an attempt
to restore the "read" timeout, since it was changed earlier in
`authenticate`, to reflect the connect timeout value, since the
subsequent operation(s) are
Hi Severin,
On 09/10/2018 06:27 AM, Severin Gehwolf wrote:
On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
Is there a good
reason to not use -O3 -ffp-contract=off everywhere?
Is there a good reason to use -O3 rather than -O2?
Not sure.
On Fri, 2018-09-07 at 10:19 -0700, Erik Joelsson wrote:
> On 2018-09-07 09:56, Severin Gehwolf wrote:
> > On Fri, 2018-09-07 at 09:12 -0700, Erik Joelsson wrote:
> > > To me it sounds like we want this flag if the toolchain is either gcc or
> > > clang, so please make it conditional on that.
> >
On 10/09/2018 09:10, Magnus Ihse Bursie wrote:
:
Updated patch, which copies the SDP template for linux too:
diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk
--- a/make/copy/Copy-java.base.gmk
+++ b/make/copy/Copy-java.base.gmk
@@ -183,7 +183,7 @@
TARGETS +=
Hi Gustavo,
On Mon, 2018-09-10 at 10:15 -0300, Gustavo Romero wrote:
> Hi Severin,
>
> On 09/10/2018 06:27 AM, Severin Gehwolf wrote:
> > On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
> > > On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
> > > > Is there a good
> > > > reason to not use
> On Sep 10, 2018, at 10:35 PM, Sean Mullan wrote:
>
>> After the changes I wonder - should the jarPath category be renamed to
>> jarFile (or something else) ?
>
> Yes, renaming it to "jarFile" makes more sense. You will need to update the
> CSR with this change too.
Well, maybe
Hi Sean, Max,
do you think we need property jdk.includeInExceptions=jar at all, if
we don't resolve the absolute path?
@Matthias:
small remark to the code:
src/java.base/share/classes/sun/security/util/SecurityProperties.java
36 public static String privilegeGetOverridable(String propName)
On Monday 10 September 2018 05:30 PM, Chris Hegarty wrote:
Vyom,
The NPE is originating from the finally block of the LdapClient
`authenticate` method. In the finally block there is an attempt
to restore the "read" timeout, since it was changed earlier in
`authenticate`, to reflect the
Vyom,
You are correct, the change that I proposed is minimal
and some fragility still remains.
I talked with Daniel, walked through the code one more
time, and I am now convinced that your original proposal
is correct ( since the pooling is at the level of
LdapClient, rather than at the level
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/
- SocketExceptions class has been adjusted to new
sun.security.util.SecurityProperties
- Attributes getErrorPosition adjusted (see proposal of Christoph " I think
it would be enough to drop the privileged section and
On 9/8/18 11:42 AM, Wang Weijun wrote:
Thinking about this again. Looks like the absolute path is not necessary. Even
if there are multiple files using the same name, they will be in different
directories, no matter absolute or relative. Suppose the jarPath info is used
for debugging purpose
Nice find Chris.
But I have to wonder why the NPE wasn't thrown at the
very beginning of `authenticate` namely one of these
two lines:
int readTimeout = conn.readTimeout;
conn.readTimeout = conn.connectTimeout;
which happen to be called even before ensureOpen() is
called a few
On 9/10/18 9:59 AM, Baesken, Matthias wrote:
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/
- SocketExceptions class has been adjusted to new
sun.security.util.SecurityProperties
- Attributes getErrorPosition adjusted (see proposal of Christoph " I think it would
Looks good.
/Erik
On 2018-09-10 01:10, Magnus Ihse Bursie wrote:
On 2018-09-05 15:26, Alan Bateman wrote:
On 05/09/2018 13:58, Magnus Ihse Bursie wrote:
The file sdp.conf.template is copied only when building for solaris,
but it resides in the unix source directory.
SDP is legacy now and
> On Sep 10, 2018, at 9:59 PM, Baesken, Matthias
> wrote:
>
> New webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/
Looks fine to me.
>
> - SocketExceptions class has been adjusted to new
> sun.security.util.SecurityProperties
> - Attributes getErrorPosition
I've filed JDK-8210551.
/Erik
On 2018-09-10 09:29, 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.
/Erik
On 2018-09-10 03:29, Severin Gehwolf wrote:
Hi Erik,
On Fri,
On 2018/9/10 5:41 PM, Alan Bateman wrote:
On 10/09/2018 10:40, Amy Lu wrote:
Good point!
How about to resolve it later in a separate issueto-be-filed?
Okay with me.
-Alan
Thank you Alan!
Pushed, and created JDK-8210548 as follow up.
Thanks,
Amy
On 9/10/18 4:21 AM, Baesken, Matthias wrote:
I think it would be enough to drop the privileged section and just return
"filename" as is. (without conveting to a file object).
OK, any objections on this ?
No, this is fine with me.
--Sean
> On Sep 10, 2018, at 10:46 PM, Langer, Christoph
> wrote:
>
> Hi Sean, Max,
>
> do you think we need property jdk.includeInExceptions=jar at all,
> if we don't resolve the absolute path?
I think so. File path is still sensitive.
In fact, I tend to believe people usually use absolute
On 10/09/2018 15:53, vyom tewari wrote:
Yes , this will definitely solve this NPE issue but we may hit NPE other
places as well because we are setting 'LdapClient.com' to null
asynchronously.
I agree with Vyom here.
Other solutions that have been investigated - such as only
setting the
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.
/Erik
On 2018-09-10 03:29, Severin Gehwolf wrote:
Hi Erik,
On Fri, 2018-09-07 at 10:19 -0700, Erik Joelsson wrote:
Instead of checking for
On 10/09/2018 18:53, mandy chung wrote:
To analyze class dependencies of a multi-release JAR file,
jdeps --multi-release option must be specified so that only
entries of the specified version will be analyzed.
This is to fix a bug in jdeps that fails when it is given
both MR JARs and non-MR
Roger,
You've run into the standard naming ambiguity problem of "when is a path
a search path, with elements separated by File.pathSeparator (e.g. class
path, source path), and when is it a file path, with elements separated
by File.separator (e.g. a nio.file.Path identifying a file or
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 string using the
path separator delimiter
and return either List or List. Empty path elements are
ignored.
For compatibility with current URLClassPath behavior
On 09/10/2018 02:15 PM, Gustavo Romero wrote:
> Hi Severin,
>
> On 09/10/2018 06:27 AM, Severin Gehwolf wrote:
>> On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
>>> On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
Is there a good
reason to not use -O3 -ffp-contract=off everywhere?
Hi Ivan,
Thanks for the suggestion.
Webrev updated:
http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/
Thanks, Roger
On 9/4/2018 3:38 PM, Ivan Gerasimov wrote:
Thank you Roger!
I'm not sure if it plays any significant role, but an unnecessary call
to nanoTime() after
To analyze class dependencies of a multi-release JAR file,
jdeps --multi-release option must be specified so that only
entries of the specified version will be analyzed.
This is to fix a bug in jdeps that fails when it is given
both MR JARs and non-MR JARs. --multi-release option should
be
On 10/09/2018 19:28, Jonathan Gibbons wrote:
Roger,
You've run into the standard naming ambiguity problem of "when is a
path a search path, with elements separated by File.pathSeparator
(e.g. class path, source path), and when is it a file path, with
elements separated by File.separator
Hi,
> > do you think we need property jdk.includeInExceptions=jar at
> all, if we don't resolve the absolute path?
>
> I think so. File path is still sensitive.
>
> In fact, I tend to believe people usually use absolute paths for JAR files (or
> maybe made absolute by using a file:// URL
On 20/08/2018 16:18, Andrew Dinn wrote:
Hi Alan,
Round 4:
I have redrafted the JEP and updated the implementation in the light of
your last feedback:
JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851
Formatted JEP: http://openjdk.java.net/jeps/8207851
New webrev:
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 change for handling long path specified in the
-Xbootclasspath/a on windows.
Highlight of changes:
-
> On Sep 11, 2018, at 3:29 AM, Langer, Christoph
> wrote:
>
> Ok, maybe it should be named "priviledgedGetOverridable" then.
Ah yes. My mistake.
Thank you, Alan
Regards,
Chris
> On 10 Sep 2018, at 5:42 PM, Alan Bateman wrote:
>
>
>
> On 10/09/2018 10:13, Chris Yin wrote:
>> Thank you, Alan
>>
>> Sure, I modified a little to remove “.” and use Path.of as you suggested to
>> improve file handling, minor revision as below, thanks
>>
OK, I understand the need for quoting, although I wonder how many folk
have bothered with that up to now (looking at javac, jtreg!) ;-)
I'd stay with
List getList(String searchPath)
and then either have people use
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/
This fix is to remove the hand crafted map file (lib/tzmappings) on
Windows, which maps Windows
Hi Jon,
On 9/10/2018 4:47 PM, Jonathan Gibbons wrote:
Roger,
I had in mind your first "disambiguate" suggetion
(searchPathToStrings, searchPathToPaths)
but I note your initial comment "Is the search path the input string
or the return value? Well its both, but with different structure. "
Looks good.
/Erik
On 2018-09-10 14: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/
This fix is to remove the hand crafted
Roger,
I had in mind your first "disambiguate" suggetion (searchPathToStrings,
searchPathToPaths)
but I note your initial comment "Is the search path the input string or
the return value? Well its both, but with different structure. "
Since we have
Paths.get
how about
List
On 9/10/18 5:13 PM, Weijun Wang wrote:
On Sep 11, 2018, at 3:29 AM, Langer, Christoph wrote:
Ok, maybe it should be named "priviledgedGetOverridable" then.
Ah yes. My mistake.
Small spelling nit: there's no "d" before "g", so this should likely be
privilegedGetOverridable
public static Collector collectingAndThen(
Collector downstream,
Function finisher);
public static Collector collectingAndThen(
Collector downstream1,
Collector
Hi Jaikiran,
Terribly sorry about this. I completely missed the review request you posted on
this a couple weeks ago now.
Comments below.
Returns a fixed-size list backed by the specified array.
OK. Same as the original. :-)
The passed array is held as a reference in the returned list.
57 matches
Mail list logo
