- just a new
> Also given
> that these are buffers of primitive types then an alternative would be to be
> explicit as to how it it differs from the Java Language == operator and do a
> "see also" for Double#equals(double)? Minor comment on compareTo is that
> "invoking" would be more consistent than "using".
Changed.
>
> Would you have time to add a test to
> test/java/nio/Buffer/Basic-X.java.template for this? (you need to run
> genBasic.sh to re-generate the tests when you change this).
Done.
Unfortunately, this change is starting to grow:
I removed the dangerous "rm -rf build" from genBasic.sh
It made no sense to me that "char" would have a fulltype of
"character", but "int" didn't have a fulltype of "integer".
I fixed that, and that allowed $Fulltype$ to be usable in
the source.
case $type in
char) fulltype=character;;
+ int) fulltype=integer;;
*) fulltype=$type;;
esac
Much bigger webrev now at
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/DoubleBuffer/
Martin
> -Alan.
>
>
>
>
>
>
>
>
>
>
From msbmail.java at gmail.com Mon Nov 23 16:59:15 2009
From: msbmail.java at gmail.com (Mark Bisho)
Date: Mon, 23 Nov 2009 16:59:15 -0800
Subject: Volunteering for the NIO Project
Message-ID: <4b0b2fe4.0d0bca0a.062c.ffff9655@mx.google.com>
Hello Everyone,
I'd like to volunteer to contribute to the OpenJDK NIO Project. I know I'm a
little late the current game, but I was hoping there was still some value I
could contribute to the NIO Project.
Your activities are definitely in my major area of interest. I have many
years of experience in C/C++ and Java on both Linux and Windows. I have some
Unix kernel experience as well as experience with multiple versions of
multiple Windows SDKs. I've recently done modification for personal use to
some JDK 6 code regarding native Linux operations with the io.File object,
so I have some familiarity of your code base and build environment.
For the past year I have been working for a company that audits commercial
source code specifically for open source code usage and license compliance.
This is done while assisting with the development and debugging of a
java-based application. This activity has given me a great introduction to
OpenJDK and is responsible for bring me to your doorstep.
I currently have 2 personal computers I can use for cross-platform
development: Ubuntu 9.10 (Karmic Koala) and Windows XP. (I had no compelling
reason to migrate to Vista, and I am giving Windows 7 a wait-and-see
approach.)
Please tell me you can make use of my services. I'm sure I'll be happy with
whatever is available. I enjoy ramping up on technologies new to me. I take
my commitments very seriously, so I am sure you will be very satisfied.
Regards,
Mark Bisho
http://www.linkedin.com/pub/dir/Mark/Bisho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20091123/04b0d875/attachment.html
From fweimer at bfk.de Tue Nov 24 01:34:55 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Tue, 24 Nov 2009 09:34:55 +0000
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
(Martin Buchholz's message of "Mon\,
23 Nov 2009 15\:27\:49 -0800")
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
Message-ID: <82aayc8dvk.fsf@mid.bfk.de>
* Martin Buchholz:
> I can also do the minimal patch to compareTo
> that considers NaN as greater than any other value.
How do you order NaNs with different bit patterns?
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra?e 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
From Alan.Bateman at Sun.COM Tue Nov 24 03:26:28 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 24 Nov 2009 11:26:28 +0000
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
Message-ID: <4B0BC2E4.5060409@sun.com>
Martin Buchholz wrote:
> :
> Yes, you're right - a sad situation.
>
> I'd like to change the behavior so that e.g.
> DoubleBuffer.equals compares corresponding elements using Double.equals
> and
> DoubleBuffer.compareTo compares corresponding elements using Double.compareTo
>
> but maybe that's too bold a step for the JDK.
>
I think so as we don't know what/who it might break.
> I can also do the minimal patch to compareTo
> that considers NaN as greater than any other value.
> But that would be introducing yet another
> way of comparing floating point values.
> Hmmmmm....I'm sadly talking myself into taking that
> conservative but disagreeable decision.
> OK. Done.
>
It's unfortunate but I don't see another solution that won't cause more
problems.
A few comments on the current webrev:
Kelly renamed X-Buffer.java to X-Buffer.java.template a few weeks ago
(just noticed that your webrev is against X-Buffer.java).
The clarification to the equals javadoc is mostly okay. I think I'd
prefer the second sentence (currently starting with "Unlike ...") to go
something like "Note that positive zero and negative zero compare equal
and so this method differs to $Fulltype$#equals".
Minor nit is that you need a space after to be locally consistent
(same issue in compareTo).
The clarification to the compareTo javadoc is also okay except that the
sentences are long - how about this as an alternative:
"This method differs to the Java language comparison operations in that
it considers $Fulltype$.NaN to be equal to itself and greater than all
other $type$ values (including $Fulltype$.POSITIVE_INFINITY). As
positive zero and negative zero compare equals so then it differs to the
$Fulltype$#compare($type$,$type$)".
Thanks for adding a new test to Basic-X.java. I think you might have
left a few debug messages that you might want to remove.
> :
>
>
>> Would you have time to add a test to
>> test/java/nio/Buffer/Basic-X.java.template for this? (you need to run
>> genBasic.sh to re-generate the tests when you change this).
>>
>
> Done.
>
> Unfortunately, this change is starting to grow:
>
> I removed the dangerous "rm -rf build" from genBasic.sh
>
Looks like it was left over from other changes.
> It made no sense to me that "char" would have a fulltype of
> "character", but "int" didn't have a fulltype of "integer".
> I fixed that, and that allowed $Fulltype$ to be usable in
> the source.
>
> case $type in
> char) fulltype=character;;
> + int) fulltype=integer;;
> *) fulltype=$type;;
> esac
>
I can't see any problem doing this but can you compare the generated
code to make sure it is the same?
-Alan.
From Alan.Bateman at Sun.COM Tue Nov 24 03:30:32 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 24 Nov 2009 11:30:32 +0000
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <82aayc8dvk.fsf@mid.bfk.de>
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
<82aayc8dvk.fsf@mid.bfk.de>
Message-ID: <4B0BC3D8.2030901@sun.com>
Florian Weimer wrote:
> * Martin Buchholz:
>
>
>> I can also do the minimal patch to compareTo
>> that considers NaN as greater than any other value.
>>
>
> How do you order NaNs with different bit patterns?
>
They are essentially collapsed to a single canonical value.
-Alan.
From fweimer at bfk.de Tue Nov 24 03:39:38 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Tue, 24 Nov 2009 11:39:38 +0000
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <4B0BC3D8.2030901@sun.com> (Alan Bateman's message of "Tue\,
24 Nov 2009 11\:30\:32 +0000")
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
<82aayc8dvk.fsf@mid.bfk.de> <4B0BC3D8.2030901@sun.com>
Message-ID: <827htg6tj9.fsf@mid.bfk.de>
* Alan Bateman:
> Florian Weimer wrote:
>> * Martin Buchholz:
>>
>>
>>> I can also do the minimal patch to compareTo
>>> that considers NaN as greater than any other value.
>>>
>>
>> How do you order NaNs with different bit patterns?
> They are essentially collapsed to a single canonical value.
Does this happen transparently by the JVM? Double.compare() does not
do it, as far as I can tell.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra?e 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
From Alan.Bateman at Sun.COM Tue Nov 24 03:46:49 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 24 Nov 2009 11:46:49 +0000
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <827htg6tj9.fsf@mid.bfk.de>
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
<82aayc8dvk.fsf@mid.bfk.de> <4B0BC3D8.2030901@sun.com>
<827htg6tj9.fsf@mid.bfk.de>
Message-ID: <4B0BC7A9.8060809@sun.com>
Florian Weimer wrote:
> :
> Does this happen transparently by the JVM? Double.compare() does not
> do it, as far as I can tell.
>
>
Double.compare will use doubleToLongBits. AFAIK, the only method that
preserves or exposes NaN values is doubleToRawLongBits.
-Alan.
From fweimer at bfk.de Tue Nov 24 03:53:49 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Tue, 24 Nov 2009 11:53:49 +0000
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <4B0BC7A9.8060809@sun.com> (Alan Bateman's message of "Tue\,
24 Nov 2009 11\:46\:49 +0000")
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
<82aayc8dvk.fsf@mid.bfk.de> <4B0BC3D8.2030901@sun.com>
<827htg6tj9.fsf@mid.bfk.de> <4B0BC7A9.8060809@sun.com>
Message-ID: <823a446svm.fsf@mid.bfk.de>
* Alan Bateman:
> Florian Weimer wrote:
>> :
>> Does this happen transparently by the JVM? Double.compare() does not
>> do it, as far as I can tell.
> Double.compare will use doubleToLongBits. AFAIK, the only method that
> preserves or exposes NaN values is doubleToRawLongBits.
Oh, I had missed this. Thanks for the clarification.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra?e 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
From Joe.Darcy at Sun.COM Tue Nov 24 17:45:57 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 24 Nov 2009 17:45:57 -0800
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
Message-ID: <4B0C8C55.20904@sun.com>
Martin Buchholz wrote:
> On Sun, Nov 22, 2009 at 07:41, Alan Bateman wrote:
>
>> Martin Buchholz wrote:
>>
>>> I have a webrev for y'all at
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/DoubleBuffer/
>>>
>>> 6666666: (bf) Improve floating-point buffer comparison
>>>
>>> Describe the exact behavior of {Double,Float}Buffer.{equals,compareTo}.
>>>
>>> Fix the behavior of
>>> {Double,Float}Buffer.compareTo
>>> so that it satisfies the Comparable contract.
>>>
>>> I'd also like to fix the behavior of {Double,Float}Buffer.equals to be
>>> compatible with {Double,Float}.equals, but the proposed change assumes
>>> that we are stuck with the historic behavior and should simply
>>> document it.
>>>
>>> Martin
>>>
>>>
>> I've created this bug to track this:
>> 6903754: (bf) Improve floating-point buffer comparison
>>
>> I haven't had time yet to fully digest the proposal (at least, from an
>> initial glance, the 0.0/-0.0 case where it looks like equals and compareTo
>> will now be inconsistent).
>>
>
> Yes, you're right - a sad situation.
>
> I'd like to change the behavior so that e.g.
> DoubleBuffer.equals compares corresponding elements using Double.equals
> and
> DoubleBuffer.compareTo compares corresponding elements using Double.compareTo
>
> but maybe that's too bold a step for the JDK.
>
> I can also do the minimal patch to compareTo
> that considers NaN as greater than any other value.
> But that would be introducing yet another
> way of comparing floating point values.
> Hmmmmm....I'm sadly talking myself into taking that
> conservative but disagreeable decision.
> OK. Done.
>
> One passing comment on the javadoc update is that
>
>> the clarification as to how equals behaves might be better to be part of
>> item 3 rather than starting a new item (as it logically follows).
>>
>
> ?! It does not start a new - just a new
>
>
>> Also given
>> that these are buffers of primitive types then an alternative would be to be
>> explicit as to how it it differs from the Java Language == operator and do a
>> "see also" for Double#equals(double)? Minor comment on compareTo is that
>> "invoking" would be more consistent than "using".
>>
For the morbidly curious, I thought I would send in a few comments on
the nature of IEEE 754 floating-point equality.
First, the IEEE 754 standard defines four mutually exclusive possible
ordering relations between numbers:
* equal
* greater than
* less than
* unordered
A NaN is unordered with respective to every floating-point value,
including itself. This was done so that NaNs would not quietly slip by
without due notice. Since (NaN == NaN) is false, the IEEE 754 "=="
relation is *not* an equivalence relation. There are other ways IEEE
754 == is not an equivalence relation. For example, the two values -0.0
and +0.0 compare as equal, but they are not equivalent since 1.0/-0.0 =>
-infinity and 1.0/+0.0 => + infinity. There are two zeros in IEEE 754
because there are two infinities. Another way to add infinity to the
real numbers is to have a single (unsigned) projective infinity. In
such a system, there is only one zero. Early x87 chips before IEEE 754
was standardized had support for both signed (affine) and projective
infinities. The different ways of adding infinity are more convenient
for different kinds of computations.
However, there are cases where one wants an true equivalence relation
over floating-point values, such as test programs, and one needs a total
ordering, such as when sorting. In my numerical tests I have methods
that return true if:
(x == y) && (if x and y are both zero they have the same sign) || (x and
y are both NaN)
which is conveniently computed using (Double.compareTo(x, y) == 0). For
sorting or a total order, the semantics of Double.compareTo are fine; it
doesn't matter where the NaNs are ordered to as long as they are
consistently ordered.
I wasn't aware of a mixture of IEEE 754 and Double.compareTo being used
in the Buffer classes, but I'm not confident I can asses the behavioral
compatibility impact of switching the implementation algorithm.
-Joe
From martinrb at google.com Tue Nov 24 18:23:46 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Nov 2009 18:23:46 -0800
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <4B0BC2E4.5060409@sun.com>
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
<4B0BC2E4.5060409@sun.com>
Message-ID: <1ccfd1c10911241823y77681654hbc4ee989a23d7ff4@mail.gmail.com>
On Tue, Nov 24, 2009 at 03:26, Alan Bateman wrote:
> Martin Buchholz wrote:
> Kelly renamed X-Buffer.java to X-Buffer.java.template a few weeks ago (just
> noticed that your webrev is against X-Buffer.java).
I was surprised that my mq upgrade went without a conflict.
The rename Just Worked!
I improved the spec to make it hopefully less clumsy,
and added some more tests as well.
>> It made no sense to me that "char" would have a fulltype of
>> "character", but "int" didn't have a fulltype of "integer".
>> I fixed that, and that allowed $Fulltype$ to be usable in
>> the source.
>>
>> ?case $type in
>> ? char) ?fulltype=character;;
>> + ?int) ? fulltype=integer;;
>> ? *) ? ? fulltype=$type;;
>> ?esac
>>
>
> I can't see any problem doing this but can you compare the generated code to
> make sure it is the same?
I'm pretty sure that the only change is in the doc for CharBuffer.java.
It now talks about "char buffer" instead of "character buffer",
which is (sadly) a clear improvement.
I'd like to commit my latest version. webrev regenerated.
(Unless of course we suddenly become bold enough to
switch to saner semantics)
Martin
From Alan.Bateman at Sun.COM Wed Nov 25 06:40:22 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 25 Nov 2009 14:40:22 +0000
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <1ccfd1c10911241823y77681654hbc4ee989a23d7ff4@mail.gmail.com>
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
<4B0BC2E4.5060409@sun.com>
<1ccfd1c10911241823y77681654hbc4ee989a23d7ff4@mail.gmail.com>
Message-ID: <4B0D41D6.8050605@sun.com>
Martin Buchholz wrote:
> :
> I improved the spec to make it hopefully less clumsy,
> and added some more tests as well.
>
It is better. One small comment on equals is that it might be better if
the "Unlike ..." statement were changed slightly to say that the method
considers positive zero and negative zero to be equal before
{Float,Double}.equals is mentioned. That way the mention of the
difference is more of a "by the way" and the reader don't have to follow
the link.
In compareTo, it might be better if we changed "This method compares two
XXX values as if by ..." to "Elements are compared as if by ..." (just
a suggestion to make it make it follow the second paragraph a bit better).
> :
>
> I'm pretty sure that the only change is in the doc for CharBuffer.java.
> It now talks about "char buffer" instead of "character buffer",
> which is (sadly) a clear improvement.
>
OK and thanks for checking.
> I'd like to commit my latest version. webrev regenerated.
>
> (Unless of course we suddenly become bold enough to
> switch to saner semantics)
>
Assuming you mean +0.0/-0.0 then it's not clear what/who it would break.
Minimally it would require a "get out of jail" switch to restore the
long standing behavior.
-Alan.
From martinrb at google.com Wed Nov 25 19:03:41 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 25 Nov 2009 19:03:41 -0800
Subject: DoubleBuffer.compareTo is not anti-symmetric
In-Reply-To: <4B0D41D6.8050605@sun.com>
References: <1ccfd1c10911201119t6c23c12u8fd890e8d79d73f1@mail.gmail.com>
<4B07070D.3070404@sun.com>
<1ccfd1c10911201826y2ff718eftf612e9024831a87e@mail.gmail.com>
<4B095BA7.6010604@sun.com>
<1ccfd1c10911231527i7a867ebbwc82820c9001d0215@mail.gmail.com>
<4B0BC2E4.5060409@sun.com>
<1ccfd1c10911241823y77681654hbc4ee989a23d7ff4@mail.gmail.com>
<4B0D41D6.8050605@sun.com>
Message-ID: <1ccfd1c10911251903w716923c7xd5cae6e9ec0dba18@mail.gmail.com>
On Wed, Nov 25, 2009 at 06:40, Alan Bateman wrote:
> Martin Buchholz wrote:
>>
>> :
>> I improved the spec to make it hopefully less clumsy,
>> and added some more tests as well.
>>
>
> It is better. One small comment on equals is that it might be better if the
> "Unlike ..." statement were changed slightly to say that the method
> considers positive zero and negative zero to be equal before
> {Float,Double}.equals is mentioned. That way the mention of the difference
> is more of a "by the way" and the reader don't have to follow the link.
Reworded to reverse order.
> In compareTo, it might be better if we changed "This method compares two XXX
> values as if by ..." ?to "Elements are compared as if by ..." (just a
> suggestion to make it make it follow the second paragraph a bit better).
I changed one occurrence of "values" to "elements".
You may have noticed that much of my javadoc was taken from Double.java.
Martin
From uckelman at nomic.net Fri Nov 27 15:48:14 2009
From: uckelman at nomic.net (Joel Uckelman)
Date: Sat, 28 Nov 2009 00:48:14 +0100
Subject: zipfs and relative paths
In-Reply-To: <4B01CBC3.7070502@sun.com>
References: <20091116154828.1573B100B5@charybdis.ellipsis.cx>
<4B018A6E.4060904@sun.com>
<20091116201052.00CA4100B5@charybdis.ellipsis.cx>
<4B01CBC3.7070502@sun.com>
Message-ID: <20091127234815.715F2100C2@charybdis.ellipsis.cx>
Thus spake Alan Bateman:
> Joel Uckelman wrote:
> >
> Path operations with the demo zip provider should be similar to the
> default provider on Solaris/Linux so if you have access to either then
> it should be easy to compare. So fs.getPath("foo/").toString() should
> return "foo" and fs.getPath("foo/../../bar").normalize() should result
> in a Path that represent "../bar". Another idea is look at
> test/java/nio/file/Path/PathOps.java - that test exercises all of the
> path operations and could be easily modified to verify the zip provider
> (the sanity.sh test for the zip provider doesn't provide good coverage).
>
> -Alan.
More patches for zipfs:
* s/pathForprint/pathForPrint/g
* Fixed comment typos.
* Use String ctor directly, instead of substring(), no need to keep larger
array around.
* Replaced StringBuffer with StringBuilder.
* ZipFilePath.normalize() now works.
* ZipPathParser.normalize() now chops trailing slashes.
* ZipPathParser.resolve() now handles leading '..' in relative paths properly.
* Introduced checkPath() to throw NPE and ProviderMismatchExceptions before
using Paths passed as arguments.
* Fixed endsWith() to handle absolute other path properly (/foo !endsWith /).
* Fixed startsWith(): Absolute paths do not start with relative ones.
There's still more to do after this... I don't have zipfs passing all of
the tests I wrote yet.
-------------- next part --------------
# HG changeset patch
# User uckelman at adsl-208-39.dsl.uva.nl
# Date 1258402555 -3600
# Node ID 1a3ffe00a8e0a2eeef40f1237f69b87da910256a
# Parent 221e7d8e0dfd1bceca8f5b847b5326f4c25279c7
s/pathForprint/pathForPrint/g
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -73,13 +73,13 @@
private final byte[] pathForZip;
private final ReadLock readLock = new ReentrantReadWriteLock().readLock();
private ZipFilePath pathToZip;
- private final byte[] pathForprint;
+ private final byte[] pathForPrint;
// package-private
ZipFilePath(ZipFileSystem fileSystem, byte[] pathInZip) {
this.fileSystem = fileSystem;
this.path = pathInZip;
- this.pathForprint = pathInZip;
+ this.pathForPrint = pathInZip;
boolean isAbs = (path[0] == '/');
String toResolve = new String(path);
if (!isAbs) {
@@ -100,7 +100,7 @@
this.fileSystem = fileSystem;
this.path = pathForZip;
this.pathForZip = pathForZip;
- this.pathForprint = pathInZip; //given path
+ this.pathForPrint = pathInZip; //given path
}
public boolean isNestedZip() {
@@ -650,7 +650,7 @@
@Override
public String toString() {
- return new String(pathForprint);
+ return new String(pathForPrint);
}
@Override
-------------- next part --------------
# HG changeset patch
# User uckelman at adsl-208-39.dsl.uva.nl
# Date 1258405833 -3600
# Node ID f627e54903f3c8e8f78bd454c814a983927e9b73
# Parent 1a3ffe00a8e0a2eeef40f1237f69b87da910256a
Fixed comment typos.
Use String ctor directly, instead of substring(), no need to keep larger
array around.
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
@@ -208,14 +208,14 @@
pathInZip.getChars(0, len, pathArr, 0);
//Repleace all Separators \\ with Zip Separator /
- //throws InavalidPathException in Windows and Unux if char is not valid
+ //throws InavalidPathException in Windows and Unix if char is not valid
// in respective file systems.
for (int i = 0; i < len; i++) {
if (pathArr[i] == '\\') {
pathArr[i] = '/';
}
- if (fileSepa == '\\') { //If Path is In Windows
+ if (fileSepa == '\\') { //If Path is in Windows
if ((pathArr[i] < '\u0020') || (invalidChars.indexOf(pathArr[i]) != -1)) {
throw new InvalidPathException(pathInZip, "Invalid char at " + i);
}
@@ -223,7 +223,7 @@
((i == len - 1) && pathArr[i] == ' '))) {
throw new InvalidPathException(pathInZip, "Trailing space at" + (i - 1));
}
- } else if (fileSepa == '/') { //If path In In Unix
+ } else if (fileSepa == '/') { //If path is in Unix
if (pathArr[i] == '\u0000') {
throw new InvalidPathException(pathInZip, "Null char at" + i);
}
@@ -240,9 +240,8 @@
}
}
- return new String(pathArr).substring(0, size);
-
+ return new String(pathArr, 0, size);
}
// Remove DotSlash(./) and resolve DotDot (..) components
-------------- next part --------------
# HG changeset patch
# User uckelman at adsl-208-39.dsl.uva.nl
# Date 1258500243 -3600
# Node ID aa42666df3a0d3c5ba65a165b98b7f1ce63ec5ec
# Parent f627e54903f3c8e8f78bd454c814a983927e9b73
Replaced StringBuffer with StringBuilder.
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -350,7 +350,7 @@
int elements = endIndex - beginIndex;
String result = null;
- StringBuffer result1 = new StringBuffer("");
+ StringBuilder result1 = new StringBuilder("");
int index = beginIndex;
for (; elements-- != 0;) {
if (endIndex == offsets.size() && elements == 0) {
@@ -382,7 +382,7 @@
int elements = endIndex - beginIndex;
String result = null;
- StringBuffer result1 = new StringBuffer("");
+ StringBuilder result1 = new StringBuilder("");
int index = beginIndex;
for (; elements-- != 0;) {
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
@@ -286,10 +286,9 @@
}
}
//Construct final path
- StringBuffer resolved = (prefix) ? new StringBuffer("/") : new StringBuffer("");
+ final StringBuilder resolved = new StringBuilder(prefix ? "/" : "");
for (String comp : stack) {
resolved.append(comp).append("/");
-
}
String resolvedPath = "";
-------------- next part --------------
# HG changeset patch
# User uckelman at adsl-208-39.dsl.uva.nl
# Date 1258588273 -3600
# Node ID bfd37a1b962cec761051254d4b3737f5132c8086
# Parent aa42666df3a0d3c5ba65a165b98b7f1ce63ec5ec
ZipFilePath.normalize() now works.
ZipPathParser.normalize() now chops trailing slashes.
ZipPathParser.resolve() now handles leading '..' in relative paths properly.
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -1183,21 +1183,24 @@
}
/*
- * /foo// -- > /foo/
- * /foo/./ -- > /foo/
+ * /foo// -- > /foo
+ * /foo/./ -- > /foo
* /foo/../bar -- > /bar
* /foo/../bar/../baz -- > /baz
* //foo//./bar -- > /foo/bar
* /../ -- > /
- * ../foo -- > foo
+ * ../foo -- > ../foo
* foo/bar/.. -- > foo
- * foo/../../bar -- > bar
+ * foo/../../bar -- > ../bar
* foo/../bar -- > bar
**/
@Override
public Path normalize() {
- //pathForZip is normalized path for ZipFileSystem
- return new ZipFilePath(fileSystem, pathForZip, pathForZip);
+ return new ZipFilePath(
+ fileSystem,
+ ZipPathParser.resolve(new String(path)).getBytes(),
+ pathForZip
+ );
}
@Override
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipPathParser.java
@@ -32,8 +32,9 @@
package com.sun.nio.zipfs;
import java.nio.file.*;
+import java.util.Iterator;
import java.util.LinkedList;
-import java.util.Stack;
+import java.util.ListIterator;
import java.util.regex.*;
@@ -132,7 +133,7 @@
}
return 0; // path length >1 and No Prefix
}
- return 0; //Path lenght=1 and it does not have any prefix
+ return 0; //Path length=1 and it does not have any prefix
}
static int nextNonSeparator(String path, int off) {
@@ -178,7 +179,6 @@
}
}
return compList;
-
}
private static int findZipComponent(int prefixLen, String path) {
@@ -241,64 +241,62 @@
}
+ // Remove trailing slash unless whole path is '/'
+ if (size > 1 && pathArr[size-1] == '/') size--;
+
return new String(pathArr, 0, size);
}
// Remove DotSlash(./) and resolve DotDot (..) components
static String resolve(String path) {
+ final boolean prefix = path.startsWith("/");
+ final LinkedList parts = getComponents(path);
- int len = path.length();
- char pathArr[] = new char[len];
- path.getChars(0, len, pathArr, 0);
- //Remove ./ component ,Remove this if not necessary
- char ch = pathArr[0];
- int prefixPos = (ch == '/') ? 1 : 0;
- int size = len;
+ int previousDirsAtBeginning = 0;
- for (int i = prefixPos + 1; i < size; i++) {
- if ((pathArr[i] == '/' && pathArr[i - 1] == '.') &&
- (i == prefixPos + 1 || pathArr[i - 2] == '/')) {
- System.arraycopy(pathArr, i + 1, pathArr, i - 1, size - (i + 1));
- size -= 2;
- i--;
+ // Remove redundant parts.
+ for (ListIterator i = parts.listIterator(); i.hasNext(); ) {
+ final String part = i.next();
+
+ if (part.equals(".")) {
+ // ".": Remove.
+ i.remove();
}
+ else if (part.equals("..")) {
+ // "..":
+ // Absolute paths: Remove this and the previous name, if any.
+ // Relative paths: Keep if we are part of a leading string of
+ // ".." names; otherwise remove this and the previous name.
+ if (prefix || i.previousIndex() > previousDirsAtBeginning) {
+ i.remove();
- }
- //Remove final . if path has one. which is not needed for zip path
- if ((size >= 2) && pathArr[size - 1] == '.' && pathArr[size - 2] == '/') {
- System.arraycopy(pathArr, 0, pathArr, 0, size - 1);
- size -= 1;
+ // hasPrevious() can be false for the absolute path "/.."
+ if (i.hasPrevious()) {
+ i.previous();
+ i.remove();
+ }
+ }
+ else {
+ // We are relative, must keep leading ".."
+ previousDirsAtBeginning++;
+ }
+ }
+ else {
+ // Otherwise keep this name (for now).
+ }
}
- //Resolve ../ components
- String pathStr = new String(pathArr, 0, size);
- boolean prefix = pathStr.startsWith("/");
- boolean endsWith = pathStr.endsWith("/");
- LinkedList compArr = getComponents(pathStr);
- Stack stack = new Stack();
- for (int i = 0; i < compArr.size(); i++) {
- stack.push(compArr.get(i));
- if (compArr.get(i).equals("..")) {
- stack.pop();
- if (i > 0 && stack.size() > 0) {
- stack.pop();
- }
+ // Construct the resulting path string.
+ final StringBuilder res = new StringBuilder(prefix ? "/" : "");
+
+ final Iterator i = parts.iterator();
+ if (i.hasNext()) {
+ res.append(i.next());
+ while (i.hasNext()) {
+ res.append("/").append(i.next());
}
}
- //Construct final path
- final StringBuilder resolved = new StringBuilder(prefix ? "/" : "");
- for (String comp : stack) {
- resolved.append(comp).append("/");
- }
- String resolvedPath = "";
- if (!resolved.toString().equals("")) {
- if (!endsWith && resolved.length() != 1) {
- resolvedPath = resolved.substring(0, resolved.length() - 1);
- } else {
- resolvedPath = resolved.toString();
- }
- }
- return (resolvedPath);
+ return res.toString();
}
}
-------------- next part --------------
# HG changeset patch
# User Joel Uckelman
# Date 1259358283 -3600
# Node ID ed35a667769562b2090f5e2ef509f58b3b3528e6
# Parent bfd37a1b962cec761051254d4b3737f5132c8086
Introduced checkPath() to throw NPE and ProviderMismatchExceptions before
using Paths passed as arguments.
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -103,6 +103,18 @@
this.pathForPrint = pathInZip; //given path
}
+ private ZipFilePath checkPath(Path path) {
+ if (path == null) {
+ throw new NullPointerException();
+ }
+
+ if (!(path instanceof ZipFilePath)) {
+ throw new ProviderMismatchException();
+ }
+
+ return (ZipFilePath) path;
+ }
+
public boolean isNestedZip() {
Pattern pattern = Pattern.compile("\\.(?i)(zip|jar)");
Matcher matcher = null;
@@ -498,26 +510,21 @@
@Override
public Path relativize(Path other) {
- if (other == null) {
- throw new NullPointerException();
- }
- if (!(other instanceof ZipFilePath)) {
- throw new ProviderMismatchException();
- }
- ZipFilePath other1 = (ZipFilePath) other;
- if (other1.equals(this)) {
+ final ZipFilePath otherPath = checkPath(other);
+
+ if (otherPath.equals(this)) {
return null;
}
- if (this.isAbsolute() != other1.isAbsolute()) {
- return other1;
+ if (this.isAbsolute() != otherPath.isAbsolute()) {
+ return otherPath;
}
int i = 0;
int ti = this.getNameCount();
- int oi = other1.getNameCount();
+ int oi = otherPath.getNameCount();
for (; i < ti && i < oi; i++) {
- if (!this.getName(i).equals(other1.getName(i))) {
+ if (!this.getName(i).equals(otherPath.getName(i))) {
break;
}
}
@@ -531,7 +538,7 @@
ZipFilePath subPath = null;
int subpathlen = 0;
if (i < oi) {
- subPath = other1.subpath(i, oi);
+ subPath = otherPath.subpath(i, oi);
subpathlen = subPath.path.length;
}
byte[] result = new byte[arr.length + subpathlen];
@@ -592,41 +599,28 @@
@Override
public boolean startsWith(Path other) {
+ final ZipFilePath otherPath = checkPath(other);
- ZipFilePath other1 = null;
- if (other == null) {
- throw new NullPointerException();
- }
- if (other instanceof ZipFilePath) {
- other1 = (ZipFilePath) other;
- }
-
- int otherCount = other1.getNameCount();
+ int otherCount = otherPath.getNameCount();
if (getNameCount() < otherCount) {
return false;
}
for (int i = 0; i < otherCount; i++) {
- if (other1.getName(i).equals(getName(i))) {
+ if (otherPath.getName(i).equals(getName(i))) {
continue;
} else {
return false;
}
}
return true;
-
}
@Override
public boolean endsWith(Path other) {
- ZipFilePath other1 = null;
- if (other == null) {
- throw new NullPointerException();
- }
- if (other instanceof ZipFilePath) {
- other1 = (ZipFilePath) other;
- }
- int i = other1.getNameCount();
+ final ZipFilePath otherPath = checkPath(other);
+
+ int i = otherPath.getNameCount();
int j = getNameCount();
if (j < i) {
@@ -634,14 +628,13 @@
}
for (--i, --j; i >= 0; i--, j--) {
- if (other1.getName(i).equals(getName(j))) {
+ if (otherPath.getName(i).equals(getName(j))) {
continue;
} else {
return false;
}
}
return true;
-
}
public FileSystemProvider provider() {
@@ -677,9 +670,7 @@
@Override
public int compareTo(Path other) {
-
- ZipFilePath otherPath = (ZipFilePath) other;
- //int c = zipPath.compareTo(otherPath.zipPath);
+ final ZipFilePath otherPath = checkPath(other);
int len1 = path.length;
int len2 = otherPath.path.length;
-------------- next part --------------
# HG changeset patch
# User Joel Uckelman
# Date 1259363453 -3600
# Node ID 9f5cf65ff5e02cfdd74144a772e819c0425f273b
# Parent ed35a667769562b2090f5e2ef509f58b3b3528e6
Fixed endsWith() to handle absolute other path properly (/foo !endsWith /).
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -618,22 +618,28 @@
@Override
public boolean endsWith(Path other) {
- final ZipFilePath otherPath = checkPath(other);
+ final ZipFilePath that = checkPath(other);
- int i = otherPath.getNameCount();
- int j = getNameCount();
+ if (that.isAbsolute()) {
+ return this.isAbsolute() ? this.equals(that) : false;
+ }
+
+ int i = that.getNameCount();
+ int j = this.getNameCount();
if (j < i) {
return false;
}
-
+
for (--i, --j; i >= 0; i--, j--) {
- if (otherPath.getName(i).equals(getName(j))) {
- continue;
- } else {
- return false;
+ if (that.getName(i).equals(this.getName(j))) {
+ continue;
+ }
+ else {
+ return false;
}
}
+
return true;
}
-------------- next part --------------
# HG changeset patch
# User Joel Uckelman
# Date 1259365111 -3600
# Node ID e05c7be3271e4d74c10a4b2672de3025245bad19
# Parent 9f5cf65ff5e02cfdd74144a772e819c0425f273b
Fixed startsWith(): Absolute paths do not start with relative ones.
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -599,20 +599,26 @@
@Override
public boolean startsWith(Path other) {
- final ZipFilePath otherPath = checkPath(other);
+ final ZipFilePath that = checkPath(other);
- int otherCount = otherPath.getNameCount();
- if (getNameCount() < otherCount) {
+ if (that.isAbsolute() != this.isAbsolute()) {
return false;
}
- for (int i = 0; i < otherCount; i++) {
- if (otherPath.getName(i).equals(getName(i))) {
+ final int thatCount = that.getNameCount();
+ if (getNameCount() < thatCount) {
+ return false;
+ }
+
+ for (int i = 0; i < thatCount; i++) {
+ if (that.getName(i).equals(getName(i))) {
continue;
- } else {
+ }
+ else {
return false;
}
}
+
return true;
}
From uckelman at nomic.net Sun Nov 29 07:54:44 2009
From: uckelman at nomic.net (Joel Uckelman)
Date: Sun, 29 Nov 2009 16:54:44 +0100
Subject: zipfs and relative paths
In-Reply-To: <4B02904C.3090102@sun.com>
References: <20091116154828.1573B100B5@charybdis.ellipsis.cx>
<4B018A6E.4060904@sun.com>
<20091116201052.00CA4100B5@charybdis.ellipsis.cx>
<20091116210626.BCB82100B5@charybdis.ellipsis.cx>
<4B02904C.3090102@sun.com>
Message-ID: <20091129155444.6D54B100C2@charybdis.ellipsis.cx>
Thus spake Alan Bateman:
>
> Have you found cases where the toString is returning a path string with
> a trailing slash or after a resolve that toString returns a path string
> with a double slash in the middle? I haven't observed this but if there
> are cases they it's a bug.
>
No, I haven't turned up any of those yet. All of my Path ops tests pass
now, so I think there are no bugs of this sort left.
--
J.
From uckelman at nomic.net Sun Nov 29 07:57:17 2009
From: uckelman at nomic.net (Joel Uckelman)
Date: Sun, 29 Nov 2009 16:57:17 +0100
Subject: zipfs and relative paths
In-Reply-To: <20091127234815.715F2100C2@charybdis.ellipsis.cx>
References: <20091116154828.1573B100B5@charybdis.ellipsis.cx>
<4B018A6E.4060904@sun.com>
<20091116201052.00CA4100B5@charybdis.ellipsis.cx>
<4B01CBC3.7070502@sun.com>
<20091127234815.715F2100C2@charybdis.ellipsis.cx>
Message-ID: <20091129155717.8F9E1100C2@charybdis.ellipsis.cx>
Thus spake Joel Uckelman:
>
> More patches for zipfs:
>
Here's two more zipfs patches:
* Simplified subpath(). (This was overcomplex.)
* normalize() now returns null for paths equivalent to "."
-------------- next part --------------
# HG changeset patch
# User Joel Uckelman
# Date 1259509387 -3600
# Node ID cdf7fdb56c04d9e60d1f1e7a670069d86eaa6a94
# Parent e05c7be3271e4d74c10a4b2672de3025245bad19
Simplified subpath().
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -345,34 +345,33 @@
@Override
public ZipFilePath subpath(int beginIndex, int endIndex) {
+ initOffsets();
- initOffsets();
if (beginIndex < 0) {
throw new IllegalArgumentException();
}
+
if (beginIndex >= (1 + offsets.size())) {
throw new IllegalArgumentException();
}
+
if (endIndex > (1 + offsets.size())) {
throw new IllegalArgumentException();
}
+
if (beginIndex >= endIndex) {
throw new IllegalArgumentException();
}
- int elements = endIndex - beginIndex;
- String result = null;
- StringBuilder result1 = new StringBuilder("");
- int index = beginIndex;
- for (; elements-- != 0;) {
- if (endIndex == offsets.size() && elements == 0) {
- result1.append(subString(offsets.get(index), path.length));
- break;
- }
- result1.append(subString(offsets.get(index), offsets.get(++index)));
+ String result = subString(
+ offsets.get(beginIndex),
+ endIndex < offsets.size() ? offsets.get(endIndex) : path.length
+ );
+
+ if (result.endsWith("/")) {
+ result = result.substring(0, result.length()-1);
}
- result = result1.toString();
- result = (result.endsWith("/")) ? result.substring(0, result.length() - 1) : result;
+
return new ZipFilePath(fileSystem, result.getBytes());
}
-------------- next part --------------
# HG changeset patch
# User Joel Uckelman
# Date 1259509878 -3600
# Node ID d5401dc6df718abde155439521ee5a5fd9090b6c
# Parent cdf7fdb56c04d9e60d1f1e7a670069d86eaa6a94
normalize() now returns null for paths equivalent to "."
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -1198,11 +1198,10 @@
**/
@Override
public Path normalize() {
- return new ZipFilePath(
- fileSystem,
- ZipPathParser.resolve(new String(path)).getBytes(),
- pathForZip
- );
+ final String parsed = ZipPathParser.resolve(new String(path));
+
+ return parsed.equals("") ? null :
+ new ZipFilePath(fileSystem, parsed.getBytes(), pathForZip);
}
@Override
From uckelman at nomic.net Sun Nov 29 10:00:42 2009
From: uckelman at nomic.net (Joel Uckelman)
Date: Sun, 29 Nov 2009 19:00:42 +0100
Subject: zipfs and relative paths
In-Reply-To: <20091129155717.8F9E1100C2@charybdis.ellipsis.cx>
References: <20091116154828.1573B100B5@charybdis.ellipsis.cx>
<4B018A6E.4060904@sun.com>
<20091116201052.00CA4100B5@charybdis.ellipsis.cx>
<4B01CBC3.7070502@sun.com>
<20091127234815.715F2100C2@charybdis.ellipsis.cx>
<20091129155717.8F9E1100C2@charybdis.ellipsis.cx>
Message-ID: <20091129180043.10DA2100C2@charybdis.ellipsis.cx>
Thus spake Joel Uckelman:
>
> Here's two more zipfs patches:
>
> * Simplified subpath(). (This was overcomplex.)
> * normalize() now returns null for paths equivalent to "."
>
And one more:
* Cannot relativize() when exactly one path is absolute.
I think all of the methods which manipulate Paths work now.
-------------- next part --------------
# HG changeset patch
# User Joel Uckelman
# Date 1259513221 -3600
# Node ID 46fe5da2beaaee6f28f02dfcb673725b4df7c4b5
# Parent d5401dc6df718abde155439521ee5a5fd9090b6c
Cannot relativize() when exactly one path is absolute.
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -514,8 +514,9 @@
if (otherPath.equals(this)) {
return null;
}
+
if (this.isAbsolute() != otherPath.isAbsolute()) {
- return otherPath;
+ throw new IllegalArgumentException();
}
int i = 0;
From Alan.Bateman at Sun.COM Sun Nov 29 11:45:19 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sun, 29 Nov 2009 19:45:19 +0000
Subject: zipfs and relative paths
In-Reply-To: <20091129180043.10DA2100C2@charybdis.ellipsis.cx>
References: <20091116154828.1573B100B5@charybdis.ellipsis.cx>
<4B018A6E.4060904@sun.com>
<20091116201052.00CA4100B5@charybdis.ellipsis.cx>
<4B01CBC3.7070502@sun.com>
<20091127234815.715F2100C2@charybdis.ellipsis.cx>
<20091129155717.8F9E1100C2@charybdis.ellipsis.cx>
<20091129180043.10DA2100C2@charybdis.ellipsis.cx>
Message-ID: <4B12CF4F.2060805@sun.com>
Joel,
Thanks for the patches. I'll review them in the next few days and push
them to the nio/nio/jdk repository.
-Alan.
From uckelman at nomic.net Sun Nov 29 11:48:24 2009
From: uckelman at nomic.net (Joel Uckelman)
Date: Sun, 29 Nov 2009 20:48:24 +0100
Subject: zipfs and relative paths
In-Reply-To: <4B12CF4F.2060805@sun.com>
References: <20091116154828.1573B100B5@charybdis.ellipsis.cx>
<4B018A6E.4060904@sun.com>
<20091116201052.00CA4100B5@charybdis.ellipsis.cx>
<4B01CBC3.7070502@sun.com>
<20091127234815.715F2100C2@charybdis.ellipsis.cx>
<20091129155717.8F9E1100C2@charybdis.ellipsis.cx>
<20091129180043.10DA2100C2@charybdis.ellipsis.cx>
<4B12CF4F.2060805@sun.com>
Message-ID: <20091129194824.EE259100C2@charybdis.ellipsis.cx>
Thus spake Alan Bateman:
> Joel,
>
> Thanks for the patches. I'll review them in the next few days and push
> them to the nio/nio/jdk repository.
>
> -Alan.
Here's one more:
* getParent() returned null instead of "/" for single-element absolute paths
("/foo").
-------------- next part --------------
# HG changeset patch
# User Joel Uckelman
# Date 1259523988 -3600
# Node ID 073e75b34c3d2fdb8c49d0ce259e9cedf85f1cc9
# Parent 46fe5da2beaaee6f28f02dfcb673725b4df7c4b5
getParent() returned null instead of "/" for single-element absolute paths
("/foo").
diff --git a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
--- a/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
+++ b/src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs/ZipFilePath.java
@@ -269,14 +269,24 @@
@Override
public ZipFilePath getParent() {
- int count = getNameCount();
- if (count == 0 || count == 1) {
+ final int count = getNameCount();
+
+ // a root has no parent
+ if (count == 0) {
return null;
}
+
+ // a single-name path
+ if (count == 1) {
+ // has the root as its parent if absolute, and no parent otherwise
+ return isAbsolute() ?
+ new ZipFilePath(this.fileSystem, new byte[]{path[0]}) : null;
+ }
+
+ // all other paths have a parent
int position = offsets.get(count - 1);
String parent = subString(0, position - 1);
return new ZipFilePath(this.fileSystem, parent.getBytes());
-
}
public ZipFilePath getParentEntry() {