Re: RFR: JDK-8185758: jdk.smartcardio has broken docs for exceptions

[Mandy Chung]

> On Aug 2, 2017, at 4:21 PM, Jonathan Gibbons  
> wrote:
> 
> (I'm not sure if there is a better list for this request, but the request is 
> so simple, I'm hoping it will be sufficient.
> 
> Please review this very simple fix to replace two uses of ... 
> with {@code...}.
> 
> The underlying problem being fixed is incorrect handling of the first 
> sentence in a couple of cases, due to the presence of a '?' in the code 
> expression.  The doclet was treating the ? as terminating the first sentence, 
> leading to confusing output, and incorrect HTML being generated.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8185758
> Webrev: http://cr.openjdk.java.net/~jjg/8185758/webrev.00/

Looks good.

Mandy

Re: RFR: JDK-8185758: jdk.smartcardio has broken docs for exceptions

[Ivan Gerasimov]

The change looks good!

With kind regards,

Ivan


On 8/2/17 4:21 PM, Jonathan Gibbons wrote:
(I'm not sure if there is a better list for this request, but the 
request is so simple, I'm hoping it will be sufficient.


Please review this very simple fix to replace two uses of 
... with {@code...}.


The underlying problem being fixed is incorrect handling of the first 
sentence in a couple of cases, due to the presence of a '?' in the 
code expression.  The doclet was treating the ? as terminating the 
first sentence, leading to confusing output, and incorrect HTML being 
generated.


JBS: https://bugs.openjdk.java.net/browse/JDK-8185758
Webrev: http://cr.openjdk.java.net/~jjg/8185758/webrev.00/

-- Jon

RFR: JDK-8185758: jdk.smartcardio has broken docs for exceptions

[Jonathan Gibbons]

(I'm not sure if there is a better list for this request, but the 
request is so simple, I'm hoping it will be sufficient.


Please review this very simple fix to replace two uses of 
... with {@code...}.


The underlying problem being fixed is incorrect handling of the first 
sentence in a couple of cases, due to the presence of a '?' in the code 
expression.  The doclet was treating the ? as terminating the first 
sentence, leading to confusing output, and incorrect HTML being generated.


JBS: https://bugs.openjdk.java.net/browse/JDK-8185758
Webrev: http://cr.openjdk.java.net/~jjg/8185758/webrev.00/

-- Jon

Re: [10] RFR 8185754 : Typo in java.util.regex.Pattern javadoc: no slash in \p class

[Ivan Gerasimov]

Thanks!

Pushed.


On 8/2/17 4:00 PM, Brian Burkhalter wrote:

Hi Ivan,

These look fine.

Brian

On Aug 2, 2017, at 3:36 PM, Ivan Gerasimov > wrote:



Would you please help review the fix?

--- a/src/java.base/share/classes/java/util/regex/Pattern.java
+++ b/src/java.base/share/classes/java/util/regex/Pattern.java
@@ -667,11 +667,11 @@
 […]
- * A decimal digit character:{@code p{IsDigit}}
+ * A decimal digit character:{@code \p{IsDigit}}
[…]
- * A punctuation character:{@code p{IsPunctuation}}
+ * A punctuation character:{@code \p{IsPunctuation}}




--
With kind regards,
Ivan Gerasimov

Re: [10] RFR 8185754 : Typo in java.util.regex.Pattern javadoc: no slash in \p class

[Brian Burkhalter]

Hi Ivan,

These look fine.

Brian

On Aug 2, 2017, at 3:36 PM, Ivan Gerasimov  wrote:

> Would you please help review the fix?
> 
> --- a/src/java.base/share/classes/java/util/regex/Pattern.java
> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java
> @@ -667,11 +667,11 @@
>  […]
> - * A decimal digit character:{@code p{IsDigit}}
> + * A decimal digit character:{@code \p{IsDigit}}
> […]
> - * A punctuation character:{@code p{IsPunctuation}}
> + * A punctuation character:{@code \p{IsPunctuation}}

[10] RFR 8185754 : Typo in java.util.regex.Pattern javadoc: no slash in \p class

[Ivan Gerasimov]

Hello!

A couple of typos was spotted in the javadoc.

Would you please help review the fix?

diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java 
b/src/java.base/share/classes/java/util/regex/Pattern.java

--- a/src/java.base/share/classes/java/util/regex/Pattern.java
+++ b/src/java.base/share/classes/java/util/regex/Pattern.java
@@ -667,11 +667,11 @@
  * {@code \p{Alpha}}
  * An alphabetic character:{@code \p{IsAlphabetic}}
  * {@code \p{Digit}}
- * A decimal digit character:{@code p{IsDigit}}
+ * A decimal digit character:{@code \p{IsDigit}}
  * {@code \p{Alnum}}
  * An alphanumeric character:{@code 
[\p{IsAlphabetic}\p{IsDigit}]}

  * {@code \p{Punct}}
- * A punctuation character:{@code p{IsPunctuation}}
+ * A punctuation character:{@code \p{IsPunctuation}}
  * {@code \p{Graph}}
  * A visible character: {@code 
[^\p{IsWhite_Space}\p{gc=Cc}\p{gc=Cs}\p{gc=Cn}]}

  * {@code \p{Print}}


--
With kind regards,
Ivan Gerasimov

Re: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush

[Roger Riggs]

Hi Daniel,

Yep, it does not try/need to handle the case where a prefix of the match 
appears within the match.
When a mismatch is detected, it starts fresh for a match. Someday, it 
may need an upgrade,

but for now its sufficient.

Thanks, Roger


On 8/2/2017 11:43 AM, Daniel Fuchs wrote:

Hi Roger,

On 02/08/2017 16:32, Roger Riggs wrote:

Hi Daniel,

I considered keeping track of the partial match across the flush, but 
it could only work
if the partial match was a prefix of the replacement string. It got 
complicated quickly.


Since this is used (only) for RMI, in which flushes are used at the 
end of messages, it seemed
sufficient to document it as not working across flushes and with a 
debug message

if flush was in the middle of a partial match.


OK, looks good then.
It occurred to me that the current match detection is eager anyway.
That is, if the matchBytes are { 0, 0, 0, 6 } and the stream
is { 3 0 0 0 0 6 0 ... } then unless I'm mistaken no match will
be detected, because matching will start at byte 1 (it would
need to start at byte 2 to detect a full match).

So I guess this is a best effort which happens to work correctly
with the input we use in our tests?

best regards,

-- daniel



Thanks, Roger


On 8/2/2017 11:25 AM, Daniel Fuchs wrote:

Hi Roger,

I wonder if the MatchReplaceOutputStream should store the
partial match index at the time the partial bytes are flushed
in order to verify that this was indeed a partial match,
and report an error if it later finds that flush() was indeed
called during a full match? The potential Error to throw could
be created and recorded in flush() in order to diagnose
the offending flush() call...

On the other hand to do this properly you'd probably need
to maintain a stack of partial match indexes and corresponding
potential Errors to throw in case flush() is called again with
a partial match while the previous partial matching hasn't
been invalidated yet...

I mean - if your matched bytes are stg like  0 0 0 6
and the stream looks like:

  3 0 0  0  ...

then either 6 or 0 0 6 coming after  the second flush would
make the test fail to find & replace the full match...

But maybe it's not worth it if you are sure that flush() cannot
be called during a full match/replace sequence?

best regards,

-- daniel



On 02/08/2017 15:21, Roger Riggs wrote:
Please review a correction in the RMI TestSocketFactory 
MatchReplaceOutputStream to correctly flush
partial matches.  It can cause hangs when the one or more bytes 
before a flush are a partial match

for the pattern and the consumer is waiting for the pending bytes.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html

Issue:
https://bugs.openjdk.java.net/browse/JDK-8185719

Thanks, Roger

Re: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush

[Daniel Fuchs]

Hi Roger,

On 02/08/2017 16:32, Roger Riggs wrote:

Hi Daniel,

I considered keeping track of the partial match across the flush, but it 
could only work
if the partial match was a prefix of the replacement string.   It got 
complicated quickly.


Since this is used (only) for RMI, in which flushes are used at the end 
of messages, it seemed
sufficient to document it as not working across flushes and with a debug 
message

if flush was in the middle of a partial match.


OK, looks good then.
It occurred to me that the current match detection is eager anyway.
That is, if the matchBytes are { 0, 0, 0, 6 } and the stream
is { 3 0 0 0 0 6 0 ... } then unless I'm mistaken no match will
be detected, because matching will start at byte 1 (it would
need to start at byte 2 to detect a full match).

So I guess this is a best effort which happens to work correctly
with the input we use in our tests?

best regards,

-- daniel



Thanks, Roger


On 8/2/2017 11:25 AM, Daniel Fuchs wrote:

Hi Roger,

I wonder if the MatchReplaceOutputStream should store the
partial match index at the time the partial bytes are flushed
in order to verify that this was indeed a partial match,
and report an error if it later finds that flush() was indeed
called during a full match? The potential Error to throw could
be created and recorded in flush() in order to diagnose
the offending flush() call...

On the other hand to do this properly you'd probably need
to maintain a stack of partial match indexes and corresponding
potential Errors to throw in case flush() is called again with
a partial match while the previous partial matching hasn't
been invalidated yet...

I mean - if your matched bytes are stg like  0 0 0 6
and the stream looks like:

  3 0 0  0  ...

then either 6 or 0 0 6 coming after  the second flush would
make the test fail to find & replace the full match...

But maybe it's not worth it if you are sure that flush() cannot
be called during a full match/replace sequence?

best regards,

-- daniel



On 02/08/2017 15:21, Roger Riggs wrote:
Please review a correction in the RMI TestSocketFactory 
MatchReplaceOutputStream to correctly flush
partial matches.  It can cause hangs when the one or more bytes 
before a flush are a partial match

for the pattern and the consumer is waiting for the pending bytes.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html

Issue:
https://bugs.openjdk.java.net/browse/JDK-8185719

Thanks, Roger

Re: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush

[Roger Riggs]

Hi Daniel,

I considered keeping track of the partial match across the flush, but it 
could only work
if the partial match was a prefix of the replacement string.   It got 
complicated quickly.


Since this is used (only) for RMI, in which flushes are used at the end 
of messages, it seemed
sufficient to document it as not working across flushes and with a debug 
message

if flush was in the middle of a partial match.

Thanks, Roger


On 8/2/2017 11:25 AM, Daniel Fuchs wrote:

Hi Roger,

I wonder if the MatchReplaceOutputStream should store the
partial match index at the time the partial bytes are flushed
in order to verify that this was indeed a partial match,
and report an error if it later finds that flush() was indeed
called during a full match? The potential Error to throw could
be created and recorded in flush() in order to diagnose
the offending flush() call...

On the other hand to do this properly you'd probably need
to maintain a stack of partial match indexes and corresponding
potential Errors to throw in case flush() is called again with
a partial match while the previous partial matching hasn't
been invalidated yet...

I mean - if your matched bytes are stg like  0 0 0 6
and the stream looks like:

  3 0 0  0  ...

then either 6 or 0 0 6 coming after  the second flush would
make the test fail to find & replace the full match...

But maybe it's not worth it if you are sure that flush() cannot
be called during a full match/replace sequence?

best regards,

-- daniel



On 02/08/2017 15:21, Roger Riggs wrote:
Please review a correction in the RMI TestSocketFactory 
MatchReplaceOutputStream to correctly flush
partial matches.  It can cause hangs when the one or more bytes 
before a flush are a partial match

for the pattern and the consumer is waiting for the pending bytes.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8185719

Thanks, Roger

Re: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush

[Daniel Fuchs]

Hi Roger,

I wonder if the MatchReplaceOutputStream should store the
partial match index at the time the partial bytes are flushed
in order to verify that this was indeed a partial match,
and report an error if it later finds that flush() was indeed
called during a full match? The potential Error to throw could
be created and recorded in flush() in order to diagnose
the offending flush() call...

On the other hand to do this properly you'd probably need
to maintain a stack of partial match indexes and corresponding
potential Errors to throw in case flush() is called again with
a partial match while the previous partial matching hasn't
been invalidated yet...

I mean - if your matched bytes are stg like  0 0 0 6
and the stream looks like:

  3 0 0  0  ...

then either 6 or 0 0 6 coming after  the second flush would
make the test fail to find & replace the full match...

But maybe it's not worth it if you are sure that flush() cannot
be called during a full match/replace sequence?

best regards,

-- daniel



On 02/08/2017 15:21, Roger Riggs wrote:
Please review a correction in the RMI TestSocketFactory 
MatchReplaceOutputStream to correctly flush
partial matches.  It can cause hangs when the one or more bytes before a 
flush are a partial match

for the pattern and the consumer is waiting for the pending bytes.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8185719

Thanks, Roger

Re: RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush

[Lance Andersen]

Hi Roger,

the changes seem reasonable.

Best
Lance
> On Aug 2, 2017, at 10:21 AM, Roger Riggs  wrote:
> 
> Please review a correction in the RMI TestSocketFactory 
> MatchReplaceOutputStream to correctly flush
> partial matches.  It can cause hangs when the one or more bytes before a 
> flush are a partial match
> for the pattern and the consumer is waiting for the pending bytes.
> 
> Webrev:
>  http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html
> 
> Issue:
>  https://bugs.openjdk.java.net/browse/JDK-8185719
> 
> Thanks, Roger
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

[Mandy Chung]

> On Aug 2, 2017, at 7:08 AM, Jaroslav Tulach  
> wrote:
> 
>> This is Graal-specific MBean.  It doesn’t seem that it must be registered as
>> “platform mbean” which has to implement PlatformManagedObject.
>> 
>> Graal can register the MBean at runtime when java.management is present by
>> calling ManagementFactory.getPlatformMBeanServer().registerMBean method. 
>> That seems to be a better alternative.  Separating the MBean in a different
>> module would still be applicable.
> 
> This is not possible to do cleanly. When shall Graal register the bean? On 
> first compilation? Then it may enable the whole ManagementFactory 
> infrastructure too early and influence results of regular Java programs.
> 
> We have seen a benchmark failure due to registering the Graal bean too early. 
> The bean registration triggered the java.util.logging infrastructure on and 
> as 
> a result the benchmarking test failed. 
> 
> The test tried to set "java.util.logging.config.file" property and then it 
> assumed it will be used on subsequent call to Logger.getLogger(...). But the 
> property was ignored as the Logger was already initialized.
> 
> I believe that exactly for this reason there is the PlatformManagedObject & 
> co. infrastructure. To not trigger the management infrastructure on 
> prematurely. All the HotSpot beans are registered "lazily". As part of 
> internal JDK infrastructure we believe Graal should have a way to be part of 
> such "lazy initialization" too.
> 
> I hope the need for the requested functionality is now clearer.

As described in the previous mail, the current way to register a platform
MBean is to have a provider module that provides
sun.management.spi.PlatformMBeanProvider.  The provider module will get 
resolved during service binding.  jdk.management is one example.

Mandy

RFR 8185719 [testlibrary] : RMI TestSocketFactory does not flush

[Roger Riggs]

Please review a correction in the RMI TestSocketFactory 
MatchReplaceOutputStream to correctly flush
partial matches.  It can cause hangs when the one or more bytes before a 
flush are a partial match

for the pattern and the consumer is waiting for the pending bytes.

Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-flush-8185719/index.html

Issue:
  https://bugs.openjdk.java.net/browse/JDK-8185719

Thanks, Roger

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

[Jaroslav Tulach]

> This is Graal-specific MBean.  It doesn’t seem that it must be registered as
> “platform mbean” which has to implement PlatformManagedObject.
> 
> Graal can register the MBean at runtime when java.management is present by
> calling ManagementFactory.getPlatformMBeanServer().registerMBean method. 
> That seems to be a better alternative.  Separating the MBean in a different
> module would still be applicable.

This is not possible to do cleanly. When shall Graal register the bean? On 
first compilation? Then it may enable the whole ManagementFactory 
infrastructure too early and influence results of regular Java programs.

We have seen a benchmark failure due to registering the Graal bean too early. 
The bean registration triggered the java.util.logging infrastructure on and as 
a result the benchmarking test failed. 

The test tried to set "java.util.logging.config.file" property and then it 
assumed it will be used on subsequent call to Logger.getLogger(...). But the 
property was ignored as the Logger was already initialized.

I believe that exactly for this reason there is the PlatformManagedObject & 
co. infrastructure. To not trigger the management infrastructure on 
prematurely. All the HotSpot beans are registered "lazily". As part of 
internal JDK infrastructure we believe Graal should have a way to be part of 
such "lazy initialization" too.

I hope the need for the requested functionality is now clearer.
-jt

Re: Review Request: JDK-8185541: Add back test cases for resource lookup from bootclasspath

[Alan Bateman]

On 01/08/2017 20:05, Mandy Chung wrote:

This patch adds back the test cases that were added for JDK-6760902 but
later were removed by JDK-8142968. Those test cases are useful and converted
to use -Xbootclasspath/a.

Webrev at:
   http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8185541/webrev.00/


Looks good to me.

-Alan

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

[Ivan Gerasimov]

On 7/28/17 12:16 PM, Jonathan Bluett-Duncan wrote:


Hi Ivan,

It looks like the MyComparator code example which you gave in your 
last email lost its formatting along the way, so I'm finding it 
difficult to read. Would you mind resubmitting it?




Oh, sorry about that.
I've just uploaded another modification of the comparator here:
http://cr.openjdk.java.net/~igerasim/8134512/test/Test.java

With kind regards,
Ivan


Cheers,
Jonathan

On 28 July 2017 at 17:25, Ivan Gerasimov > wrote:


Hi Peter!

Thank a lot for looking into this!

On 7/28/17 7:32 AM, Peter Levart wrote:

Hi Ivan,

In the light of what Stuart Marks wrote, then what do you
think about a parameterized comparator (would be sub-optimal,
I know) where one would supply
2 Comparator(s) which would be used to compare Ax and Nx
sub-sequences respectively as described below...

Yes.  Inspired by what Stuart suggested I made a draft of such a
comparator (see below).
It works, but as you've said it's not that efficient (mostly due
to expensive substrings) and a bit harder to use in a simple case.
Now I need to think about how to combine two approaches.

For Nx sub-sequences, one would need a comparator comparing
the reversed sequence lexicographically,

I'm not sure I understand why they need to be reversed.

but for Ax sub-sequences, one could choose from a plethora of
case-(in)sensitive comparator(s) and collators already
available on the platform.

Yes. In the example below I used compareToIgnoreCase to compare
alpha subsequences.

---

class MyComparator implements Comparator
{Comparator alphaCmp;Comparator
numCmp;MyComparator(Comparator alphaCmp,Comparator
numCmp) {this.alphaCmp = alphaCmp;this.numCmp = numCmp;}boolean
skipLeadingZeroes(String s, int len) {for (int i = 0; i < len ;
++i) {if (Character.digit(s.charAt(i), 10) != 0)return
false;}return true;}@Override public int compare(String o1, String
o2) {Supplier s1 = new NumberSlicer(o1);Supplier
s2 = new NumberSlicer(o2);while (true) {// alpha part String ss1 =
s1.get();String ss2 = s2.get();int cmp = alphaCmp.compare(ss1,
ss2);if (cmp != 0) return cmp;if (ss1.length() == 0) return 0;//
numeric part ss1 = s1.get();ss2 = s2.get();int len1 =
ss1.length();int len2 = ss2.length();int dlen = len1 - len2;if
(dlen > 0) {if (!skipLeadingZeroes(ss1, dlen))return 1;ss1 =
ss1.substring(dlen, len1);} else if (dlen < 0) {if
(!skipLeadingZeroes(ss2, -dlen))return -1;ss2 =
ss2.substring(-dlen, len2);}cmp = numCmp.compare(ss1, ss2);if (cmp
!= 0) return cmp;if (dlen != 0) return dlen;}}static class
NumberSlicer implements Supplier {private String
sequence;private boolean expectNumber = false;private int index =
0;NumberSlicer(String s) {sequence = s;}@Override public String
get() {int start = index, end = start, len = sequence.length() -
start;for (; len > 0; ++end, --len) {if
(Character.isDigit(sequence.ch arAt(end)) ^
expectNumber)break;}expectNumber = !expectNumber;return
sequence.substring(start, index = end);}}}Here how it
is invoked with case-insensitive comparator:Arrays.sort(str,new

MyComparator(Comparator.comparing(String::toString,String::compareToIgnoreCase),Comparator.comparing(String::toString,String::compareTo)));

simple test results for case insensitive sorting:java 1java 1
javajava 1 JAVAJava 2JAVA 5jaVA 6.1java 10java 10 v 13Java 10 v
013Java 10 v 13java 10 v 113Java 2017Java 2017Java 20017Java
200017Java 217Java 2017Java 2017Java 20017With
kind regards, Ivan




--
With kind regards,
Ivan Gerasimov

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

[Ivan Gerasimov]

Thank you Peter for sharing your thoughts and experiments!


On 7/29/17 10:22 AM, Peter Levart wrote:

Hi Ivan,

On 07/28/2017 06:25 PM, Ivan Gerasimov wrote:


Hi Peter!

Thank a lot for looking into this!

On 7/28/17 7:32 AM, Peter Levart wrote:

Hi Ivan,

In the light of what Stuart Marks wrote, then what do you think 
about a parameterized comparator (would be sub-optimal, I know) 
where one would supply
2 Comparator(s) which would be used to compare Ax and Nx 
sub-sequences respectively as described below...


Yes.  Inspired by what Stuart suggested I made a draft of such a 
comparator (see below).
It works, but as you've said it's not that efficient (mostly due to 
expensive substrings) and a bit harder to use in a simple case.

Now I need to think about how to combine two approaches.


There is a bug in MyComparator. Comparing "1" with "2" gives 0 
(equal). You must not return "equal" when both alpha prefixes are empty.


Yes, you're right.  Should have checked the length of numerical 
substrings, or just use a separate method for end-of-sequence.




For Nx sub-sequences, one would need a comparator comparing the 
reversed sequence lexicographically,

I'm not sure I understand why they need to be reversed.


Scrap that. I got confused.  :-o

but for Ax sub-sequences, one could choose from a plethora of 
case-(in)sensitive comparator(s) and collators already available on 
the platform.


Yes. In the example below I used compareToIgnoreCase to compare alpha 
subsequences.

...
Arrays.sort(str,new 
MyComparator(Comparator.comparing(String::toString,String::compareToIgnoreCase),Comparator.comparing(String::toString,String::compareTo)));
Substrings are by copy. There is another approach. Originally you 
created the NumericComparator to compare CharSequence(s) - not 
String(s) as you did with MyComparator. So why not keeping that? 
Well, it was mostly for illustrative purposes.  Of course the final code 
should deal with CharSequences, not Strings for generality. However, I 
assume that in most cases this comparator will need to work with 
Strings, and it's important to remember that String.subSequence() is as 
expensive as String.substring() [1] [1] 
http://docs.oracle.com/javase/8/docs/api/java/lang/String.html#subSequence-int-int- 

While talking about types, you don't need to have a generic parameter: 
NumericComparator implements 
CharSequence simple: NumericComparator implements 
Comparator is suitable for comparing any subtype of 
CharSequence as use-sites should accept Comparator or 
Comparator. 
But it wouldn't work in a case you need to pass the comparator to a 
function of form  fun(Comparator cmp).
For example: Stream sorted(Comparator comparator); 
You can use Comparator to sort Stream as well as 
Stream or Stream... I tried an approach 
where sub-sequences are CharSequence objects by delegation and use 
sub-comparators that don't convert CharSequence(s) to String(s). 
Here's what this looks like: 
http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/AlphadecimalComparator.java 
with supporting sub-comparator classes: 
http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/CharSequenceComparator.java 
http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/DecimalComparator.java 
I created a JMH  benchmark comparing your 02/webrev 
(ivan.NumericComparator): 
http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/ivan/NumericComparator.java 
with a modified variant of your MyComparator that works correctly 
(ivan.MyComparator): 
http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/ivan/MyComparator.java 
and my (peter.AlphadecimalComparator). The later two are tested with 
case-sensitive (CS) and case-insensitive (CIS) variants for comparing 
alpha sub-sequences. Here are the results: 
http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/bench_results_speed.txt 
With -prof gc, it can be seen that JIT is able to optimize-away 
allocation of sub-sequence CharSequence(s). When the hot code is 
JIT-ed, at least with provided helper sub-comparators, no allocation 
is taking place (not so with MyComparator which creates substrings): 
http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/bench_results_gc.txt 


That's a very good news then!
The performance of AlphadecimalComparator is about 50% slower than 
your specialized NumericComparator, but it allows custom 
parametrization. Perhaps the decimal part of variations could be 
hidden behind a boolean or an enum parameter (there is a 
leading-zeroes-greater, leading-zeroes-less, but also a 
leading-zeroes-equal variant that makes sense). I tried to do that by 
making DecimalComparator an enum and restricting the