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

Hello! An AbstractStringBuilder#compareTo implementation is wrong. You cannot simply compare the whole byte array. Here's the test-case: public class Test { public static void main(String[] args) { StringBuilder sb1 = new StringBuilder("test1"); StringBuilder sb2 = new

Re: Cannot add attribute into main attributes of a jar if there is no version

On 1/29/18, 4:57 PM, mandy chung wrote: On 1/29/18 4:22 PM, Weijun Wang wrote: Ping again. On Jan 22, 2018, at 1:12 PM, Weijun Wang wrote: src/java.base/share/classes/java/util/jar/Attributes.java: 329@SuppressWarnings("deprecation") 330void

Re: Cannot add attribute into main attributes of a jar if there is no version

> On Jan 30, 2018, at 8:57 AM, mandy chung wrote: > > > > On 1/29/18 4:22 PM, Weijun Wang wrote: >> Ping again. >> >> >>> On Jan 22, 2018, at 1:12 PM, Weijun Wang >>> wrote: >>> >>>

Re: Cannot add attribute into main attributes of a jar if there is no version

On 1/29/18 4:22 PM, Weijun Wang wrote: Ping again. On Jan 22, 2018, at 1:12 PM, Weijun Wang wrote: src/java.base/share/classes/java/util/jar/Attributes.java: 329 @SuppressWarnings("deprecation") 330 void writeMain(DataOutputStream out) throws

Re: Cannot add attribute into main attributes of a jar if there is no version

Ping again. > On Jan 22, 2018, at 1:12 PM, Weijun Wang wrote: > > src/java.base/share/classes/java/util/jar/Attributes.java: > > 329 @SuppressWarnings("deprecation") > 330 void writeMain(DataOutputStream out) throws IOException > 331 { > 332

Re: RFR: 8196331: Optimize Character.digit for latin1 input

Hi, you may can construct the lookup table as a static String constant to slim down the footprint and treat it as a byte[] as we do in the Charset coders. -Ulf Am 29.01.2018 um 22:04 schrieb Claes Redestad: I'll experiment and analyze a bit more tomorrow to see if I can find a good

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

On Jan 29, 2018, at 4:00 PM, John Rose wrote: > > Then the various array-backed implementations > (and their sublists) would simply override their respective > stream views. BTW, this notion is more general than you might think. It applies to collections, like the

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

Reviewed (officially). This is a good point-fix. — John P.S. I still think we have some tech. debt to discharge in finding a way to generically provide zero-copy access to array data, across interoperating collections APIs. If we got the deeper, more general answer right, we would be able to

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

> On Jan 29, 2018, at 3:30 PM, Martin Buchholz wrote: > > > > On Mon, Jan 29, 2018 at 3:10 PM, Paul Sandoz > wrote: > > > > On Jan 29, 2018, at 1:02 PM, Martin Buchholz >

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

On Mon, Jan 29, 2018 at 3:10 PM, Paul Sandoz wrote: > > > > On Jan 29, 2018, at 1:02 PM, Martin Buchholz > wrote: > > > > I'm going to expedite this a little since we are building further changes > > on top. > > > > RFR: jsr166 jdk integration

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

> On Jan 29, 2018, at 1:02 PM, Martin Buchholz wrote: > > I'm going to expedite this a little since we are building further changes > on top. > > RFR: jsr166 jdk integration 2018-02 > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html >

Re: JDK-8196298: Add null Reader and Writer

I made a few minor changes to the CSR [1] verbiage. Probably the nullWriter() documentation should also be updated to explicitly mention all variants of both append() and write(). Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8196350 On Jan 29, 2018, at 12:58 PM, Brian

Re: RFR: 8196331: Optimize Character.digit for latin1 input

Right, I can't really explain why, but the effect is very visible and reproducible in microbenchmarks. Differences in generated ASM might be indicating that the inlining behavior changes enough to shift the result around; maybe a job for @ForceInline? I'll experiment and analyze a bit more

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

I'm going to expedite this a little since we are building further changes on top. RFR: jsr166 jdk integration 2018-02 http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8196207: Inefficient ArrayList.subList().toArray()

Re: JDK-8196298: Add null Reader and Writer

Great - thanks - will take a look. Brian On Jan 29, 2018, at 11:43 AM, Patrick Reinhart wrote: > Just added a new CSR for it based on the one for InputStream/OutputStream...

Re: RFR[JDK10]: 8195837: (tz) Support tzdata2018c

Looks good to me. Naoto On 1/29/18 12:49 AM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA integration (tzdata2018c) into JDK10. Bug: https://bugs.openjdk.java.net/browse/JDK-8195837 Webrev: http://cr.openjdk.java.net/~rpatil/8195837/webrev.00/ All the TimeZone related tests

Re: JDK-8196298: Add null Reader and Writer

Just added a new CSR for it based on the one for InputStream/OutputStream... -Patrick Am 29.01.2018 um 17:14 schrieb Brian Burkhalter: > Hi Patrick, > > Conceptually this looks good. There might be some javadoc tweaks > needed but those can be worked out while this is a draft CSR (to be >

Re: RFR: 8196331: Optimize Character.digit for latin1 input

Smaller in only the upper bound? I would an explicit upper bounds check would dominate that of the bounds check for the array itself. Paul. > On Jan 29, 2018, at 11:37 AM, Claes Redestad > wrote: > > I ran with a smaller byte[] initially and saw about a 10%

Re: RFR: 8196331: Optimize Character.digit for latin1 input

I ran with a smaller byte[] initially and saw about a 10% improvement from removing the branch, which is why I felt the superfluous bytes were motivated. /Claes Paul Sandoz skrev: (29 januari 2018 19:14:44 CET) > > >> On Jan 29, 2018, at 9:44 AM, Martin Buchholz

JDK-8196298: Add null Reader and Writer

Hi there, I saw that great extension on InputStream/OutputStream adding a Null implementation there. Based on those I would propose a similar addition to the Reader/Writer. -Patrick Here is what the API would look like based on the existing from InputStream/OutputStream:     /** *

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

Hi, Looks good. Base64.java: line 120  typo:  "outputut" -> "output" Roger On 1/29/2018 1:20 PM, Paul Sandoz wrote: +1 We will require a CSR for the minor adjustment to the specification. Paul. On Jan 29, 2018, at 9:52 AM, Xueming Shen wrote: On 01/26/2018

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

+1 We will require a CSR for the minor adjustment to the specification. Paul. > On Jan 29, 2018, at 9:52 AM, Xueming Shen wrote: > > On 01/26/2018 03:53 PM, Paul Sandoz wrote: >> >> Base64 >> — >> >> 138 lineLength = lineLength >> 2 << 2; >> >> I know the code was

Re: RFR: 8196331: Optimize Character.digit for latin1 input

> On Jan 29, 2018, at 9:44 AM, Martin Buchholz wrote: > > Thanks. I might try to shrink the size of the static array, by only > storing values between '0' and 'z', at the cost of slightly greater lookup > costs for each char. > I was wondering the same, or just clip the

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

On 01/26/2018 03:53 PM, Paul Sandoz wrote: 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 sure, we can go the straightforward bit

Re: RFR: 8196331: Optimize Character.digit for latin1 input

Thanks. I might try to shrink the size of the static array, by only storing values between '0' and 'z', at the cost of slightly greater lookup costs for each char. On Mon, Jan 29, 2018 at 3:15 AM, Claes Redestad wrote: > Hi, > > for the latin1 block of CharacterData

Re: RFR[JDK10]: 8195837: (tz) Support tzdata2018c

Google has been successfully running jdk8 and jdk9 with 2018c. On Mon, Jan 29, 2018 at 12:49 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2018c) into JDK10. > Bug: https://bugs.openjdk.java.net/browse/JDK-8195837 > Webrev:

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

That’s better :-) If you wanna make it static i suggest: s/inputFileName/INPUT_FILE_NAME although there is little benefit here since all access is local to main. Up to you to make local or keep static. No need for another review. Paul. > On Jan 29, 2018, at 4:17 AM, Amy Lu

Re: RFR[JDK10]: 8195837: (tz) Support tzdata2018c

On 29 January 2018 at 14:42, Seán Coffey wrote: > The changes look fine to me Ramanand. The europe file contains some > interesting comments about the rolled back changes that have been made for > 2018c. A plan on how to resolve these pending changes can be followed up via

Re: JDK-8196298: Add null Reader and Writer

Hi Patrick, Conceptually this looks good. There might be some javadoc tweaks needed but those can be worked out while this is a draft CSR (to be filed). Thanks, Brian On Jan 27, 2018, at 12:45 AM, Patrick Reinhart wrote: > I saw that great extension on

Re: RFR[JDK10]: 8195837: (tz) Support tzdata2018c

The changes look fine to me Ramanand. The europe file contains some interesting comments about the rolled back changes that have been made for 2018c. A plan on how to resolve these pending changes can be followed up via JDK-8195595 Regards, Sean. On 29/01/18 08:49, Ramanand Patil wrote: Hi

Re: RFR JDK-8194412 : Adding 256 units of IsoFields.QUARTER_YEARS broken

Hi Ivan, Looks good! Thanks, Roger On 1/28/2018 6:09 PM, Stephen Colebourne wrote: Spelling mistake in tests "qarterYears" Otherwise, looks good. thanks Stephen On 27 January 2018 at 19:37, Ivan Gerasimov wrote: Hello! It was spotted that adding more then 255

Re: Optimizing UUID#fromString(String)

Awesome. Excited to see the Character.digit improvements! To set expectations from here, I'll need to do two things to move forward: 1. I need to sign the OCA, as you've pointed out. As a courtesy, I'd like to alert my employer before doing so. This has been a non-issue for similar agreements

Re: Clarification for adding classes shipped with JDK to sun.rmi.registry.registryFilter property in java.security file

Hi Roger, Thank you for your inputs. I agree with you that logging the filtering action can help developers to easily identify the classes which are failed due to the new filtering mechanism. However, it may not be fair to ask the application developers to add the basic JDK classes when

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

Updated on the inputFileName. Please review: http://cr.openjdk.java.net/~amlu/8196211/webrev.01/ Thanks, Amy On 27/01/2018 2:32 AM, Paul Sandoz wrote: Hi, Quick observation. EUCTWBufferBoundaryDecodeTest uses a different data file on windows and it uses the line separator as a trigger. Is

Re: Optimizing UUID#fromString(String)

Hi, I've filed two RFEs: - https://bugs.openjdk.java.net/browse/JDK-8196331 for providing a   fast-path for ASCII/Latin1 input to Character.digit. Patch out   for review - https://bugs.openjdk.java.net/browse/JDK-8196334 for tracking   the optimizations specific to UUID proposed here Jon, if

RFR: 8196331: Optimize Character.digit for latin1 input

Hi, for the latin1 block of CharacterData we can improve the digit(int, int) implementation by providing an optimized lookup table. This improves microbenchmarks exercising Integer.parseInt, Long.parseLong and UUID.fromString etc by around 50%for typical inputs. Webrev:

RFR[JDK10]: 8195837: (tz) Support tzdata2018c

Hi all, Please review the latest TZDATA integration (tzdata2018c) into JDK10. Bug: https://bugs.openjdk.java.net/browse/JDK-8195837 Webrev: http://cr.openjdk.java.net/~rpatil/8195837/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.