Re: Fwd: Files.walk() is unusable because of AccessDeniedException

Good morning, well I would like to be able to manage the outcome of the processing myself and not get an exception in a part where I have no control. For example, I would expect to get an exception when I tried to read a file where I don't have the permission. I would not expect to get an

[9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point

Hello, The previous attempt to fix this one failed in the installer build, as it does not recognize the added macro. I've updated the fix to add extra check for static build (yeah, this is redundant with the real jni_util.h, but effectively avoid the installer build failure).

Re: JDK 9 RFR of JDK-8151904: test/java/lang/StackWalker/VerifyStackTrace.java needs to handle update releases

> On May 19, 2016, at 10:40 PM, Hamlin Li wrote: > > The test currently hardcodes the version number "9". We should build a JDK > with a different release number e.g. 9.1 and checks if this test handles it > properly. > Test run successfully on 9-ea+118,

Re: VarHandles on non-int-sized fields and atomic operations

On 25/05/2016 6:43 AM, David Holmes wrote: On 25/05/2016 5:29 AM, Aleksey Shipilev wrote: On 05/24/2016 05:43 AM, John Rose wrote: On May 23, 2016, at 4:20 PM, Martin Buchholz > wrote: As I said in a previous message, you can implement subword

Re: VarHandles on non-int-sized fields and atomic operations

More high-level observations on low-level operations: We already sort-of have an existing field qualifier for atomic: "volatile" ! It is already the case that e.g. volatile long is atomic while unadorned long is not. But atomics without CAS make us sad, so we're adding them. Also, by analogy,

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

On Tue, May 24, 2016 at 11:49 AM, Alan Bateman wrote: > Yeah, the context isn't clear here. This is all related to the HotSpot CDS > feature and so very tied to the built-in class loaders. File paths are > recorded at -Xshare:dump time and checked at -Xshare:on time. Too

Re: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math

Hi Brian, Pushed with typo corrects; thanks, -Joe On 5/24/2016 1:47 PM, Brian Burkhalter wrote: Hi Joe, In the new version of BigDecimal at line 3586: “as defined” -> “as defined in”. Otherwise +1. Thanks, Brian On May 24, 2016, at 12:27 PM, joe darcy

Re: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math

Hi Joe, In the new version of BigDecimal at line 3586: “as defined” -> “as defined in”. Otherwise +1. Thanks, Brian On May 24, 2016, at 12:27 PM, joe darcy wrote: > We don't apply a policy consistently, but I did another pass on BigDecimal > and BigInteger to be more

Re: VarHandles on non-int-sized fields and atomic operations

On 25/05/2016 5:29 AM, Aleksey Shipilev wrote: On 05/24/2016 05:43 AM, John Rose wrote: On May 23, 2016, at 4:20 PM, Martin Buchholz > wrote: As I said in a previous message, you can implement subword CAS using fullword CAS in a loop.

Re: Files.walk() is unusable because of AccessDeniedException

On 24/05/2016 20:52, e...@zusammenkunft.net wrote: The AccessDeniedExceptions are not a java security mechanism. It is a OS mechanism and i think it is good that java reveals all information also available with native access (i.e. if you have no 'x' permission on a dir you cannot enter it

Re: VarHandles on non-int-sized fields and atomic operations

> On 24 May 2016, at 21:29, Aleksey Shipilev > wrote: > > On 05/24/2016 05:43 AM, John Rose wrote: >> On May 23, 2016, at 4:20 PM, Martin Buchholz > > wrote: >>> >>> As I said in a previous message, you can

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Hi Martin, Thanks for the review. > On May 24, 2016, at 10:57 AM, Martin Buchholz wrote: > > English syntax error. > > + * Attempts to convert to the given string to a file URL. > Will fix. > --- > > There should be some motivation for why you are calling

RE: Files.walk() is unusable because of AccessDeniedException

The AccessDeniedExceptions are not a java security mechanism. It is a OS mechanism and i think it is good that java reveals all information also available with native access (i.e. if you have no 'x' permission on a dir you cannot enter it but you can see it (as long asmyou have read permission

Re: VarHandles on non-int-sized fields and atomic operations

On 05/24/2016 05:43 AM, John Rose wrote: > On May 23, 2016, at 4:20 PM, Martin Buchholz > wrote: >> >> As I said in a previous message, you can implement subword CAS using >> fullword CAS in a loop. >> >> cas8bit(expect, update) { >> for (;;) {

Re: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math

Hi Brian, We don't apply a policy consistently, but I did another pass on BigDecimal and BigInteger to be more consistent: http://cr.openjdk.java.net/~darcy/8157724.1 This also includes an additional @jls tag in BigInteger to the arithmetic operations in JLS and a @see from BigDecimal's

Re: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math

Hi Joe, Yes, that is useful. I had not recalled seeing the emphasis tag before so I was curious as to the policy. Thanks, Brian On May 24, 2016, at 11:59 AM, joe darcy wrote: > As I understand it, if one is being pedantic about HTML tags, "" is more > of a semantic tag

Re: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math

Hi Brian, As I understand it, if one is being pedantic about HTML tags, "" is more of a semantic tag while "" is purely typographical so there are cases where "" should not be replaced by "". HTH, -Joe On 5/24/2016 11:44 AM, Brian Burkhalter wrote: Hi Joe, At new line 1902 and

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

On 24/05/2016 18:57, Martin Buchholz wrote: English syntax error. + * Attempts to convert to the given string to a file URL. --- There should be some motivation for why you are calling toRealPath, and e.g. not toAbsolutePath. What problem are you trying to solve? At Google we have

Re: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math

Hi Joe, At new line 1902 and elsewhere, is preferable to in general? (Not a question pertaining only to this change.) +1 Brian On May 24, 2016, at 11:28 AM, joe darcy wrote: > The javadoc of the java.math package has various locations where the @jls, > @apiNote,

Re: JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math

Hi Joe, The changes look reasonable Best Lance > On May 24, 2016, at 2:28 PM, joe darcy wrote: > > Hello, > > The javadoc of the java.math package has various locations where the @jls, > @apiNote, etc. javadoc tags could be used. Those tags should be used as >

RE: Fwd: Files.walk() is unusable because of AccessDeniedException

Hi, The API documentation makes the point that if there is a security manager installed which denies access to some entries amongst the visited files and directories then those entries are silently skipped, their presence not being disclosed by the walk terminating early due to an access

JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math

Hello, The javadoc of the java.math package has various locations where the @jls, @apiNote, etc. javadoc tags could be used. Those tags should be used as appropriate. Please review the webrev below which makes those updates along with some typo fixes:

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

English syntax error. + * Attempts to convert to the given string to a file URL. --- There should be some motivation for why you are calling toRealPath, and e.g. not toAbsolutePath. What problem are you trying to solve? At Google we have special needs - this is the kind of change we end up

RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Hi, Please review the following webrev that changes the jdk.internal.loader.ClassLoaders.addURLToUCP() to java.internal.loader.ClassLoaders.toFileURL(). The change is provided by Alan (thanks, Alan!). webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.00/ but:

Re: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec

Hi Roger, > On 24 May 2016, at 15:36, Roger Riggs wrote: > > To keep it simple and clean, the change from @exception to @throws is not > needed > and reduces the number of files changed. That's what the change is all about. I was thinking about it a year ago:

Re: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec

Hi Pavel, To keep it simple and clean, the change from @exception to @throws is not needed and reduces the number of files changed. The change in the parameter name is a bit unusual, typically they are not changed but in this case the change is needed to make parameter name consistent with

Re: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec

Thanks for looking at this! > On 24 May 2016, at 15:16, Aleksey Shipilev > wrote: > > *) CharArrayReader: code changes What's your concern with 'b'->'buf' rename? Access parameter's name through reflection or something else? > *) It's weird to see @exception and

Re: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec

On 05/24/2016 05:08 PM, Pavel Rappo wrote: > Could you please review a trivial change for JDK-8157677? > >http://cr.openjdk.java.net/~prappo/8157677/webrev.00/ *) CharArrayReader: code changes *) It's weird to see @exception and @throws side-by-side: * @exception IOException If

8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec

Hi, Could you please review a trivial change for JDK-8157677? http://cr.openjdk.java.net/~prappo/8157677/webrev.00/ http://cr.openjdk.java.net/~prappo/8157677/specdiff.00/overview-summary.html Thanks, -Pavel

Re: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST

Thanks, Naufal - I'll take a look and let you & Paul know when it's processed. cheers, dalibor topic On 23.05.2016 12:53, Mohamed Naufal wrote: Hi Paul, I've already sent a signed copy of the OCA to oracle-ca...@oracle.com. Thanks, Naufal On 23 May 2016 at 16:13, Paul Sandoz

Re: RFR[9]: 8156868 MethodHandles.zero(Class) doc issues

> On 24 May 2016, at 08:40, shilpi.rast...@oracle.com wrote: > > Thanks Paul!! > > Please see http://cr.openjdk.java.net/~srastogi/8156868/webrev.02/ > +1 Paul.

Re: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05

> On 24 May 2016, at 01:03, Martin Buchholz wrote: > > On Mon, May 23, 2016 at 3:29 PM, Aleksey Shipilev > wrote: >> On 05/23/2016 11:32 PM, Martin Buchholz wrote: >>> JSR166 CVS has some unfinished work in progress, but enough minor >>>

Re: VarHandles on non-int-sized fields and atomic operations

> On 24 May 2016, at 08:50, David Holmes wrote: > My only problem with VarHandles is that I can't see anything that defines > when the various AccessModes are unsupported. ?? > Each producer of a VarHandle (factory method) specifies the supported access modes. The

Re: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05

> On 23 May 2016, at 21:32, Martin Buchholz wrote: > > JSR166 CVS has some unfinished work in progress, but enough minor > changes have accumulated that we should integrate into openjdk9: > >

Re: Fwd: Files.walk() is unusable because of AccessDeniedException

On 05/20/2016 10:38 AM, Gilles Habran wrote: > why is my message still waiting for approval after a month ? What is it you want Java to do? You can't walk the directory because you don't have permission. sudo should work. Andrew.

Re: VarHandles on non-int-sized fields and atomic operations

> On 24 May 2016, at 02:55, Martin Buchholz wrote: > > Another way to look at it: We have an existing field > > boolean closed; > > which should be updated using CAS for correctness, but currently is not. > I should not have to change the type of the field to int just so

Re: VarHandles on non-int-sized fields and atomic operations

Expansion ... On 24/05/2016 4:50 PM, David Holmes wrote: On 24/05/2016 9:20 AM, Martin Buchholz wrote: On Mon, May 23, 2016 at 3:48 PM, Aleksey Shipilev wrote: By the way, what exactly are you winning with 1-byte field in AtomicBoolean? I'm not trying to

Re: VarHandles on non-int-sized fields and atomic operations

On 24/05/2016 9:20 AM, Martin Buchholz wrote: On Mon, May 23, 2016 at 3:48 PM, Aleksey Shipilev wrote: By the way, what exactly are you winning with 1-byte field in AtomicBoolean? I'm not trying to replace the int field inside the AtomicBoolean with a boolean -

Re: RFR[9]: 8156868 MethodHandles.zero(Class) doc issues

Thanks Paul!! Please see http://cr.openjdk.java.net/~srastogi/8156868/webrev.02/ On 5/23/2016 9:08 PM, Paul Sandoz wrote: On 23 May 2016, at 08:27, shilpi.rast...@oracle.com wrote: Hi All, Please review small doc changes- http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/ Fixed

Re: JDK 9 RFR of JDK-8151768: Consider moving pack200 tests to tier 1

Looks fine Amy; thanks, -Joe On 5/23/2016 11:10 PM, Amy Lu wrote: Currently tools/pack200 tests are defined to be part of tier 2 testing. The pack200 tests have a history of finding VM issue and they are good candidates for tier 1 testing, in which trying to cover VM-related functionality.

JDK 9 RFR of JDK-8151768: Consider moving pack200 tests to tier 1

Currently tools/pack200 tests are defined to be part of tier 2 testing. The pack200 tests have a history of finding VM issue and they are good candidates for tier 1 testing, in which trying to cover VM-related functionality. This patch is to move tools/pack200 tests from tier2 to tier1. bug: