From Lari at Hotari.net  Sat Apr 11 14:23:06 2015
From: Lari at Hotari.net (Lari Hotari)
Date: Sat, 11 Apr 2015 10:23:06 -0400
Subject: Any native WatchService implementation planned on Mac OS X for
	JDK9?
In-Reply-To: <53E52739.9090506@oracle.com>
References: <53E52739.9090506@oracle.com>
Message-ID: <55292E4A.8060206@hotari.net>

> There isn't anything to test, it just hasn't bubbled up to the top of
> anyone's list. We definitely need to get to it at some point as isn't
> good for the OS X port to be using the polling implementation.
>
> -Alan.

What's the current status of
https://bugs.openjdk.java.net/browse/JDK-7133447 ?
It's pretty disappointing that WatchService doesn't have a native
implementation on Mac OS X.
Is it going to make it to JDK9 GA?

-Lari
https://twitter.com/@lhotari

From fgaliegue at gmail.com  Tue Apr 14 12:36:47 2015
From: fgaliegue at gmail.com (Francis Galiegue)
Date: Tue, 14 Apr 2015 14:36:47 +0200
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
Message-ID: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>

My recall is that at some point this flag was supported by the fs
provider but now the page seems to have changed:

http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemproviderprops.html

Did I misread the documentation completely and it was never supported?

-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

From christopherbrown06 at gmail.com  Wed Apr 15 19:49:05 2015
From: christopherbrown06 at gmail.com (Christopher Brown)
Date: Wed, 15 Apr 2015 21:49:05 +0200
Subject: Any native WatchService implementation planned on Mac OS X for
	JDK9?
In-Reply-To: <55292E4A.8060206@hotari.net>
References: <53E52739.9090506@oracle.com> <55292E4A.8060206@hotari.net>
Message-ID: <CAN_qnoOGeMkkjQ9fg-+9rD03OU=mdb-U0m8MBp+DjTrFtmDLYA@mail.gmail.com>

Hello,

I'm still interested in this too.  Will it bubble up soon, in time for JDK9
GA for example?

Thanks,
Christopher


On 11 April 2015 at 16:23, Lari Hotari <Lari at hotari.net> wrote:

> > There isn't anything to test, it just hasn't bubbled up to the top of
> > anyone's list. We definitely need to get to it at some point as isn't
> > good for the OS X port to be using the polling implementation.
> >
> > -Alan.
>
> What's the current status of
> https://bugs.openjdk.java.net/browse/JDK-7133447 ?
> It's pretty disappointing that WatchService doesn't have a native
> implementation on Mac OS X.
> Is it going to make it to JDK9 GA?
>
> -Lari
> https://twitter.com/@lhotari
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150415/9386c493/attachment.html>

From Alan.Bateman at oracle.com  Fri Apr 17 13:20:07 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 Apr 2015 14:20:07 +0100
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
In-Reply-To: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>
References: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>
Message-ID: <55310887.8050708@oracle.com>

On 14/04/2015 13:36, Francis Galiegue wrote:
> My recall is that at some point this flag was supported by the fs
> provider but now the page seems to have changed:
>
> http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemproviderprops.html
>
> Did I misread the documentation completely and it was never supported?
>
"create" and "encoding" have been the two documented property names, I 
don't ever recall having "readonly". Sherman - do you remember anything 
on this?

The zip provider just tests if the zip file is writable and if so then 
newFileSystem creates a writeable file system. If the zip file is not 
writable (or it can't be determined) then newFileSystem creates a 
read-only file system.

-Alan

From fgaliegue at gmail.com  Fri Apr 17 15:24:50 2015
From: fgaliegue at gmail.com (Francis Galiegue)
Date: Fri, 17 Apr 2015 17:24:50 +0200
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
In-Reply-To: <55310887.8050708@oracle.com>
References: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>
	<55310887.8050708@oracle.com>
Message-ID: <CALcybBD-WZhO44S+6HP1t8Tf=AR4Pez35XQXc0OJ8OzyVT5ZcA@mail.gmail.com>

Hello,

On Fri, Apr 17, 2015 at 3:20 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 14/04/2015 13:36, Francis Galiegue wrote:
>>
>> My recall is that at some point this flag was supported by the fs
>> provider but now the page seems to have changed:
>>
>>
>> http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemproviderprops.html
>>
>> Did I misread the documentation completely and it was never supported?
>>
> "create" and "encoding" have been the two documented property names, I don't
> ever recall having "readonly". Sherman - do you remember anything on this?
>
> The zip provider just tests if the zip file is writable and if so then
> newFileSystem creates a writeable file system. If the zip file is not
> writable (or it can't be determined) then newFileSystem creates a read-only
> file system.
>

OK... But I believe it would be a nice option to have. Would such a
feature request be considered at all?

Regards,
-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

From xueming.shen at oracle.com  Fri Apr 17 15:27:38 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 17 Apr 2015 08:27:38 -0700
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
In-Reply-To: <55310887.8050708@oracle.com>
References: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>
	<55310887.8050708@oracle.com>
Message-ID: <5531266A.30504@oracle.com>

On 4/17/15 6:20 AM, Alan Bateman wrote:
> On 14/04/2015 13:36, Francis Galiegue wrote:
>> My recall is that at some point this flag was supported by the fs
>> provider but now the page seems to have changed:
>>
>> http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemproviderprops.html 
>>
>>
>> Did I misread the documentation completely and it was never supported?
>>
> "create" and "encoding" have been the two documented property names, I 
> don't ever recall having "readonly". Sherman - do you remember 
> anything on this?
>
> The zip provider just tests if the zip file is writable and if so then 
> newFileSystem creates a writeable file system. If the zip file is not 
> writable (or it can't be determined) then newFileSystem creates a 
> read-only file system.
>
> -Alan

There is a "readonly" flag field, which is set if the zip file itself is 
a readly only file.

-Sherman

From brian.burkhalter at oracle.com  Tue Apr 21 00:33:05 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 20 Apr 2015 17:33:05 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
Message-ID: <78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>

Reprising this thread:

http://mail.openjdk.java.net/pipermail/nio-dev/2015-March/003074.html

I have an updated patch for review when convenient:

http://cr.openjdk.java.net/~bpb/8065556/webrev.03/

I hope that it adequately addresses the points that were raised in the discussion. I am not sure about Buffer.srcEqualsThisBufferException() ?

Thanks,

Brian

From Alan.Bateman at oracle.com  Tue Apr 21 16:10:43 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Apr 2015 17:10:43 +0100
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
Message-ID: <55367683.5050409@oracle.com>

On 21/04/2015 01:33, Brian Burkhalter wrote:
> Reprising this thread:
>
> http://mail.openjdk.java.net/pipermail/nio-dev/2015-March/003074.html
>
> I have an updated patch for review when convenient:
>
> http://cr.openjdk.java.net/~bpb/8065556/webrev.03/
>
> I hope that it adequately addresses the points that were raised in the discussion. I am not sure about Buffer.srcEqualsThisBufferException() ?
Would it be cleaner to rename of these to something like failXXXX 
(failNegativeCapacity or failPositionOutOfBounds for example) that 
throws the exception rather than returns it. That would reduce the 
method names a bit too.

What is the issue with srcEqualsThisBufferException? That scenario is 
specified to throw IAE.

Extending the test coverage for this case is good. If you can then keep 
the line length consistent with the rest of the test.

-Alan.







From Alan.Bateman at oracle.com  Tue Apr 21 16:12:43 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Apr 2015 17:12:43 +0100
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
In-Reply-To: <CALcybBD-WZhO44S+6HP1t8Tf=AR4Pez35XQXc0OJ8OzyVT5ZcA@mail.gmail.com>
References: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>	<55310887.8050708@oracle.com>
	<CALcybBD-WZhO44S+6HP1t8Tf=AR4Pez35XQXc0OJ8OzyVT5ZcA@mail.gmail.com>
Message-ID: <553676FB.1040701@oracle.com>

On 17/04/2015 16:24, Francis Galiegue wrote:
> :
> OK... But I believe it would be a nice option to have. Would such a
> feature request be considered at all?
>
No objection but I wonder if it is would be used. Are you looking for 
this specifically for the zip provider or thinking about an equivalent 
with another provider?

-Alan

From fgaliegue at gmail.com  Tue Apr 21 16:26:24 2015
From: fgaliegue at gmail.com (Francis Galiegue)
Date: Tue, 21 Apr 2015 18:26:24 +0200
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
In-Reply-To: <553676FB.1040701@oracle.com>
References: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>
	<55310887.8050708@oracle.com>
	<CALcybBD-WZhO44S+6HP1t8Tf=AR4Pez35XQXc0OJ8OzyVT5ZcA@mail.gmail.com>
	<553676FB.1040701@oracle.com>
Message-ID: <CALcybBA35pycesrHWHrreyP7H4yEyH9H0h0r+mLbdzwN2h0+JA@mail.gmail.com>

On Tue, Apr 21, 2015 at 6:12 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 17/04/2015 16:24, Francis Galiegue wrote:
>>
>> :
>> OK... But I believe it would be a nice option to have. Would such a
>> feature request be considered at all?
>>
> No objection but I wonder if it is would be used. Are you looking for this
> specifically for the zip provider or thinking about an equivalent with
> another provider?
>

That is a good question... And which I believe is somewhat related to
the usage of JSR 203 today. And that is still, unfortunately, very
little.

And I am certainly not a "guinea pig" for a casual user since I
implemented a couple of FileSystems myself. Anyway, in this package
(https://github.com/fge/java7-fs-more), I have implemented a
MoreFileSystems.openZip(path, boolean), which, if the second argument
is true ("read only, please"), wraps the JRE provided
FileSystemProvider and FileSystem with "read only" versions (that is,
throw ReadOnlyFileSystemException on any write attempt).

Notwithstanding the "shortcuts" made available (that is: open a
FileSystem over the zip; then wrap it read only if requested), I
believe it would be a nice addition to the standard API to provide a
way to do this, as in:

FileSystems.newReadOnlyFileSystem(uri, env)

or the like.

-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

From brian.burkhalter at oracle.com  Tue Apr 21 16:47:11 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Apr 2015 09:47:11 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <55367683.5050409@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
	<55367683.5050409@oracle.com>
Message-ID: <4208F41D-E624-47FF-A123-46705DF84349@oracle.com>


On Apr 21, 2015, at 9:10 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Would it be cleaner to rename of these to something like failXXXX (failNegativeCapacity or failPositionOutOfBounds for example) that throws the exception rather than returns it. That would reduce the method names a bit too.

Sounds like a good idea.

> What is the issue with srcEqualsThisBufferException? That scenario is specified to throw IAE.

It was more a matter of its relative importance in the cold vs. hot code dichotomy as this methods does not perform String construction. It does make things uniform at least.

> Extending the test coverage for this case is good. If you can then keep the line length consistent with the rest of the test.

Good idea, also.

I?ll work on this and post another patch when ready.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150421/f99e615e/attachment.html>

From vitalyd at gmail.com  Tue Apr 21 18:20:21 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 21 Apr 2015 14:20:21 -0400
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <55367683.5050409@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
	<55367683.5050409@oracle.com>
Message-ID: <CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>

>
> Would it be cleaner to rename of these to something like failXXXX
> (failNegativeCapacity or failPositionOutOfBounds for example) that throws
> the exception rather than returns it. That would reduce the method names a
> bit too.


Martin mentioned this bug earlier in this thread:
https://bugs.openjdk.java.net/browse/JDK-6533165

On Tue, Apr 21, 2015 at 12:10 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 21/04/2015 01:33, Brian Burkhalter wrote:
>
>> Reprising this thread:
>>
>> http://mail.openjdk.java.net/pipermail/nio-dev/2015-March/003074.html
>>
>> I have an updated patch for review when convenient:
>>
>> http://cr.openjdk.java.net/~bpb/8065556/webrev.03/
>>
>> I hope that it adequately addresses the points that were raised in the
>> discussion. I am not sure about Buffer.srcEqualsThisBufferException() ?
>>
> Would it be cleaner to rename of these to something like failXXXX
> (failNegativeCapacity or failPositionOutOfBounds for example) that throws
> the exception rather than returns it. That would reduce the method names a
> bit too.
>
> What is the issue with srcEqualsThisBufferException? That scenario is
> specified to throw IAE.
>
> Extending the test coverage for this case is good. If you can then keep
> the line length consistent with the rest of the test.
>
> -Alan.
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150421/4b1e91fc/attachment-0001.html>

From brian.burkhalter at oracle.com  Tue Apr 21 18:23:52 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Apr 2015 11:23:52 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
	<55367683.5050409@oracle.com>
	<CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>
Message-ID: <05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>


On Apr 21, 2015, at 11:20 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Would it be cleaner to rename of these to something like failXXXX (failNegativeCapacity or failPositionOutOfBounds for example) that throws the exception rather than returns it. That would reduce the method names a bit too.
> 
> Martin mentioned this bug earlier in this thread:https://bugs.openjdk.java.net/browse/JDK-6533165

Thanks, Vitaly. I saw that. My response was intended to change the names for consistency only, not to change that the method only returned the exception. Sorry I was unclear.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150421/0a6fe066/attachment.html>

From brian.burkhalter at oracle.com  Tue Apr 21 19:36:36 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Apr 2015 12:36:36 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
	<55367683.5050409@oracle.com>
	<CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>
	<05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>
Message-ID: <4E61739E-9922-4EBA-BB61-EF0375ABEB31@oracle.com>


On Apr 21, 2015, at 11:23 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> On Apr 21, 2015, at 11:20 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
>> Would it be cleaner to rename of these to something like failXXXX (failNegativeCapacity or failPositionOutOfBounds for example) that throws the exception rather than returns it. That would reduce the method names a bit too.
>> 
>> Martin mentioned this bug earlier in this thread:https://bugs.openjdk.java.net/browse/JDK-6533165
> 
> Thanks, Vitaly. I saw that. My response was intended to change the names for consistency only, not to change that the method only returned the exception. Sorry I was unclear.

To re-clarify, given the issue that Vitaly and previously Martin referred to, I think that if name consistency were desirable then something like createXXXException() (createNegativeCapacityException() or createPositionOutOfBoundsException() for example) with the throw statement remaining in the caller would be more appropriate.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150421/aadab9ab/attachment.html>

From martinrb at google.com  Tue Apr 21 20:17:46 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 21 Apr 2015 13:17:46 -0700
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
In-Reply-To: <CALcybBA35pycesrHWHrreyP7H4yEyH9H0h0r+mLbdzwN2h0+JA@mail.gmail.com>
References: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>
	<55310887.8050708@oracle.com>
	<CALcybBD-WZhO44S+6HP1t8Tf=AR4Pez35XQXc0OJ8OzyVT5ZcA@mail.gmail.com>
	<553676FB.1040701@oracle.com>
	<CALcybBA35pycesrHWHrreyP7H4yEyH9H0h0r+mLbdzwN2h0+JA@mail.gmail.com>
Message-ID: <CA+kOe08QNpr5mKnn1kk+KiHyQ0CZm0a-kJdauUCavVX8Z-JSMg@mail.gmail.com>

It seems "obvious" that file system implementations should have options for
read-only access, mirroring the readonly options from mount(8).

For existing zip files, one almost always wants to open them read-only.
New zip files are almost always rewritten from scratch.

On Tue, Apr 21, 2015 at 9:26 AM, Francis Galiegue <fgaliegue at gmail.com>
wrote:

> On Tue, Apr 21, 2015 at 6:12 PM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> > On 17/04/2015 16:24, Francis Galiegue wrote:
> >>
> >> :
> >> OK... But I believe it would be a nice option to have. Would such a
> >> feature request be considered at all?
> >>
> > No objection but I wonder if it is would be used. Are you looking for
> this
> > specifically for the zip provider or thinking about an equivalent with
> > another provider?
> >
>
> That is a good question... And which I believe is somewhat related to
> the usage of JSR 203 today. And that is still, unfortunately, very
> little.
>
> And I am certainly not a "guinea pig" for a casual user since I
> implemented a couple of FileSystems myself. Anyway, in this package
> (https://github.com/fge/java7-fs-more), I have implemented a
> MoreFileSystems.openZip(path, boolean), which, if the second argument
> is true ("read only, please"), wraps the JRE provided
> FileSystemProvider and FileSystem with "read only" versions (that is,
> throw ReadOnlyFileSystemException on any write attempt).
>
> Notwithstanding the "shortcuts" made available (that is: open a
> FileSystem over the zip; then wrap it read only if requested), I
> believe it would be a nice addition to the standard API to provide a
> way to do this, as in:
>
> FileSystems.newReadOnlyFileSystem(uri, env)
>
> or the like.
>
> --
> Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
> JSON Schema in Java: http://json-schema-validator.herokuapp.com
> Parsers in pure Java: https://github.com/fge/grappa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150421/a07ffed3/attachment.html>

From mik3hall at gmail.com  Tue Apr 21 20:22:01 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 21 Apr 2015 15:22:01 -0500
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
In-Reply-To: <CA+kOe08QNpr5mKnn1kk+KiHyQ0CZm0a-kJdauUCavVX8Z-JSMg@mail.gmail.com>
References: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>
	<55310887.8050708@oracle.com>
	<CALcybBD-WZhO44S+6HP1t8Tf=AR4Pez35XQXc0OJ8OzyVT5ZcA@mail.gmail.com>
	<553676FB.1040701@oracle.com>
	<CALcybBA35pycesrHWHrreyP7H4yEyH9H0h0r+mLbdzwN2h0+JA@mail.gmail.com>
	<CA+kOe08QNpr5mKnn1kk+KiHyQ0CZm0a-kJdauUCavVX8Z-JSMg@mail.gmail.com>
Message-ID: <B7B315BF-00E3-4868-B4B7-0FAE22A1C18F@gmail.com>

On Apr 21, 2015, at 3:17 PM, Martin Buchholz <martinrb at google.com> wrote:

> It seems "obvious" that file system implementations should have options for read-only access, mirroring the readonly options from mount(8).
> 
> For existing zip files, one almost always wants to open them read-only.  New zip files are almost always rewritten from scratch.

But you?re not talking about a static zip file you are talking about a zip FileSystem. What?s the point of using FileSystem if there is nothing dynamic going on?

Michael Hall





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150421/a067584b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5262 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150421/a067584b/smime-0001.p7s>

From Alan.Bateman at oracle.com  Tue Apr 21 20:43:10 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Apr 2015 21:43:10 +0100
Subject: Bundled zip FileSystemProvider fails to recognize "readonly"?
In-Reply-To: <CA+kOe08QNpr5mKnn1kk+KiHyQ0CZm0a-kJdauUCavVX8Z-JSMg@mail.gmail.com>
References: <CALcybBD-QJmc81ga9GFc4-HeCCWys-GGticEFJyQK8Py8tqDEw@mail.gmail.com>	<55310887.8050708@oracle.com>	<CALcybBD-WZhO44S+6HP1t8Tf=AR4Pez35XQXc0OJ8OzyVT5ZcA@mail.gmail.com>	<553676FB.1040701@oracle.com>	<CALcybBA35pycesrHWHrreyP7H4yEyH9H0h0r+mLbdzwN2h0+JA@mail.gmail.com>
	<CA+kOe08QNpr5mKnn1kk+KiHyQ0CZm0a-kJdauUCavVX8Z-JSMg@mail.gmail.com>
Message-ID: <5536B65E.1010904@oracle.com>

On 21/04/2015 21:17, Martin Buchholz wrote:
> It seems "obvious" that file system implementations should have 
> options for read-only access, mirroring the readonly options from 
> mount(8).
>
> For existing zip files, one almost always wants to open them 
> read-only.  New zip files are almost always rewritten from scratch.
>
The approximately equivalent to mount options is the env parameters 
specified to the newFileSystem. There aren't any standard options defined.

The zip provider of course can of course create read-only or read-write 
file systems. It decides based on whether whether the zip file is 
writable or not. It would have been better to have it exposed, and would 
be trivial to do of course.

-Alan.

From brian.burkhalter at oracle.com  Tue Apr 21 22:22:48 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Apr 2015 15:22:48 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <4E61739E-9922-4EBA-BB61-EF0375ABEB31@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
	<55367683.5050409@oracle.com>
	<CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>
	<05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>
	<4E61739E-9922-4EBA-BB61-EF0375ABEB31@oracle.com>
Message-ID: <F9496F9A-5A98-4411-8566-19FD15EDCD48@oracle.com>

Another iteration of this patch has been posted at

http://cr.openjdk.java.net/~bpb/8065556/webrev.04/

to be reviewed at your convenience.

Summary:

1) Exception creation methods renamed for consistency to createXYZException().
2) Methods in #1 still create and return an IAE but leave throwing it to the caller.
3) Static methods in #1 moved up below constructors for style consistency.
4) Line lengths adjusted in tests to be within conventional limits.

Thanks,

Brian

On Apr 21, 2015, at 12:36 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> To re-clarify, given the issue that Vitaly and previously Martin referred to, I think that if name consistency were desirable then something like createXXXException() (createNegativeCapacityException() or createPositionOutOfBoundsException() for example) with the throw statement remaining in the caller would be more appropriate.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150421/51d31dab/attachment.html>

From brian.burkhalter at oracle.com  Thu Apr 23 01:16:43 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 22 Apr 2015 18:16:43 -0700
Subject: RFR of 8024086:(fs) AtomicMoveNotSupportedException allows reason to
	be null
Message-ID: <B759187C-E075-45EE-B8AC-F43B5EBE9DCA@oracle.com>

This trivial specification issue does seem to have merit:

Issue:	https://bugs.openjdk.java.net/browse/JDK-8024086
Diff:

--- a/src/java.base/share/classes/java/nio/file/AtomicMoveNotSupportedException.java
+++ b/src/java.base/share/classes/java/nio/file/AtomicMoveNotSupportedException.java
@@ -45,7 +45,7 @@
      * @param   target
      *          a string identifying the target file or {@code null} if not known
      * @param   reason
-     *          a reason message with additional information
+     *          a reason message with additional information or {@code null}
      */
     public AtomicMoveNotSupportedException(String source,
                                            String target,

It?s probably a virtual guarantee however that stating it is ?trivial? will result in a ?no, it?s non-trivial.?

Please review at your convenience. Does not seem that a CCC request would be needed here, does it?

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150422/69540e3d/attachment.html>

From Alan.Bateman at oracle.com  Thu Apr 23 16:28:08 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Apr 2015 17:28:08 +0100
Subject: RFR of 8024086:(fs) AtomicMoveNotSupportedException allows reason
	to be null
In-Reply-To: <B759187C-E075-45EE-B8AC-F43B5EBE9DCA@oracle.com>
References: <B759187C-E075-45EE-B8AC-F43B5EBE9DCA@oracle.com>
Message-ID: <55391D98.9010307@oracle.com>



On 23/04/2015 02:16, Brian Burkhalter wrote:
> This trivial specification issue does seem to have merit:
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8024086
> Diff:
>
> --- 
> a/src/java.base/share/classes/java/nio/file/AtomicMoveNotSupportedException.java
> +++ 
> b/src/java.base/share/classes/java/nio/file/AtomicMoveNotSupportedException.java
> @@ -45,7 +45,7 @@
>     * @param   target
>     *          a string identifying the target file or {@code null} if 
> not known
>     * @param   reason
> -     *          a reason message with additional information
> +     *          a reason message with additional information or 
> {@code null}
>     */
>   public AtomicMoveNotSupportedException(String source,
>                                           String target,
>
> It?s probably a virtual guarantee however that stating it is ?trivial? 
> will result in a ?no, it?s non-trivial.?
>
I think this looks okay. It is technically a spec change (but one that 
matches long standing behavior) so will need to be tracked.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150423/5139e99f/attachment.html>

From Alan.Bateman at oracle.com  Thu Apr 23 16:38:09 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Apr 2015 17:38:09 +0100
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <F9496F9A-5A98-4411-8566-19FD15EDCD48@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>	<55367683.5050409@oracle.com>	<CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>	<05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>	<4E61739E-9922-4EBA-BB61-EF0375ABEB31@oracle.com>
	<F9496F9A-5A98-4411-8566-19FD15EDCD48@oracle.com>
Message-ID: <55391FF1.8000100@oracle.com>



On 21/04/2015 23:22, Brian Burkhalter wrote:
> Another iteration of this patch has been posted at
>
> http://cr.openjdk.java.net/~bpb/8065556/webrev.04/ 
> <http://cr.openjdk.java.net/%7Ebpb/8065556/webrev.04/>
>
> to be reviewed at your convenience.
>
> Summary:
>
> 1) Exception creation methods renamed for consistency to 
> createXYZException().
> 2) Methods in #1 still create and return an IAE but leave throwing it 
> to the caller.
> 3) Static methods in #1 moved up below constructors for style consistency.
> 4) Line lengths adjusted in tests to be within conventional limits.
>
The approach looks okay to me. It would have been interesting to have 
done micro benchmarks to see it matches Martin's observation/bug as that 
was news to me.

In Buffer then it would be nice to reduce the method names a bit so that 
the declarations don't spill over two lines. I realize it's just nit 
picking but it's good to keep the code consistent when you can.

The test update looks okay now.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150423/44232cc6/attachment-0001.html>

From brian.burkhalter at oracle.com  Thu Apr 23 17:12:31 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 23 Apr 2015 10:12:31 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <55391FF1.8000100@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>	<55367683.5050409@oracle.com>	<CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>	<05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>	<4E61739E-9922-4EBA-BB61-EF0375ABEB31@oracle.com>
	<F9496F9A-5A98-4411-8566-19FD15EDCD48@oracle.com>
	<55391FF1.8000100@oracle.com>
Message-ID: <374AE40B-F71F-456C-B165-8E4FDEED3301@oracle.com>


On Apr 23, 2015, at 9:38 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> The approach looks okay to me. It would have been interesting to have done micro benchmarks to see it matches Martin's observation/bug as that was news to me.

I could do that if you like. I need to brush up on JMH anyway as I used a lot during a certain period of time but that?s a while ago now.

> In Buffer then it would be nice to reduce the method names a bit so that the declarations don't spill over two lines. I realize it's just nit picking but it's good to keep the code consistent when you can.

Understood. I?ll see what I can do. I also did not like this sort of style:

    private IllegalArgumentException createSomeException( // indent == 4
            Object someParameter, ?) // indent == 8

> The test update looks okay now.

Good.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150423/1715c58c/attachment.html>

From brian.burkhalter at oracle.com  Thu Apr 23 17:13:19 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 23 Apr 2015 10:13:19 -0700
Subject: RFR of 8024086:(fs) AtomicMoveNotSupportedException allows reason
	to be null
In-Reply-To: <55391D98.9010307@oracle.com>
References: <B759187C-E075-45EE-B8AC-F43B5EBE9DCA@oracle.com>
	<55391D98.9010307@oracle.com>
Message-ID: <E600A7B0-545F-41A8-A8AE-18A26D254E5C@oracle.com>


On Apr 23, 2015, at 9:28 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> I think this looks okay. It is technically a spec change (but one that matches long standing behavior) so will need to be tracked.

I?ll file the CCC request in that case for the sake of completeness.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150423/471933a6/attachment.html>

From alexey.utkin at gmail.com  Thu Apr 23 17:31:18 2015
From: alexey.utkin at gmail.com (Alexey Utkin)
Date: Thu, 23 Apr 2015 20:31:18 +0300
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <55391FF1.8000100@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
	<55367683.5050409@oracle.com>
	<CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>
	<05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>
	<4E61739E-9922-4EBA-BB61-EF0375ABEB31@oracle.com>
	<F9496F9A-5A98-4411-8566-19FD15EDCD48@oracle.com>
	<55391FF1.8000100@oracle.com>
Message-ID: <CABsW4Owz8iQ2QVTOs0y=3fVSxu+_fB2bNF+sE-t5pYL=Axwwpw@mail.gmail.com>

IMHO

http://cr.openjdk.java.net/~bpb/8065556/webrev.04/src/java.base/share/classes/java/nio/Buffer.java.frames.html
{code}
272         if (newPosition > limit | newPosition < 0)
273             throw createPositionOutOfBoundsException(newPosition);
=================================================================
326         if (newLimit > capacity | newLimit < 0)
327             throw createLimitOutOfBoundsException(newLimit);
{code}

is not good code style.

Regards,
-uta

On Thu, Apr 23, 2015 at 7:38 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>
> On 21/04/2015 23:22, Brian Burkhalter wrote:
>
> Another iteration of this patch has been posted at
>
> http://cr.openjdk.java.net/~bpb/8065556/webrev.04/
>
> to be reviewed at your convenience.
>
> Summary:
>
> 1) Exception creation methods renamed for consistency to
> createXYZException().
> 2) Methods in #1 still create and return an IAE but leave throwing it to the
> caller.
> 3) Static methods in #1 moved up below constructors for style consistency.
> 4) Line lengths adjusted in tests to be within conventional limits.
>
> The approach looks okay to me. It would have been interesting to have done
> micro benchmarks to see it matches Martin's observation/bug as that was news
> to me.
>
> In Buffer then it would be nice to reduce the method names a bit so that the
> declarations don't spill over two lines. I realize it's just nit picking but
> it's good to keep the code consistent when you can.
>
> The test update looks okay now.
>
> -Alan

From brian.burkhalter at oracle.com  Thu Apr 23 18:04:27 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 23 Apr 2015 11:04:27 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <CABsW4Owz8iQ2QVTOs0y=3fVSxu+_fB2bNF+sE-t5pYL=Axwwpw@mail.gmail.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>
	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>
	<55367683.5050409@oracle.com>
	<CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>
	<05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>
	<4E61739E-9922-4EBA-BB61-EF0375ABEB31@oracle.com>
	<F9496F9A-5A98-4411-8566-19FD15EDCD48@oracle.com>
	<55391FF1.8000100@oracle.com>
	<CABsW4Owz8iQ2QVTOs0y=3fVSxu+_fB2bNF+sE-t5pYL=Axwwpw@mail.gmail.com>
Message-ID: <87566457-AABA-4599-8A0A-42069FD741B8@oracle.com>

Alexey,

These changes were suggested by others based on various data points in their experience so I will leave it to them to respond to the specifics of your comment. I would say however that it seems to me to be less of a question of style than what works from a performance perspective. The latter consideration dictates the admittedly ugly style.

Brian

On Apr 23, 2015, at 10:31 AM, Alexey Utkin <alexey.utkin at gmail.com> wrote:

> IMHO
> 
> http://cr.openjdk.java.net/~bpb/8065556/webrev.04/src/java.base/share/classes/java/nio/Buffer.java.frames.html
> {code}
> 272         if (newPosition > limit | newPosition < 0)
> 273             throw createPositionOutOfBoundsException(newPosition);
> =================================================================
> 326         if (newLimit > capacity | newLimit < 0)
> 327             throw createLimitOutOfBoundsException(newLimit);
> {code}
> 
> is not good code style.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150423/98bf46de/attachment-0001.html>

From brian.burkhalter at oracle.com  Fri Apr 24 18:52:32 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 24 Apr 2015 11:52:32 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <55391FF1.8000100@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>	<CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>	<78EF121A-B63E-4CFB-AF6D-5E9849DAEF07@oracle.com>	<55367683.5050409@oracle.com>	<CAHjP37EY6tDuGoyamu6vtbD3_NisjM9vWrq3jDSQiiONBE=ubg@mail.gmail.com>	<05891A56-CD99-481A-8F97-5F25893164E7@oracle.com>	<4E61739E-9922-4EBA-BB61-EF0375ABEB31@oracle.com>
	<F9496F9A-5A98-4411-8566-19FD15EDCD48@oracle.com>
	<55391FF1.8000100@oracle.com>
Message-ID: <F05F800C-9AC4-4012-8100-7E6B5AC72CE5@oracle.com>

On Apr 23, 2015, at 9:38 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> The approach looks okay to me. It would have been interesting to have done micro benchmarks to see it matches Martin's observation/bug as that was news to me.

Here are some results using JMH with my local JDK9 fastdebug builds. 

Ubuntu 12.04-x86 VM, 1 fork, 20 warmup iterations, 25 benchmark iterations

Benchmark                                       Mode  Cnt       Score      Error  Units
MyBenchmark.createAndThrowException            thrpt   25  726912.251 ? 4290.454  ops/s
MyBenchmark.createAndThrowExceptionWithParams  thrpt   25  636919.265 ? 3861.024  ops/s
MyBenchmark.throwReturnedException             thrpt   25  739061.398 ? 3653.874  ops/s
MyBenchmark.throwReturnedExceptionWithParams   thrpt   25  642605.571 ? 3602.519  ops/s

Mac OS 10.9.5 native, 2 forks, 20 warmup iterations, 25 benchmark iterations

Benchmark                                       Mode  Cnt      Score      Error  Units
MyBenchmark.createAndThrowException            thrpt   50  80054.822 ?  257.876  ops/s
MyBenchmark.createAndThrowExceptionWithParams  thrpt   50  60709.551 ?  198.745  ops/s
MyBenchmark.throwReturnedException             thrpt   50  65792.276 ? 2750.755  ops/s
MyBenchmark.throwReturnedExceptionWithParams   thrpt   50  75005.831 ? 2048.279  ops/s

The benchmark source is included below.

These results look to me to be rather ambiguous on OS X. On Linux there is no significant difference between the invoked failure method throwing the exception directly versus the calling method throwing the exception returned by a method although the mean value for the latter approach is slightly faster.

I am not particularly a ?performance guy? so if you?ve any suggestions regarding these benchmarks please don?t hesitate to educate me a little.

> In Buffer then it would be nice to reduce the method names a bit so that the declarations don't spill over two lines. I realize it's just nit picking but it's good to keep the code consistent when you can.

Please see the updated patch at:

http://cr.openjdk.java.net/~bpb/8065556/webrev.05/

Summary: Changed IllegalArgumentException-returning method names to shorter versions all of the form createXYZException() so as to eliminate line wrapping.

Thanks,

Brian

? Benchmark Source ?

    static IllegalArgumentException createIAE() {
        return new IllegalArgumentException("You passed in a lame parameter, dude!");
    }

    static void throwIAE() {
        throw new IllegalArgumentException("You passed in a lame parameter, dude!");
    }

    static IllegalArgumentException createIAEWithParams(int p1, int p2) {
        return new IllegalArgumentException("Bad param 1 " + p1
                                            + " bad param 2 " + p2);
    }

    static void throwIAEWithParams(int p1, int p2) {
        throw new IllegalArgumentException("Bad param 1 " + p1
                                           + " bad param 2 " + p2);
    }

    @Benchmark
    public IllegalArgumentException throwReturnedException() {
        try {
            throw createIAE();
        } catch (IllegalArgumentException e) {
            return e;
        }
    }

    @Benchmark
    public IllegalArgumentException throwReturnedExceptionWithParams() {
        try {
            throw createIAEWithParams(42, 666);
        } catch (IllegalArgumentException e) {
            return e;
        }
    }

    @Benchmark
    public IllegalArgumentException createAndThrowException() {
        try {
            throwIAE();
        } catch (IllegalArgumentException e) {
            return e;
        }
        return null;
    }

    @Benchmark
    public IllegalArgumentException createAndThrowExceptionWithParams() {
        try {
            throwIAEWithParams(42, 666);
        } catch (IllegalArgumentException e) {
            return e;
        }
        return null;
    }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150424/9eb315cb/attachment.html>