Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

2017-07-23 Thread Ivan Gerasimov 

Thank you Jonathan for looking into that!

I agree with all your suggestions.

Here's the updated webrev with suggested modifications:
WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/02/webrev/

With kind regards,
Ivan

On 7/23/17 3:56 AM, Jonathan Bluett-Duncan wrote:

Meant to reply to core-libs-dev as well; doing so now.

Jonathan

On 23 July 2017 at 11:50, Jonathan Bluett-Duncan 
> wrote:


Hi Ivan,

I'm not a reviewer per se, but I thought I'd chime in.

There's a few things with Comparator.java which I think could be
improved:

 1. `comparingNumericallyLeadingZerosAhead()` is a confusing name
for me, as the "ahead" has no meaning in my mind; IMO the name
`comparingNumericallyLeadingZerosFirst()` better implies that
"0001" < "001" < "01".
 2. It wasn't clear to me from the javadoc that the comparators
compare strings like "abc9" and "abc10" as "abc9" < "abc10",
so I think they should include more examples.
 3. There's a typo in the javadocs for both methods: "represets"
--> "represents".
 4. Where the javadocs say "follows the procedure", I think it'd
make more grammatical sense if they said "does the following".
 5. The lines which say "at the boundary of a subsequence,
consisting of decimal digits, the" would flow better if they
said "at the boundary of a subsequence *consisting solely of
decimal digits*, then the". Note the removal of the comma
between "subsequence" and "consisting".

Hope this helps!

Jonathan

On 23 July 2017 at 05:36, Ivan Gerasimov
> wrote:

Hello!

This is a gentle reminder.

The proposed comparator implementation would be particularly
useful when one will need to compare version strings.
Some popular file managers also use similar comparing
algorithm, as the results often look more natural to the human
eyes (e.g. File Explorer on Windows, Files on Ubuntu).

Now, as Java 10 is been worked on, to sort the list of Java
names correctly, this kind of comparator is needed:

Look: a list { ... "Java 8", "Java 9", "Java 10" } definitely
looks nicer than { "Java 1", "Java 10", "Java 2", ... }  :-)

Would you please help review the proposal?

With kind regards,
Ivan



On 7/19/17 1:41 AM, Ivan Gerasimov wrote:

Hello!

It is a proposal to provide a String comparator, which
will pay attention to the numbers embedded into the
strings (should they present).

This proposal was initially discussed back in 2014 and
seemed to bring some interest from the community:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html




In the latest webrev two methods are added to the public API:
j.u.Comparator.comparingNumerically() and
j.u.Comparator.comparingNumericallyLeadingZerosAhead().

The regression test is extended to exercise this new
comparator.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512

WEBREV:
http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/


Comments, suggestions are very welcome!


-- 
With kind regards,

Ivan Gerasimov





--
With kind regards,
Ivan Gerasimov

[10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

2017-07-23 Thread Claes Redestad 

Hi,

java.lang.CharacterDataLatin1 and others are generated at build time by 
the GenerateCharacter tool, which has a -string mode to generate lookup 
tables as Strings literals rather than arrays directly. This serves 
multiple purposes:


1. it reduces the size of the generated bytecode, which is necessary to 
keep code below method bytecode limits if the arrays generated are very 
large
2. it may under certain circumstances (large enough arrays, JITed code) 
be a performance optimization


While having other performance benefits, the compact strings feature 
that went into 9 made String::toCharArray less friendly to startup, and 
since the same feature means we're now always loading 
CharacterDataLatin1 on bootstrap in all locales it seemed reasonable to 
re-examine whether this class in particular really gains from generating 
its lookup tables via String literals.


Turns out it doesn't. By generating CharacterDataLatin1 tables as arrays 
explicitly:


- executed bytecode drop from 21,782 to 2,077 when initializing this 
class (approximately 2% of executed bytecode; 1.5% of total instructions)

- slight reduction (~1Kb) in the minimum retained heap usage
- the size of CharacterDataLatin1.class only grows from 6458 to 7385 bytes

Proposed patch is to drop passing -string to GenerateCharacter for the 
latin1 case:


Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/
Bug:https://bugs.openjdk.java.net/browse/JDK-8185104

Thanks!

/Claes

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

2017-07-23 Thread Jonathan Bluett-Duncan 
Meant to reply to core-libs-dev as well; doing so now.

Jonathan

On 23 July 2017 at 11:50, Jonathan Bluett-Duncan 
wrote:

> Hi Ivan,
>
> I'm not a reviewer per se, but I thought I'd chime in.
>
> There's a few things with Comparator.java which I think could be improved:
>
>1. `comparingNumericallyLeadingZerosAhead()` is a confusing name for
>me, as the "ahead" has no meaning in my mind; IMO the name `
>comparingNumericallyLeadingZerosFirst()` better implies that "0001" <
>"001" < "01".
>2. It wasn't clear to me from the javadoc that the comparators compare
>strings like "abc9" and "abc10" as "abc9" < "abc10", so I think they should
>include more examples.
>3. There's a typo in the javadocs for both methods: "represets" -->
>"represents".
>4. Where the javadocs say "follows the procedure", I think it'd make
>more grammatical sense if they said "does the following".
>5. The lines which say "at the boundary of a subsequence, consisting
>of decimal digits, the" would flow better if they said "at the boundary of
>a subsequence *consisting solely of decimal digits*, then the". Note
>the removal of the comma between "subsequence" and "consisting".
>
> Hope this helps!
>
> Jonathan
>
> On 23 July 2017 at 05:36, Ivan Gerasimov 
> wrote:
>
>> Hello!
>>
>> This is a gentle reminder.
>>
>> The proposed comparator implementation would be particularly useful when
>> one will need to compare version strings.
>> Some popular file managers also use similar comparing algorithm, as the
>> results often look more natural to the human eyes (e.g. File Explorer on
>> Windows, Files on Ubuntu).
>>
>> Now, as Java 10 is been worked on, to sort the list of Java names
>> correctly, this kind of comparator is needed:
>>
>> Look: a list { ... "Java 8", "Java 9", "Java 10" } definitely looks nicer
>> than { "Java 1", "Java 10", "Java 2", ... }  :-)
>>
>> Would you please help review the proposal?
>>
>> With kind regards,
>> Ivan
>>
>>
>>
>> On 7/19/17 1:41 AM, Ivan Gerasimov wrote:
>>
>>> Hello!
>>>
>>> It is a proposal to provide a String comparator, which will pay
>>> attention to the numbers embedded into the strings (should they present).
>>>
>>> This proposal was initially discussed back in 2014 and seemed to bring
>>> some interest from the community:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-De
>>> cember/030343.html
>>>
>>> In the latest webrev two methods are added to the public API:
>>> j.u.Comparator.comparingNumerically() and
>>> j.u.Comparator.comparingNumericallyLeadingZerosAhead().
>>>
>>> The regression test is extended to exercise this new comparator.
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/
>>>
>>> Comments, suggestions are very welcome!
>>>
>>>
>> --
>> With kind regards,
>> Ivan Gerasimov
>>
>>
>