Re: JDK 9 RFR to problem list a failing test

+ 1 On 12/16/15, 1:58 PM, joe darcy wrote: Hello, The test java/beans/Introspector/Test6277246.java fails to compile after the change for JDK-8144479 , reporting an error /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:39: error: cannot

Re: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2]

e if "new RandomAccessFile) throws an exception here. And we need to keep the "zfile" open/alive if everything works well, so it appears the try-with-resourecs does not really help anything here. Thanks, Sherman Regards, Sean. On 12/12/2015 18:43, Xueming Shen wrote: Hi, The chan

RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2]

uot;len <=0" check in ZipFileInputStream.read() All tests seem to pass now. Thanks, Sherman On 11/11/15 12:22 PM, Xueming Shen wrote: Hi Please help review the changes for JDK-8142508 Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 webrev: http://cr.openjdk.java.net/~sherman/8142508

Re: Is setting -Dsun.jnu.encoding from the command line supposed to work?

Don't do it, that's all I would suggest :-) same as "file.encoding", they are both supposed to be informative read-only system property. Here is the history of sun.jnu.encoding http://ccc.us.oracle.com/4958170 -sherman On 12/11/2015 09:00 AM, Martin Buchholz wrote: IIRC I complained about

Re: Is setting -Dsun.jnu.encoding from the command line supposed to work?

On 12/11/2015 09:53 AM, Xueming Shen wrote: Don't do it, that's all I would suggest :-) same as "file.encoding", they are both supposed to be informative read-only system property. Here is the history of sun.jnu.encoding http://ccc.us.oracle.com/4958170 My apology, forgot the &quo

RFR JDK-8144958: changes by JDK-8142508 seems to have broken jtreg

Please help review the change for 8144958. issue: https://bugs.openjdk.java.net/browse/JDK-8144958 webrev: http://cr.openjdk.java.net/~sherman/8144958/ The changeset pushed this morning for 8142508 appears to trigger jtreg fail on some tests. ---

Re: RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk

d alone ? It would have to be tuned down in terms of resources if added to the auto-test list. Regards, Sean. On 11/11/15 20:22, Xueming Shen wrote: Hi Please help review the changes for JDK-8142508 (third try) Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 webrev: http://cr.openjdk.

RPR JDK-8143854: java/util/regex/RegExTest.java.RegExTest failed

Hi, Please help review the change for JDK-8143854 Issue: https://bugs.openjdk.java.net/browse/JDK-8143854 webrev: http://cr.openjdk.java.net/~sherman/8143854 This is triggered by the same cause of bug JDK-8079419. However the fix for 8079419 missed the possibility that the last character of

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi Yuji, I will take a look at your PoC. Might need some time and even bring in the security guy to evaluate the proposal. It seems like you are only interested in the "traditional PKWare decryption", which is, based on the wiki, "known to be seriously flawed, and in particular is

Re: RFR:8143413:add toEpochSecond methods for efficient access

phen On 1 December 2015 at 14:21, Roger Riggs <roger.ri...@oracle.com> wrote: Hi Sherman, On 11/30/2015 6:09 PM, Xueming Shen wrote: On 11/30/2015 01:26 PM, Stephen Colebourne wrote: Converting LocalDate<-> java.util.Date is the question with the largest number of votes on SO

Re: RFR:8143413:add toEpochSecond methods for efficient access

Hi, While it is kinda understandable to have LocalDate.toEpochSecond(...) to get the epoch seconds since 1970.1.1, with the assumption of the time is at the midnight of that day. It is strange to have the Local/OffsetTime to have two public methods with the assumption of the "date" is at epoch

Re: RFR:8143413:add toEpochSecond methods for efficient access

part of it in your app. One of the advantage of java.time.LDT/LD/LT is now we have separate abstract for these different need, I don't see the common need of having a LocalTime only meas the "local time" of 1970-01-01, or I misunderstood something here. -Sherman Stephen On 30 N

Re: RFR:8143413:add toEpochSecond methods for efficient access

n of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to remove that LocalDateTime middle man, with some arrangement. -Sherman Note that these methods are specifically not referencing java.util.Date itself. Epoch seconds is the appropriate intermediate form here, and still wi

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, The change looks fine. thanks, Sherman On 11/18/2015 01:27 PM, Steve Drach wrote: Hi, Please review the latest iteration of the webrev for runtime support of multi-release jar files. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238:

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On 11/23/2015 07:08 AM, Aleksey Shipilev wrote: On 11/23/2015 04:34 PM, Ivan Gerasimov wrote: With this fixed patch: http://cr.openjdk.java.net/~igerasim/8136500/8136500-addition-1.patch all tests from test/lang pass. Would you give it another chance? Okay, but this is better be the last

Re: RFR JDK-8143330: No appropriate CCC request for two new protected methods added in JDK9b93 by JDK-8141132

I missed the override version in StringBuffer.java, thanks Tobias for catching it. http://cr.openjdk.java.net/~sherman/8143553 https://bugs.openjdk.java.net/browse/JDK-8143553 I did re-generate the api doc, but still missed it :-( Thanks, Sherman On 11/19/2015 12:50 PM, Xueming Shen wrote

Re: RFR JDK-8143330: No appropriate CCC request for two new protected methods added in JDK9b93 by JDK-8141132

Thanks Joe, Alan! The synopsis has been updated accordingly. On 11/19/2015 12:43 PM, Alan Bateman wrote: On 19/11/2015 20:39, joe darcy wrote: Looks good Sherman; thanks, Looks okay to me too. We should fix the synopsis on the JIRA issue or at least put a better message in the change-set

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 11/11/15 8:44 AM, Steve Drach wrote: Hi, Please review the new webrev that addresses the issues raised by Sherman and Alan in the last iteration. In particular: - fixed the race condition in isMultiRelease() and another one with the variables ‘version’ and ‘configured’ - changed the

RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk

Hi Please help review the changes for JDK-8142508 (third try) Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev Mainly to address the issues in current j.u.z.ZipFile implementation as listed below (1) The ZIP file format support

Re: JDK 9 RFR of JDK-8142369: Move TestLocalTime.java to tier 2

looks good! On 11/9/15 4:27 PM, joe darcy wrote: Hello, The test java/util/zip/TestLocalTime.java fails intermittently (JDK-8135108). The test should be marked accordingly and moved to tier 2 until the problem is addressed. Patch below. Thanks, -Joe diff -r 5ee9639ba99f

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, My apology for slow response. I was sick in bed since last Sat... I've scanned the update, here are my comments (1) The newly added "configured" obviously will help in most use scenario, but (yes, there is always a but :-)), given the related code is not synchronized, I'm

Re: RFR: String Density/Compact String JEP 254 (update)

On 11/1/15 10:18 AM, Alan Bateman wrote: On 30/10/2015 21:30, Xueming Shen wrote: Hi, Thanks for the comments/suggestions. Here are the updated webrevs with minor changes here and there based on the feedback. I spent time going through the changes in jdk repo and it looks very good. One

Re: RFR: String Density/Compact String JEP 254 (update)

://javaweb.us.oracle.com/~tohartma/compact_strings/hotspot/ http://javaweb.us.oracle.com/~tohartma/compact_strings/hotspot_test_closed/ The code is ready for integration. The current plan is to integrate via the hotspot repo in coming week if it passes the PIT. Thanks -Sherman On 10/5/15 8:30 AM, Xueming

Re: RFR: 8066644: Fix deprecation warnings in jdk.zipfs module

On 10/28/2015 03:00 PM, Claes Redestad wrote: On 2015-10-27 16:37, Claes Redestad wrote: On 2015-10-27 15:09, Claes Redestad wrote: On 2015-10-27 14:40, Aleksey Shipilev wrote: On 10/24/2015 11:54 PM, Claes Redestad wrote: webrev: bug: https://bugs.openjdk.java.net/browse/JDK-8066644

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

n Oct 21, 2015, at 12:54 AM, Wang Weijun <weijun.w...@oracle.com> wrote: On Oct 21, 2015, at 3:17 PM, Xueming Shen <xueming.s...@oracle.com> wrote: We might want to bring in Max to take a look if what I said is really a supported use scenario. I haven't read Steve's latest code chan

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

ebrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/%7Epsandoz/multiversion-jar/jar-webrev/> Thanks, Steve On Oct 15, 2015, at 8:47 PM, Xueming Shen <xueming.s...@oracle.com <mailto:xueming.s...@oracle.com>> wrote: On 10/15/15 1:53 AM, Paul

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

On 10/16/15 4:49 AM, Claes Redestad wrote: On 2015-10-16 04:09, Xueming Shen wrote: On 10/15/15 3:08 PM, Claes Redestad wrote: On 2015-10-15 23:21, Chris Hegarty wrote: On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: Hello, This does change a bit the semantic of the length check

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

On 10/16/2015 3:20 PM, Claes Redestad wrote: On 2015-10-16 18:48, Xueming Shen wrote: looks fine. though it might be better to simply check len != b.length, as it's still possible that reallAllBytes returns a byte[] with length > len, if the entry is compressed, and the "length&q

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

On 10/16/15 9:24 AM, Claes Redestad wrote: On 2015-10-16 18:02, Xueming Shen wrote: Why do we no longer check the length of the returned byte[] from is.readAllBytes() against ze.getSize()? I think the original IOUtils.readFully() throws EOFE if we don't get enough bytes. Good catch

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

On 10/15/15 3:08 PM, Claes Redestad wrote: On 2015-10-15 23:21, Chris Hegarty wrote: On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: Hello, This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/15/15 1:53 AM, Paul Sandoz wrote: On 15 Oct 2015, at 05:00, Xueming Shen <xueming.s...@oracle.com> wrote: I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry to support this feature, given most of the

Re: RFR: 6907252: ZipFileInputStream Not Thread-Safe

On 10/14/15 6:20 AM, Seán Coffey wrote: Looking to tighten up access between the java and native level zip library calls. This extra check should ensure that we don't hit SEGV on thread races. I've also taken the opportunity to make the ZStreamRef address variable volatile. I'm still getting

Re: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8

On 10/14/2015 09:02 AM, Nikolay Gorshkov wrote: Please, review the following fix in core-libs area for the bug https://bugs.openjdk.java.net/browse/JDK-8133206 : http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.00/ The bug is a regression of the recent zlib 1.2.3 => 1.2.8 library

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Steve, Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? -Sherman On 10/14/2015 09:07 AM, Steve Drach wrote: Hi, Let’s try again, this time there are tests. Please review the following webrev that adds support for multi-release jars as specified in

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/14/15 4:04 PM, Steve Drach wrote: Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden? It didn’t seem necessary. The root entries are the “public interface”, we’re just providing aliased entry contents. It does not sound right. The "exported public

RFR: String Density/Compact String JEP 254

Hi, Please review the change for JEP 254/Compact String project. JPE 254: http://openjdk.java.net/jeps/254 Issue: https://bugs.openjdk.java.net/browse/JDK-8054307 Webrevs: http://cr.openjdk.java.net/~sherman/8054307/jdk/

RFR: String Density/Compact String JEP 254

Hi, Please review the change for JEP 254/Compact String project. JPE 254: http://openjdk.java.net/jeps/254 Issue: https://bugs.openjdk.java.net/browse/JDK-8054307 Webrevs: http://cr.openjdk.java.net/~sherman/8054307/jdk/

Re: RFR: JDK-8073187: Unexpected side effect in Pack200

looks good! sherman On 09/23/2015 10:42 AM, Kumar Srinivasan wrote: Hi John, Sherman, I noticed a flaw in my fix, ie. in a section of the logic that is present but unused, and reserved for future use, fixed it here anyway, for correctness. The full webrev:

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 9/15/15 9:48 PM, Stuart Marks wrote: On 9/10/15 2:12 PM, Xueming Shen wrote: I think it might be a "nice to have" for a "fail-fast" effort after the the consumer consumed/accepted the result (the second check), but isn't it a bug for the consumer to accept any re

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 09/16/2015 04:08 PM, Stuart Marks wrote: On 9/16/15 8:43 AM, Xueming Shen wrote: I'm talking about the check "immediately" prior to the call to accept(). It will not function after the modCount tips over to the negative int value, because the "expectedCount >=0" c

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 09/10/2015 01:22 PM, Stuart Marks wrote: On 9/9/15 3:51 PM, Xueming Shen wrote: One more comment regarding the CME check. 2829 if (expectedCount != modCount) { 2830 throw new ConcurrentModificationException(); 2831 } While

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 09/10/2015 01:55 PM, Paul Sandoz wrote: On 10 Sep 2015, at 22:22, Stuart Marks wrote: It'd be better to initialize expectedCount to modCount in constrocutor? That's how I had it initially, but at Paul Sandoz' suggestion I delayed the initialization to the first

Re: RFR(m) 2: 8072722: add stream support to Scanner

Hi Stuart, Can't modCount be increased to negative in extreme case? 2705 if (expectedCount>= 0&& expectedCount != modCount) { 2706 throw new ConcurrentModificationException(); 2707 } It'd be better to initialize expectedCount to modCount in

Re: RFR(m) 2: 8072722: add stream support to Scanner

sequential stream, this condition is always checked in the immediate next round of tryAdvance(). Just doubt it really benefits anyone. It's true that it almost costs nothing though. -Sherman On 09/09/2015 03:35 PM, Xueming Shen wrote: Hi Stuart, Can't modCount be increased to negative in ex

Re: RFR: 8134984: Text files should end in exactly one newline

On 09/02/2015 01:05 PM, Martin Buchholz wrote: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/one-newline/one-newline.patch https://bugs.openjdk.java.net/browse/JDK-8134984 Sherman, what's up with

RFR JDK-8039390: Unexpected behaviour of String.format with null arguments

Hi, Please help review fix for issue: https://bugs.openjdk.java.net/browse/JDK-8039390 webrev: http://cr.openjdk.java.net/~sherman/8039390 The j.u.Formatter implementation outputs null/Null for all conversions if the argument is null (except 'b'/'B', in which the result is false/FALSE).

Re: RFR 9: 8133022: Instant.toEpochMilli() silently overflows

looks good. On 8/6/15 11:07 AM, Roger Riggs wrote: Hi, Please review the update to include the additional case and fix. http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/ Thanks, Roger On 8/6/2015 12:37 PM, Roger Riggs wrote: Hi Ivan, I looked at that but didn't find a

RFR JDK-8022224: Intermittent test failures in sun/nio/cs/FindDecoderBugs.java, ,

Hi, Would you please help review the proposed change for JDK-804. issue: https://bugs.openjdk.java.net/browse/JDK-804 webrev: http://cr.openjdk.java.net/~sherman/804/ The fix for this particular problem is at ln#135-#137. The rest is the clean to remove unused the code (was for

Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale

On 07/30/2015 03:01 PM, David Holmes wrote: On 31/07/2015 1:41 AM, Xueming Shen wrote: On 07/30/2015 01:37 AM, Volker Simonis wrote: On Thu, Jul 30, 2015 at 9:51 AM, Alan Batemanalan.bate...@oracle.com wrote: On 30/07/2015 06:21, Xueming Shen wrote: : Each platform has a list of supported

Re: RFR(xs): 8132745: minor cleanup of java/util/Scanner/ScanTest.java

+1 On 07/30/2015 03:40 PM, Joseph D. Darcy wrote: Looks fine Stuart, -Joe On 7/30/2015 3:39 PM, Stuart Marks wrote: Hi all, Please review this quick cleanup to this test I moved into the open yesterday. It changes the JVM's locale, and out of an abundance of caution it's safer to run

Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale

that a charset is unsupported from our repository. -sherman Xueming Shen xueming.s...@oracle.com mailto:xueming.s...@oracle.com schrieb am Fr., 31. Juli 2015 00:35: On 07/30/2015 03:01 PM, David Holmes wrote: On 31/07/2015 1:41 AM, Xueming Shen wrote: On 07/30/2015 01:37 AM, Volker Simonis

RFR JDK-8080252: java.util.Formatter documentation of %n converter is misleading

Hi, Please help review the change for issue: https://bugs.openjdk.java.net/browse/JDK-8080252 webrev: http://cr.openjdk.java.net/~sherman/8080252/ It appears we updated the j.u.Formatter implementation to use the newly introduced method System.lineSeparator() in jdk7, but did not update the

Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale

On 7/29/15 2:23 AM, Volker Simonis wrote: On Tue, Jul 28, 2015 at 11:11 PM, Xueming Shen xueming.s...@oracle.com wrote: Volker, If fine with you I will re-open the gb18080 specific bug and fix it by adding the gb18030 into stdcs-solaris/linux and aix (does aix have a gb18030 locale

Re: RFR(s): 8132206: move ScanTest.java into OpenJDK

On 7/28/15 6:45 PM, Stuart Marks wrote: Hi all, Please review this small change to add a test for java.util.Scanner into OpenJDK. This test was inadvertently omitted from OpenJDK when the regression tests were migrated into the open. Bug: https://bugs.openjdk.java.net/browse/JDK-8132206

Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale

, it sounds to be implementation specific decision. Thanks Jonathan On Jul 29, 2015, at 4:56 AM, Xueming Shen xueming.s...@oracle.com wrote: yes, gb18030 needs to be in linux/unix std-solaris/unix as well. -sherman On 07/28/2015 09:51 AM, Volker Simonis wrote: Hi Jonathan, Alan, this is a known

Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale

On 7/29/15 9:53 PM, David Holmes wrote: Hi Sherman, On 30/07/2015 1:54 PM, Xueming Shen wrote: Here is the webrev to add those missing charsets. The assumption back then was that the linux platform has successfully migrated to the utf-8 default world. This process seems somewhat ad-hoc

Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale

Volker, If fine with you I will re-open the gb18080 specific bug and fix it by adding the gb18030 into stdcs-solaris/linux and aix (does aix have a gb18030 locale?). And keep the 8087171 open for a more general solution, such as using iconv for a IconvCharset -Sherman On 07/28/2015 09:51

Re: RFR: 8132459: ExceptionInInitializerError from 'java -version' on Linux under zh_CN.GB18030 locale

yes, gb18030 needs to be in linux/unix std-solaris/unix as well. -sherman On 07/28/2015 09:51 AM, Volker Simonis wrote: Hi Jonathan, Alan, this is a known problem and we've already discussed it intensively. Please have a look at: 8081674: EmptyStackException at startup if running with

Re: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455

On 7/17/15 8:45 AM, Xueming Shen wrote: On 7/17/15 1:04 AM, Peter Levart wrote: Hi Sherman, On 07/15/2015 09:10 PM, Xueming Shen wrote: Hi, Please help review the change for JDK-8130914. issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman

Re: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455

On 7/17/15 1:04 AM, Peter Levart wrote: Hi Sherman, On 07/15/2015 09:10 PM, Xueming Shen wrote: Hi, Please help review the change for JDK-8130914. issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/ This is a regression triggered

Re: RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455

the test without adding some explicit test that provoke this issue. It appears this existing test can easily catch the bug, so I just add the bugid to indicate that this regression test can be used for that particular bug. thanks, -sherman /Claes Xueming Shen xueming.s...@oracle.com skrev: (15

RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455

Hi, Please help review the change for JDK-8130914. issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/ This is a regression triggered by https://bugs.openjdk.java.net/browse/JDK-8130914

Re: RFR [S] 8131034: Cleanup in j.u.regex.Pattern.quote()

looks good. On 07/12/2015 09:32 AM, Ivan Gerasimov wrote: Hello! There's a minor issue in the current implementation of Pattern.quote() with possible numeric overflow when calculating initial capacity of StringBuilder. With the fix, some slight optimizations were done and a few typos were

Re: RFR [S] 6854417: TESTBUG: java/util/regex/RegExTest.java fails intermittently

On 07/12/2015 02:01 PM, Ivan Gerasimov wrote: Hello! RegExTest fails sometimes in checking Boyer-Moore search. This is because it was assumed that after insertion a pattern into a string at some position, we'll find it at the same position. That's not true if we insert 'aa' into 'xxaxx' at

Re: RFR 8124977 cmdline encoding challenges on Windows

Hi Kirk, Two questions (1) Why do you need to change the encoding used by the java.io.Console class. My understanding is that the console encoding is specifically used to talk to the underlying terminal, it should just be the one used by the underlying terminal/console. I don't

Re: RFR [XXS] 8130778: (str) Make AbstractStringBuilder.append(CharSequence, int, int) to throw StringIndexOutOfBoundsException

Hi, Arguably the StringIndexOutOfBoundsException should only be used when the index is out of a String (the builder included) boundary, but the offending object and the index here is CharSequence/index. The places that throw StringIndexoutOfBoundsException are all for the index/offset/length

Re: RFR JDK-8075526: Need a way to read and write time in UTC

On 07/06/2015 07:15 AM, Claes Redestad wrote: Hi, On 2015-07-01 19:05, Xueming Shen wrote: On 07/01/2015 05:02 AM, Claes Redestad wrote: Hi, On 2015-06-30 23:11, Xueming Shen wrote: Hi, Please help review and comment on this rfe. Issue: https://bugs.openjdk.java.net/browse/JDK-8075526

Re: RFR JDK-8075526: Need a way to read and write time in UTC

On 07/01/2015 05:02 AM, Claes Redestad wrote: Hi, On 2015-06-30 23:11, Xueming Shen wrote: Hi, Please help review and comment on this rfe. Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 webrev: http://cr.openjdk.java.net/~sherman/8075526 I think this looks reasonable. I think we

Re: RFR JDK-8075526: Need a way to read and write time in UTC

. Some nitpicks: TestLocalTime.java: 0. line 51, s/supoprt/support/ 1. line 63, you have a } out of place 2. line 71, misplaced , 3. line 111: extra LF. Thanks Kumar On 6/30/2015 2:11 PM, Xueming Shen wrote: Hi, Please help review and comment on this rfe. Issue: https://bugs.openjdk.java.net

RFR JDK-8075526: Need a way to read and write time in UTC

Hi, Please help review and comment on this rfe. Issue: https://bugs.openjdk.java.net/browse/JDK-8075526 webrev: http://cr.openjdk.java.net/~sherman/8075526 Background info: The title of the RFE is a little mis-leading. All the existing set/get date-time methods actually work with UTC time.

RFR JDK-8129544: ArrayIndexOutOfBoundsException when decoding corrupt Base64 string

Hi, Please help review the change for JDK-8129544. Issue: https://bugs.openjdk.java.net/browse/JDK-8129544 Webrev: http://cr.openjdk.java.net/~sherman/8129544 Thanks, -Sherman

Re: RFR 8080640: Reduce copying when reading JAR/ZIP entries

looks good! -Sherman On 06/23/2015 12:47 PM, Staffan Friberg wrote: Hi Sherman, Removed the check, http://cr.openjdk.java.net/~sfriberg/JDK-8080640/webrev.4 Cheers, Staffan On 06/23/2015 11:22 AM, Xueming Shen wrote: Hi Staffan, #527 check is probably unnecessary. The size and csize

RFR of 8074819: Resolve disabled warnings for libzip

Hi, Please help review the change to resolve the disabled parentheses warnings for libzip issue: https://bugs.openjdk.java.net/browse/JDK-8074819 webrev: http://cr.openjdk.java.net/~sherman/8074819 thanks, Sherman

Re: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset

On 06/09/2015 11:03 AM, Mandy Chung wrote: Does my patch work fine on 8u?If it works fine, I prefer to get that simple fix in 8u and take the time to have a better fix in 9 (jdk9 is still under development and I have assumed that it's not a show stopper to you. Let me know if it blocks

Re: RFR 8080640: Reduce copying when reading JAR/ZIP entries

you sponsor this change once it has been reviewed? Thanks, Staffan On 06/03/2015 10:45 AM, Xueming Shen wrote: Staffan, I'm not convinced that the benefit here is significant enough to change the getInputStream() to return a ByteArrayInputStream, given this can be easily achieved by wrapping

Re: RFR 8072773 (fs) Files.lines needs a better splitting implementation for stream source

On 06/03/2015 08:53 AM, Paul Sandoz wrote: Hi, Please review an optimization for Files.lines for certain charsets: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072773-File-lines/webrev/ If a charset is say US-ASCII or UTF-8 it is possible to implement an efficient splitting Spliterator

Re: Lower overhead String encoding/decoding

Richard, I'm still planning to be the sponsor for this RFE and get this one into the jdk9. We are current working on JEP 254 [1][2][3]in which the internal storage mechanism is changed from char[] to byte[]. If this JEP get approved and is scheduled to target JDK9, the decoding/encoding

Re: RFR 8080640: Reduce copying when reading JAR/ZIP entries

on this disagreement and move on with the agreed getBytes() for now. Thanks, -Sherman On 06/02/2015 10:27 AM, Staffan Friberg wrote: On 05/22/2015 01:15 PM, Staffan Friberg wrote: On 05/22/2015 11:51 AM, Xueming Shen wrote: On 05/22/2015 11:41 AM, Staffan Friberg wrote: On 05/21/2015 11:00 AM, Staffan

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

Ivan, The code looks fine for me. Just wonder what's the motivation of using the newStringUnsafe() in the test case. Simply to save the char[] copy to speed up the test? I don't think we really care about it here, right? -Sherman On 06/01/2015 11:53 AM, Ivan Gerasimov wrote: On

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

On 5/30/2015 11:38 PM, Peter Levart wrote: Hi, Yes, this one is much easier to grasp. As I understand the check is to avoid overflow in calculation of StringBuilder initial capacity (newLenHint). If overflow happened, newLenHint would be negative and StringBuilder construction would fail

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

On 5/30/15 7:19 PM, Ivan Gerasimov wrote: Hi everyone! Here's another webrev, in which replace() is implemented with StringBuilder. On my benchmark it is almost as fast as the version backed with arrays, but this variant is much shorter. Credits to Sherman for combining the general

Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext

It was originally written to be the base class for both std and ext charsets providers... maybe it should just be merged into the ExtendedCharsets class later separately. -sherman On 5/29/2015 12:04 AM, Alan Bateman wrote: On 29/05/2015 07:58, Xueming Shen wrote: Please help review change

RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext

Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules. issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 Thanks, -Sherman

Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext

On 05/29/2015 09:28 AM, Mandy Chung wrote: On 05/29/2015 12:20 AM, Xueming Shen wrote: It was originally written to be the base class for both std and ext charsets providers... maybe it should just be merged into the ExtendedCharsets class later separately. Perhaps better to merge it now

Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext

On 5/29/15 4:02 PM, Ulf Zibis wrote: Am 29.05.2015 um 19:42 schrieb Xueming Shen: But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ... Hm

Re: RFR JDK-8038310: Re-examine integration of extended Charsets

On 5/28/15 12:46 AM, Alan Bateman wrote: On 27/05/2015 20:09, Xueming Shen wrote: Hi, Please help review the change of changing the hard-wired extended charsets loading mechanism to ServiceLoader.loadInstalled(), for the module system. With the fix for JDK-8069588 in JDK 9 all charsets

Re: RFR JDK-8038310: Re-examine integration of extended Charsets

On 05/28/2015 09:05 AM, Mandy Chung wrote: On 05/28/2015 08:53 AM, Xueming Shen wrote: http://cr.openjdk.java.net/~sherman/8069588_8038310/webrev This change looks okay. This code optimizes for space and assumes one single installed provider which I am not sure if it buys us much

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

targLen = max(1, tagLen); ? On 05/27/2015 10:59 AM, Ivan Gerasimov wrote: On 27.05.2015 20:40, Xueming Shen wrote: The .append(srepl) - append(srep.value) And I would simply remove the fastpath for the target.length() = 0 special case ... And maybe pick an appropriate initial size

RFR JDK-8038310: Re-examine integration of extended Charsets

Hi, Please help review the change of changing the hard-wired extended charsets loading mechanism to ServiceLoader.loadInstalled(), for the module system. With the fix for JDK-8069588 in JDK 9 all charsets needed to startup in supported environments are in the base module. This change is to

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

-igerasim_2015_05_27_14_47-b00, mixed mode) 25) 100663296 real0m2.585s user0m1.875s sys0m0.887s Sincerely yours, Ivan On 27.05.2015 2:38, Xueming Shen wrote: Ivan, It might be worth trying String.index + StringBuilder, instead of writing/handling everything yourself. Yes, it inevitably adds an arraycopy

Re: RFR JDK-8028480: (zipfs) NoSuchFileException on creating a file in ZipFileSystem with CREATE and WRITE

On 5/27/15 8:27 AM, Alan Bateman wrote: On 26/05/2015 20:23, Xueming Shen wrote: Hi, Please help review the changes for JDK-8028480 and JDK-8034773 issues: https://bugs.openjdk.java.net/browse/JDK-8028480 https://bugs.openjdk.java.net/browse/JDK-8034773 webrev: http://cr.openjdk.java.net

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

); i = j + targLen; } while ((j = indexOf(starget, i)) 0); return sb.append(this, i, length()).toString(); } -Sherman On 05/27/2015 10:06 AM, Ivan Gerasimov wrote: On 27.05.2015 18:44, Xueming Shen wrote: You might want to use directly sb.append.(char[], off, len

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

On 05/27/2015 12:43 PM, Ivan Gerasimov wrote: On 27.05.2015 21:08, Xueming Shen wrote: targLen = max(1, tagLen); ? Well, almost :) With such targLen, (i = j + targLen) would result in i == length() + 1, which will cause IOOBE in the following append(). I'm sure the algorithms can

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

On 05/27/2015 01:10 PM, Xueming Shen wrote: On 05/27/2015 12:43 PM, Ivan Gerasimov wrote: On 27.05.2015 21:08, Xueming Shen wrote: targLen = max(1, tagLen); ? Well, almost :) With such targLen, (i = j + targLen) would result in i == length() + 1, which will cause IOOBE in the following

RFR JDK-8028480: (zipfs) NoSuchFileException on creating a file in ZipFileSystem with CREATE and WRITE

Hi, Please help review the changes for JDK-8028480 and JDK-8034773 issues: https://bugs.openjdk.java.net/browse/JDK-8028480 https://bugs.openjdk.java.net/browse/JDK-8034773 webrev: http://cr.openjdk.java.net/~sherman/8028480_8034773/ Thanks, -Sherman

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

Ivan, It might be worth trying String.index + StringBuilder, instead of writing/handling everything yourself. Yes, it inevitably adds an arraycopy at the end to convert the StrinbBuilder to String, but it might have better balance between performance and code complexity. The regex is probably

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

On 5/26/15 10:08 AM, Ivan Gerasimov wrote: Thank you Roger for looking at this! On 26.05.2015 19:40, Roger Riggs wrote: Hi Ivan, Did you consider doing the optimization inside of Pattern.compile/replaceAll. That would have a broader impact and benefit. In Pattern.compile the flag LITERAL

RFR JDK-8042125: Japanese character converters incompatible between Java 7 and Java 8

Hi Please help the change for 8042125 issue: https://bugs.openjdk.java.net/browse/JDK-8042125 webrev: http://cr.openjdk.java.net/~sherman/8042125 It's a regression caused by the changes of JDK-6653797. The direct triggers are (1) the .c2b mapping table for ms932/0208is missing (regardless the

RFR: JDK-8064736: Part of java.util.jar.JarFile spec looks confusing with references to Zip

Hi Some doc update/typo fixes. issue: https://bugs.openjdk.java.net/browse/JDK-8064736 webrev: http://cr.openjdk.java.net/~sherman/8064736 Thanks, -Sherman

RFR JDK-8060161: re-examine sun/nio/cs/Test4200310.sh, test is invalid for modular image

Alan, I agree that we should just remove this old regression test. It does not server an purpose after those jar files are gone. Please help review. issue: https://bugs.openjdk.java.net/browse/JDK-8060161 webrev: http://cr.openjdk.java.net/~sherman/8060161/ -Sherman

<    1   2   3   4   5   6   7   8   9   10   >