Hi David, yes, it's the intent to make it only available in full jre,
for now.
Thanks!
-Sherman
On 4/15/14 12:22 AM, David Holmes wrote:
Hi Sherman,
Can you confirm that the intent is that this remains only available in
a full JRE and not in any Compact Profile?
Thanks,
David
On 15/04/2014 1:48 PM, Xueming Shen wrote:
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
