Re: Filing Bugs Against the Core Libs

On 30/08/2016 1:25 PM, Russ Harmon wrote: On Mon, Aug 29, 2016 at 7:27 PM David Holmes mailto:david.hol...@oracle.com>> wrote: Hi Russ, On 26/08/2016 5:39 AM, Russ Harmon wrote: > Hello, > > I'd like to report a (minor) feature request / bug in the core libs. What's

RE: RFR: 8164982 Fix legal notices in java/lang, java/net, java/util tests.

Hi, Shura. > Webrev: http://cr.openjdk.java.net/~shurailine/8164982/webrev.00/ The problem noted in [3] is not present in the latest webrev. The changes look fine with me. Thanks, iris -Original Message- From: Alexandre (Shura) Iline Sent: Monday, August 29, 2016 3:16 PM To: core-libs

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

On 8/29/2016 20:18, Alan Bateman wrote: FilePermCompat is a ugly, particularly FilePermission changing its public fields. Do you prefer the traditional SharedSecrets way? SharedSecrets.setJavaIoFilePermissionAccess( new JavaIoFilePermissionAccessImpl()); Also method names like

Re: Filing Bugs Against the Core Libs

Hi Russ, On 26/08/2016 5:39 AM, Russ Harmon wrote: Hello, I'd like to report a (minor) feature request / bug in the core libs. What's the best way for me to do that? Brian already gave you the general answer, but in this case one of your colleagues at Google, Martin Buccholz, is one of the p

RFR 9: JEP 290: Filter Incoming Serialization Data

  Include original message A quick thought on the array size filter: The system creates an array with a size read from the stream. If Mallory sends a multidimensional array in the stream, then Mallory can consume all jvm memory without exceeding the array size limit or the stream data limit.

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

Hi Steve, > On Aug 29, 2016, at 12:43 PM, Steve Drach wrote: > > Hi, > > Please review the following two changesets that enables jdeps to use > multi-release jar files. The output from the tool shows versioned > dependencies by prefixing them with “version #/“ where version # is 9, 10, > et

Re: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain

> On 29 Aug 2016, at 15:32, Martin Buchholz wrote: > > We had already agreed on making these changes, and the detail looks good, so > approved! > Thanks. > but ... I wish there was less confusion ... maybe it's unavoidable ... I'm > going to check the docs carefully every time I use one of

Re: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain

We had already agreed on making these changes, and the detail looks good, so approved! but ... I wish there was less confusion ... maybe it's unavoidable ... I'm going to check the docs carefully every time I use one of these APIs! ... feel free to ignore rambling: I am having second thoughts ab

RFR: 8164982 Fix legal notices in java/lang, java/net, java/util tests.

Hi. Webrev: http://cr.openjdk.java.net/~shurailine/8164982/webrev.00/ This was previously reviewed as part of [1]. The script for generating these changes is in process of being fixed. Meanwhile, I suggest to start integrating portions of the work. The tests included in this fix have already b

Re: RFR (JAXB): 8159240: XSOM parser incorrectly processes type names with whitespaces

Hi Aleksej, The patch is fine. As we discussed, it's too bad the case [number]s were not universally unique in identifying the types (that makes it hard for the code maintenance), otherwise we would have been able to consolidate the collapse calls by types. We can live with the code as is, b

Re: RFR: 6543126: Level.known can leak memory

> On Aug 29, 2016, at 6:10 AM, Daniel Fuchs wrote: > > Here is a new webrev that uses ClassLoaderValue as Peter suggested. > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.04/ > Looks good in general. 553 // KnowLevelCLV is used to register custom level instances with t

RFR: 8153654: Update jdeps to be multi-release jar aware

Hi, Please review the following two changesets that enables jdeps to use multi-release jar files. The output from the tool shows versioned dependencies by prefixing them with “version #/“ where version # is 9, 10, etc. webrevs: http://cr.openjdk.java.net/~sdrach/8153654/webrev.08/

RFR: 8162431: CatalogUriResolver with circular/self referencing catalog file is not throwing CatalogException as expected.

Hi, Please review a patch that fixes an issue where circular references were not caught if catalogs are pre-loaded. Note that to trigger the issue (circular references), the Catalog must be instructed to load additional catalogs. This can be done by either setting DEFER to false, or providing

Re: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code

Hello! > this is a bit subtle, but there's a special restriction on the jrtfs > code to only use 8-compatible APIs to be able to produce the jrt-fs.jar > that can be used on JDK 8 to interact with Java 9 runtime images. > Ah, I see. Thank you for explanation. With best regards, Tagir Valeev.

Re: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code

Hi, On 2016-08-29 21:01, Tagir Valeev wrote: Hello! (2) to use Collections.singleton() as Claes suggested. It appears the "singleton set" is better choice (light) in this case. Btw why not new-and-cool Set.of() ? http://download.java.net/java/jdk9/docs/api/java/util/Set.html#of-E- this i

Re: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code

Hello! > (2) to use Collections.singleton() as Claes suggested. It appears the "singleton set" is > better choice (light) in this case. Btw why not new-and-cool Set.of() ? http://download.java.net/java/jdk9/docs/api/java/util/Set.html#of-E- With best regards, Tagir Valeev.

Re: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions

Hi Stefan, If you are using the built-in extension functions, try turning on the following feature: private static final String ENABLE_EXTENSION_FUNCTIONS = "http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions";; tf.setFeature(ENABLE_EXTENSION_FUNCTIONS, true); If you a

RFR: 8164858: Enable build-time use of java.lang.invoke resolve tracing

Hi, this patch adds generation of a trace of resolved java.lang.invoke classes when generating the classlist, and uses this trace as input when linking the runtime images. Bug: https://bugs.openjdk.java.net/browse/JDK-8164858 Webrevs: http://cr.openjdk.java.net/~redestad/8164858/top.01/ http://

Re: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code

On 29/08/2016 17:26, Xueming Shen wrote: Hi Webrev has been updated accordingly http://cr.openjdk.java.net/~sherman/8066577/webrev/ (1) the iterator is to synchronize on JrtDirectoryStream.this (2) to use Collections.singleton() as Claes suggested. It appears the "singleton set" is

Re: Filing Bugs Against the Core Libs

Hello, You can report issues via [1] or if you have a Java Bug System ID via [2]. Brian [1] http://bugs.java.com/ [2] https://bugs.openjdk.java.net/secure/Dashboard.jspa On Aug 25, 2016, at 12:39 PM, Russ Harmon wrote: > Hello, > > I'd like to report a (minor) feature request / bug in the co

Re: RFR 8164691 Stream specification clarifications for iterate and collect

Hello! Changes look ok to me, thanks. With best regards, Tagir Valeev. On Mon, Aug 29, 2016 at 8:04 PM, Paul Sandoz wrote: > Thanks, updated in place, > Paul. > > > On 26 Aug 2016, at 17:20, Stuart Marks wrote: > > > > Hi Paul, > > > > Overall looks good. > > > > A couple minor wording commen

Re: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code

> On 29 Aug 2016, at 09:26, Xueming Shen wrote: > > On 8/27/16 12:57 AM, Alan Bateman wrote: >> On 26/08/2016 17:48, Xueming Shen wrote: >> >>> Hi, >>> >>> This is a aged rfe from Paul's code review comments for the old code. base. >>> The >>> implementation has been changed lots since. Some

Re: RFR 8164691 Stream specification clarifications for iterate and collect

Thanks, updated in place, Paul. > On 26 Aug 2016, at 17:20, Stuart Marks wrote: > > Hi Paul, > > Overall looks good. > > A couple minor wording comments. For the 3-arg collectors, the combiner arg > is defined as > > * @param combiner an href="package-summary.html#Associativity">associative

Re: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code

On 8/27/16 12:57 AM, Alan Bateman wrote: On 26/08/2016 17:48, Xueming Shen wrote: Hi, This is a aged rfe from Paul's code review comments for the old code. base. The implementation has been changed lots since. Some has gone, some has been updated accordingly. Just went through the list and

Filing Bugs Against the Core Libs

Hello, I'd like to report a (minor) feature request / bug in the core libs. What's the best way for me to do that? I recently ran into this stack trace . It's not very useful to me, since I can't determine from either the messag

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

Hi Alan I am glad you think this change is useful. As for the 3-value property, in my opinion even the absolute <=> relative translation might not be really useful in a production environment. Who can guarantee a program is always launched from a certain directory and access a file using a re

Re: RFR: 6543126: Level.known can leak memory

Hi Peter, Mandy, On 20/08/16 21:17, Mandy Chung wrote: It is a good observation. Pinning on a class loader is a good solution. On the other hand, the Level API isn’t well designed for customization (so does LogManager or Logger) that should be re-examined at some point in the future (which i

Re: RFR: JDK-8161000 - GPL header incorrect - classfile/classpath

+1 -Sundar On 8/29/2016 5:46 PM, Jim Laskey (Oracle) wrote: > On behalf of Swamy > > http://cr.openjdk.java.net/~jlaskey/8161000/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8161000

Re: RFR 8164705: Remove pathname canonicalization from FilePermission

On 25/08/2016 04:55, Weijun Wang wrote: Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8164705/webrev.00 From the beginning of JDK, FilePermission canonicalizes the input path and use the result in implies() and equals(). This has been a big performance hurt and leads to

RFR: JDK-8161000 - GPL header incorrect - classfile/classpath

On behalf of Swamy http://cr.openjdk.java.net/~jlaskey/8161000/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8161000

Re: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame

Hi David, I still do not understand why you think you need to make any changes in libjli ?? Certainly I do not think you should be printing anything about exceptions. Thanks, David H. On 26/08/2016 9:55 PM, David Simms wrote: Hi David, Updated webrev: http://cr.openjdk.java.net/~dsimms/816