RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

[Xueming Shen]

Hi,

webrev has been updated to use the name space jdk.nio.zipfs.

http://cr.openjdk.java.net/~sherman/8038500/webrev/

-Sherman

On 4/14/14 12:15 PM, Xueming Shen wrote:
> On 4/14/14 11:56 AM, Alan Bateman wrote:
>> On 14/04/2014 18:52, Xueming Shen wrote:
>>> Thanks Mandy and Alan for the review.
>>>
>>> webrev has been updated accordingly to
>>>
>>> (1) Removed the basic.sh. The tests are now using test.jdk to access 
>>> the zipfs.jar directly
>>> (2) Updated most of the class to package package, only 
>>> ZipFileSystemProvider (the spi interface)
>>>      and ZipInfo are public.
>>>      The ZipInfo is a handy utility sometime I find it useful to 
>>> simply do java com.sun.nio.zipfs.Info xyz.zip
>>>      to display all cen and loc tables in details. I may take 
>>> sometime to find a better home for it later.
>>> (3) I have not migrated the test target zipfs.jar to an 
>>> "independent" test source (created during test) yet,
>>>      will definitely later in a separate thread when we move to 
>>> modules.
>>> (4) Yes, I mean to keep Demo there as an interactive regression test.
>>>
>>> http://cr.openjdk.java.net/~sherman/8038500/webrev/
>>>
>>> -Sherman
>> Iris asked me off-list about the name space which makes me wonder if 
>> we should use the opportunity to move this to jdk.<something>. As 
>> it's a service provider then nothing should be accessing these 
>> classes directly. The only thing that comes to mind is 
>> ZipFileAttributeView/ZipFileAttributes where the API provides a 
>> type-safe means to access attributes. In the webrev then these are 
>> being changed to package-private so I think would break anyone that 
>> might be using them anyway.
>>
>
> go with jdk.nio.zipfs? I'm fine with that if this is the new directory 
> to go. though it appears we have 1000+ classes at com.sun...
>
> -sherman