On 10/11/2011 04:36 AM, Ulf Zibis wrote:
Am 30.09.2011 22:46, schrieb Xueming Shen:
I believe we changed from (b1 xyz) to (b1 x) == -2 back to
2009(?) because
the benchmark shows the shift version is slightly faster. Do you
have any number
shows any difference now. My non-scientific
http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf
Go to 3.9 Unicode Encoding Forms. Or simply search D93
On 10/1/2011 2:21 PM, Ulf Zibis wrote:
Am 30.09.2011 22:46, schrieb Xueming Shen:
On 09/30/2011 07:09 AM, Ulf Zibis wrote:
(1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42
On 09/30/2011 07:09 AM, Ulf Zibis wrote:
(1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---
CoderResult.malformedForLength(1)
It appears the Unicode Standard now explicitly recommends to return
the malformed length 2,
what UTF-8 is doing now, for this scenario
My idea behind is, that
in this case, from Standard point view?
Am 29.09.2011 05:27, schrieb Xueming Shen:
Hi,
On 9/28/2011 3:44 PM, Ulf Zibis wrote:
5. IMHO charset CESU-8 should be hosted in extended-charsets,
otherwise it should be added to java.nio.StandardCharsets
We have lots of charsets provided via the standard
Hi,
[I combined the proposed charge for #7082884, in which no one appears to be
interested:-) into this one]
Unicode Standard added Addition Constraints on conversion of ill-formed
UTF-8
in version 5.1 [1] and updated in 6.0 again with further clarification
[2] regarding
how a conformance
Hi,
On 9/28/2011 3:44 PM, Ulf Zibis wrote:
Hi Sherman,
1. bug 7096080 is not visible at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7096080
It might take couple days for it to show up on bugs.sun.com. But it has
exactly the same content as
my previous email. In fact I simply
Hi,
Unicode Standard added Addition Constraints on conversion of ill-formed
UTF-8
in version 5.1 [1] and updated in 6.0 again with further clarification
[2] regarding
how a conformance implementation should handle ill-formed UTF-8 byte
sequence. Basically it says
(1) the conversion process
Looks fine.
On 9/13/2011 1:54 PM, Mandy Chung wrote:
6915797: Remove sun.tools.jar.JarImageSource that is not used
7090178: Move java.util.XMLUtils to another package to avoid split
package
Webrev at:
http://cr.openjdk.java.net/~mchung/6915797/webrev.00/
The synopsis says it all.
On 09/02/2011 06:00 AM, Rémi Forax wrote:
On 09/02/2011 01:34 PM, Alan Bateman wrote:
Rémi Forax wrote:
Arghhh, next() can return null !
CharsetProvider provider = ...
IteratorCharset it = provider.charsets();
IteratorCharset it2 = provider.charsets();
Charset charset = it.next();
Changeset: 812c6d4d6a58
Author:sherman
Date: 2011-09-02 10:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/812c6d4d6a58
6898310: (cs) Charset cache lookups should be synchronized
Summary: synchronize the lookup in iterator
Reviewed-by: alanb
!
Hi,
This is a forward porting. Same fix has been in jdk5/6, and will be in
jdk 7u2 later.
http://cr.openjdk.java.net/~sherman/6898310/webrev
The change itself is relative simple. And given its race-condition
nature, no reliable
regression test case is provided.
Thanks!
-Sherman
Hi Sebastian,
On 08/30/2011 01:23 AM, Sebastian Sickelmann wrote:
Sorry i have forgotten the webrev url.
http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/
with couple changes from your original patch.
(1) Undo the changes in DecimalFormat.java and Format.java.
Sebastian,
src/share/classes/sun/misc/Launcher.java in new patch appears to miss a
ending } at ln#487
-Sherman
On 08/30/2011 10:20 AM, Xueming Shen wrote:
Hi Sebastian,
On 08/30/2011 01:23 AM, Sebastian Sickelmann wrote:
Sorry i have forgotten the webrev url.
http://oss-patches.24.eu
Changeset: 8a51f0e24380
Author:sherman
Date: 2011-08-30 11:53 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a51f0e24380
7084245: Update usages of InternalError to use exception chaining
Summary: to use new InternalError constructor with cause chainning
Reviewed-by: alanb,
Hi Sebastian,
I will help to push the patch, if people all agreed the changes proposed.
I pulled your patch and generated the webrev at
http://cr.openjdk.java.net/~sherman/7084245/webrev
with couple changes from your original patch.
(1) Undo the changes in DecimalFormat.java and Format.java.
On 08/26/2011 01:17 PM, Alan Bateman wrote:
Xueming Shen wrote:
Alan
Webrev has been updated to
(1) use the new try(resource){}
(2) update the existing test case LargetZip to
a) be able to add one more entry at the end of the 4g zip via
ZipFileSystem
b) read through all entries
On 08/26/2011 02:45 PM, Alan Bateman wrote:
Sebastian Sickelmann wrote:
Hi,
is there someone who wants to review / support this simple warning
removal?
The webrev is:
http://oss-patches.24.eu/openjdk8/Simple_Warning/
-- Sebastian*
*
This is JSSE so probably best if someone from the
Please ignored this email. My apology. Wrong click.
On 08/26/2011 03:16 PM, Xueming Shen wrote:
On 08/26/2011 02:45 PM, Alan Bateman wrote:
Sebastian Sickelmann wrote:
Hi,
is there someone who wants to review / support this simple warning
removal?
The webrev is:
http://oss-patches.24.eu
Changeset: 973d923af88c
Author:sherman
Date: 2011-08-26 15:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/973d923af88c
7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong data size for ZIP64
extended information extra field
Summary: fixed the wrong size when writing
/24/2011 12:06 AM, Alan Bateman wrote:
Xueming Shen wrote:
:
Fix has been verified/test manually with existing test cases. Given
the nature
of the 4G zip data file. I'm not including an auto regression test.
Webrev is at
http://cr.openjdk.java.net/~sherman/7077769/webrev
The zip64 fix looks
The fix tires to address two issues in ZipFileSystem class
(1) The OutputStream used to write out the bits in sync() is not wrapped
by a BufferedOutputStream. Without the BufferedOutputStream wrapper,
we basically write all ZIP header tables (loc and cen) byte by byte. How
big is the impact to
Hi,
This is something long over due. Some background info.
(1)The java.nio.charset package (to replace the private sun.io package)
is added into
JDK 1.4 as the result of the nio JSR. Part of the sun.io
converters were migrated to
the java.nio.charset implementation in JDK8.
(2)
Ulf,
I tried to be conservative to not touch the source code, just in case I
might be forced
to put them back again:-) But since I have already removed the whole
sun.io source
branch, it's reasonable to do the complete cleanup up as well. The
webrev has been
updated accordingly (to remove
/2011 2:07 AM, Alan Bateman wrote:
Xueming Shen wrote:
Hi,
This is something long over due. Some background info.
(1)The java.nio.charset package (to replace the private sun.io
package) is added into
JDK 1.4 as the result of the nio JSR. Part of the sun.io
converters were migrated
that
line will not do anything.
Thanks,
Sasha
[1] Actually, it gets set to -Xlint:all -Xlint:-path, but that's
temporary. This happens in jdk/make/common/shared/Defs-java.gmk.
On 8/17/2011 11:41 AM, Xueming Shen wrote:
Thanks Sasha,
The flag has been set to true, as suggested.
The webrev has
Changeset: 2961329a6774
Author:sherman
Date: 2011-08-17 14:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2961329a6774
6237353: Remove sun.io package from j2se binary
Summary: Removed sun.io package and related test cases
Reviewed-by: alanb
!
Changeset: 11cc9c2e0431
Author:sherman
Date: 2011-08-17 15:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11cc9c2e0431
7066490: @since 1.7 tag is missing for
java.util.regex.Matcher.group(java.lang.String)
Summary: Added the @since 1.7 tag
Reviewed-by: mduigou, forax
!
from outside
should access them directly.
Am 17.08.2011 20:41, schrieb Xueming Shen:
Ulf,
I tried to be conservative to not touch the source code, just in case
I might be forced
to put them back again:-)
Then we could provide my small sun.io-wrapper, maybe as additional
resource like JDK
Looks good. Thanks for fixing them.
On 08/08/2011 02:37 PM, Mandy Chung wrote:
Simple fix on these tests to run on cygwin.
7036518: TEST_BUG: add cygwin support to
test/java/nio/charset/coders/CheckSJISMappingProp.sh
7036519: TEST_BUG: add cygwin support to test/demo/zipfs/basic.sh
Webrev
OK, it's a nit-pick and it has nothing to do with this fix, and it
probably has been there from day
one. But just wonder if those %n should be replaced by /n in those
properties file, otherwise
my guess is that the result of java -help will not have the correct
line-end on Windows platform.
For
On 06/21/2011 12:32 PM, Xueming Shen wrote:
OK, it's a nit-pick and it has nothing to do with this fix, and it
probably has been there from day
one. But just wonder if those %n should be replaced by /n in those
properties file, otherwise
I meant to say the /n should be replaced by %n.
my
makes
the compatibility issue less severe:-) especially it's hard to
explain the case.
-Sherman
On 6/8/2011 8:27 AM, Tim Ellison wrote:
Hi Sherman, ok so I'll admit to reading through to the end of your note
and finding it interesting ;-)
Some comments in-lined.
On 03/Jun/2011 22:55, Xueming
Changeset: d830ec851cee
Author:sherman
Date: 2011-05-14 11:55 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d830ec851cee
7044849: Constructs for Unicode binary properties should be \p{IsXXX} not
p{isXXX}
Summary: fixed the doc typo
Reviewed-by: alanb
!
Changeset: 501ca93ea3ef
Author:sherman
Date: 2011-05-11 08:54 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/501ca93ea3ef
7043234: (fmt) java.util.Formatter links in javadoc to BigDecimal need to be
fixed
Summary: fixed the doc miss
Reviewed-by: alanb, emcmanus
!
On 5/7/2011 10:55 AM, Ulf Zibis wrote:
Rémi, thanks for your feedback.
Am 07.05.2011 18:00, schrieb Rémi Forax:
On 05/07/2011 02:17 PM, Ulf Zibis wrote:
Hi all,
please excuse, that I have still problems to accept this additional
class, but +1 for the plural name.
If those charset
On 05-07-2011 上午 9:00, Rémi Forax wrote:
On 05/07/2011 02:17 PM, Ulf Zibis wrote:
Hi all,
please excuse, that I have still problems to accept this additional
class, but +1 for the plural name.
If those charset constants are there, people _will use_ them without
respect on the existing
On 5/2/2011 7:31 AM, Alan Bateman wrote:
Xueming Shen wrote:
Hi
This is motivated by Neil's request to optimize common-case UTF8 path
for native ZipFile.getEntry calls [1].
As I said in my replying email [2] I believe a better approach might
be to patch UTF8 charset directly to
implement
Changeset: fa17f2b9a6d5
Author:sherman
Date: 2011-05-02 11:42 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa17f2b9a6d5
7040220: java/char_encodin Optimize UTF-8 charset for String.getBytes()/new
String(byte[])
Summary: implement sun.nio.cs.ArrayEn/Decoer in utf8
Changeset: 4ac05b50f09c
Author:sherman
Date: 2011-05-01 11:39 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4ac05b50f09c
7036522: j.u.r.Pattern documentation errors
Summary: updated the Perl related information
Reviewed-by: alanb
!
Hi
This is motivated by Neil's request to optimize common-case UTF8 path
for native ZipFile.getEntry calls [1].
As I said in my replying email [2] I believe a better approach might be
to patch UTF8 charset directly to
implement sun.nio.cs.ArrayDecoder/Encoder interface to speed up the
coding
)
Thanks,
-Sherman
Am 28.04.2011 08:34, schrieb Xueming Shen:
Hi
This is motivated by Neil's request to optimize common-case UTF8 path
for native ZipFile.getEntry calls [1].
As I said in my replying email [2] I believe a better approach might
be to patch UTF8 charset directly to
implement
On 04/28/2011 01:55 PM, Ulf Zibis wrote:
Am 28.04.2011 21:56, schrieb Xueming Shen:
That said, you do have the point, we should do better even in
malformed case, ...
Yes, that's what I wanted to point on.
But I thought, you could go 1 step further, declaring bb as member of
UTF_8.Decoder
Changeset: 775b77e74bec
Author:sherman
Date: 2011-04-28 20:18 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/775b77e74bec
7037261: j.l.Character.isLowerCase/isUpperCase need to match the Unicode
Standard
Summary: updated j.l.c.lsLowerCase/isUpperCase
Reviewed-by: okutsu
!
On 04-13-2011 3:00 PM, Mike Duigou wrote:
Mike, can you share the results of performance testing at various compression levels? Is
there much difference between the levels or an apparent sweet spot?
For low hanging fruit for jdk 7 it might be worth considering raising the
default compression
On 04-26-2011 2:20 AM, Alan Bateman wrote:
Xueming Shen wrote:
Thanks Mark!
Let's go with UNICODE_PROPERTY, if there is no objection.
I went through the updates to the javadoc and the approach looks good
and nicely done. A minor comment is that the compile(String,int)
method repeats
Thanks Tom!
The j.u.regex does not have its own direct access to PropList for now,
have to use the properties from j..l.Character
class. I will have to move those CharacterDateNN classes from the
java.lang package (package private) to sun.lang
or somewhere that both j.u.Character and
Two more names, UNICODE_PROPERTIES and UNICODE_CLASSES, are suggested.
any opinion?
-Sherman
On 4/23/2011 6:50 PM, Xueming Shen wrote:
Forwarding...forgot to include the list.
Original Message
Subject: Re: Codereview Request: 7039066 j.u.rgex does not match
TR#18 RL1.4
I don't think CLASS(ES) would be optimal.
bc; Bidi_Class
ccc ; Canonical_Combining_Class
http://unicode.org/Public/UNIDATA/PropertyAliases.txt
Mark
/— Il meglio è l’inimico del bene —/
On Sun, Apr 24, 2011 at 11:22, Xueming Shen xueming.s...@oracle.com
mailto:xueming.s
Hi
This proposal tries to address
(1) j.u.regex does not meet Unicode regex's Simple Word Boundaries [1]
requirement as Tom pointed
out in his email on i18n-dev list [2]. Basically we have 3 problems here.
a. ju.regex word boundary construct \b and \B uses Unicode
\p{letter} +
, Xueming Shen wrote:
Hi
This proposal tries to address
(1) j.u.regex does not meet Unicode regex's Simple Word Boundaries
[1] requirement as Tom pointed
out in his email on i18n-dev list [2]. Basically we have 3 problems here.
a. ju.regex word boundary construct \b and \B uses Unicode
\p
Forwarding...forgot to include the list.
Original Message
Subject: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18
RL1.4 Simple Word Boundaries and RL1.2 Properties
Date: Sat, 23 Apr 2011 17:53:42 -0700
From: Xueming Shen xueming.s...@oracle.com
To: Tom
On 4/18/2011 5:33 AM, Neil Richards wrote:
On Thu, 2011-04-14 at 14:48 -0700, Xueming Shen wrote:
Opinion? anything I overlooked/missed?
Hi Sherman,
Thanks once more for all your help and advice on this - I'm in favour of
almost all of what you suggest. :-)
I think it's worthwhile trying
Hi Neil,
All tests passed.
I'm starting to push your last patch. I generated the webrev at
http://cr.openjdk.java.net/~sherman/7031076/webrev/
It should be exactly the same as your last patch.
Thanks,
Sherman
On 4/18/2011 9:49 AM, Xueming Shen wrote:
On 4/18/2011 5:33 AM, Neil Richards
Changeset: 98688c4be64b
Author:sherman
Date: 2011-04-18 10:51 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/98688c4be64b
7031076: Retained ZipFile InputStreams increase heap demand
Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd
Reviewed-by: sherman,
Regards
Mike
*From:* Mike Duigou mike.dui...@oracle.com
*To:* mike.ske...@talk21.com
*Cc:* Xueming Shen xueming.s...@oracle.com; core-libs-dev Libs
core-libs-dev@openjdk.java.net
*Sent:* Wednesday, 13 April, 2011 23:00:26
/missed?
-Sherman
On 04/13/2011 08:25 AM, Steve Poole wrote:
On 13/04/11 16:19, Steve Poole wrote:
On 12/04/11 20:33, Xueming Shen wrote:
Hi Neil,
Hi Sherman , Neil is out on vacation so I will do my best to stand
in for him.
(1) I believe it would be better to keep the synchronization
On 04/13/2011 08:25 AM, Steve Poole wrote:
On 13/04/11 16:19, Steve Poole wrote:
On 12/04/11 20:33, Xueming Shen wrote:
Hi Neil,
Hi Sherman , Neil is out on vacation so I will do my best to stand
in for him.
(1) I believe it would be better to keep the synchronization lock
for get
On 04-13-2011 3:00 PM, Mike Duigou wrote:
Mike, can you share the results of performance testing at various compression levels? Is
there much difference between the levels or an apparent sweet spot?
For low hanging fruit for jdk 7 it might be worth considering raising the
default compression
Hi Neil,
(1) I believe it would be better to keep the synchronization lock for
get/releaseInfalter()
local instead of using the global ZipFile.this, which I agree
is simple. But it also
means each/every time when you release the used inflater back to
cache, ZipFile.this
has to
Changeset: c8f22fc4aa00
Author:sherman
Date: 2011-04-10 23:33 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c8f22fc4aa00
7033561: Missing Unicode Script aliases
Summary: added 6.0 aliases
Reviewed-by: okutsu, peytoia, alanb
! src/share/classes/java/lang/Character.java
!
://cr.openjdk.java.net/~sherman/7031076/webrev/
What do you think? have a better idea?
Sherman
On 04-08-2011 5:36 AM, Neil Richards wrote:
On Thu, 2011-04-07 at 16:02 -0700, Xueming Shen wrote:
It appears it might not be necessary to do the finalize() in
ZipFileInflaterInputStream
Neil,
It appears it might not be necessary to do the finalize() in
ZipFileInflaterInputStream. The
ZipFileInflaterInputStream itself does not directly hold any native
resource by itself that
needs to be released at the end of its life circle, if not closed
explicitly. The native resource/
Hi Mike,
We are in the final stage of the JDK7 development, work like this is
unlikely to get in the
last minute. I have filed a CR/RFE to trace this issue, we can use this
CR as the start
point for the discussion and target for some jdk7 update releases or JDK8.
7034403: proposal to
It appears the aliases mapping for Character.UnicodeScript is not
updated accordingly when
we upgraded the Unicode support to 6.0 for JDK7. The difference between
the previous version
(5.2) and 6.0 of the aliases are these 3 missing names reported in #7033561.
The webrev with the change is
Thanks! webrev has been updated accordingly.
-Sherman
On 04/06/2011 01:29 PM, Alan Bateman wrote:
Xueming Shen wrote:
It appears the aliases mapping for Character.UnicodeScript is not
updated accordingly when
we upgraded the Unicode support to 6.0 for JDK7. The difference
between
Changeset: 59f43e232481
Author:sherman
Date: 2011-04-04 11:30 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59f43e232481
6751338: ZIP inflater/deflater performance
Summary: To use GetPrimitiveArrayCritical for bye array access
Reviewed-by: bristor, alanb
!
On 04-02-2011 9:01 AM, Dave Bristor wrote:
The webrev looks fine. I have only this minor comment:
* Inflater.c:
A minor suggestion: In inflateBytes, cases Z_OK and Z_NEED_DICT, I suggest
replacing:
this_off += this_len - strm-avail_in;
(*env)-SetIntField(env, this, offID, this_off);
On 4/1/2011 11:56 PM, Jeroen Frijters wrote:
Xueming Shen wrote:
I'm not a GC guy, so I might be missing something here, but if close()
is being explicitly invoked by some thread, means someone has a strong
reference to it, I don't think the finalize() can kick in until that
close() returns
On 04-02-2011 12:47 AM, Xueming Shen wrote:
On 4/1/2011 11:56 PM, Jeroen Frijters wrote:
Xueming Shen wrote:
I'm not a GC guy, so I might be missing something here, but if close()
is being explicitly invoked by some thread, means someone has a strong
reference to it, I don't think
Thanks David!
And Neil, it seems my assumption is wrong and we do need the
synchronization for the close().
Your latest patch looks fine for me.
Thanks,
-Sherman
On 04-02-2011 6:15 PM, David Holmes wrote:
Xueming Shen said the following on 04/02/11 17:00:
On 4/1/2011 4:17 PM, David
On 04/01/2011 09:42 AM, Neil Richards wrote:
On Wed, 2011-03-30 at 13:31 -0700, Xueming Shen wrote:
Isn't it true that when the finalize()-close() gets invoked, there
should be no strong reference anywhere else that you can use to invoke
close() in other thread?
It's true that once finalize
Dave, Alan,
Here is the final webrev based on Dave's patch and the jdk1.5 code that
does not
have the change for 6206933. JPRT job result suggests no new testing
failure and
my non-scientific benchmark test (to use GZIPOu/InputStream to compress/
decompress the rt.jar) does show relative
On 03/30/2011 12:53 PM, Neil Richards wrote:
Hi Sherman,
Thanks for your review and comments on this.
On Tue, 2011-03-29 at 12:05 -0700, Xueming Shen wrote:
Hi Neil,
It appears to be a regression in scenario you described (user
application never close the input stream after use
Hi Neil,
It appears to be a regression in scenario you described (user
application never close the
input stream after use and the ZipFile instance being retained during
the lifetime of the
process). The proposed approach seems to solve this particular problem.
Here are my comments regarding
Changeset: 3eb51bf7e859
Author:sherman
Date: 2011-03-17 11:42 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3eb51bf7e859
6796662: (fmt spec) Formatter spec on BigDecimal output should not reference
Float a
Summary: updated the spec doc
Reviewed-by: alanb
!
Changeset: 05911dc54a67
Author:sherman
Date: 2011-03-16 12:16 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05911dc54a67
6803681: RFE: Need new codeset converter for IBM Cp1364
Summary: forward port the Cp1364
Reviewed-by: alanb
! make/sun/nio/cs/FILES_java.gmk
+
Changeset: 90b7926884a8
Author:sherman
Date: 2011-03-04 11:35 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90b7926884a8
7023244: (zipfs) langtools CompileTest fails on read-only file system
Summary: replaced checkAccess with Files.isWritable()
Reviewed-by: alanb
!
Stuart,
Here are my comments on non-pack changes. I'm sure Kumar will look at
those pack files later.
GetMethodsReturnClones.java: ln#43 diamond conersion?
Available.java: it's not your change, but I believe we should do the
try-with_resources on the ZipFile zfile as well.
InfoZip.java.:
Kumar,
Would you please help review the change in your pack code?
Thanks,
-Sherman
On 2011-2-23 22:26, Stuart Marks wrote:
Hi Sherman, all,
Here's a webrev to convert code in the jar/zip implementation files
and tests to use the new Java 7 try-with-resources construct.
Changeset: dbc74475822f
Author:sherman
Date: 2011-02-16 11:11 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbc74475822f
6999337: java.exe fails to start if some directory names in path to java
binaries contain Russian characters
Summary: updated to make sure the system
Changeset: 8711aedb08f2
Author:sherman
Date: 2011-02-11 12:20 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8711aedb08f2
7007596: (zipfs) FileSystems.newFileSystem(FileRef...) always employs zipfs
regardless the real Path type.
Summary: updated newFileSystem() to throw UOE
Changeset: 21a1e86dedc2
Author:sherman
Date: 2011-02-11 17:09 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/21a1e86dedc2
6996192: Console.readPassword race: input echo off must be prior to writing
prompt
Summary: To turn off echo before prompt
Reviewed-by: alanb
!
Changeset: 6661a1dfa369
Author:sherman
Date: 2011-02-08 13:30 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6661a1dfa369
7017840: (zipfs) test/demo/zipfs/basic.sh needs to be updated due to 7013420
Summary: updated try-with-resourcse usage in test/demo code
Reviewed-by:
Changeset: b8662dac7c91
Author:sherman
Date: 2011-02-04 13:17 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8662dac7c91
7005986: (zipfs) ZipPath.startsWith() fails because of the implementation of
getName(index)
Summary: Updated starsWith/endsWith to be consistent with
Changeset: 035ecca4379c
Author:sherman
Date: 2011-02-03 13:49 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/035ecca4379c
7014645: Support perl style Unicode hex notation \x{...}
Summary: Added the construct \x{...} for Unicode hex notation support
Reviewed-by: alanb, okutsu
Changeset: 4cc447291326
Author:sherman
Date: 2011-01-24 11:47 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4cc447291326
7006576: (zipfs) Path.exists() always returns false on dirs when zip/JAR file
built without dirs
7009092: (zipfs) ZipPath.isSameFile() should always
Changeset: 4379c762ec50
Author:sherman
Date: 2011-01-04 14:17 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4379c762ec50
7009618: regression test failed caused by the fix for 7003462
Summary: avoid caching the ended Inflater in ZipFile class
Reviewed-by: alanb
!
Changeset: 1740ad242f56
Author:sherman
Date: 2010-12-13 14:12 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1740ad242f56
7003462: cannot read InputStream returned by
java.util.ZipFile.getInputStream(ZipEntry)
Summary: The returned InflatedInputStream object should be kept
Changeset: 01b6d147db50
Author:sherman
Date: 2010-12-08 12:15 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/01b6d147db50
6527572: (cs) Charset.forName can throw NullPointerException when testing bug
level
Summary: fixed the race condition
Reviewed-by: alanb
!
Changeset: 956de70712e0
Author:sherman
Date: 2010-12-08 12:54 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/956de70712e0
6415373: (cs) UnicodeEncoder emits BOM when there are no bytes to encode
Summary: no BOM output if no byte to encode
Reviewed-by: alanb
!
Changeset: 03513756704c
Author:sherman
Date: 2010-12-08 20:11 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03513756704c
5076980: (fmt) FormattableFlags specifies unsupported '^' format flag
Summary: replaced '^' with 'S' in spec
Reviewed-by: darcy
!
Please help review the change for
6415373: (cs) UnicodeEncoder emits BOM when there are no bytes to encode
http://cr.openjdk.java.net/~sherman/6415373/webrev
Thanks,
-Sherman
On 11/22/2010 05:52, Alan Bateman wrote:
Xueming Shen wrote:
Alan,
After staring those simple, 11 lines of change for minutes, I believe
we should simply
go back with the original approach at
http://cr.openjdk.java.net/~sherman/6858865/webrev.00
The change in
http://cr.openjdk.java.net
Changeset: 0049b9a85e74
Author:sherman
Date: 2010-11-22 16:03 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0049b9a85e74
6858865: Fix for 6728376 causes regression if the size of data is 0 and
malloc returns Null for 0-length
Summary: don't throw OOME when in or out buffer
Changeset: 7fac77daa9be
Author:sherman
Date: 2010-11-22 16:12 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fac77daa9be
7001434: charset name for Cp833 should be x-IBM833.
Summary: changed the name to x-IBM833 in extsbcs
Reviewed-by: alanb
!
Alan,
Last time when Martin and I discussed this issue we agreed that the
submitter is right
about this. (The charset is a mapping between a sequence of bytes
and a sequence
of sisteen-bit Unicode characters, so the character discussed here
should be a utf-16
character...)
On 11/19/2010 01:31, Alan Bateman wrote:
Xueming Shen wrote:
Alan,
It might not be a real regression if only consider the supported
platforms
(and yes, the malloc manpageI can found does clearly indicate NULL is
for error).
However I prefer to add some checks to make sure it behaves
Thanks Alan!
webrev has been updated accordingly to fix the typo.
-Sherman
On 11/19/2010 01:38, Alan Bateman wrote:
Xueming Shen wrote:
Alan, Kelly,
Would you please help review the patch that tries to address those
compiler warning
in zip area?
http://cr.openjdk.java.net/~sherman
On 11/19/2010 09:55 AM, Alan Bateman wrote:
Xueming Shen wrote:
:
We can probably do that for Inflater.c (and probably better do that
at java level before
we even come down here), but thing gets a little complicated for
Deflater. One of the
paths of the deflateBytes is to deal with parameter
Changeset: d9e4556acd4a
Author:sherman
Date: 2010-11-19 12:55 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d9e4556acd4a
6989471: compiler warnings building java/zip native code
Summary: remvoed the warning
Reviewed-by: ohair, alanb
!
1001 - 1100 of 1299 matches
Mail list logo
