RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider
david.holmes at oracle.com
Tue Apr 15 07:22:18 UTC 2014
Can you confirm that the intent is that this remains only available in a
full JRE and not in any Compact Profile?
On 15/04/2014 1:48 PM, Xueming Shen wrote:
> webrev has been updated to use the name space jdk.nio.zipfs.
> 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
>>>> (4) Yes, I mean to keep Demo there as an interactive regression test.
>>> 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...
More information about the core-libs-dev