OK, Thanks!
btw, did you ask this before?
http://cr.openjdk.java.net/~sherman/6581715/webrev/
-Sherman
Martin Buchholz wrote:
On Fri, May 14, 2010 at 19:24, Xueming Shen wrote:
Martin Buchholz wrote:
Well, the obvious thing to do is to use ZipFile,
and if something goes wrong,
back
On Fri, May 14, 2010 at 19:24, Xueming Shen wrote:
> Martin Buchholz wrote:
>>
>> Well, the obvious thing to do is to use ZipFile,
>> and if something goes wrong,
>> back off and try the old implementation with
>> ZipInputStream in addition.
>>
>>
>
> I will add a check like
>
> if (fname != null
Martin Buchholz wrote:
Well, the obvious thing to do is to use ZipFile,
and if something goes wrong,
back off and try the old implementation with
ZipInputStream in addition.
I will add a check like
if (fname != null && new File(fname).length() < 0x1L)
go ZipFile;
else
go ZipIn
Well, the obvious thing to do is to use ZipFile,
and if something goes wrong,
back off and try the old implementation with
ZipInputStream in addition.
If the JDK has ZIP64 support,
what goes wrong?
Martin
On Fri, May 14, 2010 at 16:18, Xueming Shen wrote:
>
> It appears the backport to 6u of th
It appears the backport to 6u of the optimization we did in #6332094
breaks someone's code.
Obviously the ZipInputStream works fine with >4G zipfile even without
the ZIP64 format support
as long as the individual zip entries inside is smaller than the 4G
limit, so the sequential reading in j
Changeset: 2fb3d7dbaa32
Author:sherman
Date: 2010-05-14 13:46 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2fb3d7dbaa32
4263582: RFE: GZIPInputStream throws IOException on non-gzipped data
Summary: throw ZipException instead of IOException
Reviewed-by: martin
! src/share/c
Changeset: ac74c3b96e49
Author:sherman
Date: 2010-05-14 13:30 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ac74c3b96e49
6952701: Use http://www.ietf.org/rfc for rfc references in jdk public APIs
Summary: replace www.isi.edu/in-notes with www.ietf.org/rfc
Reviewed-by: martin
On Fri, May 14, 2010 at 12:39, Xueming Shen wrote:
>
> webrev has been updated to update the isi.edu reference to ietf (and one
> iana) for public APIs.
>
> The references in src/share/classes/com/sun are not touched, including 2
> apache drop-in xml code.
>
> Should be enough for today's exercise
webrev has been updated to update the isi.edu reference to ietf (and one
iana) for public APIs.
The references in src/share/classes/com/sun are not touched, including 2
apache drop-in xml code.
Should be enough for today's exercise:-)
Sherman
Martin Buchholz wrote:
There's 23 occurrences
There's 23 occurrences of isi.edu under jdk/src.
Could we do an even more global global-replace?
$ rg -w isi.edu | wc -l
23
Martin
On Fri, May 14, 2010 at 11:43, Xueming Shen wrote:
> OK, please help review.
>
> 6952701: Use http://www.ietf.org/rfc for those rfc links in java.util.zip's
> packa
OK, please help review.
6952701: Use http://www.ietf.org/rfc for those rfc links in
java.util.zip's package doc
http://cr.openjdk.java.net/~sherman/6952701/webrev
-Sherman
Martin Buchholz wrote:
On Fri, May 14, 2010 at 08:31, Xueming Shen wrote:
Hi
The links to http://www.isi.edu/in-n
On Fri, May 14, 2010 at 08:31, Xueming Shen wrote:
> Hi
>
> The links to http://www.isi.edu/in-notes/rfc195[012].txt on java.util.zip's
> class API
> seem broken (for a while?). I don't know if this is a temporary or permanent
> removal
> of the rfc stuff on isi site. Should we consider move the l
Hi
The links to http://www.isi.edu/in-notes/rfc195[012].txt on
java.util.zip's class API
seem broken (for a while?). I don't know if this is a temporary or
permanent removal
of the rfc stuff on isi site. Should we consider move the links to
somewhere more
"stable"? how about http://www.ietf.o
13 matches
Mail list logo
