From stuart.marks at oracle.com  Sat Oct  3 02:40:36 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 2 Oct 2015 19:40:36 -0700
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application
In-Reply-To: <56090249.6040809@oracle.com>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
Message-ID: <560F4024.6050505@oracle.com>



On 9/28/15 2:03 AM, Alexander Scherbatiy wrote:
>   Is it possible to use autoboxing in the fix instead of
> Boolean.valueOf(someBooleanVariable)?

Hi,

These cases are all interesting because they end up requiring boxed Boolean 
values, whether explicitly or implicitly via autoboxing:

1. AquaTabbedPaneUI.java -- use of boxed Boolean as a tri-state (!)

2. CAccessibility.java -- return value from Callable<Boolean>

3. LWCToolkit.java -- value in Properties (like Map<Object,Object>)

For #2 and #3 I think auto-boxing instead of valueOf() is just fine. I guess 
using Boolean.TRUE or Boolean.FALSE instead of true or false is ok, as it's a 
micro-optimization to prevent autoboxing from generating a call to 
Boolean.valueOf(true|false). I'm sure the JIT compiler will inline such calls, 
so this speeds up interpreted code a tiny bit at the expense of a little 
verbosity in the code.

The explicit calls to Boolean.valueOf(some boolean expression) I think can 
simply be replaced with autoboxing in all cases.

The weird one is in AquaTabbedPaneUI.java, which has

     protected Boolean isDefaultFocusReceiver = null;

Ugh! It would be nice to get rid of null as a marker for uninitialized state, 
but that might require too much analysis to show that the change would be 
correct. This is, I think, the only case where the code has to be explicit about 
dealing with a boxed Boolean object that might be null, as opposed to true or false.

The only place that really has to do that is isDefaultFocusReceiver(), which 
checks for null up front. I'm not sure that using Boolean.valueOf() and 
Boolean.booleanValue() in the rest of the method are really helpful in denoting 
that this is a boxed, nullable Boolean though. So I'd switch to autoboxing here too.

s'marks

From alexandr.scherbatiy at oracle.com  Tue Oct  6 13:06:57 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 06 Oct 2015 16:06:57 +0300
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application
In-Reply-To: <560F4024.6050505@oracle.com>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com>
Message-ID: <5613C771.5020906@oracle.com>

On 10/3/2015 5:40 AM, Stuart Marks wrote:
>
>
> On 9/28/15 2:03 AM, Alexander Scherbatiy wrote:
>>   Is it possible to use autoboxing in the fix instead of
>> Boolean.valueOf(someBooleanVariable)?
>
> Hi,
>
> These cases are all interesting because they end up requiring boxed 
> Boolean values, whether explicitly or implicitly via autoboxing:
>
> 1. AquaTabbedPaneUI.java -- use of boxed Boolean as a tri-state (!)
>
> 2. CAccessibility.java -- return value from Callable<Boolean>
>
> 3. LWCToolkit.java -- value in Properties (like Map<Object,Object>)
>
> For #2 and #3 I think auto-boxing instead of valueOf() is just fine. I 
> guess using Boolean.TRUE or Boolean.FALSE instead of true or false is 
> ok, as it's a micro-optimization to prevent autoboxing from generating 
> a call to Boolean.valueOf(true|false). I'm sure the JIT compiler will 
> inline such calls, so this speeds up interpreted code a tiny bit at 
> the expense of a little verbosity in the code.
>
> The explicit calls to Boolean.valueOf(some boolean expression) I think 
> can simply be replaced with autoboxing in all cases.
>
> The weird one is in AquaTabbedPaneUI.java, which has
>
>     protected Boolean isDefaultFocusReceiver = null;
>

   I do not mean to change the isDefaultFocusReceivertype type to 
boolean. It was just interesting are there pros and cons to use a short 
version with autoboxing  for assignment:
       isDefaultFocusReceiver = defaultFocusReceiver != null && 
defaultFocusReceiver.equals(component);
   instead of the long version:
       isDefaultFocusReceiver = Boolean.valueOf(defaultFocusReceiver != 
null && defaultFocusReceiver.equals(component));

    Thanks,
    Alexandr.

> Ugh! It would be nice to get rid of null as a marker for uninitialized 
> state, but that might require too much analysis to show that the 
> change would be correct. This is, I think, the only case where the 
> code has to be explicit about dealing with a boxed Boolean object that 
> might be null, as opposed to true or false.
>
> The only place that really has to do that is isDefaultFocusReceiver(), 
> which checks for null up front. I'm not sure that using 
> Boolean.valueOf() and Boolean.booleanValue() in the rest of the method 
> are really helpful in denoting that this is a boxed, nullable Boolean 
> though. So I'd switch to autoboxing here too.
>
> s'marks


From sebastian.sickelmann at gmx.de  Wed Oct  7 19:59:18 2015
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 7 Oct 2015 21:59:18 +0200
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application(macos)
In-Reply-To: <5613C771.5020906@oracle.com>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
Message-ID: <56157996.80803@gmx.de>

Please find the updated webrev at:

http://cr.openjdk.java.net/~sebastian/5108778/macos/webrev.00/

For some general discussion on regression-tests for this please find the
thread in discuss[0][1] and for the general suggestion to make more
wrapper-type-constructors deprecated find [2] at core-libs-dev.

[0]
http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html
[1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html

-- Sebastian

On 10/06/2015 03:06 PM, Alexander Scherbatiy wrote:
> On 10/3/2015 5:40 AM, Stuart Marks wrote:
>>
>>
>> On 9/28/15 2:03 AM, Alexander Scherbatiy wrote:
>>>   Is it possible to use autoboxing in the fix instead of
>>> Boolean.valueOf(someBooleanVariable)?
>>
>> Hi,
>>
>> These cases are all interesting because they end up requiring boxed
>> Boolean values, whether explicitly or implicitly via autoboxing:
>>
>> 1. AquaTabbedPaneUI.java -- use of boxed Boolean as a tri-state (!)
>>
>> 2. CAccessibility.java -- return value from Callable<Boolean>
>>
>> 3. LWCToolkit.java -- value in Properties (like Map<Object,Object>)
>>
>> For #2 and #3 I think auto-boxing instead of valueOf() is just fine.
>> I guess using Boolean.TRUE or Boolean.FALSE instead of true or false
>> is ok, as it's a micro-optimization to prevent autoboxing from
>> generating a call to Boolean.valueOf(true|false). I'm sure the JIT
>> compiler will inline such calls, so this speeds up interpreted code a
>> tiny bit at the expense of a little verbosity in the code.
>>
>> The explicit calls to Boolean.valueOf(some boolean expression) I
>> think can simply be replaced with autoboxing in all cases.
>>
>> The weird one is in AquaTabbedPaneUI.java, which has
>>
>>     protected Boolean isDefaultFocusReceiver = null;
>>
>
>   I do not mean to change the isDefaultFocusReceivertype type to
> boolean. It was just interesting are there pros and cons to use a
> short version with autoboxing  for assignment:
>       isDefaultFocusReceiver = defaultFocusReceiver != null &&
> defaultFocusReceiver.equals(component);
>   instead of the long version:
>       isDefaultFocusReceiver = Boolean.valueOf(defaultFocusReceiver !=
> null && defaultFocusReceiver.equals(component));
>
>    Thanks,
>    Alexandr.
>
>> Ugh! It would be nice to get rid of null as a marker for
>> uninitialized state, but that might require too much analysis to show
>> that the change would be correct. This is, I think, the only case
>> where the code has to be explicit about dealing with a boxed Boolean
>> object that might be null, as opposed to true or false.
>>
>> The only place that really has to do that is
>> isDefaultFocusReceiver(), which checks for null up front. I'm not
>> sure that using Boolean.valueOf() and Boolean.booleanValue() in the
>> rest of the method are really helpful in denoting that this is a
>> boxed, nullable Boolean though. So I'd switch to autoboxing here too.
>>
>> s'marks
>
>


From stuart.marks at oracle.com  Wed Oct  7 21:27:30 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 7 Oct 2015 14:27:30 -0700
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application
In-Reply-To: <5613C771.5020906@oracle.com>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
Message-ID: <56158E42.2010202@oracle.com>

On 10/6/15 6:06 AM, Alexander Scherbatiy wrote:
> On 10/3/2015 5:40 AM, Stuart Marks wrote:
>> The weird one is in AquaTabbedPaneUI.java, which has
>>
>>     protected Boolean isDefaultFocusReceiver = null;
>>
>
>    I do not mean to change the isDefaultFocusReceivertype type to boolean. It
> was just interesting are there pros and cons to use a short version with
> autoboxing  for assignment:
>        isDefaultFocusReceiver = defaultFocusReceiver != null &&
> defaultFocusReceiver.equals(component);
>    instead of the long version:
>        isDefaultFocusReceiver = Boolean.valueOf(defaultFocusReceiver != null &&
> defaultFocusReceiver.equals(component));

I agree, changing Boolean to boolean here is too invasive for a cleanup change.

Right, the "interesting" issue is if this code were changed to use autoboxing, 
it would end up being this:

     if (isDefaultFocusReceiver == null) {
         // ...
         isDefaultFocusReceiver = defaultFocusReceiver != null && 
defaultFocusReceiver.equals(component);
     }

The isDefaultFocusReceiver field is being checked against null and then a 
boolean value is being assigned to it. That looks strange.

I guess in this case the call to Boolean.valueOf() makes it clearer what's going 
on. But I'll leave the final decision to you.

s'marks

>
>     Thanks,
>     Alexandr.
>
>> Ugh! It would be nice to get rid of null as a marker for uninitialized state,
>> but that might require too much analysis to show that the change would be
>> correct. This is, I think, the only case where the code has to be explicit
>> about dealing with a boxed Boolean object that might be null, as opposed to
>> true or false.
>>
>> The only place that really has to do that is isDefaultFocusReceiver(), which
>> checks for null up front. I'm not sure that using Boolean.valueOf() and
>> Boolean.booleanValue() in the rest of the method are really helpful in
>> denoting that this is a boxed, nullable Boolean though. So I'd switch to
>> autoboxing here too.
>>
>> s'marks
>

From alexandr.scherbatiy at oracle.com  Thu Oct  8 11:06:40 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 08 Oct 2015 14:06:40 +0300
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application(macos)
In-Reply-To: <56157996.80803@gmx.de>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
	<56157996.80803@gmx.de>
Message-ID: <56164E40.4040205@oracle.com>


   The fix looks good to me.

   Note that there are usually necessary to have at least two reviewers 
for a fix in Open JDK.

   Are you going to push the fix as part of other fixes for different 
JDK areas or as a separate fix?
   In the second case you need to file a new bug for it.

   Thanks,
   Alexandr.

On 10/7/2015 10:59 PM, Sebastian Sickelmann wrote:
> Please find the updated webrev at:
>
> http://cr.openjdk.java.net/~sebastian/5108778/macos/webrev.00/
>
> For some general discussion on regression-tests for this please find the
> thread in discuss[0][1] and for the general suggestion to make more
> wrapper-type-constructors deprecated find [2] at core-libs-dev.
>
> [0]
> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html
> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html
> [2]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html
>
> -- Sebastian
>
> On 10/06/2015 03:06 PM, Alexander Scherbatiy wrote:
>> On 10/3/2015 5:40 AM, Stuart Marks wrote:
>>>
>>> On 9/28/15 2:03 AM, Alexander Scherbatiy wrote:
>>>>    Is it possible to use autoboxing in the fix instead of
>>>> Boolean.valueOf(someBooleanVariable)?
>>> Hi,
>>>
>>> These cases are all interesting because they end up requiring boxed
>>> Boolean values, whether explicitly or implicitly via autoboxing:
>>>
>>> 1. AquaTabbedPaneUI.java -- use of boxed Boolean as a tri-state (!)
>>>
>>> 2. CAccessibility.java -- return value from Callable<Boolean>
>>>
>>> 3. LWCToolkit.java -- value in Properties (like Map<Object,Object>)
>>>
>>> For #2 and #3 I think auto-boxing instead of valueOf() is just fine.
>>> I guess using Boolean.TRUE or Boolean.FALSE instead of true or false
>>> is ok, as it's a micro-optimization to prevent autoboxing from
>>> generating a call to Boolean.valueOf(true|false). I'm sure the JIT
>>> compiler will inline such calls, so this speeds up interpreted code a
>>> tiny bit at the expense of a little verbosity in the code.
>>>
>>> The explicit calls to Boolean.valueOf(some boolean expression) I
>>> think can simply be replaced with autoboxing in all cases.
>>>
>>> The weird one is in AquaTabbedPaneUI.java, which has
>>>
>>>      protected Boolean isDefaultFocusReceiver = null;
>>>
>>    I do not mean to change the isDefaultFocusReceivertype type to
>> boolean. It was just interesting are there pros and cons to use a
>> short version with autoboxing  for assignment:
>>        isDefaultFocusReceiver = defaultFocusReceiver != null &&
>> defaultFocusReceiver.equals(component);
>>    instead of the long version:
>>        isDefaultFocusReceiver = Boolean.valueOf(defaultFocusReceiver !=
>> null && defaultFocusReceiver.equals(component));
>>
>>     Thanks,
>>     Alexandr.
>>
>>> Ugh! It would be nice to get rid of null as a marker for
>>> uninitialized state, but that might require too much analysis to show
>>> that the change would be correct. This is, I think, the only case
>>> where the code has to be explicit about dealing with a boxed Boolean
>>> object that might be null, as opposed to true or false.
>>>
>>> The only place that really has to do that is
>>> isDefaultFocusReceiver(), which checks for null up front. I'm not
>>> sure that using Boolean.valueOf() and Boolean.booleanValue() in the
>>> rest of the method are really helpful in denoting that this is a
>>> boxed, nullable Boolean though. So I'd switch to autoboxing here too.
>>>
>>> s'marks
>>


From sebastian.sickelmann at gmx.de  Fri Oct  9 10:09:36 2015
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Fri, 9 Oct 2015 12:09:36 +0200
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application(macos)
In-Reply-To: <56164E40.4040205@oracle.com>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
	<56157996.80803@gmx.de> <56164E40.4040205@oracle.com>
Message-ID: <56179260.3060205@gmx.de>

On 10/08/2015 01:06 PM, Alexander Scherbatiy wrote:
>
>   The fix looks good to me.
>
Thank.

>   Note that there are usually necessary to have at least two reviewers
> for a fix in Open JDK.

I thought patches before feature complete needs only one reviewer. [4][5]
But two reviewers are always better.

>
>   Are you going to push the fix as part of other fixes for different
> JDK areas or as a separate fix?
>   In the second case you need to file a new bug for it.

Actually i am planing to collect feedback from all dependent
mailing-list and than decide how to
progress.

-- Sebastian

[4] http://openjdk.java.net/guide/changePlanning.html
[5] http://openjdk.java.net/projects/jdk9/
>
>   Thanks,
>   Alexandr.
>
> On 10/7/2015 10:59 PM, Sebastian Sickelmann wrote:
>> Please find the updated webrev at:
>>
>> http://cr.openjdk.java.net/~sebastian/5108778/macos/webrev.00/
>>
>> For some general discussion on regression-tests for this please find the
>> thread in discuss[0][1] and for the general suggestion to make more
>> wrapper-type-constructors deprecated find [2] at core-libs-dev.
>>
>> [0]
>> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html
>> [2]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html
>>
>>
>> -- Sebastian
>>
>> On 10/06/2015 03:06 PM, Alexander Scherbatiy wrote:
>>> On 10/3/2015 5:40 AM, Stuart Marks wrote:
>>>>
>>>> On 9/28/15 2:03 AM, Alexander Scherbatiy wrote:
>>>>>    Is it possible to use autoboxing in the fix instead of
>>>>> Boolean.valueOf(someBooleanVariable)?
>>>> Hi,
>>>>
>>>> These cases are all interesting because they end up requiring boxed
>>>> Boolean values, whether explicitly or implicitly via autoboxing:
>>>>
>>>> 1. AquaTabbedPaneUI.java -- use of boxed Boolean as a tri-state (!)
>>>>
>>>> 2. CAccessibility.java -- return value from Callable<Boolean>
>>>>
>>>> 3. LWCToolkit.java -- value in Properties (like Map<Object,Object>)
>>>>
>>>> For #2 and #3 I think auto-boxing instead of valueOf() is just fine.
>>>> I guess using Boolean.TRUE or Boolean.FALSE instead of true or false
>>>> is ok, as it's a micro-optimization to prevent autoboxing from
>>>> generating a call to Boolean.valueOf(true|false). I'm sure the JIT
>>>> compiler will inline such calls, so this speeds up interpreted code a
>>>> tiny bit at the expense of a little verbosity in the code.
>>>>
>>>> The explicit calls to Boolean.valueOf(some boolean expression) I
>>>> think can simply be replaced with autoboxing in all cases.
>>>>
>>>> The weird one is in AquaTabbedPaneUI.java, which has
>>>>
>>>>      protected Boolean isDefaultFocusReceiver = null;
>>>>
>>>    I do not mean to change the isDefaultFocusReceivertype type to
>>> boolean. It was just interesting are there pros and cons to use a
>>> short version with autoboxing  for assignment:
>>>        isDefaultFocusReceiver = defaultFocusReceiver != null &&
>>> defaultFocusReceiver.equals(component);
>>>    instead of the long version:
>>>        isDefaultFocusReceiver = Boolean.valueOf(defaultFocusReceiver !=
>>> null && defaultFocusReceiver.equals(component));
>>>
>>>     Thanks,
>>>     Alexandr.
>>>
>>>> Ugh! It would be nice to get rid of null as a marker for
>>>> uninitialized state, but that might require too much analysis to show
>>>> that the change would be correct. This is, I think, the only case
>>>> where the code has to be explicit about dealing with a boxed Boolean
>>>> object that might be null, as opposed to true or false.
>>>>
>>>> The only place that really has to do that is
>>>> isDefaultFocusReceiver(), which checks for null up front. I'm not
>>>> sure that using Boolean.valueOf() and Boolean.booleanValue() in the
>>>> rest of the method are really helpful in denoting that this is a
>>>> boxed, nullable Boolean though. So I'd switch to autoboxing here too.
>>>>
>>>> s'marks
>>>
>
>


From Sergey.Bylokhov at oracle.com  Fri Oct  9 10:53:12 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 9 Oct 2015 13:53:12 +0300
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application(macos)
In-Reply-To: <56164E40.4040205@oracle.com>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
	<56157996.80803@gmx.de> <56164E40.4040205@oracle.com>
Message-ID: <56179C98.1070109@oracle.com>

Looks fine to me too.

From alexandr.scherbatiy at oracle.com  Fri Oct  9 14:00:20 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 09 Oct 2015 17:00:20 +0300
Subject: Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective
	on MacOS
In-Reply-To: <D221CDA8.490A6%ebakke@mit.edu>
References: <D221CDA8.490A6%ebakke@mit.edu>
Message-ID: <5617C874.6090203@oracle.com>


   Hello Mike,

   The initial Clipboard support in CToolkit in Mac OS X [1] recognizes 
only NSPasteboard data types that have "JAVA_DATAFLAVOR:" prefix:
---------------------
+jlong indexForFormat(NSString *format) {
...
+    // If we don't recognize the format, but it's a Java "custom" 
format register it
+    if (returnValue == -1 && ([format hasPrefix:@"JAVA_DATAFLAVOR:"]) ) {
+        returnValue = registerFormatWithPasteboard(format);
+    }
---------------------

   What was the reason that Java supports only these java custom formats 
on Mac OS X?

   See also issue [2]:  JDK-8136781 
SystemFlavorMap.addFlavorForUnencodedNative is ineffective on MacOS

   [1] 
http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/dfe77a31519f
   [2] https://bugs.openjdk.java.net/browse/JDK-8136781

   Thanks,
   Alexandr.

On 9/18/2015 9:18 PM, Eirik Bakke wrote:
> Hi, macosx-port-dev.
>
> There seems to be a bug in the MacOS implementation underlying SystemFlavorMap.addFlavorForUnencodedNative. Where would the best place to report this be? Is this the relevant mailing list?
>
> The bug report follows:
>
> My Java application allows users to paste selections from Microsoft Excel. The data is retrieved using Excel's binary BIFF8 format rather than in plain text format in order to reliably detect date formatting, preserve numerical precision, and such. On Windows, getting to the relevant clipboard InputStream can be achieved by calling SystemFlavorMap.addUnencodedNativeForFlavor to map a new DataFlavor to a native data type identifier. On MacOS, however, there seems to be a bug that renders SystemFlavorMap.addUnencodedNativeForFlavor ineffective.
>
> Looking at the JDK source code, the bug seems to be that sun.lwawt.macosx.CDataTransferer.registerFormatWithPasteboard is never called when SystemFlavorMap.addUnencodedNativeForFlavor/ addFlavorForUnencodedNative is used to register a new native clipboard data format. This leads Java_sun_lwawt_macosx_CClipboard_getClipboardFormats in macosx/native/sun/awt/CClipboard.m to never return formats of the new type, because indexForFormat (in CDataTransferer.m) will always return -1.
>
> The observation above lead me to a workaround for the bug, which is to call sun.awt.datatransfer.DataTransferer.getInstance().getFormatsForFlavor(myNewFlavor, (SystemFlavorMap) SystemFlavorMap.getDefaultFlavorMap()) once after first mapping the flavor using addUnencodedNativeForFlavor and addFlavorForUnencodedNative. This works because the call to getFormatsForFlavor forces DataTransferer.getFormatForNativeAsLong to be called with the new native data type identifier, which in turn causes registerFormatWithPasteboard to be called in CDataTransferer.m. I'm worried that the workaround will cease to work in the future, however, since it relies on an obscure side-effect of a method in a private API from the sun.awt package.
>
> I've assembled a minimal example here: https://gist.github.com/eirikbakke/e8022f9f8d26c28eecd7
>
> -- Eirik
>


From swingler at apple.com  Sun Oct 11 16:29:14 2015
From: swingler at apple.com (Mike Swingler)
Date: Sun, 11 Oct 2015 09:29:14 -0700
Subject: Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective on
	MacOS
In-Reply-To: <5617C874.6090203@oracle.com>
References: <D221CDA8.490A6%ebakke@mit.edu> <5617C874.6090203@oracle.com>
Message-ID: <A7A4D332-EA21-46D8-9F5A-655C369B4609@apple.com>

Excellent question. I honestly don?t know, since the addition of that section was part of the original Java 1.4 implementation bring-up on Cocoa (and shares no lineage with the Carbon-based 1.3). While there were bug fixes in the DnD machinery around that area, the flavor map was a section that ?just worked?. As far as I know, the point of the ?JAVA_DATAFLAVOR:? prefix was only route serialized Java objects through the NSPasteboard during a drag-and-drop operation. Presumably nobody bothered copying/pasting more complex data types than the ones we provided translators for above (or if they did, the bugs never hit our threshold for investigating).

I?m sorry I?m not able to explain why it is the way it is, but hopefully the historical context will be helpful.

Regards,
Mike Swingler
Apple Inc.

> On Oct 9, 2015, at 7:00 AM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
>  Hello Mike,
> 
>  The initial Clipboard support in CToolkit in Mac OS X [1] recognizes only NSPasteboard data types that have "JAVA_DATAFLAVOR:" prefix:
> ---------------------
> +jlong indexForFormat(NSString *format) {
> ...
> +    // If we don't recognize the format, but it's a Java "custom" format register it
> +    if (returnValue == -1 && ([format hasPrefix:@"JAVA_DATAFLAVOR:"]) ) {
> +        returnValue = registerFormatWithPasteboard(format);
> +    }
> ---------------------
> 
>  What was the reason that Java supports only these java custom formats on Mac OS X?
> 
>  See also issue [2]:  JDK-8136781 SystemFlavorMap.addFlavorForUnencodedNative is ineffective on MacOS
> 
>  [1] http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/dfe77a31519f
>  [2] https://bugs.openjdk.java.net/browse/JDK-8136781
> 
>  Thanks,
>  Alexandr.
> 
> On 9/18/2015 9:18 PM, Eirik Bakke wrote:
>> Hi, macosx-port-dev.
>> 
>> There seems to be a bug in the MacOS implementation underlying SystemFlavorMap.addFlavorForUnencodedNative. Where would the best place to report this be? Is this the relevant mailing list?
>> 
>> The bug report follows:
>> 
>> My Java application allows users to paste selections from Microsoft Excel. The data is retrieved using Excel's binary BIFF8 format rather than in plain text format in order to reliably detect date formatting, preserve numerical precision, and such. On Windows, getting to the relevant clipboard InputStream can be achieved by calling SystemFlavorMap.addUnencodedNativeForFlavor to map a new DataFlavor to a native data type identifier. On MacOS, however, there seems to be a bug that renders SystemFlavorMap.addUnencodedNativeForFlavor ineffective.
>> 
>> Looking at the JDK source code, the bug seems to be that sun.lwawt.macosx.CDataTransferer.registerFormatWithPasteboard is never called when SystemFlavorMap.addUnencodedNativeForFlavor/ addFlavorForUnencodedNative is used to register a new native clipboard data format. This leads Java_sun_lwawt_macosx_CClipboard_getClipboardFormats in macosx/native/sun/awt/CClipboard.m to never return formats of the new type, because indexForFormat (in CDataTransferer.m) will always return -1.
>> 
>> The observation above lead me to a workaround for the bug, which is to call sun.awt.datatransfer.DataTransferer.getInstance().getFormatsForFlavor(myNewFlavor, (SystemFlavorMap) SystemFlavorMap.getDefaultFlavorMap()) once after first mapping the flavor using addUnencodedNativeForFlavor and addFlavorForUnencodedNative. This works because the call to getFormatsForFlavor forces DataTransferer.getFormatForNativeAsLong to be called with the new native data type identifier, which in turn causes registerFormatWithPasteboard to be called in CDataTransferer.m. I'm worried that the workaround will cease to work in the future, however, since it relies on an obscure side-effect of a method in a private API from the sun.awt package.
>> 
>> I've assembled a minimal example here: https://gist.github.com/eirikbakke/e8022f9f8d26c28eecd7
>> 
>> -- Eirik
>> 
> 


From sebastian.sickelmann at gmx.de  Tue Oct 13 19:32:13 2015
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Tue, 13 Oct 2015 21:32:13 +0200
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application(macos)
In-Reply-To: <56164E40.4040205@oracle.com>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
	<56157996.80803@gmx.de> <56164E40.4040205@oracle.com>
Message-ID: <561D5C3D.7050408@gmx.de>

On 10/08/2015 01:06 PM, Alexander Scherbatiy wrote:
>
>   Are you going to push the fix as part of other fixes for different
> JDK areas or as a separate fix?
>   In the second case you need to file a new bug for it.
>
I think the patches in the other areas are much bigger than
this(macosx-port-dev) one. I think I should handle the changes separated
for each mailing-list/repository.

Should i than create a sub-task in JBS for each mailing-list/repository
who have reviewed the change?
Do I have to recreate the webrev for the new ticket-number?

Thanks,
Sebastian
>   Thanks,
>   Alexandr.
>


From alexandr.scherbatiy at oracle.com  Tue Oct 20 10:23:03 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 20 Oct 2015 13:23:03 +0300
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application(macos)
In-Reply-To: <561D5C3D.7050408@gmx.de>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
	<56157996.80803@gmx.de> <56164E40.4040205@oracle.com>
	<561D5C3D.7050408@gmx.de>
Message-ID: <56261607.3010403@oracle.com>

On 10/13/2015 10:32 PM, Sebastian Sickelmann wrote:
> On 10/08/2015 01:06 PM, Alexander Scherbatiy wrote:
>>    Are you going to push the fix as part of other fixes for different
>> JDK areas or as a separate fix?
>>    In the second case you need to file a new bug for it.
>>
> I think the patches in the other areas are much bigger than
> this(macosx-port-dev) one. I think I should handle the changes separated
> for each mailing-list/repository.
>
> Should i than create a sub-task in JBS for each mailing-list/repository
> who have reviewed the change?
> Do I have to recreate the webrev for the new ticket-number?

    Just create a new issue in java.awt area and send the bug id.
    You can copy the same approved webrev under the new bug id if you wish.

   Thanks,
   Alexandr.

>
> Thanks,
> Sebastian
>>    Thanks,
>>    Alexandr.
>>


From sebastian.sickelmann at gmx.de  Wed Oct 21 17:59:40 2015
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Wed, 21 Oct 2015 19:59:40 +0200
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application(macos)
In-Reply-To: <56261607.3010403@oracle.com>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
	<56157996.80803@gmx.de> <56164E40.4040205@oracle.com>
	<561D5C3D.7050408@gmx.de> <56261607.3010403@oracle.com>
Message-ID: <5627D28C.2050803@gmx.de>

On 10/20/2015 12:23 PM, Alexander Scherbatiy wrote:
> On 10/13/2015 10:32 PM, Sebastian Sickelmann wrote:
>> On 10/08/2015 01:06 PM, Alexander Scherbatiy wrote:
>>>    Are you going to push the fix as part of other fixes for different
>>> JDK areas or as a separate fix?
>>>    In the second case you need to file a new bug for it.
>>>
>> I think the patches in the other areas are much bigger than
>> this(macosx-port-dev) one. I think I should handle the changes separated
>> for each mailing-list/repository.
>>
>> Should i than create a sub-task in JBS for each mailing-list/repository
>> who have reviewed the change?
>> Do I have to recreate the webrev for the new ticket-number?
>
>    Just create a new issue in java.awt area and send the bug id.
>    You can copy the same approved webrev under the new bug id if you
> wish.
>
Hi, i create a subtask JDK-8139754 for this. Unfortunatly i cannot scp
to cr.openjdk.java.net
anymore. I somehow "managed" that the server does not accept my
publickey anymore.

I mailed to keys at openjdk.java.net (found that on another thread) but
don't get an answer
yet. Is there anotherway to update my public key on cr.openjdk.java.net?
My username is sebastian

Thanks,
Sebastian

>   Thanks,
>   Alexandr.
>
>>
>> Thanks,
>> Sebastian
>>>    Thanks,
>>>    Alexandr.
>>>
>
>


From alexandr.scherbatiy at oracle.com  Thu Oct 22 11:43:43 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 22 Oct 2015 14:43:43 +0300
Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created
	in Java application(macos)
In-Reply-To: <5627D28C.2050803@gmx.de>
References: <5606BCF8.6090603@gmx.de> <56090249.6040809@oracle.com>
	<560F4024.6050505@oracle.com> <5613C771.5020906@oracle.com>
	<56157996.80803@gmx.de> <56164E40.4040205@oracle.com>
	<561D5C3D.7050408@gmx.de> <56261607.3010403@oracle.com>
	<5627D28C.2050803@gmx.de>
Message-ID: <5628CBEF.6010208@oracle.com>


   I have pushed your fix to the JDK 9: 
http://hg.openjdk.java.net/jdk9/client/jdk/rev/deb544c19dec

   Thanks,
   Alexandr.

On 10/21/2015 8:59 PM, Sebastian Sickelmann wrote:
> On 10/20/2015 12:23 PM, Alexander Scherbatiy wrote:
>> On 10/13/2015 10:32 PM, Sebastian Sickelmann wrote:
>>> On 10/08/2015 01:06 PM, Alexander Scherbatiy wrote:
>>>>     Are you going to push the fix as part of other fixes for different
>>>> JDK areas or as a separate fix?
>>>>     In the second case you need to file a new bug for it.
>>>>
>>> I think the patches in the other areas are much bigger than
>>> this(macosx-port-dev) one. I think I should handle the changes separated
>>> for each mailing-list/repository.
>>>
>>> Should i than create a sub-task in JBS for each mailing-list/repository
>>> who have reviewed the change?
>>> Do I have to recreate the webrev for the new ticket-number?
>>     Just create a new issue in java.awt area and send the bug id.
>>     You can copy the same approved webrev under the new bug id if you
>> wish.
>>
> Hi, i create a subtask JDK-8139754 for this. Unfortunatly i cannot scp
> to cr.openjdk.java.net
> anymore. I somehow "managed" that the server does not accept my
> publickey anymore.
>
> I mailed to keys at openjdk.java.net (found that on another thread) but
> don't get an answer
> yet. Is there anotherway to update my public key on cr.openjdk.java.net?
> My username is sebastian
>
> Thanks,
> Sebastian
>
>>    Thanks,
>>    Alexandr.
>>
>>> Thanks,
>>> Sebastian
>>>>     Thanks,
>>>>     Alexandr.
>>>>
>>


From alexandr.scherbatiy at oracle.com  Wed Oct 28 14:21:11 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 28 Oct 2015 17:21:11 +0300
Subject: <AWT Dev> [9] Review request for 8132503: [macosx] Chinese full
	stop symbol cannot be entered with Pinyin IM on OS X
In-Reply-To: <562F4F93.3000207@oracle.com>
References: <562F4F93.3000207@oracle.com>
Message-ID: <5630D9D7.7030908@oracle.com>

On 10/27/2015 1:18 PM, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for the bug.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8132503
> Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.00
>
> The bug consists in the fact that after the fix for JDK-8068283, when 
> IDEOGRAPHIC FULL STOP character "?" is entered from a keyboard using 
> Pinyin IM, "java.awt.event.InputMethodEvent" is not generated and FULL 
> STOP character "." is entered in "javax.swing.JTextArea" component.
>
> The solution adds the additional check to "if" condition, which was 
> edited by the fix for JDK-8068283,
>
> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length > 
> 2)) {"
>
> in the method "- (void) insertText:(id) replacementRange:(NSRange)" 
> from the file 
> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m". This 
> additional check defines, whether the analyzed code point belongs to 
> Unicode code points range "U+3000 ? U+303F" ("CJK Symbols and 
> Punctuation"), which contains "?" character and, if it is so, 
> generates "InputMethodEvent".
>
    It was interested for me does Cocoa or Java allow to get a minimal 
and maximal character for the given Unicode Block.
    I was not able to find how to do it in Cocoa.
    Java has an open RFE JDK-7057645 Add methods to 
Character.UnicodeBlock (returning first & last codepoints, the list of 
blocks).
    May be the current issue can be one more valid use case for the RFE.

    I have just few comments:
     - aString is treated as NSString. Can it have more than one Unicode 
character?
     - It could be better to move the check that a unichar belongs to a 
separate function that can be easily extended later for new Unicode Blocks.

   Thanks,
   Alexandr.

> It was verified in a local environment that the regression test from 
> the fix for JDK-8068283 does not fail with this fix also.
>
> Thank you,
> Anton


From alexandr.scherbatiy at oracle.com  Thu Oct 29 16:24:07 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 29 Oct 2015 19:24:07 +0300
Subject: <AWT Dev> [9] Review request for 8132503: [macosx] Chinese full
	stop symbol cannot be entered with Pinyin IM on OS X
In-Reply-To: <5632449A.5020005@oracle.com>
References: <562F4F93.3000207@oracle.com> <5630D9D7.7030908@oracle.com>
	<56320C88.4060003@oracle.com> <5632449A.5020005@oracle.com>
Message-ID: <56324827.5080403@oracle.com>

On 10/29/2015 7:08 PM, Anton Litvinov wrote:
> Hello Alexander,
>
> The second version of the fix, which addresses your suggestion 
> concerning introduction of a separate method checking, if the 
> "unichar" belongs to certain Unicode blocks, was created. For this 
> purpose the method "-(BOOL) isCodePointInUnicodeBlockNeedingIMEvent: 
> (unichar) codePoint;" was introduced. Could you please review the 
> second version of the fix.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.01


    The fix looks good to me.

    Thanks,
    Alexandr.

>
> Thank you,
> Anton
>
> On 10/29/2015 3:09 PM, Anton Litvinov wrote:
>> Hello Alexander,
>>
>> Thank you for review of this fix. Responses to your questions are 
>> following.
>>
>> 1) I also was not able to find any methods available in 
>> "java.lang.Character", "java.lang.Character.UnicodeBlock", 
>> "java.lang.Character.Subset" classes or API in Cocoa which would 
>> allow to get minimal and maximal code point for the given Unicode 
>> block. I do not think that resuming work on RFE JDK-7057645 created 
>> in 2011 will help to resolve this particular bug, because it will not 
>> be possible to introduce a new API in JDK 8, for which this bug was 
>> originally filed.
>>
>> 2) Yes, I think that "aString" can have more than 1 Unicode 
>> character, since it is described as "The text to insert" in the 
>> documentation of the method "(void)insertText:(id)aString 
>> replacementRange:(NSRange)" 
>> (https://developer.apple.com/library/mac/documentation/Cocoa/Reference/NSTextInputClient_Protocol/#//apple_ref/occ/intfm/NSTextInputClient/insertText:replacementRange:)
>>
>> And, if "aString" contains more than 1 Unicode character, this case 
>> was already taken into account by "(utf16Length > 2)" check.
>>
>> "AWTView.m" without this fix:
>> 893     if ([self hasMarkedText] || !fProcessingKeystroke || 
>> (utf16Length > 2)) {
>>
>> "AWTView.m" with this fix:
>> 894     if (utf16Length > 2) {
>> 895         aStringIsComplex = YES;
>>
>> 3) Concerning creation of a separate function for checking, if 
>> "unichar" belongs to certain Unicode blocks. Did you mean addition of 
>> the possible function which would just check, if "unichar" is in any 
>> of the Unicode blocks hard coded in the function? Or did you mean the 
>> function which would just check, if "unichar" belongs to 1 Unicode 
>> block, whose identifier is transferred to the function, for example, 
>> as some "enum" value?
>>
>> Thank you,
>> Anton
>>
>> On 10/28/2015 5:21 PM, Alexander Scherbatiy wrote:
>>> On 10/27/2015 1:18 PM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132503
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.00
>>>>
>>>> The bug consists in the fact that after the fix for JDK-8068283, 
>>>> when IDEOGRAPHIC FULL STOP character "?" is entered from a 
>>>> keyboard using Pinyin IM, "java.awt.event.InputMethodEvent" is not 
>>>> generated and FULL STOP character "." is entered in 
>>>> "javax.swing.JTextArea" component.
>>>>
>>>> The solution adds the additional check to "if" condition, which was 
>>>> edited by the fix for JDK-8068283,
>>>>
>>>> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length 
>>>> > 2)) {"
>>>>
>>>> in the method "- (void) insertText:(id) replacementRange:(NSRange)" 
>>>> from the file 
>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m". 
>>>> This additional check defines, whether the analyzed code point 
>>>> belongs to Unicode code points range "U+3000 ? U+303F" ("CJK 
>>>> Symbols and Punctuation"), which contains "?" character and, if it 
>>>> is so, generates "InputMethodEvent".
>>>>
>>>    It was interested for me does Cocoa or Java allow to get a 
>>> minimal and maximal character for the given Unicode Block.
>>>    I was not able to find how to do it in Cocoa.
>>>    Java has an open RFE JDK-7057645 Add methods to 
>>> Character.UnicodeBlock (returning first & last codepoints, the list 
>>> of blocks).
>>>    May be the current issue can be one more valid use case for the RFE.
>>>
>>>    I have just few comments:
>>>     - aString is treated as NSString. Can it have more than one 
>>> Unicode character?
>>>     - It could be better to move the check that a unichar belongs to 
>>> a separate function that can be easily extended later for new 
>>> Unicode Blocks.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>> It was verified in a local environment that the regression test 
>>>> from the fix for JDK-8068283 does not fail with this fix also.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>
>


From alexander.zuev at oracle.com  Thu Oct 29 23:39:39 2015
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Fri, 30 Oct 2015 02:39:39 +0300
Subject: <AWT Dev> [9] Review request for 8132503: [macosx] Chinese full
	stop symbol cannot be entered with Pinyin IM on OS X
In-Reply-To: <5632449A.5020005@oracle.com>
References: <562F4F93.3000207@oracle.com> <5630D9D7.7030908@oracle.com>
	<56320C88.4060003@oracle.com> <5632449A.5020005@oracle.com>
Message-ID: <5632AE3B.50405@oracle.com>

Anton,

   this version looks fine to me.

/Alex

On 29/10/15 19:08, Anton Litvinov wrote:
> Hello Alexander,
>
> The second version of the fix, which addresses your suggestion 
> concerning introduction of a separate method checking, if the 
> "unichar" belongs to certain Unicode blocks, was created. For this 
> purpose the method "-(BOOL) isCodePointInUnicodeBlockNeedingIMEvent: 
> (unichar) codePoint;" was introduced. Could you please review the 
> second version of the fix.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.01
>
> Thank you,
> Anton
>
> On 10/29/2015 3:09 PM, Anton Litvinov wrote:
>> Hello Alexander,
>>
>> Thank you for review of this fix. Responses to your questions are 
>> following.
>>
>> 1) I also was not able to find any methods available in 
>> "java.lang.Character", "java.lang.Character.UnicodeBlock", 
>> "java.lang.Character.Subset" classes or API in Cocoa which would 
>> allow to get minimal and maximal code point for the given Unicode 
>> block. I do not think that resuming work on RFE JDK-7057645 created 
>> in 2011 will help to resolve this particular bug, because it will not 
>> be possible to introduce a new API in JDK 8, for which this bug was 
>> originally filed.
>>
>> 2) Yes, I think that "aString" can have more than 1 Unicode 
>> character, since it is described as "The text to insert" in the 
>> documentation of the method "(void)insertText:(id)aString 
>> replacementRange:(NSRange)" 
>> (https://developer.apple.com/library/mac/documentation/Cocoa/Reference/NSTextInputClient_Protocol/#//apple_ref/occ/intfm/NSTextInputClient/insertText:replacementRange:)
>>
>> And, if "aString" contains more than 1 Unicode character, this case 
>> was already taken into account by "(utf16Length > 2)" check.
>>
>> "AWTView.m" without this fix:
>> 893     if ([self hasMarkedText] || !fProcessingKeystroke || 
>> (utf16Length > 2)) {
>>
>> "AWTView.m" with this fix:
>> 894     if (utf16Length > 2) {
>> 895         aStringIsComplex = YES;
>>
>> 3) Concerning creation of a separate function for checking, if 
>> "unichar" belongs to certain Unicode blocks. Did you mean addition of 
>> the possible function which would just check, if "unichar" is in any 
>> of the Unicode blocks hard coded in the function? Or did you mean the 
>> function which would just check, if "unichar" belongs to 1 Unicode 
>> block, whose identifier is transferred to the function, for example, 
>> as some "enum" value?
>>
>> Thank you,
>> Anton
>>
>> On 10/28/2015 5:21 PM, Alexander Scherbatiy wrote:
>>> On 10/27/2015 1:18 PM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132503
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.00
>>>>
>>>> The bug consists in the fact that after the fix for JDK-8068283, 
>>>> when IDEOGRAPHIC FULL STOP character "?" is entered from a 
>>>> keyboard using Pinyin IM, "java.awt.event.InputMethodEvent" is not 
>>>> generated and FULL STOP character "." is entered in 
>>>> "javax.swing.JTextArea" component.
>>>>
>>>> The solution adds the additional check to "if" condition, which was 
>>>> edited by the fix for JDK-8068283,
>>>>
>>>> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length 
>>>> > 2)) {"
>>>>
>>>> in the method "- (void) insertText:(id) replacementRange:(NSRange)" 
>>>> from the file 
>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m". 
>>>> This additional check defines, whether the analyzed code point 
>>>> belongs to Unicode code points range "U+3000 ? U+303F" ("CJK 
>>>> Symbols and Punctuation"), which contains "?" character and, if it 
>>>> is so, generates "InputMethodEvent".
>>>>
>>>    It was interested for me does Cocoa or Java allow to get a 
>>> minimal and maximal character for the given Unicode Block.
>>>    I was not able to find how to do it in Cocoa.
>>>    Java has an open RFE JDK-7057645 Add methods to 
>>> Character.UnicodeBlock (returning first & last codepoints, the list 
>>> of blocks).
>>>    May be the current issue can be one more valid use case for the RFE.
>>>
>>>    I have just few comments:
>>>     - aString is treated as NSString. Can it have more than one 
>>> Unicode character?
>>>     - It could be better to move the check that a unichar belongs to 
>>> a separate function that can be easily extended later for new 
>>> Unicode Blocks.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>> It was verified in a local environment that the regression test 
>>>> from the fix for JDK-8068283 does not fail with this fix also.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>
>