Re: Oracle Java 8u161 regression in XML Schema Factory

Thanks Sean. It's more likely a JDK issue because my coworker simply swapped the JAVA_HOME from 8u161 which failed with that error to 8u151 and it worked fine. I'll ask if he's got the cycles to distill a reproducer. If he does I'll open a JBS ticket. Thanks, Kris On Fri, Jan 26, 2018 at 12:06

Re: [PATCH] Inefficient ArrayList.subList().toArray()

Thanks for quick review! Indeed, there must be checkForComodification() at the beginning of each method, my bad. Btw, ArrayList produced by java.util.Arrays.asList() is also RandomAccess and array-based but has no custom implementation of subList(). Could we apply the same approach for

Re: Oracle Java 8u161 regression in XML Schema Factory

I don't see them being related with data given below. Maybe there's a classpath configuration issue ? If you feel there's a bug in the JDK libraries, please report it via https://bugs.java.com/ regards, Sean. On 26/01/2018 00:23, Krystal Mok wrote: Hi guys, A coworker of mine had hit this

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Joe, 1. Seems odd that StringBuilder and StringBuffer are comparable but don't have an equals/hashcode implementation. Seems like if you are to stick with that you'll have to add the standard "natural ordering is inconsistent with equals" verbiage. 2. For StringBuffer compare, won't you have to

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Just to note that JSR-310 had to add a CharSequence comparison method. Not the same as this one, but a data point, and perhaps a target to become public in a future webrev. See DateTimeParseContext.subSequenceEquals(). Stephen On 26 January 2018 at 03:00, Joe Wang

Re: [PATCH] Inefficient ArrayList.subList().toArray()

On 2018-01-26 07:20, Martin Buchholz wrote: It's still possible to find simple performance improvements in classes like ArrayList. Indeed! It seems ArrayList.SubList delegates quite a few of its implementations to AbstractList and AbstractCollection, which uses iterators for things that could

[8u-dev] RFR - 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

Hi folks, I'd like to backport this change to 8u-dev. The changes are straightforward enough but 8u needs some changes that were made to InnocuousThread. (strictly it doesn't need all of the changes I've made but I've made an effort to make the code look as close to 9 as possible) bug:

Re: [PATCH] Inefficient ArrayList.subList().toArray()

It may be that array-backed lists inheriting from AbstractList is not useful except when creating a prototype (or as a way of testing AbstractList!) because a high-quality implementation should always override. On Fri, Jan 26, 2018 at 5:31 AM, Claes Redestad wrote: >

Re: [JDK 11] RFR 8196211: Move two sun/nio/cs tests into OpenJDK

Hi, Quick observation. EUCTWBufferBoundaryDecodeTest uses a different data file on windows and it uses the line separator as a trigger. Is it possible to better formalize this by passing in the argument for the file via jtreg? Paul. > On Jan 25, 2018, at 11:45 PM, Amy Lu

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Thanks Stephen for the note. I downloaded the api [1], but don't seem to see a class "DateTimeParseContext". Do you have a pointer to the current webrev? What does it do, and what would be the implication with regards to the CharSequence compare method? [1]

RFR: 8179294 several langtools tests depend on jar but do not declare that dependency

Hi, Please review fix which adds absent module dependencies in Pack200 and Jlink tests. http://cr.openjdk.java.net/~anazarov/JDK-8179294/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8179294 —Thanks, Andrei

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

java.time.format.DateTimeParseContext.subSequenceEquals On 1/26/18, 1:48 PM, huizhe wang wrote: Thanks Stephen for the note. I downloaded the api [1], but don't seem to see a class "DateTimeParseContext". Do you have a pointer to the current webrev? What does it do, and what would be the

Re: RFR: 8179294 several langtools tests depend on jar but do not declare that dependency

Added test from duplicated issue http://cr.openjdk.java.net/~anazarov/JDK-8179294/webrev.01/ —Andrei > On 26 Jan 2018, at 15:17, Andrey Nazarov wrote: > > Hi, > > Please review fix which adds absent

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Thanks for the comments, Jason. The topic about equals/hashcode had been discussed. They are currently inherited, and by definition of CharSequence, equality is generally undefined. One could argue for it to be a lexicographic comparison, but that means changing the current specification,

Re: RFR: 8179294 several langtools tests depend on jar but do not declare that dependency

the fix looks good to me. -- Igor > On Jan 26, 2018, at 3:25 PM, Andrey Nazarov > wrote: > > Added test from duplicated issue > http://cr.openjdk.java.net/~anazarov/JDK-8179294/webrev.01/ > > >

Re: RFR JDK-8176379: java.util.Base64 mime encoder behaves incorrectly if initialized with a line length of size 1-3

Base64 — 138 lineLength = lineLength >> 2 << 2; I know the code was shuffled up but i find the following clearer in terms of bit manipulation: // Round down to nearest mulitple of 4 lineLength &= ~0b11 TestBase64 — Is there a test passing in a negative value for len? Thanks, Paul. >

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Thanks Sherman.  Found it now.  Interesting method. What was the motivation? Does any class implement CharSequence in 310? Best, Joe On 1/26/2018 2:12 PM, Xueming Shen wrote: java.time.format.DateTimeParseContext.subSequenceEquals On 1/26/18, 1:48 PM, huizhe wang wrote: Thanks Stephen for

RFR JDK-8176379: java.util.Base64 mime encoder behaves incorrectly if initialized with a line length of size 1-3

Hi, Please help review the change for JDK-8176379 issue: https://bugs.openjdk.java.net/browse/JDK-8176379 webrev: http://cr.openjdk.java.net/~sherman/8176379/webrev It appears the spec is somewhat misleading and/or incorrect in this corner case. And the implementation of the mime type encoder