From Vladislav.Karnaukhov at oracle.com  Mon Apr  1 05:48:53 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 01 Apr 2013 16:48:53 +0400
Subject: <AWT Dev> [8] Review request for 8010721: [macosx] In JDK7 the
	menu bar disappears when a Dialog is shown
In-Reply-To: <5154666C.3080706@oracle.com>
References: <5152F7F0.1020907@oracle.com>
	<B151C854-5083-4EF8-A130-F97A8F0D386E@oracle.com>
	<5154607A.90301@oracle.com> <5154666C.3080706@oracle.com>
Message-ID: <51598235.7080702@oracle.com>

Hello Sergey, all,

please review a new version: 
http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.02/

I agree that previous one was too complex and error-prone. The current 
version is much lighter and addresses various use-cases with different 
windows types and modality.

Regards,
- Vlad

On 3/28/2013 07:49 PM, Sergey Bylokhov wrote:
> Not sure that now it looks better.
>
> On 3/28/13 7:23 PM, Vladislav Karnaukhov wrote:
>> Hello Leonid, all,
>>
>> thanks for the review and could you please review a new version:
>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/
>>
>> This version is implemented completely via JNF; I removed all changes
>> from Java part.
>>
>> Regards,
>> - Vlad
>>
>> On 27.03.13 18:10, Leonid Romanov wrote:
>>> Hi,
>>> For 1, perhaps you could use AWTWindow's javaPlatformWindow to get to
>>> corresponding LWWindowPeer, which has peerType field.
>>>
>>> On Mar 27, 2013, at 5:45 PM, Vladislav
>>> Karnaukhov<Vladislav.Karnaukhov at oracle.com>  wrote:
>>>
>>>> Hello,
>>>>
>>>> please review a fix for 8010721.
>>>>
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721
>>>> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/
>>>>
>>>> This implementation handles a scenario when a modal dialog is shown:
>>>> in this case we dim main window' menu bar items (if any).
>>>>
>>>> However, there are 2 issues that I'd like to discuss:
>>>> 1. Apple JDK always hides the menu bar when a new *form* doesn't
>>>> have any. My realization keeps the main form' menu bar if a new form
>>>> is shown. I wasn't able to determine a way to distinguish a Frame
>>>> from a Dialog: both of them are AWTWindow.
>>>>
>>>> 2. Could you please provide ideas for tests (if we need them here)?
>>>> When a modal dialog is being shown, can we access the menu bar to
>>>> check if items became dimmed?
>>>>
>>>> Regards,
>>>> - Vlad
>>
>
>



From dan.xu at oracle.com  Mon Apr  1 15:16:57 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Mon, 01 Apr 2013 15:16:57 -0700
Subject: Review Request: JDK-8000406 - change files using @GenerateNativeHeader
	to use @Native
Message-ID: <515A0759.5070602@oracle.com>

Hi All,

In this fix, I have updated files in JDK libraries to use @Native 
annotation instead of @GenerateNativeHeader  to mark classes that 
contain no native methods but constants used by native codes.

@GenerateNativeHeader was added earlier in the development for 
JDK8."This has proved problematic for some core classes with respect to 
Jigsaw, since the use of such an annotation creates a compile-time 
dependency from the base module to the module containing javax.tools, 
and the base module should not have any dependencies." After switching 
to @Native annotation, the dependency problem will be solved as 
java.lang.annotation.Native is in the proposed base module. In addition, 
the annotation has been refined not to be on the class level but on the 
constants themselves, which also makes the generated header files much 
cleaner.

This effort is part of JDK-8000404. After jdk libraries uptaking the 
annotation changes, @GenerateNativeHeader annotation will be removed 
completely.

CCC: http://ccc.us.oracle.com/8000404
webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/

Thanks for your feedback!

-Dan

From brent.christian at oracle.com  Mon Apr  1 16:59:35 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 01 Apr 2013 16:59:35 -0700
Subject: [7u-dev] Request for approval to backport 8003228: (props)
	sun.jnu.encoding should be set to UTF-8 [macosx],
	(plus follow-up test fixes 8005962 & 8006039)
Message-ID: <515A1F67.40100@oracle.com>

Hi,

I would like to request backport of:
http://bugs.sun.com/view_bug.do?bug_id=8003228

After 8003228 went into jdk8, two test bugs were subsequently filed and 
fixed:
http://bugs.sun.com/view_bug.do?bug_id=8005962
http://bugs.sun.com/view_bug.do?bug_id=8006039

I would like to push all 3 at once to avoid introducing test failures.

The webrev against jdk7u-dev containing the 3 fixes is here:
http://cr.openjdk.java.net/~bchristi/jdk7u-dev/8003228/webrev.0/

An automated build+test cycle on supported platforms shows no new test 
failures.

Discussion of the jdk8 fix can be found at [1] and [2].

Thanks,
-Brent

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013184.html

[2] 
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-January/005309.html

From Alan.Bateman at oracle.com  Tue Apr  2 01:12:49 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 02 Apr 2013 09:12:49 +0100
Subject: Review Request: JDK-8000406 - change files using
	@GenerateNativeHeader to use @Native
In-Reply-To: <515A0759.5070602@oracle.com>
References: <515A0759.5070602@oracle.com>
Message-ID: <515A9301.7030800@oracle.com>

On 01/04/2013 23:16, Dan Xu wrote:
> Hi All,
>
> In this fix, I have updated files in JDK libraries to use @Native 
> annotation instead of @GenerateNativeHeader  to mark classes that 
> contain no native methods but constants used by native codes.
>
> @GenerateNativeHeader was added earlier in the development for 
> JDK8."This has proved problematic for some core classes with respect 
> to Jigsaw, since the use of such an annotation creates a compile-time 
> dependency from the base module to the module containing javax.tools, 
> and the base module should not have any dependencies." After switching 
> to @Native annotation, the dependency problem will be solved as 
> java.lang.annotation.Native is in the proposed base module. In 
> addition, the annotation has been refined not to be on the class level 
> but on the constants themselves, which also makes the generated header 
> files much cleaner.
>
> This effort is part of JDK-8000404. After jdk libraries uptaking the 
> annotation changes, @GenerateNativeHeader annotation will be removed 
> completely.
>
> CCC: http://ccc.us.oracle.com/8000404
> webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/
>
> Thanks for your feedback!
>
> -Dan
This is great work - thank you for doing this.

As the majority of the changed code is in the 2d/awt/client area then I 
hope that you will get timely reviews from those areas. The main thing 
with a change like this is that the changes build on all platforms and 
I've know you've verified that.

I skimmed through the webrev and don't see anything obviously wrong. I 
focused mostly on the non-client code and they all look right. It's 
interesting that @GenerateNativeHeader was added to several classes with 
native methods, I don't know why that was the case. I was also unaware 
that we had Haskell code in the build.

So thumbs up from me. I assume you or Jon will remove 
GenerateNativeHeader from the langtools repository once your changes are 
pushed.

-Alan


From anthony.petrov at oracle.com  Tue Apr  2 02:42:16 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 02 Apr 2013 13:42:16 +0400
Subject: <AWT Dev> [8] Review request for 8010721: [macosx] In JDK7 the
	menu bar disappears when a Dialog is shown
In-Reply-To: <51598235.7080702@oracle.com>
References: <5152F7F0.1020907@oracle.com>	<B151C854-5083-4EF8-A130-F97A8F0D386E@oracle.com>	<5154607A.90301@oracle.com>
	<5154666C.3080706@oracle.com> <51598235.7080702@oracle.com>
Message-ID: <515AA7F8.10304@oracle.com>

Hi Vladislav,

>  541         [CMenuBar activate:self.javaMenuBar modallyDisabled:NO];

Should this call be wrapped in an if (self.javaMenuBar != NULL) check? 
The same question about line 543 and the opposite->javaMenuBar 
correspondingly.

Also, are we sure that "opposite" is always non-null? What happens if 
you switch to another app, and then click on the dialog making it a key 
window again?

--
best regards,
Anthony

On 4/1/2013 16:48, Vladislav Karnaukhov wrote:
> Hello Sergey, all,
> 
> please review a new version: 
> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.02/
> 
> I agree that previous one was too complex and error-prone. The current 
> version is much lighter and addresses various use-cases with different 
> windows types and modality.
> 
> Regards,
> - Vlad
> 
> On 3/28/2013 07:49 PM, Sergey Bylokhov wrote:
>> Not sure that now it looks better.
>>
>> On 3/28/13 7:23 PM, Vladislav Karnaukhov wrote:
>>> Hello Leonid, all,
>>>
>>> thanks for the review and could you please review a new version:
>>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/
>>>
>>> This version is implemented completely via JNF; I removed all changes
>>> from Java part.
>>>
>>> Regards,
>>> - Vlad
>>>
>>> On 27.03.13 18:10, Leonid Romanov wrote:
>>>> Hi,
>>>> For 1, perhaps you could use AWTWindow's javaPlatformWindow to get to
>>>> corresponding LWWindowPeer, which has peerType field.
>>>>
>>>> On Mar 27, 2013, at 5:45 PM, Vladislav
>>>> Karnaukhov<Vladislav.Karnaukhov at oracle.com>  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> please review a fix for 8010721.
>>>>>
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721
>>>>> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/
>>>>>
>>>>> This implementation handles a scenario when a modal dialog is shown:
>>>>> in this case we dim main window' menu bar items (if any).
>>>>>
>>>>> However, there are 2 issues that I'd like to discuss:
>>>>> 1. Apple JDK always hides the menu bar when a new *form* doesn't
>>>>> have any. My realization keeps the main form' menu bar if a new form
>>>>> is shown. I wasn't able to determine a way to distinguish a Frame
>>>>> from a Dialog: both of them are AWTWindow.
>>>>>
>>>>> 2. Could you please provide ideas for tests (if we need them here)?
>>>>> When a modal dialog is being shown, can we access the menu bar to
>>>>> check if items became dimmed?
>>>>>
>>>>> Regards,
>>>>> - Vlad
>>>
>>
>>
> 
> 

From anthony.petrov at oracle.com  Tue Apr  2 05:07:38 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 02 Apr 2013 16:07:38 +0400
Subject: <AWT Dev> Review Request: JDK-8000406 - change files using
	@GenerateNativeHeader to use @Native
In-Reply-To: <515A0759.5070602@oracle.com>
References: <515A0759.5070602@oracle.com>
Message-ID: <515ACA0A.4000809@oracle.com>

Hi Dan,

Changes to awt code look fine to me.

--
best regards,
Anthony

On 4/2/2013 2:16, Dan Xu wrote:
>   Hi All,
> 
> In this fix, I have updated files in JDK libraries to use @Native 
> annotation instead of @GenerateNativeHeader  to mark classes that 
> contain no native methods but constants used by native codes.
> 
> @GenerateNativeHeader was added earlier in the development for JDK8. 
> "This has proved problematic for some core classes with respect to 
> Jigsaw, since the use of such an annotation creates a compile-time 
> dependency from the base module to the module containing javax.tools, 
> and the base module should not have any dependencies." After switching 
> to @Native annotation, the dependency problem will be solved as 
> java.lang.annotation.Native is in the proposed base module. In addition, 
> the annotation has been refined not to be on the class level but on the 
> constants themselves, which also makes the generated header files much 
> cleaner.
> 
> This effort is part of JDK-8000404. After jdk libraries uptaking the 
> annotation changes, @GenerateNativeHeader annotation will be removed 
> completely.
> 
> CCC: http://ccc.us.oracle.com/8000404
> webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/
> 
> Thanks for your feedback!
> 
> -Dan

From philip.race at oracle.com  Tue Apr  2 12:37:05 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 02 Apr 2013 12:37:05 -0700
Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using
	@GenerateNativeHeader to use @Native
In-Reply-To: <515A0759.5070602@oracle.com>
References: <515A0759.5070602@oracle.com>
Message-ID: <515B3361.6080503@oracle.com>

The addition of @Native to various lines in SunGraphics2D.java look to 
have pushed them >80 chars
and it looks to me as if previously the author took some care to limit 
it. Moreover the indentation
of the comment block `on lines 127-130 is no longer aligned.

Maybe it would be easier for that case to put the annotation on the line 
above as in
@Native
static final int FOO ...


Otherwise looks OK, looks like you found files that had 
@GenerateNativeHeaders that
didn't need it and cleaned those up, and in native sources removed 
unneeded header
file imports too.

I do have a background question about how it works.
There is an implication here that only the constants with @native might
be included in generated header files. Is that true ?

Whereas if a class has native method declarations, then  it doesn't need
these annotations, but you get all constants in the header file. Is that 
right ?

-phil.

On 4/1/13 3:16 PM, Dan Xu wrote:
> Hi All,
>
> In this fix, I have updated files in JDK libraries to use @Native 
> annotation instead of @GenerateNativeHeader  to mark classes that 
> contain no native methods but constants used by native codes.
>
> @GenerateNativeHeader was added earlier in the development for 
> JDK8."This has proved problematic for some core classes with respect 
> to Jigsaw, since the use of such an annotation creates a compile-time 
> dependency from the base module to the module containing javax.tools, 
> and the base module should not have any dependencies." After switching 
> to @Native annotation, the dependency problem will be solved as 
> java.lang.annotation.Native is in the proposed base module. In 
> addition, the annotation has been refined not to be on the class level 
> but on the constants themselves, which also makes the generated header 
> files much cleaner.
>
> This effort is part of JDK-8000404. After jdk libraries uptaking the 
> annotation changes, @GenerateNativeHeader annotation will be removed 
> completely.
>
> CCC: http://ccc.us.oracle.com/8000404
> webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/
>
> Thanks for your feedback!
>
> -Dan


From Vladislav.Karnaukhov at oracle.com  Wed Apr  3 03:20:35 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 03 Apr 2013 14:20:35 +0400
Subject: <AWT Dev> [8] Review request for 8010721: [macosx] In JDK7 the
	menu bar disappears when a Dialog is shown
In-Reply-To: <515AA7F8.10304@oracle.com>
References: <5152F7F0.1020907@oracle.com>	<B151C854-5083-4EF8-A130-F97A8F0D386E@oracle.com>	<5154607A.90301@oracle.com>
	<5154666C.3080706@oracle.com> <51598235.7080702@oracle.com>
	<515AA7F8.10304@oracle.com>
Message-ID: <515C0273.8030809@oracle.com>

Hello Anthony, all,

thanks for the review; please see inline.

Please find a new version here: 
http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.03/

On 4/2/2013 01:42 PM, Anthony Petrov wrote:
> Hi Vladislav,
>
>>  541         [CMenuBar activate:self.javaMenuBar modallyDisabled:NO];
>
> Should this call be wrapped in an if (self.javaMenuBar != NULL) check?
> The same question about line 543 and the opposite->javaMenuBar
> correspondingly.
"activate" is a static function and there's a null check inside. We can 
pass the parameter without additional null check.

>
> Also, are we sure that "opposite" is always non-null? What happens if
> you switch to another app, and then click on the dialog making it a key
> window again?
Agreed. I added a null check for "opposite" variable.

>
> --
> best regards,
> Anthony
>
> On 4/1/2013 16:48, Vladislav Karnaukhov wrote:
>> Hello Sergey, all,
>>
>> please review a new version:
>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.02/
>>
>> I agree that previous one was too complex and error-prone. The current
>> version is much lighter and addresses various use-cases with different
>> windows types and modality.
>>
>> Regards,
>> - Vlad
>>
>> On 3/28/2013 07:49 PM, Sergey Bylokhov wrote:
>>> Not sure that now it looks better.
>>>
>>> On 3/28/13 7:23 PM, Vladislav Karnaukhov wrote:
>>>> Hello Leonid, all,
>>>>
>>>> thanks for the review and could you please review a new version:
>>>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/
>>>>
>>>> This version is implemented completely via JNF; I removed all changes
>>>> from Java part.
>>>>
>>>> Regards,
>>>> - Vlad
>>>>
>>>> On 27.03.13 18:10, Leonid Romanov wrote:
>>>>> Hi,
>>>>> For 1, perhaps you could use AWTWindow's javaPlatformWindow to get to
>>>>> corresponding LWWindowPeer, which has peerType field.
>>>>>
>>>>> On Mar 27, 2013, at 5:45 PM, Vladislav
>>>>> Karnaukhov<Vladislav.Karnaukhov at oracle.com>  wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> please review a fix for 8010721.
>>>>>>
>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721
>>>>>> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/
>>>>>>
>>>>>> This implementation handles a scenario when a modal dialog is shown:
>>>>>> in this case we dim main window' menu bar items (if any).
>>>>>>
>>>>>> However, there are 2 issues that I'd like to discuss:
>>>>>> 1. Apple JDK always hides the menu bar when a new *form* doesn't
>>>>>> have any. My realization keeps the main form' menu bar if a new form
>>>>>> is shown. I wasn't able to determine a way to distinguish a Frame
>>>>>> from a Dialog: both of them are AWTWindow.
>>>>>>
>>>>>> 2. Could you please provide ideas for tests (if we need them here)?
>>>>>> When a modal dialog is being shown, can we access the menu bar to
>>>>>> check if items became dimmed?
>>>>>>
>>>>>> Regards,
>>>>>> - Vlad
>>>>
>>>
>>>
>>
>>



From anthony.petrov at oracle.com  Wed Apr  3 04:02:23 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 03 Apr 2013 15:02:23 +0400
Subject: <AWT Dev> [8] Review request for 8010721: [macosx] In JDK7 the
	menu bar disappears when a Dialog is shown
In-Reply-To: <515C0273.8030809@oracle.com>
References: <5152F7F0.1020907@oracle.com>	<B151C854-5083-4EF8-A130-F97A8F0D386E@oracle.com>	<5154607A.90301@oracle.com>
	<5154666C.3080706@oracle.com> <51598235.7080702@oracle.com>
	<515AA7F8.10304@oracle.com> <515C0273.8030809@oracle.com>
Message-ID: <515C0C3F.4010400@oracle.com>

The fix looks good to me. Thank you.

--
best regards,
Anthony

On 4/3/2013 14:20, Vladislav Karnaukhov wrote:
> Hello Anthony, all,
> 
> thanks for the review; please see inline.
> 
> Please find a new version here: 
> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.03/
> 
> On 4/2/2013 01:42 PM, Anthony Petrov wrote:
>> Hi Vladislav,
>>
>>>  541         [CMenuBar activate:self.javaMenuBar modallyDisabled:NO];
>>
>> Should this call be wrapped in an if (self.javaMenuBar != NULL) check?
>> The same question about line 543 and the opposite->javaMenuBar
>> correspondingly.
> "activate" is a static function and there's a null check inside. We can 
> pass the parameter without additional null check.
> 
>>
>> Also, are we sure that "opposite" is always non-null? What happens if
>> you switch to another app, and then click on the dialog making it a key
>> window again?
> Agreed. I added a null check for "opposite" variable.
> 
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 4/1/2013 16:48, Vladislav Karnaukhov wrote:
>>> Hello Sergey, all,
>>>
>>> please review a new version:
>>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.02/
>>>
>>> I agree that previous one was too complex and error-prone. The current
>>> version is much lighter and addresses various use-cases with different
>>> windows types and modality.
>>>
>>> Regards,
>>> - Vlad
>>>
>>> On 3/28/2013 07:49 PM, Sergey Bylokhov wrote:
>>>> Not sure that now it looks better.
>>>>
>>>> On 3/28/13 7:23 PM, Vladislav Karnaukhov wrote:
>>>>> Hello Leonid, all,
>>>>>
>>>>> thanks for the review and could you please review a new version:
>>>>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/
>>>>>
>>>>> This version is implemented completely via JNF; I removed all changes
>>>>> from Java part.
>>>>>
>>>>> Regards,
>>>>> - Vlad
>>>>>
>>>>> On 27.03.13 18:10, Leonid Romanov wrote:
>>>>>> Hi,
>>>>>> For 1, perhaps you could use AWTWindow's javaPlatformWindow to get to
>>>>>> corresponding LWWindowPeer, which has peerType field.
>>>>>>
>>>>>> On Mar 27, 2013, at 5:45 PM, Vladislav
>>>>>> Karnaukhov<Vladislav.Karnaukhov at oracle.com>  wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> please review a fix for 8010721.
>>>>>>>
>>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721
>>>>>>> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/
>>>>>>>
>>>>>>> This implementation handles a scenario when a modal dialog is shown:
>>>>>>> in this case we dim main window' menu bar items (if any).
>>>>>>>
>>>>>>> However, there are 2 issues that I'd like to discuss:
>>>>>>> 1. Apple JDK always hides the menu bar when a new *form* doesn't
>>>>>>> have any. My realization keeps the main form' menu bar if a new form
>>>>>>> is shown. I wasn't able to determine a way to distinguish a Frame
>>>>>>> from a Dialog: both of them are AWTWindow.
>>>>>>>
>>>>>>> 2. Could you please provide ideas for tests (if we need them here)?
>>>>>>> When a modal dialog is being shown, can we access the menu bar to
>>>>>>> check if items became dimmed?
>>>>>>>
>>>>>>> Regards,
>>>>>>> - Vlad
>>>>>
>>>>
>>>>
>>>
>>>
> 
> 

From dan.xu at oracle.com  Wed Apr  3 07:53:41 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 03 Apr 2013 07:53:41 -0700
Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using
	@GenerateNativeHeader to use @Native
In-Reply-To: <515B3361.6080503@oracle.com>
References: <515A0759.5070602@oracle.com> <515B3361.6080503@oracle.com>
Message-ID: <515C4275.80503@oracle.com>

Hi Phil,

Thank you for your good comments. Please see my answers below.

On 04/02/2013 12:37 PM, Phil Race wrote:
> The addition of @Native to various lines in SunGraphics2D.java look to 
> have pushed them >80 chars
> and it looks to me as if previously the author took some care to limit 
> it. Moreover the indentation
> of the comment block `on lines 127-130 is no longer aligned.
>
> Maybe it would be easier for that case to put the annotation on the 
> line above as in
> @Native
> static final int FOO ...
>
I use a program to automatically scan and modify files. And the length 
program is not noticed. I will fix the format issue.
>
> Otherwise looks OK, looks like you found files that had 
> @GenerateNativeHeaders that
> didn't need it and cleaned those up, and in native sources removed 
> unneeded header
> file imports too.
>
> I do have a background question about how it works.
> There is an implication here that only the constants with @native might
> be included in generated header files. Is that true ?
>
> Whereas if a class has native method declarations, then  it doesn't need
> these annotations, but you get all constants in the header file. Is 
> that right ?
>

If a class has native method declarations, then we don't need add 
anything. It will automatically generate the header file with all constants.

If a class contains no native methods but have constants interested by 
native codes, then we need annotations. Previously, we use 
@GenerateNativeHeader. But now we need replace them with @Native. 
@Native works on the field level. Only constants annotated with @native 
will be added as an entry in the generated native header file. (But we 
currently have a bug on this. It generates a header file with all 
constants no matter a constant has @Native or not. It will be fixed soon.)

In my change, I only add @Native annotation to constants interested by 
native codes. And if no such kind of constants and native methods 
declared, the fix does the clean-up and removes unnecessary header 
imports. Thanks!

-Dan

> -phil.
>
> On 4/1/13 3:16 PM, Dan Xu wrote:
>> Hi All,
>>
>> In this fix, I have updated files in JDK libraries to use @Native 
>> annotation instead of @GenerateNativeHeader  to mark classes that 
>> contain no native methods but constants used by native codes.
>>
>> @GenerateNativeHeader was added earlier in the development for 
>> JDK8."This has proved problematic for some core classes with respect 
>> to Jigsaw, since the use of such an annotation creates a compile-time 
>> dependency from the base module to the module containing javax.tools, 
>> and the base module should not have any dependencies." After 
>> switching to @Native annotation, the dependency problem will be 
>> solved as java.lang.annotation.Native is in the proposed base module. 
>> In addition, the annotation has been refined not to be on the class 
>> level but on the constants themselves, which also makes the generated 
>> header files much cleaner.
>>
>> This effort is part of JDK-8000404. After jdk libraries uptaking the 
>> annotation changes, @GenerateNativeHeader annotation will be removed 
>> completely.
>>
>> CCC: http://ccc.us.oracle.com/8000404
>> webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/
>>
>> Thanks for your feedback!
>>
>> -Dan
>


From Sergey.Bylokhov at oracle.com  Wed Apr  3 09:29:40 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 03 Apr 2013 20:29:40 +0400
Subject: <AWT Dev> [8] Review request for 8010721: [macosx] In JDK7 the
	menu bar disappears when a Dialog is shown
In-Reply-To: <51598235.7080702@oracle.com>
References: <5152F7F0.1020907@oracle.com>
	<B151C854-5083-4EF8-A130-F97A8F0D386E@oracle.com>
	<5154607A.90301@oracle.com> <5154666C.3080706@oracle.com>
	<51598235.7080702@oracle.com>
Message-ID: <515C58F4.9000203@oracle.com>

Hi, Vladislav.
The fix look much better.
Thanks!

On 4/1/13 4:48 PM, Vladislav Karnaukhov wrote:
> Hello Sergey, all,
>
> please review a new version: 
> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.02/
>
> I agree that previous one was too complex and error-prone. The current 
> version is much lighter and addresses various use-cases with different 
> windows types and modality.
>
> Regards,
> - Vlad
>
> On 3/28/2013 07:49 PM, Sergey Bylokhov wrote:
>> Not sure that now it looks better.
>>
>> On 3/28/13 7:23 PM, Vladislav Karnaukhov wrote:
>>> Hello Leonid, all,
>>>
>>> thanks for the review and could you please review a new version:
>>> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/
>>>
>>> This version is implemented completely via JNF; I removed all changes
>>> from Java part.
>>>
>>> Regards,
>>> - Vlad
>>>
>>> On 27.03.13 18:10, Leonid Romanov wrote:
>>>> Hi,
>>>> For 1, perhaps you could use AWTWindow's javaPlatformWindow to get to
>>>> corresponding LWWindowPeer, which has peerType field.
>>>>
>>>> On Mar 27, 2013, at 5:45 PM, Vladislav
>>>> Karnaukhov<Vladislav.Karnaukhov at oracle.com>  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> please review a fix for 8010721.
>>>>>
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721
>>>>> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/
>>>>>
>>>>> This implementation handles a scenario when a modal dialog is shown:
>>>>> in this case we dim main window' menu bar items (if any).
>>>>>
>>>>> However, there are 2 issues that I'd like to discuss:
>>>>> 1. Apple JDK always hides the menu bar when a new *form* doesn't
>>>>> have any. My realization keeps the main form' menu bar if a new form
>>>>> is shown. I wasn't able to determine a way to distinguish a Frame
>>>>> from a Dialog: both of them are AWTWindow.
>>>>>
>>>>> 2. Could you please provide ideas for tests (if we need them here)?
>>>>> When a modal dialog is being shown, can we access the menu bar to
>>>>> check if items became dimmed?
>>>>>
>>>>> Regards,
>>>>> - Vlad
>>>
>>
>>
>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Apr  4 11:02:20 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 04 Apr 2013 22:02:20 +0400
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
Message-ID: <515DC02C.1030608@oracle.com>

Hello,
Please review the fix for jdk 8. Change adds support of hidpi to Aqua l&f.
Change description:
- AquaPainter takes into account scale, when creates image.
- ImageCache now use scale factor as a key.
- CGContext also scaled to a ratio of image/control width/height
- Cleanup

Note that this fix depends from the:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866
Webrev can be found at: http://cr.openjdk.java.net/~serb/8004866/webrev.00

-- 
Best regards, Sergey.


From swingler at apple.com  Thu Apr  4 11:09:58 2013
From: swingler at apple.com (Mike Swingler)
Date: Thu, 04 Apr 2013 11:09:58 -0700
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
In-Reply-To: <515DC02C.1030608@oracle.com>
References: <515DC02C.1030608@oracle.com>
Message-ID: <FBAFD0E1-6E47-4E98-ADB9-E898F8C0502E@apple.com>

On Apr 4, 2013, at 11:02 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hello,
> Please review the fix for jdk 8. Change adds support of hidpi to Aqua l&f.
> Change description:
> - AquaPainter takes into account scale, when creates image.
> - ImageCache now use scale factor as a key.
> - CGContext also scaled to a ratio of image/control width/height
> - Cleanup
> 
> Note that this fix depends from the:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
> 
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8004866/webrev.00

Looks good to me. I know a lot of developers are looking forward to this.

Cheers,
Mike Swingler
Apple Inc.


From krueger at lesspain.de  Fri Apr  5 01:17:25 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 5 Apr 2013 10:17:25 +0200
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
In-Reply-To: <515DC02C.1030608@oracle.com>
References: <515DC02C.1030608@oracle.com>
Message-ID: <CAEnqZEW7-7P7i65ZnFs=sur1_GuG16=Y1nzZVuYR83cyMcxX+A@mail.gmail.com>

Hi,

this is great news! Thank you for your work!

One question though: Will Synth and/or Nimbus Look and Feels benefit from
this work as well in the end or shall users of those L&Fs prepare for
switching to Aqua?

Thanks a lot!

Robert



On Thu, Apr 4, 2013 at 8:02 PM, Sergey Bylokhov
<Sergey.Bylokhov at oracle.com>wrote:

> Hello,
> Please review the fix for jdk 8. Change adds support of hidpi to Aqua l&f.
> Change description:
> - AquaPainter takes into account scale, when creates image.
> - ImageCache now use scale factor as a key.
> - CGContext also scaled to a ratio of image/control width/height
> - Cleanup
>
> Note that this fix depends from the:
> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8000629<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629>
>
> Bug: http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004866<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866>
> Webrev can be found at: http://cr.openjdk.java.net/~**
> serb/8004866/webrev.00<http://cr.openjdk.java.net/~serb/8004866/webrev.00>
>
> --
> Best regards, Sergey.
>
>

From Sergey.Bylokhov at oracle.com  Fri Apr  5 04:03:27 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 05 Apr 2013 15:03:27 +0400
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
In-Reply-To: <CAEnqZEW7-7P7i65ZnFs=sur1_GuG16=Y1nzZVuYR83cyMcxX+A@mail.gmail.com>
References: <515DC02C.1030608@oracle.com>
	<CAEnqZEW7-7P7i65ZnFs=sur1_GuG16=Y1nzZVuYR83cyMcxX+A@mail.gmail.com>
Message-ID: <515EAF7F.4070507@oracle.com>

Hi, Robert.
If L&F uses vector graphics, it will look good automatically(like 
Nimbus). If it uses rasters(like Aqua), it should be tweaked.

On 4/5/13 12:17 PM, Robert Kr?ger wrote:
> Hi,
>
> this is great news! Thank you for your work!
>
> One question though: Will Synth and/or Nimbus Look and Feels benefit 
> from this work as well in the end or shall users of those L&Fs prepare 
> for switching to Aqua?

>
> Thanks a lot!
>
> Robert
>
>
>
> On Thu, Apr 4, 2013 at 8:02 PM, Sergey Bylokhov 
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     Hello,
>     Please review the fix for jdk 8. Change adds support of hidpi to
>     Aqua l&f.
>     Change description:
>     - AquaPainter takes into account scale, when creates image.
>     - ImageCache now use scale factor as a key.
>     - CGContext also scaled to a ratio of image/control width/height
>     - Cleanup
>
>     Note that this fix depends from the:
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>
>     Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866
>     Webrev can be found at:
>     http://cr.openjdk.java.net/~serb/8004866/webrev.00
>     <http://cr.openjdk.java.net/%7Eserb/8004866/webrev.00>
>
>     -- 
>     Best regards, Sergey.
>
>


-- 
Best regards, Sergey.


From krueger at lesspain.de  Fri Apr  5 04:18:28 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 5 Apr 2013 13:18:28 +0200
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
In-Reply-To: <515EAF7F.4070507@oracle.com>
References: <515DC02C.1030608@oracle.com>
	<CAEnqZEW7-7P7i65ZnFs=sur1_GuG16=Y1nzZVuYR83cyMcxX+A@mail.gmail.com>
	<515EAF7F.4070507@oracle.com>
Message-ID: <CAEnqZEV1ehEyPwMdfq2hmYGOYgvE2SGvwsv9MPYSqVXRxG8Nqg@mail.gmail.com>

Hi Sergey,

that is excellent News!

Thanks so much,

Robert


On Fri, Apr 5, 2013 at 1:03 PM, Sergey Bylokhov
<Sergey.Bylokhov at oracle.com>wrote:

>  Hi, Robert.
> If L&F uses vector graphics, it will look good automatically(like Nimbus).
> If it uses rasters(like Aqua), it should be tweaked.
>
>
> On 4/5/13 12:17 PM, Robert Kr?ger wrote:
>
> Hi,
>
>  this is great news! Thank you for your work!
>
>  One question though: Will Synth and/or Nimbus Look and Feels benefit
> from this work as well in the end or shall users of those L&Fs prepare for
> switching to Aqua?
>
>
>
>  Thanks a lot!
>
>  Robert
>
>
>
> On Thu, Apr 4, 2013 at 8:02 PM, Sergey Bylokhov <
> Sergey.Bylokhov at oracle.com> wrote:
>
>> Hello,
>> Please review the fix for jdk 8. Change adds support of hidpi to Aqua l&f.
>> Change description:
>> - AquaPainter takes into account scale, when creates image.
>> - ImageCache now use scale factor as a key.
>> - CGContext also scaled to a ratio of image/control width/height
>> - Cleanup
>>
>> Note that this fix depends from the:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8004866/webrev.00
>>
>> --
>> Best regards, Sergey.
>>
>>
>
>
> --
> Best regards, Sergey.
>
>

From marco.dinacci at gmail.com  Fri Apr  5 04:29:18 2013
From: marco.dinacci at gmail.com (Marco Dinacci)
Date: Fri, 5 Apr 2013 12:29:18 +0100
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
In-Reply-To: <515DC02C.1030608@oracle.com>
References: <515DC02C.1030608@oracle.com>
Message-ID: <CAC8dNtC0BY2vYe9EgUj=OePP-bhxvngxHrbnyh3kXQ-GLQjuzg@mail.gmail.com>

Hi,

thanks a lot for this work, this is indeed something many developers
including myself were looking for.

Is there any plan to backport all changes related to hi-dpi support to
OpenJDK 7 ?

Best,
Marco


On 4 April 2013 19:02, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hello,
> Please review the fix for jdk 8. Change adds support of hidpi to Aqua l&f.
> Change description:
> - AquaPainter takes into account scale, when creates image.
> - ImageCache now use scale factor as a key.
> - CGContext also scaled to a ratio of image/control width/height
> - Cleanup
>
> Note that this fix depends from the:
> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8000629<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629>
>
> Bug: http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004866<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866>
> Webrev can be found at: http://cr.openjdk.java.net/~**
> serb/8004866/webrev.00<http://cr.openjdk.java.net/~serb/8004866/webrev.00>
>
> --
> Best regards, Sergey.
>
>


-- 
www.intransitione.com

From alexandr.scherbatiy at oracle.com  Fri Apr  5 07:00:22 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 05 Apr 2013 18:00:22 +0400
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
In-Reply-To: <515DC02C.1030608@oracle.com>
References: <515DC02C.1030608@oracle.com>
Message-ID: <515ED8F6.7060706@oracle.com>


    The fix looks good for me.

    Thanks,
    Alexandr.

On 4/4/2013 10:02 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 8. Change adds support of hidpi to Aqua 
> l&f.
> Change description:
> - AquaPainter takes into account scale, when creates image.
> - ImageCache now use scale factor as a key.
> - CGContext also scaled to a ratio of image/control width/height
> - Cleanup
>
> Note that this fix depends from the:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8004866/webrev.00
>


From Sergey.Bylokhov at oracle.com  Fri Apr  5 09:54:06 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 05 Apr 2013 20:54:06 +0400
Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with
	Java 7 on Retina display
In-Reply-To: <5151BFCA.1060702@oracle.com>
References: <5151BFCA.1060702@oracle.com>
Message-ID: <515F01AE.4050409@oracle.com>

Hi, Jim.
I assume, that you haven't additional comments? Can I consider you as 
the second reviewer?
Note that I plan push it to awt-dev because, my other fixes depend on it.

On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 8.
> Change adds initial support of hidpi(mostly on 2d side). In the fix 
> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
> scale factor maps virtual coordinates to physical pixels.
> This change doesn't add support of hidpi to aqua l&f and doesn't add 
> support of dynamic change of scale factor.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8000629/webrev.06
> -- 
> Best regards, Sergey.


-- 
Best regards, Sergey.


From philip.race at oracle.com  Fri Apr  5 11:00:01 2013
From: philip.race at oracle.com (Phil Race)
Date: Fri, 05 Apr 2013 11:00:01 -0700
Subject: <AWT Dev> [8] Request for review: 8000629 [macosx] Blurry
	rendering with Java 7 on Retina display
In-Reply-To: <515F01AE.4050409@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
Message-ID: <515F1121.4020107@oracle.com>

SFAIK you haven't fixed the problem with TexturePaint I pointed out last 
week.
That needs to be fixed before you push.

-phil.

On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
> Hi, Jim.
> I assume, that you haven't additional comments? Can I consider you as 
> the second reviewer?
> Note that I plan push it to awt-dev because, my other fixes depend on it.
>
> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk 8.
>> Change adds initial support of hidpi(mostly on 2d side). In the fix 
>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
>> scale factor maps virtual coordinates to physical pixels.
>> This change doesn't add support of hidpi to aqua l&f and doesn't add 
>> support of dynamic change of scale factor.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>> -- 
>> Best regards, Sergey.
>
>
> -- 
> Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Apr  5 11:10:52 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 05 Apr 2013 22:10:52 +0400
Subject: <AWT Dev> [8] Request for review: 8000629 [macosx] Blurry
	rendering with Java 7 on Retina display
In-Reply-To: <515F1121.4020107@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com>
Message-ID: <515F13AC.50907@oracle.com>

Hi, Phil.
Could you please send me a screenshot and steps to reproduce.
Note that you should change hidpi mode before start j2ddemo.

On 4/5/13 10:00 PM, Phil Race wrote:
> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
> last week.
> That needs to be fixed before you push.
>
> -phil.
>
> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>> Hi, Jim.
>> I assume, that you haven't additional comments? Can I consider you as 
>> the second reviewer?
>> Note that I plan push it to awt-dev because, my other fixes depend on 
>> it.
>>
>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 8.
>>> Change adds initial support of hidpi(mostly on 2d side). In the fix 
>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
>>> scale factor maps virtual coordinates to physical pixels.
>>> This change doesn't add support of hidpi to aqua l&f and doesn't add 
>>> support of dynamic change of scale factor.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>> -- 
>>> Best regards, Sergey.
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From dan.xu at oracle.com  Fri Apr  5 15:35:03 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Fri, 05 Apr 2013 15:35:03 -0700
Subject: Review Request: JDK-8011602 - jobjc build failure on Mac
Message-ID: <515F5197.1060006@oracle.com>

Hi All,

Please review the change to fix the build issue on mac platformat 
http://cr.openjdk.java.net/~dxu/8011602/webrev/.It removes the 
un-necessary @Native annotation from 
src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. 
Therefore, the objc compilation will not dependon the new 
java.lang.annotation.Native interfacethat is only introduced in jdk8.

For the normalbuild process, even though @Native annotationis added to 
many other java classes to replace @GenerateNativeHeader, the langtool 
has the capability to handle that when building with jdk7. But on Mac 
platform, objc compilation is a special process, where the magic of 
langtool to handle new jdk8 interface in old jdk7 cannot be applied. 
Since Coder.java already has a native method, 
getNativeFFITypePtrForCode(), declared, @Native is notnecessary to be 
present, and it is safe to remove them. The other change in file, 
src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format 
correction. I have tested this fix in jprt with boot jdk as jdk7 across 
all platforms. Thanks!

webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/

-Dan

From mandy.chung at oracle.com  Fri Apr  5 16:15:06 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 05 Apr 2013 16:15:06 -0700
Subject: Review Request: JDK-8011602 - jobjc build failure on Mac
In-Reply-To: <515F5197.1060006@oracle.com>
References: <515F5197.1060006@oracle.com>
Message-ID: <515F5AFA.5060703@oracle.com>

Thumbs up.  Thanks for fixing it quickly.  The macosx jobjc build has 
its own special build logic that brought some surprise when I merged it 
with jigsaw at one time.

Mandy

On 4/5/2013 3:35 PM, Dan Xu wrote:
> Hi All,
>
> Please review the change to fix the build issue on mac platformat 
> http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the 
> un-necessary @Native annotation from 
> src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. 
> Therefore, the objc compilation will not dependon the new 
> java.lang.annotation.Native interfacethat is only introduced in jdk8.
>
> For the normal build process, even though @Native annotationis added 
> to many other java classes to replace @GenerateNativeHeader, the 
> langtool has the capability to handle that when building with jdk7. 
> But on Mac platform, objc compilation is a special process, where the 
> magic of langtool to handle new jdk8 interface in old jdk7 cannot be 
> applied. Since Coder.java already has a native method, 
> getNativeFFITypePtrForCode(), declared, @Native is not necessary to be 
> present, and it is safe to remove them. The other change in file, 
> src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format 
> correction. I have tested this fix in jprt with boot jdk as jdk7 
> across all platforms. Thanks!
>
> webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/
>
> -Dan


From dan.xu at oracle.com  Fri Apr  5 16:21:47 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Fri, 05 Apr 2013 16:21:47 -0700
Subject: Review Request: JDK-8011602 - jobjc build failure on Mac
In-Reply-To: <515F5AFA.5060703@oracle.com>
References: <515F5197.1060006@oracle.com> <515F5AFA.5060703@oracle.com>
Message-ID: <515F5C8B.7050605@oracle.com>

Right. Even the generated native headers from jobjc are saved into its 
own directory.

Thank you for your review!

-Dan


On 04/05/2013 04:15 PM, Mandy Chung wrote:
> Thumbs up.  Thanks for fixing it quickly.  The macosx jobjc build has 
> its own special build logic that brought some surprise when I merged 
> it with jigsaw at one time.
>
> Mandy
>
> On 4/5/2013 3:35 PM, Dan Xu wrote:
>> Hi All,
>>
>> Please review the change to fix the build issue on mac platformat 
>> http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the 
>> un-necessary @Native annotation from 
>> src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. 
>> Therefore, the objc compilation will not dependon the new 
>> java.lang.annotation.Native interfacethat is only introduced in jdk8.
>>
>> For the normal build process, even though @Native annotationis added 
>> to many other java classes to replace @GenerateNativeHeader, the 
>> langtool has the capability to handle that when building with jdk7. 
>> But on Mac platform, objc compilation is a special process, where the 
>> magic of langtool to handle new jdk8 interface in old jdk7 cannot be 
>> applied. Since Coder.java already has a native method, 
>> getNativeFFITypePtrForCode(), declared, @Native is not necessary to 
>> be present, and it is safe to remove them. The other change in file, 
>> src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format 
>> correction. I have tested this fix in jprt with boot jdk as jdk7 
>> across all platforms. Thanks!
>>
>> webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/
>>
>> -Dan
>


From david.holmes at oracle.com  Fri Apr  5 16:51:35 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 06 Apr 2013 09:51:35 +1000
Subject: Review Request: JDK-8011602 - jobjc build failure on Mac
In-Reply-To: <515F5C8B.7050605@oracle.com>
References: <515F5197.1060006@oracle.com> <515F5AFA.5060703@oracle.com>
	<515F5C8B.7050605@oracle.com>
Message-ID: <515F6387.8010305@oracle.com>

Dan,

Looks okay to me - glad there was a simple solution.

Still wondering why this didn't get picked up during JPRT testing though ??

Thanks,
David

On 6/04/2013 9:21 AM, Dan Xu wrote:
> Right. Even the generated native headers from jobjc are saved into its
> own directory.
>
> Thank you for your review!
>
> -Dan
>
>
> On 04/05/2013 04:15 PM, Mandy Chung wrote:
>> Thumbs up.  Thanks for fixing it quickly.  The macosx jobjc build has
>> its own special build logic that brought some surprise when I merged
>> it with jigsaw at one time.
>>
>> Mandy
>>
>> On 4/5/2013 3:35 PM, Dan Xu wrote:
>>> Hi All,
>>>
>>> Please review the change to fix the build issue on mac platformat
>>> http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the
>>> un-necessary @Native annotation from
>>> src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java.
>>> Therefore, the objc compilation will not dependon the new
>>> java.lang.annotation.Native interfacethat is only introduced in jdk8.
>>>
>>> For the normal build process, even though @Native annotationis added
>>> to many other java classes to replace @GenerateNativeHeader, the
>>> langtool has the capability to handle that when building with jdk7.
>>> But on Mac platform, objc compilation is a special process, where the
>>> magic of langtool to handle new jdk8 interface in old jdk7 cannot be
>>> applied. Since Coder.java already has a native method,
>>> getNativeFFITypePtrForCode(), declared, @Native is not necessary to
>>> be present, and it is safe to remove them. The other change in file,
>>> src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format
>>> correction. I have tested this fix in jprt with boot jdk as jdk7
>>> across all platforms. Thanks!
>>>
>>> webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/
>>>
>>> -Dan
>>
>

From dan.xu at oracle.com  Fri Apr  5 17:06:54 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Fri, 05 Apr 2013 17:06:54 -0700
Subject: Review Request: JDK-8011602 - jobjc build failure on Mac
In-Reply-To: <515F6387.8010305@oracle.com>
References: <515F5197.1060006@oracle.com> <515F5AFA.5060703@oracle.com>
	<515F5C8B.7050605@oracle.com> <515F6387.8010305@oracle.com>
Message-ID: <515F671E.3060308@oracle.com>

Hi David,

Thanks for your review. When I tested it in JPRT run, I added "-boot 
jdk1.8.0" to use jdk8 as the boot jdk. I did not realize that being able 
to build with jdk7 is a requirement. I will push the fix now. Thanks!

-Dan


On 04/05/2013 04:51 PM, David Holmes wrote:
> Dan,
>
> Looks okay to me - glad there was a simple solution.
>
> Still wondering why this didn't get picked up during JPRT testing 
> though ??
>
> Thanks,
> David
>
> On 6/04/2013 9:21 AM, Dan Xu wrote:
>> Right. Even the generated native headers from jobjc are saved into its
>> own directory.
>>
>> Thank you for your review!
>>
>> -Dan
>>
>>
>> On 04/05/2013 04:15 PM, Mandy Chung wrote:
>>> Thumbs up.  Thanks for fixing it quickly.  The macosx jobjc build has
>>> its own special build logic that brought some surprise when I merged
>>> it with jigsaw at one time.
>>>
>>> Mandy
>>>
>>> On 4/5/2013 3:35 PM, Dan Xu wrote:
>>>> Hi All,
>>>>
>>>> Please review the change to fix the build issue on mac platformat
>>>> http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the
>>>> un-necessary @Native annotation from
>>>> src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java.
>>>> Therefore, the objc compilation will not dependon the new
>>>> java.lang.annotation.Native interfacethat is only introduced in jdk8.
>>>>
>>>> For the normal build process, even though @Native annotationis added
>>>> to many other java classes to replace @GenerateNativeHeader, the
>>>> langtool has the capability to handle that when building with jdk7.
>>>> But on Mac platform, objc compilation is a special process, where the
>>>> magic of langtool to handle new jdk8 interface in old jdk7 cannot be
>>>> applied. Since Coder.java already has a native method,
>>>> getNativeFFITypePtrForCode(), declared, @Native is not necessary to
>>>> be present, and it is safe to remove them. The other change in file,
>>>> src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format
>>>> correction. I have tested this fix in jprt with boot jdk as jdk7
>>>> across all platforms. Thanks!
>>>>
>>>> webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/
>>>>
>>>> -Dan
>>>
>>


From swingler at apple.com  Sun Apr  7 09:13:53 2013
From: swingler at apple.com (Mike Swingler)
Date: Sun, 07 Apr 2013 09:13:53 -0700
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
In-Reply-To: <CAC8dNtC0BY2vYe9EgUj=OePP-bhxvngxHrbnyh3kXQ-GLQjuzg@mail.gmail.com>
References: <515DC02C.1030608@oracle.com>
	<CAC8dNtC0BY2vYe9EgUj=OePP-bhxvngxHrbnyh3kXQ-GLQjuzg@mail.gmail.com>
Message-ID: <0C9DEE58-878D-4687-92DF-082C10416378@apple.com>

It may be beneficial to put up a Q&A page on the Mac OS X Port project wiki to answer common questions like this.

As an example, I wrote up a Q&A explaining the decision making process that went into the new graphics stack for Java 7:
<https://wikis.oracle.com/display/OpenJDK/Java2D+Graphics+Design+Plan>

Having something similar for HiDPI would be very helpful to point people to when they want to know how to do X, or knowing if a certain technique is going to work.

~Mike

On Apr 5, 2013, at 4:29 AM, Marco Dinacci <marco.dinacci at gmail.com> wrote:

> Hi,
> 
> thanks a lot for this work, this is indeed something many developers including myself were looking for.
> 
> Is there any plan to backport all changes related to hi-dpi support to OpenJDK 7 ?
> 
> Best,
> Marco
> 
> 
> On 4 April 2013 19:02, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> Hello,
> Please review the fix for jdk 8. Change adds support of hidpi to Aqua l&f.
> Change description:
> - AquaPainter takes into account scale, when creates image.
> - ImageCache now use scale factor as a key.
> - CGContext also scaled to a ratio of image/control width/height
> - Cleanup
> 
> Note that this fix depends from the:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
> 
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8004866/webrev.00
> 
> -- 
> Best regards, Sergey.
> 
> 
> 
> 
> -- 
> www.intransitione.com


From Sergey.Bylokhov at oracle.com  Mon Apr  8 06:10:21 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 08 Apr 2013 17:10:21 +0400
Subject: <AWT Dev> [8] Request for review: 8000629 [macosx] Blurry
	rendering with Java 7 on Retina display
In-Reply-To: <515F1121.4020107@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com>
Message-ID: <5162C1BD.8070703@oracle.com>

Hi, Phil, JIm.
New version of the fix:
http://cr.openjdk.java.net/~serb/8000629/webrev.08
  - Assumption that we should scale all native surfaces was wrong. In 
case of managed Bufferedimage we shouldn't scale native surface, because 
they are copies 1-1.(CGLSurfaceData.java:60).
  - BufferedContext is not always updates current Paint, because it 
checks transX/transY from sg2d, which is not maintained in the scale mode.
Test: FillTexturePaint.java

Also I found a problem in the sg2d.getTransform(), where invScale does 
not apply to constrainX/Y.
Test: TransformSetGet.java

On 4/5/13 10:00 PM, Phil Race wrote:
> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
> last week.
> That needs to be fixed before you push.
>
> -phil.
>
> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>> Hi, Jim.
>> I assume, that you haven't additional comments? Can I consider you as 
>> the second reviewer?
>> Note that I plan push it to awt-dev because, my other fixes depend on 
>> it.
>>
>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 8.
>>> Change adds initial support of hidpi(mostly on 2d side). In the fix 
>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
>>> scale factor maps virtual coordinates to physical pixels.
>>> This change doesn't add support of hidpi to aqua l&f and doesn't add 
>>> support of dynamic change of scale factor.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>> -- 
>>> Best regards, Sergey.
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Apr  8 06:31:01 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 08 Apr 2013 17:31:01 +0400
Subject: [8] Request for review: 8004866 [macosx] HiDPI support in Aqua L&F
In-Reply-To: <CAC8dNtC0BY2vYe9EgUj=OePP-bhxvngxHrbnyh3kXQ-GLQjuzg@mail.gmail.com>
References: <515DC02C.1030608@oracle.com>
	<CAC8dNtC0BY2vYe9EgUj=OePP-bhxvngxHrbnyh3kXQ-GLQjuzg@mail.gmail.com>
Message-ID: <5162C695.1060005@oracle.com>

Hi, Marco.
It will be backported, when it will be stable enough.

On 4/5/13 3:29 PM, Marco Dinacci wrote:
> Hi,
>
> thanks a lot for this work, this is indeed something many developers 
> including myself were looking for.
>
> Is there any plan to backport all changes related to hi-dpi support to 
> OpenJDK 7 ?
>
> Best,
> Marco
>
>
> On 4 April 2013 19:02, Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     Hello,
>     Please review the fix for jdk 8. Change adds support of hidpi to
>     Aqua l&f.
>     Change description:
>     - AquaPainter takes into account scale, when creates image.
>     - ImageCache now use scale factor as a key.
>     - CGContext also scaled to a ratio of image/control width/height
>     - Cleanup
>
>     Note that this fix depends from the:
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>
>     Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004866
>     Webrev can be found at:
>     http://cr.openjdk.java.net/~serb/8004866/webrev.00
>     <http://cr.openjdk.java.net/%7Eserb/8004866/webrev.00>
>
>     -- 
>     Best regards, Sergey.
>
>
>
>
> -- 
> www.intransitione.com <http://www.intransitione.com>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Apr  9 02:54:28 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 09 Apr 2013 13:54:28 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Request for review: 8000629
	[macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <51633454.9060005@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <5162C1BD.8070703@oracle.com>
	<51633454.9060005@oracle.com>
Message-ID: <5163E554.7050200@oracle.com>

Hi, Jim.
On 4/9/13 1:19 AM, Jim Graham wrote:
> Hi Sergey,
>
> Did you check for possible performance hits for the new transform 
> save/compare code in BufferedContext?
I am not sure how it can be improved, because BufferedPaints.setPaint() 
depends from the current transform of the sg2d.transform. And it should 
be called, when sg2d.transform is changed.
> That is significantly more work per validate(). 
I guess in most common case only aftm.equals() was added.
> Also, isn't this case only used in the case where the caller specified 
> a null xform in the argument list?  Does that happen (or, I guess, how 
> does it happen) on a scaled graphics?
Yes this happens if xform is null, so only code under if (xform == 
null)  was changed.
>
> Something I didn't notice before - you adjust the max texture sizes in 
> CGLGraphicsConfig by the device scale, but you adjust them by 
> "getScaleFactor() * 2".  Why the "* 2"?
This is related to 7160609. The problem was in fact, that we create huge 
texture during window initialization. In the fix I change this logic to 
use GL_MAX_TEXTURE_SIZE/2.
Separate CR:8010999 was created to track it.
>
> You removed a call to flushOnScreenGraphics in LWWindowPeer.  Was that 
> just being paranoid before and really isn't needed?
Now it is called not only when the window is resized, but when the 
surface is replaced. It was moved to replaceSurfaceData.
>
> It's already done and the code is written, but in retrospect, I'm not 
> sure how much the optimizations in getTransform/setTransform are worth 
> compared to the easy readability of having the transforms done 
> linearly in a LIFO manner, such as:
>
> setTransform:
>     transform.setToIdentity();
>     if (cX|cY != 0) { transform.translate(cX, cY); }
>     if (dS != 1) transform.scale(dS, dS); }
>     transform.concatenate(Tx);
> getTransform:
>     tx = new AT(transform);
>     if (dS != 1) { tx.scale(invDs, invDs); }
>     if (cX|cY != 0) { tx.translate(-cX, -cY); }
>     return tx;
>
> (I don't think it should be changed, but I'm throwing it out there as 
> food for thought as it may be easier to maintain in the future, but it 
> could also change the performance as I'm just speculating from how I 
> remember the optimizations work...)
When it was written, I was impressed by a code in the 2D.
>
>             ...jim
>
> On 4/8/2013 6:10 AM, Sergey Bylokhov wrote:
>> Hi, Phil, JIm.
>> New version of the fix:
>> http://cr.openjdk.java.net/~serb/8000629/webrev.08
>>   - Assumption that we should scale all native surfaces was wrong. In 
>> case of managed Bufferedimage we shouldn't scale native surface, 
>> because they are copies 1-1.(CGLSurfaceData.java:60).
>>   - BufferedContext is not always updates current Paint, because it 
>> checks transX/transY from sg2d, which is not maintained in the scale 
>> mode.
>> Test: FillTexturePaint.java
>>
>> Also I found a problem in the sg2d.getTransform(), where invScale 
>> does not apply to constrainX/Y.
>> Test: TransformSetGet.java
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Apr  9 05:40:47 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 09 Apr 2013 16:40:47 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [8] Request for review: 8000629
	[macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <51633454.9060005@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <5162C1BD.8070703@oracle.com>
	<51633454.9060005@oracle.com>
Message-ID: <51640C4F.1090902@oracle.com>

Hi, Jim.
During additional testing I found some artifacts in some animation, when 
the rendering to the scaled VolatileImge is different from the non 
scaled variant. Can you please take a look to the CR:8011764.

On 4/9/13 1:19 AM, Jim Graham wrote:
> Hi Sergey,
>
> Did you check for possible performance hits for the new transform 
> save/compare code in BufferedContext?  That is significantly more work 
> per validate().  Also, isn't this case only used in the case where the 
> caller specified a null xform in the argument list? Does that happen 
> (or, I guess, how does it happen) on a scaled graphics?
>
> Something I didn't notice before - you adjust the max texture sizes in 
> CGLGraphicsConfig by the device scale, but you adjust them by 
> "getScaleFactor() * 2".  Why the "* 2"?  Shouldn't adjusting them by 
> the scale factor itself be enough?  In the unscaled case, are our max 
> textures sizes now half of what they used to be?  Also, where is this 
> code used from?  Are there cases where an unscaled texture is planned 
> and so the divide by the scale factor is unnecessarily conservative 
> (as opposed to cases like back buffer allocation where the texture may 
> be @2x...)
>
> You removed a call to flushOnScreenGraphics in LWWindowPeer.  Was that 
> just being paranoid before and really isn't needed?
>
> It's already done and the code is written, but in retrospect, I'm not 
> sure how much the optimizations in getTransform/setTransform are worth 
> compared to the easy readability of having the transforms done 
> linearly in a LIFO manner, such as:
>
> setTransform:
>     transform.setToIdentity();
>     if (cX|cY != 0) { transform.translate(cX, cY); }
>     if (dS != 1) transform.scale(dS, dS); }
>     transform.concatenate(Tx);
> getTransform:
>     tx = new AT(transform);
>     if (dS != 1) { tx.scale(invDs, invDs); }
>     if (cX|cY != 0) { tx.translate(-cX, -cY); }
>     return tx;
>
> (I don't think it should be changed, but I'm throwing it out there as 
> food for thought as it may be easier to maintain in the future, but it 
> could also change the performance as I'm just speculating from how I 
> remember the optimizations work...)
>
>             ...jim
>
> On 4/8/2013 6:10 AM, Sergey Bylokhov wrote:
>> Hi, Phil, JIm.
>> New version of the fix:
>> http://cr.openjdk.java.net/~serb/8000629/webrev.08
>>   - Assumption that we should scale all native surfaces was wrong. In 
>> case of managed Bufferedimage we shouldn't scale native surface, 
>> because they are copies 1-1.(CGLSurfaceData.java:60).
>>   - BufferedContext is not always updates current Paint, because it 
>> checks transX/transY from sg2d, which is not maintained in the scale 
>> mode.
>> Test: FillTexturePaint.java
>>
>> Also I found a problem in the sg2d.getTransform(), where invScale 
>> does not apply to constrainX/Y.
>> Test: TransformSetGet.java
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Apr 10 12:21:23 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 10 Apr 2013 19:21:23 -0000
Subject: <AWT Dev> [8] Request for review: 8000629 [macosx] Blurry
	rendering with Java 7 on Retina display
In-Reply-To: <515F13AC.50907@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <515F13AC.50907@oracle.com>
Message-ID: <524F151E.6020500@oracle.com>

Hi, Jim, Phil.
Once again=) I assume, that you haven't additional comments? Can I 
consider you as the reviewers?
Note that I plan push it to awt-dev because, my other fixes depend on it.

On 4/5/13 10:10 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> Could you please send me a screenshot and steps to reproduce.
> Note that you should change hidpi mode before start j2ddemo.
>
> On 4/5/13 10:00 PM, Phil Race wrote:
>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>> last week.
>> That needs to be fixed before you push.
>>
>> -phil.
>>
>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>> Hi, Jim.
>>> I assume, that you haven't additional comments? Can I consider you 
>>> as the second reviewer?
>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>> on it.
>>>
>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk 8.
>>>> Change adds initial support of hidpi(mostly on 2d side). In the fix 
>>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
>>>> scale factor maps virtual coordinates to physical pixels.
>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>> add support of dynamic change of scale factor.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed Apr 10 12:47:24 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 10 Apr 2013 12:47:24 -0700
Subject: <AWT Dev> [8] Request for review: 8000629 [macosx] Blurry
	rendering with Java 7 on Retina display
In-Reply-To: <524F151E.6020500@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <515F13AC.50907@oracle.com>
	<524F151E.6020500@oracle.com>
Message-ID: <5165C1CC.50608@oracle.com>

I skimmed the updated version but I haven't had a chance to try it out yet.
I'll try to do so later today or tomorrow.

-phil.

On 10/4/2013 12:21 PM, Sergey Bylokhov wrote:
> Hi, Jim, Phil.
> Once again=) I assume, that you haven't additional comments? Can I 
> consider you as the reviewers?
> Note that I plan push it to awt-dev because, my other fixes depend on it.
>
> On 4/5/13 10:10 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> Could you please send me a screenshot and steps to reproduce.
>> Note that you should change hidpi mode before start j2ddemo.
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>
>


From philip.race at oracle.com  Thu Apr 11 12:33:21 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 11 Apr 2013 12:33:21 -0700
Subject: <AWT Dev> [8] Request for review: 8000629 [macosx] Blurry
	rendering with Java 7 on Retina display
In-Reply-To: <524F151E.6020500@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <515F13AC.50907@oracle.com>
	<524F151E.6020500@oracle.com>
Message-ID: <51671001.5010302@oracle.com>

I am now fine with this latest version.

-phil.

On 10/4/13 12:21 PM, Sergey Bylokhov wrote:
> Hi, Jim, Phil.
> Once again=) I assume, that you haven't additional comments? Can I 
> consider you as the reviewers?
> Note that I plan push it to awt-dev because, my other fixes depend on it.
>
> On 4/5/13 10:10 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> Could you please send me a screenshot and steps to reproduce.
>> Note that you should change hidpi mode before start j2ddemo.
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>
>


From Abhinay.Reddyreddy at mathworks.com  Mon Apr 15 10:13:22 2013
From: Abhinay.Reddyreddy at mathworks.com (Abhinay Reddyreddy)
Date: Mon, 15 Apr 2013 17:13:22 +0000
Subject: [macosx] collate option ignored in native print dialog.
Message-ID: <353D880645CCDC429732D7A445F7F5BF462A0D64@exmb-00-ah.ad.mathworks.com>

Hi,

I am trying to use the native print dialog through DialogSelectionType.NATIVE option on Mac OS X. In this dialog if a user selects the collate option from Paper Handling options, the output from the printer is not collated. i.e The user expected output in the sequence "Page 1 Page 2 Page 1 Page2..." but the printed sequence is "Page1 Page1 .. Page 2 Page 2".

Is there any workaround to get the output to not ignore the user selection for collate option ??

Here is a simple test case.


import java.awt.*;

import javax.swing.*;

import java.awt.print.*;

import javax.print.attribute.PrintRequestAttributeSet;

import javax.print.attribute.HashPrintRequestAttributeSet;

import javax.print.attribute.standard.DialogTypeSelection;

import javax.print.attribute.standard.SheetCollate;

import javax.print.attribute.standard.Copies;


public class SunTest implements Printable

{

   public void startTestCase()

   {

PrinterJob pj = PrinterJob.getPrinterJob();

PrintRequestAttributeSet pras  = new HashPrintRequestAttributeSet();

pras.add(DialogTypeSelection.NATIVE);

pras.add(SheetCollate.COLLATED);

pras.add(new Copies(2));

pj.setPrintable(this);

        if (pj.printDialog(pras))

        {

try{

pj.print(pras);

} catch (Exception e) {

}

        }

   }


public int print(Graphics g, PageFormat pf, int pageNo) throws PrinterException

{

if(pageNo > 2)

return Printable.NO_SUCH_PAGE;

else {

g.setColor(Color.black);

Font fnt = new Font("Serif", Font.PLAIN, 32);   /* Cover page */

            g.setFont(fnt);

g.drawString("Page no: "+Integer.toString(pageNo), 100, 200);

return Printable.PAGE_EXISTS;

}

}


   public static void main (String []Args) {

      SunTest st = new SunTest ();

      st.startTestCase ();

   }

}


- Abhinay.

From heinz at javaspecialists.eu  Tue Apr 16 05:57:06 2013
From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz)
Date: Tue, 16 Apr 2013 15:57:06 +0300
Subject: Latency in starting threads on Mac OS X
Message-ID: <516D4AA2.9020701@javaspecialists.eu>

Good day my fellow Mac OS X users!

Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to
demonstrate to my class how slow it was starting threads and how much
better it is to use a FixedThreadPool.  The question that I wanted to
answer was: How many microseconds does it take on average to start a
simple thread and what is the maximum time it could take?

We all know that it can take in the milliseconds range to do the following:

Thread t = new Thread(); // even without it actually doing anything
t.start();

This is one of the reasons why the fixed thread pool only starts the
threads as we submit jobs to it, since the up-front cost might not be
worth the wait.

But how long do you think the *maximum* was that I had to wait for
t.start() to return?  100ms?  200ms?

Actually, the longest I had to wait turned out to be about 250 seconds.
Yes.  That is *seconds*, not *milliseconds*.  Just to start a single thread.

This is most certainly a bug in the OpenJDK on Mac OS X.  We did not see
this behaviour on Linux nor on Windows 7.

The bug started in OpenJDK 1.7.0_06.  Prior to that it hardly ever took
longer than 30ms to start a single thread.

java version "1.7.0_05"
heinz$ java ThreadLeakMac2
time = 1, threads = 4
time = 2, threads = 346
time = 4, threads = 7378
time = 7, threads = 9614
time = 12, threads = 10027
time = 14, threads = 10063
time = 17, threads = 26965
time = 38, threads = 27013
time = 39, threads = 452053

java version "1.7.0_06"
heinz$ java ThreadLeakMac2
time = 1, threads = 6
time = 2, threads = 256
time = 6, threads = 373
*snip*
time = 111, threads = 42592
time = 200, threads = 49419
time = 333, threads = 58976
*snip*
time = 3245, threads = 202336
time = 3706, threads = 203702
*snip*
time = 5835, threads = 267872
time = 6455, threads = 269238
time = 9170, threads = 270603

In my code, I make sure that the thread has stopped before creating the
next one by calling join().

public class ThreadLeakMac2 {
    public static void main(String[] args) throws InterruptedException {
        long threads = 0;
        long max = 0;
        while(true) {
            long time = System.currentTimeMillis();
            Thread thread = new Thread();
            thread.start(); // should finish almost immediately
            time = System.currentTimeMillis() - time;
            thread.join(); // short delay, hopefully
            threads++;
            if (time > max) {
                max = time;
                System.out.println("time = " + time +
                                   ", threads = " + threads);
            }
        }
    }
}

This would be another nice test case for Alexey's concurrency stress
test harness.

(I also posted this to the concurrency-interest list.)

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz



From kurchi.subhra.hazra at oracle.com  Tue Apr 16 09:52:11 2013
From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra)
Date: Tue, 16 Apr 2013 09:52:11 -0700
Subject: Fwd: Latency in starting threads on Mac OS X
In-Reply-To: <516D4AA2.9020701@javaspecialists.eu>
References: <516D4AA2.9020701@javaspecialists.eu>
Message-ID: <516D81BB.3090806@oracle.com>

Forwarding to core-libs.

- Kurchi

-------- Original Message --------
Subject: 	Latency in starting threads on Mac OS X
Date: 	Tue, 16 Apr 2013 15:57:06 +0300
From: 	Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
Organization: 	JavaSpecialists.eu
To: 	macosx-port-dev at openjdk.java.net



Good day my fellow Mac OS X users!

Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to
demonstrate to my class how slow it was starting threads and how much
better it is to use a FixedThreadPool.  The question that I wanted to
answer was: How many microseconds does it take on average to start a
simple thread and what is the maximum time it could take?

We all know that it can take in the milliseconds range to do the following:

Thread t = new Thread(); // even without it actually doing anything
t.start();

This is one of the reasons why the fixed thread pool only starts the
threads as we submit jobs to it, since the up-front cost might not be
worth the wait.

But how long do you think the *maximum* was that I had to wait for
t.start() to return?  100ms?  200ms?

Actually, the longest I had to wait turned out to be about 250 seconds.
Yes.  That is *seconds*, not *milliseconds*.  Just to start a single thread.

This is most certainly a bug in the OpenJDK on Mac OS X.  We did not see
this behaviour on Linux nor on Windows 7.

The bug started in OpenJDK 1.7.0_06.  Prior to that it hardly ever took
longer than 30ms to start a single thread.

java version "1.7.0_05"
heinz$ java ThreadLeakMac2
time = 1, threads = 4
time = 2, threads = 346
time = 4, threads = 7378
time = 7, threads = 9614
time = 12, threads = 10027
time = 14, threads = 10063
time = 17, threads = 26965
time = 38, threads = 27013
time = 39, threads = 452053

java version "1.7.0_06"
heinz$ java ThreadLeakMac2
time = 1, threads = 6
time = 2, threads = 256
time = 6, threads = 373
*snip*
time = 111, threads = 42592
time = 200, threads = 49419
time = 333, threads = 58976
*snip*
time = 3245, threads = 202336
time = 3706, threads = 203702
*snip*
time = 5835, threads = 267872
time = 6455, threads = 269238
time = 9170, threads = 270603

In my code, I make sure that the thread has stopped before creating the
next one by calling join().

public class ThreadLeakMac2 {
    public static void main(String[] args) throws InterruptedException {
        long threads = 0;
        long max = 0;
        while(true) {
            long time = System.currentTimeMillis();
            Thread thread = new Thread();
            thread.start(); // should finish almost immediately
            time = System.currentTimeMillis() - time;
            thread.join(); // short delay, hopefully
            threads++;
            if (time>  max) {
                max = time;
                System.out.println("time = " + time +
                                   ", threads = " + threads);
            }
        }
    }
}

This would be another nice test case for Alexey's concurrency stress
test harness.

(I also posted this to the concurrency-interest list.)

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz




From philip.race at oracle.com  Tue Apr 16 14:24:40 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 16 Apr 2013 14:24:40 -0700
Subject: [macosx] collate option ignored in native print dialog.
In-Reply-To: <353D880645CCDC429732D7A445F7F5BF462A0D64@exmb-00-ah.ad.mathworks.com>
References: <353D880645CCDC429732D7A445F7F5BF462A0D64@exmb-00-ah.ad.mathworks.com>
Message-ID: <516DC198.1000207@oracle.com>

I can reproduce on current JDK 8 too. I've filed
  JDK-8012381 : Collation selection ignored when printing on MacOS X

-phil.

On 4/15/2013 10:13 AM, Abhinay Reddyreddy wrote:
> Hi,
>
> I am trying to use the native print dialog through DialogSelectionType.NATIVE option on Mac OS X. In this dialog if a user selects the collate option from Paper Handling options, the output from the printer is not collated. i.e The user expected output in the sequence "Page 1 Page 2 Page 1 Page2..." but the printed sequence is "Page1 Page1 .. Page 2 Page 2".
>
> Is there any workaround to get the output to not ignore the user selection for collate option ??
>
> Here is a simple test case.
>
>
> import java.awt.*;
>
> import javax.swing.*;
>
> import java.awt.print.*;
>
> import javax.print.attribute.PrintRequestAttributeSet;
>
> import javax.print.attribute.HashPrintRequestAttributeSet;
>
> import javax.print.attribute.standard.DialogTypeSelection;
>
> import javax.print.attribute.standard.SheetCollate;
>
> import javax.print.attribute.standard.Copies;
>
>
> public class SunTest implements Printable
>
> {
>
>     public void startTestCase()
>
>     {
>
> PrinterJob pj = PrinterJob.getPrinterJob();
>
> PrintRequestAttributeSet pras  = new HashPrintRequestAttributeSet();
>
> pras.add(DialogTypeSelection.NATIVE);
>
> pras.add(SheetCollate.COLLATED);
>
> pras.add(new Copies(2));
>
> pj.setPrintable(this);
>
>          if (pj.printDialog(pras))
>
>          {
>
> try{
>
> pj.print(pras);
>
> } catch (Exception e) {
>
> }
>
>          }
>
>     }
>
>
> public int print(Graphics g, PageFormat pf, int pageNo) throws PrinterException
>
> {
>
> if(pageNo > 2)
>
> return Printable.NO_SUCH_PAGE;
>
> else {
>
> g.setColor(Color.black);
>
> Font fnt = new Font("Serif", Font.PLAIN, 32);   /* Cover page */
>
>              g.setFont(fnt);
>
> g.drawString("Page no: "+Integer.toString(pageNo), 100, 200);
>
> return Printable.PAGE_EXISTS;
>
> }
>
> }
>
>
>     public static void main (String []Args) {
>
>        SunTest st = new SunTest ();
>
>        st.startTestCase ();
>
>     }
>
> }
>
>
> - Abhinay.


From swpalmer at gmail.com  Tue Apr 16 16:41:46 2013
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 16 Apr 2013 19:41:46 -0400
Subject: Latency in starting threads on Mac OS X
In-Reply-To: <516D4AA2.9020701@javaspecialists.eu>
References: <516D4AA2.9020701@javaspecialists.eu>
Message-ID: <555903BF-7538-4154-A3A8-349487564EDE@gmail.com>

I doubt you are measuring what you think you are measuring. Maybe try the same while printing the GC details.
-XX:+PrintGCDetails

Scott

On 2013-04-16, at 8:57 AM, "Dr Heinz M. Kabutz" <heinz at javaspecialists.eu> wrote:

> Good day my fellow Mac OS X users!
> 
> Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to
> demonstrate to my class how slow it was starting threads and how much
> better it is to use a FixedThreadPool.  The question that I wanted to
> answer was: How many microseconds does it take on average to start a
> simple thread and what is the maximum time it could take?
> 
> We all know that it can take in the milliseconds range to do the following:
> 
> Thread t = new Thread(); // even without it actually doing anything
> t.start();
> 
> This is one of the reasons why the fixed thread pool only starts the
> threads as we submit jobs to it, since the up-front cost might not be
> worth the wait.
> 
> But how long do you think the *maximum* was that I had to wait for
> t.start() to return?  100ms?  200ms?
> 
> Actually, the longest I had to wait turned out to be about 250 seconds.
> Yes.  That is *seconds*, not *milliseconds*.  Just to start a single thread.
> 
> This is most certainly a bug in the OpenJDK on Mac OS X.  We did not see
> this behaviour on Linux nor on Windows 7.
> 
> The bug started in OpenJDK 1.7.0_06.  Prior to that it hardly ever took
> longer than 30ms to start a single thread.
> 
> java version "1.7.0_05"
> heinz$ java ThreadLeakMac2
> time = 1, threads = 4
> time = 2, threads = 346
> time = 4, threads = 7378
> time = 7, threads = 9614
> time = 12, threads = 10027
> time = 14, threads = 10063
> time = 17, threads = 26965
> time = 38, threads = 27013
> time = 39, threads = 452053
> 
> java version "1.7.0_06"
> heinz$ java ThreadLeakMac2
> time = 1, threads = 6
> time = 2, threads = 256
> time = 6, threads = 373
> *snip*
> time = 111, threads = 42592
> time = 200, threads = 49419
> time = 333, threads = 58976
> *snip*
> time = 3245, threads = 202336
> time = 3706, threads = 203702
> *snip*
> time = 5835, threads = 267872
> time = 6455, threads = 269238
> time = 9170, threads = 270603
> 
> In my code, I make sure that the thread has stopped before creating the
> next one by calling join().
> 
> public class ThreadLeakMac2 {
>   public static void main(String[] args) throws InterruptedException {
>       long threads = 0;
>       long max = 0;
>       while(true) {
>           long time = System.currentTimeMillis();
>           Thread thread = new Thread();
>           thread.start(); // should finish almost immediately
>           time = System.currentTimeMillis() - time;
>           thread.join(); // short delay, hopefully
>           threads++;
>           if (time > max) {
>               max = time;
>               System.out.println("time = " + time +
>                                  ", threads = " + threads);
>           }
>       }
>   }
> }
> 
> This would be another nice test case for Alexey's concurrency stress
> test harness.
> 
> (I also posted this to the concurrency-interest list.)
> 
> Regards
> 
> Heinz
> -- 
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 75 595 262
> Skype: kabutz
> 
> 

From david.holmes at oracle.com  Tue Apr 16 18:27:41 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Apr 2013 11:27:41 +1000
Subject: Fwd: Latency in starting threads on Mac OS X
In-Reply-To: <516D81BB.3090806@oracle.com>
References: <516D4AA2.9020701@javaspecialists.eu> <516D81BB.3090806@oracle.com>
Message-ID: <516DFA8D.4070808@oracle.com>

As I've pointed out to Heinz on the concurrency-interest list there are 
a couple of flawed assumptions in his test:

a) when you start() a new thread the OS scheduler may switch to it 
immediately (this depends on the scheduler semantics)

b) Thread.join only signifies logical termination of the Java thread. 
The native thread still has to exit the VM and the OS and so can 
encounter additional bottlenecks that result in many more threads being 
existent than expected and which can interfere with the creation of new 
threads.

I don't know specifically what may have changed between 7u5 and 7u6 in 
that regard but I think it would be a hotspot issue more than a 
libraries issue. I know 7u6 was the first version of JDK to fully 
support OS X.

David

On 17/04/2013 2:52 AM, Kurchi Subhra Hazra wrote:
> Forwarding to core-libs.
>
> - Kurchi
>
> -------- Original Message --------
> Subject:     Latency in starting threads on Mac OS X
> Date:     Tue, 16 Apr 2013 15:57:06 +0300
> From:     Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
> Organization:     JavaSpecialists.eu
> To:     macosx-port-dev at openjdk.java.net
>
>
>
> Good day my fellow Mac OS X users!
>
> Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to
> demonstrate to my class how slow it was starting threads and how much
> better it is to use a FixedThreadPool.  The question that I wanted to
> answer was: How many microseconds does it take on average to start a
> simple thread and what is the maximum time it could take?
>
> We all know that it can take in the milliseconds range to do the following:
>
> Thread t = new Thread(); // even without it actually doing anything
> t.start();
>
> This is one of the reasons why the fixed thread pool only starts the
> threads as we submit jobs to it, since the up-front cost might not be
> worth the wait.
>
> But how long do you think the *maximum* was that I had to wait for
> t.start() to return?  100ms?  200ms?
>
> Actually, the longest I had to wait turned out to be about 250 seconds.
> Yes.  That is *seconds*, not *milliseconds*.  Just to start a single
> thread.
>
> This is most certainly a bug in the OpenJDK on Mac OS X.  We did not see
> this behaviour on Linux nor on Windows 7.
>
> The bug started in OpenJDK 1.7.0_06.  Prior to that it hardly ever took
> longer than 30ms to start a single thread.
>
> java version "1.7.0_05"
> heinz$ java ThreadLeakMac2
> time = 1, threads = 4
> time = 2, threads = 346
> time = 4, threads = 7378
> time = 7, threads = 9614
> time = 12, threads = 10027
> time = 14, threads = 10063
> time = 17, threads = 26965
> time = 38, threads = 27013
> time = 39, threads = 452053
>
> java version "1.7.0_06"
> heinz$ java ThreadLeakMac2
> time = 1, threads = 6
> time = 2, threads = 256
> time = 6, threads = 373
> *snip*
> time = 111, threads = 42592
> time = 200, threads = 49419
> time = 333, threads = 58976
> *snip*
> time = 3245, threads = 202336
> time = 3706, threads = 203702
> *snip*
> time = 5835, threads = 267872
> time = 6455, threads = 269238
> time = 9170, threads = 270603
>
> In my code, I make sure that the thread has stopped before creating the
> next one by calling join().
>
> public class ThreadLeakMac2 {
>     public static void main(String[] args) throws InterruptedException {
>         long threads = 0;
>         long max = 0;
>         while(true) {
>             long time = System.currentTimeMillis();
>             Thread thread = new Thread();
>             thread.start(); // should finish almost immediately
>             time = System.currentTimeMillis() - time;
>             thread.join(); // short delay, hopefully
>             threads++;
>             if (time>  max) {
>                 max = time;
>                 System.out.println("time = " + time +
>                                    ", threads = " + threads);
>             }
>         }
>     }
> }
>
> This would be another nice test case for Alexey's concurrency stress
> test harness.
>
> (I also posted this to the concurrency-interest list.)
>
> Regards
>
> Heinz

From mik3hall at gmail.com  Tue Apr 16 19:33:44 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 16 Apr 2013 21:33:44 -0500
Subject: Latency in starting threads on Mac OS X
In-Reply-To: <555903BF-7538-4154-A3A8-349487564EDE@gmail.com>
References: <516D4AA2.9020701@javaspecialists.eu>
	<555903BF-7538-4154-A3A8-349487564EDE@gmail.com>
Message-ID: <9FF13C35-3D81-4591-9CE8-13951524B04B@gmail.com>

On Apr 16, 2013, at 6:41 PM, Scott Palmer wrote:

> I doubt you are measuring what you think you are measuring. Maybe try the same while printing the GC details.
> -XX:+PrintGCDetails

GC does seem to make a difference. 
Strange that would be platform specific.
Running the test as is I ended up with?.
time = 6437, threads = 65103

Turning on the hotspot instrumentation seemed like it would have possible performance implications itself so instead I added periodic System.gc calls.
Which again, seemed to make a difference. I decided to eliminate most of the println's and just print the time result when threads topped 100k. Make showing a number of results more mailing list friendly.

Sort of interesting running this version with no additional gc now got?
java ThreadLeakMac2
time = 3592, join time 0, threads = 100795
a considerable improvement. Which almost makes you think all the String println's might of been dragging the original? So of strange they'd matter that much.

Other results with gc requested every 50 threads
Mac-User:~ mjh$ java ThreadLeakMac2 50
time = 3601, join time 0, threads = 100794

every 100 threads?
Mac-User:~ mjh$ java ThreadLeakMac2 100
time = 2278, join time 0, threads = 106937

every 150 threads?
Mac-User:~ mjh$ java ThreadLeakMac2 150
time = 3946, join time 0, threads = 100795

So there seems to be a significantly improved, optimal value, somewhere in the neighborhood of requested gc every 100 threads.
Undoubtedly, ymmv

My version?
public class ThreadLeakMac2 {
  public static void main(String[] args) throws InterruptedException {
      long threads = 0;
      long max = 0;
      boolean gc = false;
      int GC_MOD = 0; 
      if (args.length > 0) {
          gc = true;
	      GC_MOD = new Integer(args[0]).intValue(); 
	  }
      while(true) {
          long time = System.currentTimeMillis();
          Thread thread = new Thread();
          thread.start(); // should finish almost immediately
          time = System.currentTimeMillis() - time;
          long jtime = System.currentTimeMillis();
          thread.join(); // short delay, hopefully
          jtime = System.currentTimeMillis() - jtime;
          threads++;
          if (gc && threads % GC_MOD == 0) System.gc();
          if (time > max) {
              max = time;
              if (threads > 100000) {
              	System.out.println("time = " + time + ", join time " + jtime + 
                	                 ", threads = " + threads);
              	break;
              }
          }
      }
  }
}

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter




From heinz at javaspecialists.eu  Tue Apr 16 22:03:55 2013
From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz)
Date: Wed, 17 Apr 2013 08:03:55 +0300
Subject: Fwd: Latency in starting threads on Mac OS X
In-Reply-To: <516DFA8D.4070808@oracle.com>
References: <516D4AA2.9020701@javaspecialists.eu>
	<516D81BB.3090806@oracle.com> <516DFA8D.4070808@oracle.com>
Message-ID: <516E2D3B.2000507@javaspecialists.eu>

"I know 7u6 was the first version of JDK to fully support OS X."

I think that's the key to the puzzle, David!  It is definitely an OS X 
issue.  I didn't see this happen on any other platform.

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz 



David Holmes wrote:
> As I've pointed out to Heinz on the concurrency-interest list there 
> are a couple of flawed assumptions in his test:
>
> a) when you start() a new thread the OS scheduler may switch to it 
> immediately (this depends on the scheduler semantics)
>
> b) Thread.join only signifies logical termination of the Java thread. 
> The native thread still has to exit the VM and the OS and so can 
> encounter additional bottlenecks that result in many more threads 
> being existent than expected and which can interfere with the creation 
> of new threads.
>
> I don't know specifically what may have changed between 7u5 and 7u6 in 
> that regard but I think it would be a hotspot issue more than a 
> libraries issue. I know 7u6 was the first version of JDK to fully 
> support OS X.
>
> David
>
> On 17/04/2013 2:52 AM, Kurchi Subhra Hazra wrote:
>> Forwarding to core-libs.
>>
>> - Kurchi
>>
>> -------- Original Message --------
>> Subject:     Latency in starting threads on Mac OS X
>> Date:     Tue, 16 Apr 2013 15:57:06 +0300
>> From:     Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
>> Organization:     JavaSpecialists.eu
>> To:     macosx-port-dev at openjdk.java.net
>>
>>
>>
>> Good day my fellow Mac OS X users!
>>
>> Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to
>> demonstrate to my class how slow it was starting threads and how much
>> better it is to use a FixedThreadPool.  The question that I wanted to
>> answer was: How many microseconds does it take on average to start a
>> simple thread and what is the maximum time it could take?
>>
>> We all know that it can take in the milliseconds range to do the 
>> following:
>>
>> Thread t = new Thread(); // even without it actually doing anything
>> t.start();
>>
>> This is one of the reasons why the fixed thread pool only starts the
>> threads as we submit jobs to it, since the up-front cost might not be
>> worth the wait.
>>
>> But how long do you think the *maximum* was that I had to wait for
>> t.start() to return?  100ms?  200ms?
>>
>> Actually, the longest I had to wait turned out to be about 250 seconds.
>> Yes.  That is *seconds*, not *milliseconds*.  Just to start a single
>> thread.
>>
>> This is most certainly a bug in the OpenJDK on Mac OS X.  We did not see
>> this behaviour on Linux nor on Windows 7.
>>
>> The bug started in OpenJDK 1.7.0_06.  Prior to that it hardly ever took
>> longer than 30ms to start a single thread.
>>
>> java version "1.7.0_05"
>> heinz$ java ThreadLeakMac2
>> time = 1, threads = 4
>> time = 2, threads = 346
>> time = 4, threads = 7378
>> time = 7, threads = 9614
>> time = 12, threads = 10027
>> time = 14, threads = 10063
>> time = 17, threads = 26965
>> time = 38, threads = 27013
>> time = 39, threads = 452053
>>
>> java version "1.7.0_06"
>> heinz$ java ThreadLeakMac2
>> time = 1, threads = 6
>> time = 2, threads = 256
>> time = 6, threads = 373
>> *snip*
>> time = 111, threads = 42592
>> time = 200, threads = 49419
>> time = 333, threads = 58976
>> *snip*
>> time = 3245, threads = 202336
>> time = 3706, threads = 203702
>> *snip*
>> time = 5835, threads = 267872
>> time = 6455, threads = 269238
>> time = 9170, threads = 270603
>>
>> In my code, I make sure that the thread has stopped before creating the
>> next one by calling join().
>>
>> public class ThreadLeakMac2 {
>>     public static void main(String[] args) throws InterruptedException {
>>         long threads = 0;
>>         long max = 0;
>>         while(true) {
>>             long time = System.currentTimeMillis();
>>             Thread thread = new Thread();
>>             thread.start(); // should finish almost immediately
>>             time = System.currentTimeMillis() - time;
>>             thread.join(); // short delay, hopefully
>>             threads++;
>>             if (time>  max) {
>>                 max = time;
>>                 System.out.println("time = " + time +
>>                                    ", threads = " + threads);
>>             }
>>         }
>>     }
>> }
>>
>> This would be another nice test case for Alexey's concurrency stress
>> test harness.
>>
>> (I also posted this to the concurrency-interest list.)
>>
>> Regards
>>
>> Heinz
>

From Alan.Bateman at oracle.com  Wed Apr 17 02:05:13 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Apr 2013 10:05:13 +0100
Subject: Fwd: Latency in starting threads on Mac OS X
In-Reply-To: <516DFA8D.4070808@oracle.com>
References: <516D4AA2.9020701@javaspecialists.eu>
	<516D81BB.3090806@oracle.com> <516DFA8D.4070808@oracle.com>
Message-ID: <516E65C9.7020205@oracle.com>

On 17/04/2013 02:27, David Holmes wrote:
> :
>
> I don't know specifically what may have changed between 7u5 and 7u6 in 
> that regard but I think it would be a hotspot issue more than a 
> libraries issue. I know 7u6 was the first version of JDK to fully 
> support OS X.
The Mac support went into 7u4 but Oracle builds didn't have all the 
(closed) deployment features until 7u6. Aside from the issues  that you 
pointed out, it probably needs someone to look at it more closely to 
narrow this down a bit.

-Alan

From Sergey.Bylokhov at oracle.com  Wed Apr 17 02:42:36 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 17 Apr 2013 13:42:36 +0400
Subject: [8] Request for review: 8009012 [macosx] DisplayChangedListener is
	not implemented in LWWindowPeer/CGraphicsEnvironment
Message-ID: <516E6E8C.9020506@oracle.com>

Hello,
Please review the fix for jdk 8.
displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note 
that I move out unnecessary calls to the appkit thread(in 
CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can cause 
a deadlock, when called from the non-appkit thread.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
Webrev can be found at: http://cr.openjdk.java.net/~serb/8009012/webrev.00

-- 
Best regards, Sergey.


From roger.toenz at abacus.ch  Wed Apr 17 06:40:02 2013
From: roger.toenz at abacus.ch (=?iso-8859-1?Q?Roger_T=F6nz?=)
Date: Wed, 17 Apr 2013 15:40:02 +0200
Subject: osx, java7 screen menu empty after frame.dispose
In-Reply-To: <516DC198.1000207@oracle.com>
References: <353D880645CCDC429732D7A445F7F5BF462A0D64@exmb-00-ah.ad.mathworks.com>
	<516DC198.1000207@oracle.com>
Message-ID: <F2F2C369-979D-44A4-917B-FDFF80D2EF72@abacus.ch>

hi

i've got a little Problem with the ScreenMenu

I've several Windows with their own JMenuBar.

When one of the Frames is closed with the DISPOSE_ON_CLOSE behavior, the apple-screenmenu is empty.

Below a little Example.

Roger

Mac OS X 10.8, Java 1.7u17




import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JFrame;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
import javax.swing.JTextArea;
import javax.swing.WindowConstants;

public class SwingFrameTest extends JFrame {

  static int counter = 0;


  public static void main(String[] args) {
    System.setProperty("apple.laf.useScreenMenuBar", "true");
    
    SwingFrameTest frameTest = new SwingFrameTest();
    frameTest.setTitle( "MainWindow");
    JTextArea text = new JTextArea();
    text.setText("Open two Window with the Menu=>Windows=>new\n and then close one. \nNow the Menu is empty");
    frameTest.getContentPane().add(text);
    initMenuBar(frameTest);
    frameTest.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frameTest.setVisible(true);
  }

  static void initMenuBar(final JFrame frame){
    frame.setSize(400, 400);
    frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
    JMenuBar bar = new JMenuBar();
    bar.add(new JMenu(frame.getTitle()));
    
    if(frame instanceof SwingFrameTest){
      JMenu datei = new JMenu("Windows");
      bar.add(datei);
      JMenuItem item = new JMenuItem("new");
      datei.add(item);
      item.addActionListener(new ActionListener(){

        @Override
        public void actionPerformed(ActionEvent e) {
          JFrame newFrame = new JFrame("Frame"+counter++);
          initMenuBar(newFrame);
          newFrame.setVisible(true);
        }});
    }

    frame.setJMenuBar(bar);
  }


}


From Sergey.Bylokhov at oracle.com  Wed Apr 17 07:29:30 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 17 Apr 2013 18:29:30 +0400
Subject: osx, java7 screen menu empty after frame.dispose
In-Reply-To: <F2F2C369-979D-44A4-917B-FDFF80D2EF72@abacus.ch>
References: <353D880645CCDC429732D7A445F7F5BF462A0D64@exmb-00-ah.ad.mathworks.com>
	<516DC198.1000207@oracle.com>
	<F2F2C369-979D-44A4-917B-FDFF80D2EF72@abacus.ch>
Message-ID: <516EB1CA.5030502@oracle.com>

HI,Roger.
Looks like this is a known issue.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006
Fixed in jdk 8 and jdk7uX.

On 4/17/13 5:40 PM, Roger T?nz wrote:
> hi
>
> i've got a little Problem with the ScreenMenu
>
> I've several Windows with their own JMenuBar.
>
> When one of the Frames is closed with the DISPOSE_ON_CLOSE behavior, the apple-screenmenu is empty.
>
> Below a little Example.
>
> Roger
>
> Mac OS X 10.8, Java 1.7u17
>
>
>
>
> import java.awt.event.ActionEvent;
> import java.awt.event.ActionListener;
> import javax.swing.JFrame;
> import javax.swing.JMenu;
> import javax.swing.JMenuBar;
> import javax.swing.JMenuItem;
> import javax.swing.JTextArea;
> import javax.swing.WindowConstants;
>
> public class SwingFrameTest extends JFrame {
>
>    static int counter = 0;
>
>
>    public static void main(String[] args) {
>      System.setProperty("apple.laf.useScreenMenuBar", "true");
>      
>      SwingFrameTest frameTest = new SwingFrameTest();
>      frameTest.setTitle( "MainWindow");
>      JTextArea text = new JTextArea();
>      text.setText("Open two Window with the Menu=>Windows=>new\n and then close one. \nNow the Menu is empty");
>      frameTest.getContentPane().add(text);
>      initMenuBar(frameTest);
>      frameTest.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>      frameTest.setVisible(true);
>    }
>
>    static void initMenuBar(final JFrame frame){
>      frame.setSize(400, 400);
>      frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>      JMenuBar bar = new JMenuBar();
>      bar.add(new JMenu(frame.getTitle()));
>      
>      if(frame instanceof SwingFrameTest){
>        JMenu datei = new JMenu("Windows");
>        bar.add(datei);
>        JMenuItem item = new JMenuItem("new");
>        datei.add(item);
>        item.addActionListener(new ActionListener(){
>
>          @Override
>          public void actionPerformed(ActionEvent e) {
>            JFrame newFrame = new JFrame("Frame"+counter++);
>            initMenuBar(newFrame);
>            newFrame.setVisible(true);
>          }});
>      }
>
>      frame.setJMenuBar(bar);
>    }
>
>
> }
>


-- 
Best regards, Sergey.


From roger.toenz at abacus.ch  Wed Apr 17 07:50:39 2013
From: roger.toenz at abacus.ch (=?iso-8859-1?Q?Roger_T=F6nz?=)
Date: Wed, 17 Apr 2013 16:50:39 +0200
Subject: osx, java7 screen menu empty after frame.dispose
In-Reply-To: <516EB1CA.5030502@oracle.com>
References: <353D880645CCDC429732D7A445F7F5BF462A0D64@exmb-00-ah.ad.mathworks.com>
	<516DC198.1000207@oracle.com>
	<F2F2C369-979D-44A4-917B-FDFF80D2EF72@abacus.ch>
	<516EB1CA.5030502@oracle.com>
Message-ID: <28FA47FD-9A3A-4510-B401-4F730DC5F53C@abacus.ch>

yep, that's it
thx

regards
Roger


Am 17.04.2013 um 16:29 schrieb Sergey Bylokhov <sergey.bylokhov at oracle.com>:

> HI,Roger.
> Looks like this is a known issue.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006
> Fixed in jdk 8 and jdk7uX.
> 
> -- 
> Best regards, Sergey.
> 

From roger.toenz at abacus.ch  Wed Apr 17 08:35:03 2013
From: roger.toenz at abacus.ch (=?iso-8859-1?Q?Roger_T=F6nz?=)
Date: Wed, 17 Apr 2013 17:35:03 +0200
Subject: osx, java7 screen menu empty after frame.dispose
In-Reply-To: <28FA47FD-9A3A-4510-B401-4F730DC5F53C@abacus.ch>
References: <353D880645CCDC429732D7A445F7F5BF462A0D64@exmb-00-ah.ad.mathworks.com>
	<516DC198.1000207@oracle.com>
	<F2F2C369-979D-44A4-917B-FDFF80D2EF72@abacus.ch>
	<516EB1CA.5030502@oracle.com>
	<28FA47FD-9A3A-4510-B401-4F730DC5F53C@abacus.ch>
Message-ID: <3E70DD62-049B-4436-9761-AB312D4F27E8@abacus.ch>

Hi Sergey

Maybe you're interested in my Workaround for the Moment.
In all my Frames i'm overriding the dispose Method.


public void dispose(){
          super.dispose();

          SwingUtilities.invokeLater(new Runnable(){
            @Override
            public void run() {
              for(Window window:Window.getWindows()){
                if(window.isActive()&&window instanceof JFrame){
                  JFrame activeFrame = (JFrame)window;
                  JMenuBar menuBar = activeFrame.getJMenuBar();
                  if(menuBar!=null){
                    activeFrame.setJMenuBar(new JMenuBar());
                    activeFrame.setJMenuBar(menuBar);
                  }
                }
              }
            }});
 }



regards
Roger


Am 17.04.2013 um 16:50 schrieb Roger T?nz <roger.toenz at abacus.ch>:

> yep, that's it
> thx
> 
> regards
> Roger
> 
> 
> Am 17.04.2013 um 16:29 schrieb Sergey Bylokhov <sergey.bylokhov at oracle.com>:
> 
>> HI,Roger.
>> Looks like this is a known issue.
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006
>> Fixed in jdk 8 and jdk7uX.
>> 
>> -- 
>> Best regards, Sergey.
>> 


From superstippi at gmx.de  Wed Apr 17 10:52:49 2013
From: superstippi at gmx.de (=?windows-1252?Q?Stephan_A=DFmus?=)
Date: Wed, 17 Apr 2013 19:52:49 +0200
Subject: Showstopper-bugs, bug-database not searchable
Message-ID: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>

Hi,

when entering any search-terms in this page...

http://bugs.sun.com/

?I never get any results back. For example, entering "thread" or "scroll" into "keywords" turns up empty for me, which I cannot quite believe.

Anyway, I have filed several bugs against the Mac OS X port, some of which are show stoppers for me. I have also posted to the developer forums of Apple. Maybe I can get some helpful advice here as well.

My application uses SWT 4.2.1 and no Swing or AWT at all. None of the bugs I am going to describe below exist when running my app in Apple's Java SE 6.

Here goes:

 * No splash screen support when embedding the JRE into an Application Bundle. Unfortunate, but no big deal.

 * Native scroll bars auto-hide, only in my app. The system setting is to show scrollbars when a mouse is attached (which there is), and all other apps show scrollbars. Scrollbars stay visible in my app if the system setting is put on "Always". Very unfortunate, but at least there is a work-around.

 * Native file panels (open and save) hang while trying to populate folder contents. The file panel can be navigated and dismissed, just the folder-contents fail to display. The progress indicator keeps spinning. A blocker for me.

 * Trying to create *new* files *sometimes* fails with a FileNotFoundException. Again, a blocker. Shouldn't have anything to do with SWT at all. Supposedly this was fixed in JDK 7u17, but it still happens for me in 7u21.

 * Clicking the full-screen mode icon in native OS X windows hangs. Trying to see where it hangs in the debugger (I am using Eclipse), it appears the main thread is actually running, not blocking, in the main event loop. But the window is locked up and blocks other windows from coming to the front. Full-screen mode is not entered. The application can be force-killed. A work-around would be to disable the full-screen icon in all windows. But again, this works just fine when running inside the Apple Java SE 6 JVM.

Is any of this known to anyone? I have not received any notifications on the bugs I filed, and I have provided sample code to demonstrate each bug. Since the respective snippets are small and reproduce these bugs, I should be ruling out anything weird going on specifically in my larger app, right?

The Apple employee which replied in the forums suggested at least some of this stuff may actually be SWT bugs since there may be some specific tests somewhere in the code for the JVM version and those fail with the new Oracle JVM. It's worth exploring, but I doubt this to be the case.

It is worth noting that I am not seeing these bugs in Eclipse itself. But I have the Apple Java SE 6 still installed and I assume that Eclipse uses that. But I have not yet confirmed that assumption.

Thanks for any helpful hints!

Best regards,
-Stephan


From petr.pchelko at oracle.com  Wed Apr 17 12:31:38 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 17 Apr 2013 23:31:38 +0400
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
Message-ID: <69EDADD8-EEDD-4E29-99E7-B8E5C4C93C74@oracle.com>

Hello, Stephan.

Here is one of the issues you've described:
http://bugs.sun.com/view_bug.do?bug_id=8009911

It might also be related to the following issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886

I am not aware about the rest. However they might be related with the following issue:
http://bugs.sun.com/view_bug.do?bug_id=8011686
This issue will be fixed very soon. But you can verify if it is the cause of any of our problem right now by creating the test case which does not use any AWT/Swing classes, so that AWT doesn't load.

With best regards. Petr.

17.04.2013, ? 21:52, Stephan A?mus <superstippi at gmx.de> ???????(?):

> Hi,
> 
> when entering any search-terms in this page...
> 
> http://bugs.sun.com/
> 
> ?I never get any results back. For example, entering "thread" or "scroll" into "keywords" turns up empty for me, which I cannot quite believe.
> 
> Anyway, I have filed several bugs against the Mac OS X port, some of which are show stoppers for me. I have also posted to the developer forums of Apple. Maybe I can get some helpful advice here as well.
> 
> My application uses SWT 4.2.1 and no Swing or AWT at all. None of the bugs I am going to describe below exist when running my app in Apple's Java SE 6.
> 
> Here goes:
> 
> * No splash screen support when embedding the JRE into an Application Bundle. Unfortunate, but no big deal.
> 
> * Native scroll bars auto-hide, only in my app. The system setting is to show scrollbars when a mouse is attached (which there is), and all other apps show scrollbars. Scrollbars stay visible in my app if the system setting is put on "Always". Very unfortunate, but at least there is a work-around.
> 
> * Native file panels (open and save) hang while trying to populate folder contents. The file panel can be navigated and dismissed, just the folder-contents fail to display. The progress indicator keeps spinning. A blocker for me.
> 
> * Trying to create *new* files *sometimes* fails with a FileNotFoundException. Again, a blocker. Shouldn't have anything to do with SWT at all. Supposedly this was fixed in JDK 7u17, but it still happens for me in 7u21.
> 
> * Clicking the full-screen mode icon in native OS X windows hangs. Trying to see where it hangs in the debugger (I am using Eclipse), it appears the main thread is actually running, not blocking, in the main event loop. But the window is locked up and blocks other windows from coming to the front. Full-screen mode is not entered. The application can be force-killed. A work-around would be to disable the full-screen icon in all windows. But again, this works just fine when running inside the Apple Java SE 6 JVM.
> 
> Is any of this known to anyone? I have not received any notifications on the bugs I filed, and I have provided sample code to demonstrate each bug. Since the respective snippets are small and reproduce these bugs, I should be ruling out anything weird going on specifically in my larger app, right?
> 
> The Apple employee which replied in the forums suggested at least some of this stuff may actually be SWT bugs since there may be some specific tests somewhere in the code for the JVM version and those fail with the new Oracle JVM. It's worth exploring, but I doubt this to be the case.
> 
> It is worth noting that I am not seeing these bugs in Eclipse itself. But I have the Apple Java SE 6 still installed and I assume that Eclipse uses that. But I have not yet confirmed that assumption.
> 
> Thanks for any helpful hints!
> 
> Best regards,
> -Stephan
> 


From Alan.Bateman at oracle.com  Wed Apr 17 12:49:47 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Apr 2013 20:49:47 +0100
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
Message-ID: <516EFCDB.5060903@oracle.com>

On 17/04/2013 18:52, Stephan A?mus wrote:
> :
>
>   * Trying to create *new* files *sometimes* fails with a FileNotFoundException. Again, a blocker. Shouldn't have anything to do with SWT at all. Supposedly this was fixed in JDK 7u17, but it still happens for me in 7u21.
>
Can you expand on this? If creating files was failing intermittently 
then I would expect a lot of bug reports. Maybe your issue is encoding 
related, in which case it would be interesting to know if you see this 
in jdk8 which has a number of changes in this area.

-Alan.

From dan.xu at oracle.com  Wed Apr 17 16:47:09 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 17 Apr 2013 16:47:09 -0700
Subject: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc
Message-ID: <516F347D.5030108@oracle.com>

Hi,

As for the sourcecodes for mac platform, it has a special place holding 
native and java codes for jdk, jdk/src/macosx/native/jobjc. I wonder how 
those codes are builtand whether its compilation process has any special 
handling. Thanks!

-Dan

From dan.xu at oracle.com  Wed Apr 17 16:51:11 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 17 Apr 2013 16:51:11 -0700
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F347D.5030108@oracle.com>
References: <516F347D.5030108@oracle.com>
Message-ID: <516F356F.6010107@oracle.com>

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:
> Hi,
>
> As for the sourcecodes for mac platform, it has a special place 
> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I 
> wonder how those codes are builtand whether its compilation process 
> has any special handling. Thanks!
>
> -Dan


From david.holmes at oracle.com  Wed Apr 17 17:30:13 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Apr 2013 10:30:13 +1000
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F356F.6010107@oracle.com>
References: <516F347D.5030108@oracle.com> <516F356F.6010107@oracle.com>
Message-ID: <516F3E95.1050308@oracle.com>

Hi Dan,

I don't quite understand the question but all native code building is 
handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
utilizes the set up from <top>/common/makefiles/NativeCompilation.gmk

HTH

David

On 18/04/2013 9:51 AM, Dan Xu wrote:
> Adding core-libs-dev
>
> On 04/17/2013 04:47 PM, Dan Xu wrote:
>> Hi,
>>
>> As for the sourcecodes for mac platform, it has a special place
>> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
>> wonder how those codes are builtand whether its compilation process
>> has any special handling. Thanks!
>>
>> -Dan
>

From dan.xu at oracle.com  Wed Apr 17 17:50:20 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 17 Apr 2013 17:50:20 -0700
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F3E95.1050308@oracle.com>
References: <516F347D.5030108@oracle.com> <516F356F.6010107@oracle.com>
	<516F3E95.1050308@oracle.com>
Message-ID: <516F434C.4030308@oracle.com>

Hi David,

Under src/macosx/native/jobjc folder, it contains not only native *.m 
source files, but also *.java files. If you check the build results in 
build/macosx-x86_64-normal-server-release/jdk folder, it contains some 
build results specific for jobjc, say gensrc_jobjc/, 
gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.

So it must have some extra build steps to generate those jobjc results. 
And I wonder what they are and why they are special and not merged into 
the regular native compilation and java compilation processes. Thanks!

-Dan


On 04/17/2013 05:30 PM, David Holmes wrote:
> Hi Dan,
>
> I don't quite understand the question but all native code building is 
> handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
> utilizes the set up from <top>/common/makefiles/NativeCompilation.gmk
>
> HTH
>
> David
>
> On 18/04/2013 9:51 AM, Dan Xu wrote:
>> Adding core-libs-dev
>>
>> On 04/17/2013 04:47 PM, Dan Xu wrote:
>>> Hi,
>>>
>>> As for the sourcecodes for mac platform, it has a special place
>>> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
>>> wonder how those codes are builtand whether its compilation process
>>> has any special handling. Thanks!
>>>
>>> -Dan
>>


From mik3hall at gmail.com  Wed Apr 17 18:44:52 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 17 Apr 2013 20:44:52 -0500
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F434C.4030308@oracle.com>
References: <516F347D.5030108@oracle.com> <516F356F.6010107@oracle.com>
	<516F3E95.1050308@oracle.com> <516F434C.4030308@oracle.com>
Message-ID: <D7D7B737-2AD9-4C72-BDD2-731EE99EE388@gmail.com>

On Apr 17, 2013, at 7:50 PM, Dan Xu wrote:

> So it must have some extra build steps to generate those jobjc results. And I wonder what they are and why they are special and not merged into the regular native compilation and java compilation processes. Thanks!

One of the Apple people would probably be the best source for an answer on this. 
I think roughly the jobjc stuff allows for dynamic ObjectiveC bindings from java without the use of a native compiler. Apparently, it is sort of the current successor to the past Apple JDirect or Cocoa/Java native interfaces. It would be a unique OS X thing. So probably isolated in the build process for that reason. Back when I was trying to get 32 bit builds to work I was into this a little bit but don't really remember anything on how it worked.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From david.holmes at oracle.com  Wed Apr 17 19:18:14 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Apr 2013 12:18:14 +1000
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F434C.4030308@oracle.com>
References: <516F347D.5030108@oracle.com> <516F356F.6010107@oracle.com>
	<516F3E95.1050308@oracle.com> <516F434C.4030308@oracle.com>
Message-ID: <516F57E6.7020808@oracle.com>

On 18/04/2013 10:50 AM, Dan Xu wrote:
> Hi David,
>
> Under src/macosx/native/jobjc folder, it contains not only native *.m
> source files, but also *.java files. If you check the build results in
> build/macosx-x86_64-normal-server-release/jdk folder, it contains some
> build results specific for jobjc, say gensrc_jobjc/,
> gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.
>
> So it must have some extra build steps to generate those jobjc results.
> And I wonder what they are and why they are special and not merged into
> the regular native compilation and java compilation processes. Thanks!

In jdk/makefiles:

- The java files are handled in CompileJavaClasses.gmk.
- There is special handling via GensrcJObjC.gmk

David

> -Dan
>
>
> On 04/17/2013 05:30 PM, David Holmes wrote:
>> Hi Dan,
>>
>> I don't quite understand the question but all native code building is
>> handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn
>> utilizes the set up from <top>/common/makefiles/NativeCompilation.gmk
>>
>> HTH
>>
>> David
>>
>> On 18/04/2013 9:51 AM, Dan Xu wrote:
>>> Adding core-libs-dev
>>>
>>> On 04/17/2013 04:47 PM, Dan Xu wrote:
>>>> Hi,
>>>>
>>>> As for the sourcecodes for mac platform, it has a special place
>>>> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
>>>> wonder how those codes are builtand whether its compilation process
>>>> has any special handling. Thanks!
>>>>
>>>> -Dan
>>>
>

From hs at tagtraum.com  Thu Apr 18 01:33:04 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 18 Apr 2013 10:33:04 +0200
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
Message-ID: <D066ECBB-5639-4691-8BB3-70B3E5250132@tagtraum.com>

On Apr 17, 2013, at 7:52 PM, Stephan A?mus wrote:

> when entering any search-terms in this page...
> 
> http://bugs.sun.com/
> 
> ?I never get any results back. For example, entering "thread" or "scroll" into "keywords" turns up empty for me, which I cannot quite believe.

I just experienced the same thing, trying to check on progress regarding Retina support in Java8.

The database is apparently not searchable any more.
Is this a new Oracle policy (learning how not to do it from Apple) or just a system error?

Thanks,

-hendrik

From anthony.petrov at oracle.com  Thu Apr 18 06:54:17 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 18 Apr 2013 17:54:17 +0400
Subject: <AWT Dev> [8] Request for review: 8009012 [macosx]
	DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <516E6E8C.9020506@oracle.com>
References: <516E6E8C.9020506@oracle.com>
Message-ID: <516FFB09.8080300@oracle.com>

Hi Sergey,

src/macosx/native/sun/java2d/opengl/CGLLayer.m
>  214 Java_sun_java2d_opengl_CGLLayer_nativeSetScale
>  219     [ThreadUtilities performOnMainThreadWaiting:[NSThread isMainThread] block:^(){

That's an interesting pattern, but it looks more like a workaround to 
me, because the contract defined by the nativeSetScale is unclear with 
this implementation. Where do we call this method from? Can we ensure 
all calls always occur on a specific thread?

--
best regards,
Anthony

On 04/17/13 13:42, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 8.
> displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note
> that I move out unnecessary calls to the appkit thread(in
> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can cause
> a deadlock, when called from the non-appkit thread.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8009012/webrev.00
>
> --
> Best regards, Sergey.
>

From Sergey.Bylokhov at oracle.com  Thu Apr 18 07:06:35 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 Apr 2013 18:06:35 +0400
Subject: <AWT Dev> [8] Request for review: 8009012 [macosx]
	DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <516FFB09.8080300@oracle.com>
References: <516E6E8C.9020506@oracle.com> <516FFB09.8080300@oracle.com>
Message-ID: <516FFDEB.2000909@oracle.com>

Hi, Anthony.
Currently this method is called from the replaceSurfaceData, which 
usually is called on the appkit, but can be called on a other thread. So 
this change don't block other thread.
If it was called on appkit it completes synchronously, or asynchronously 
on another thread.

On 4/18/13 5:54 PM, Anthony Petrov wrote:
>  219 [ThreadUtilities performOnMainThreadWaiting:[NSThread 
> isMainThread] block:^(){
>
> That's an interesting pattern, but it looks more like a workaround to 
> me, because the contract defined by the nativeSetScale is unclear with 
> this implementation. Where do we call this method from? Can we ensure 
> all calls always occur on a specific thread?
>
> -- 
> best regards,
> Anthony
>
> On 04/17/13 13:42, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk 8.
>> displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note
>> that I move out unnecessary calls to the appkit thread(in
>> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can cause
>> a deadlock, when called from the non-appkit thread.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8009012/webrev.00
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Thu Apr 18 07:13:58 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 18 Apr 2013 18:13:58 +0400
Subject: <AWT Dev> [8] Request for review: 8009012 [macosx]
	DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <516FFDEB.2000909@oracle.com>
References: <516E6E8C.9020506@oracle.com> <516FFB09.8080300@oracle.com>
	<516FFDEB.2000909@oracle.com>
Message-ID: <516FFFA6.7020105@oracle.com>

I see. But this still looks fishy. Could you file a separate issue to 
investigate the replaceSurfaceData() calls and see if we can redispatch 
them all to the AppKit thread, thus clarifying the contract for the 
nativeSetScale as well?

The fix looks good otherwise.

--
best regards,
Anthony

On 04/18/13 18:06, Sergey Bylokhov wrote:
> Hi, Anthony.
> Currently this method is called from the replaceSurfaceData, which
> usually is called on the appkit, but can be called on a other thread. So
> this change don't block other thread.
> If it was called on appkit it completes synchronously, or asynchronously
> on another thread.
>
> On 4/18/13 5:54 PM, Anthony Petrov wrote:
>> 219 [ThreadUtilities performOnMainThreadWaiting:[NSThread
>> isMainThread] block:^(){
>>
>> That's an interesting pattern, but it looks more like a workaround to
>> me, because the contract defined by the nativeSetScale is unclear with
>> this implementation. Where do we call this method from? Can we ensure
>> all calls always occur on a specific thread?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 04/17/13 13:42, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 8.
>>> displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note
>>> that I move out unnecessary calls to the appkit thread(in
>>> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can cause
>>> a deadlock, when called from the non-appkit thread.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8009012/webrev.00
>>>
>>> --
>>> Best regards, Sergey.
>>>
>
>

From Sergey.Bylokhov at oracle.com  Thu Apr 18 07:45:30 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 Apr 2013 18:45:30 +0400
Subject: <AWT Dev> [8] Request for review: 8009012 [macosx]
	DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <516FFFA6.7020105@oracle.com>
References: <516E6E8C.9020506@oracle.com> <516FFB09.8080300@oracle.com>
	<516FFDEB.2000909@oracle.com> <516FFFA6.7020105@oracle.com>
Message-ID: <5170070A.6060206@oracle.com>

On 4/18/13 6:13 PM, Anthony Petrov wrote:
> I see. But this still looks fishy. Could you file a separate issue to 
> investigate the replaceSurfaceData() calls and see if we can 
> redispatch them all to the AppKit thread, thus clarifying the contract 
> for the nativeSetScale as well?
But this leads to the situation which I try to eliminate -  never call 
synchronously methods on a appkit, if possible.
>
> The fix looks good otherwise.
>
> -- 
> best regards,
> Anthony
>
> On 04/18/13 18:06, Sergey Bylokhov wrote:
>> Hi, Anthony.
>> Currently this method is called from the replaceSurfaceData, which
>> usually is called on the appkit, but can be called on a other thread. So
>> this change don't block other thread.
>> If it was called on appkit it completes synchronously, or asynchronously
>> on another thread.
>>
>> On 4/18/13 5:54 PM, Anthony Petrov wrote:
>>> 219 [ThreadUtilities performOnMainThreadWaiting:[NSThread
>>> isMainThread] block:^(){
>>>
>>> That's an interesting pattern, but it looks more like a workaround to
>>> me, because the contract defined by the nativeSetScale is unclear with
>>> this implementation. Where do we call this method from? Can we ensure
>>> all calls always occur on a specific thread?
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 04/17/13 13:42, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk 8.
>>>> displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note
>>>> that I move out unnecessary calls to the appkit thread(in
>>>> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can 
>>>> cause
>>>> a deadlock, when called from the non-appkit thread.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8009012/webrev.00
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Fri Apr 19 03:11:52 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 19 Apr 2013 14:11:52 +0400
Subject: <AWT Dev> [8] Request for review: 8009012 [macosx]
	DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <5170070A.6060206@oracle.com>
References: <516E6E8C.9020506@oracle.com> <516FFB09.8080300@oracle.com>
	<516FFDEB.2000909@oracle.com> <516FFFA6.7020105@oracle.com>
	<5170070A.6060206@oracle.com>
Message-ID: <51711868.7010709@oracle.com>

I understand that. However, having methods producing different immediate 
results depending on what thread they are called on doesn't seem like a 
good design. It would be best to define explicit threading semantics 
where possible.

Since this task isn't directly related to 8009012 and may require a lot 
of code refactoring actually, I suggest to file a separate issue and 
evaluate it later, perhaps in a future release.

--
best regards,
Anthony

On 04/18/2013 06:45 PM, Sergey Bylokhov wrote:
> On 4/18/13 6:13 PM, Anthony Petrov wrote:
>> I see. But this still looks fishy. Could you file a separate issue to
>> investigate the replaceSurfaceData() calls and see if we can
>> redispatch them all to the AppKit thread, thus clarifying the contract
>> for the nativeSetScale as well?
> But this leads to the situation which I try to eliminate -  never call
> synchronously methods on a appkit, if possible.
>>
>> The fix looks good otherwise.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 04/18/13 18:06, Sergey Bylokhov wrote:
>>> Hi, Anthony.
>>> Currently this method is called from the replaceSurfaceData, which
>>> usually is called on the appkit, but can be called on a other thread. So
>>> this change don't block other thread.
>>> If it was called on appkit it completes synchronously, or asynchronously
>>> on another thread.
>>>
>>> On 4/18/13 5:54 PM, Anthony Petrov wrote:
>>>> 219 [ThreadUtilities performOnMainThreadWaiting:[NSThread
>>>> isMainThread] block:^(){
>>>>
>>>> That's an interesting pattern, but it looks more like a workaround to
>>>> me, because the contract defined by the nativeSetScale is unclear with
>>>> this implementation. Where do we call this method from? Can we ensure
>>>> all calls always occur on a specific thread?
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 04/17/13 13:42, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note
>>>>> that I move out unnecessary calls to the appkit thread(in
>>>>> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can
>>>>> cause
>>>>> a deadlock, when called from the non-appkit thread.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8009012/webrev.00
>>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>>
>>>
>>>
>
>

From Sergey.Bylokhov at oracle.com  Fri Apr 19 03:26:49 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 19 Apr 2013 14:26:49 +0400
Subject: <AWT Dev> [8] Request for review: 8009012 [macosx]
	DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <51711868.7010709@oracle.com>
References: <516E6E8C.9020506@oracle.com> <516FFB09.8080300@oracle.com>
	<516FFDEB.2000909@oracle.com> <516FFFA6.7020105@oracle.com>
	<5170070A.6060206@oracle.com> <51711868.7010709@oracle.com>
Message-ID: <51711BE9.70207@oracle.com>

On 4/19/13 2:11 PM, Anthony Petrov wrote:
> I understand that. However, having methods producing different 
> immediate results depending on what thread they are called on doesn't 
> seem like a good design. It would be best to define explicit threading 
> semantics where possible.
We already have it. We always call all setXX methods asynchronously, 
exception is only in this method where I need to change native texture 
size and layer's scale in one call on appkit, otherwise I'll get 
window's contents blinking, during screen-2-screen moving.
>
> Since this task isn't directly related to 8009012 and may require a 
> lot of code refactoring actually, I suggest to file a separate issue 
> and evaluate it later, perhaps in a future release.
>
> -- 
> best regards,
> Anthony
>
> On 04/18/2013 06:45 PM, Sergey Bylokhov wrote:
>> On 4/18/13 6:13 PM, Anthony Petrov wrote:
>>> I see. But this still looks fishy. Could you file a separate issue to
>>> investigate the replaceSurfaceData() calls and see if we can
>>> redispatch them all to the AppKit thread, thus clarifying the contract
>>> for the nativeSetScale as well?
>> But this leads to the situation which I try to eliminate - never call
>> synchronously methods on a appkit, if possible.
>>>
>>> The fix looks good otherwise.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 04/18/13 18:06, Sergey Bylokhov wrote:
>>>> Hi, Anthony.
>>>> Currently this method is called from the replaceSurfaceData, which
>>>> usually is called on the appkit, but can be called on a other 
>>>> thread. So
>>>> this change don't block other thread.
>>>> If it was called on appkit it completes synchronously, or 
>>>> asynchronously
>>>> on another thread.
>>>>
>>>> On 4/18/13 5:54 PM, Anthony Petrov wrote:
>>>>> 219 [ThreadUtilities performOnMainThreadWaiting:[NSThread
>>>>> isMainThread] block:^(){
>>>>>
>>>>> That's an interesting pattern, but it looks more like a workaround to
>>>>> me, because the contract defined by the nativeSetScale is unclear 
>>>>> with
>>>>> this implementation. Where do we call this method from? Can we ensure
>>>>> all calls always occur on a specific thread?
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 04/17/13 13:42, Sergey Bylokhov wrote:
>>>>>> Hello,
>>>>>> Please review the fix for jdk 8.
>>>>>> displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note
>>>>>> that I move out unnecessary calls to the appkit thread(in
>>>>>> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can
>>>>>> cause
>>>>>> a deadlock, when called from the non-appkit thread.
>>>>>>
>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/8009012/webrev.00
>>>>>>
>>>>>> -- 
>>>>>> Best regards, Sergey.
>>>>>>
>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Fri Apr 19 03:39:01 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 19 Apr 2013 14:39:01 +0400
Subject: <AWT Dev> [8] Request for review: 8009012 [macosx]
	DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <51711BE9.70207@oracle.com>
References: <516E6E8C.9020506@oracle.com> <516FFB09.8080300@oracle.com>
	<516FFDEB.2000909@oracle.com> <516FFFA6.7020105@oracle.com>
	<5170070A.6060206@oracle.com> <51711868.7010709@oracle.com>
	<51711BE9.70207@oracle.com>
Message-ID: <51711EC5.7060502@oracle.com>

Thanks for the explanation. Finally I understand why you need to use 
this pattern.

Since this is an exceptional use, could you please add comments (just 
above the "performOnMainThreadWaiting:[NSThread
isMainThread]" lines) to indicate why we do it this way? This would 
resolve my concern.

--
best regards,
Anthony

On 04/19/2013 02:26 PM, Sergey Bylokhov wrote:
> On 4/19/13 2:11 PM, Anthony Petrov wrote:
>> I understand that. However, having methods producing different
>> immediate results depending on what thread they are called on doesn't
>> seem like a good design. It would be best to define explicit threading
>> semantics where possible.
> We already have it. We always call all setXX methods asynchronously,
> exception is only in this method where I need to change native texture
> size and layer's scale in one call on appkit, otherwise I'll get
> window's contents blinking, during screen-2-screen moving.
>>
>> Since this task isn't directly related to 8009012 and may require a
>> lot of code refactoring actually, I suggest to file a separate issue
>> and evaluate it later, perhaps in a future release.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 04/18/2013 06:45 PM, Sergey Bylokhov wrote:
>>> On 4/18/13 6:13 PM, Anthony Petrov wrote:
>>>> I see. But this still looks fishy. Could you file a separate issue to
>>>> investigate the replaceSurfaceData() calls and see if we can
>>>> redispatch them all to the AppKit thread, thus clarifying the contract
>>>> for the nativeSetScale as well?
>>> But this leads to the situation which I try to eliminate - never call
>>> synchronously methods on a appkit, if possible.
>>>>
>>>> The fix looks good otherwise.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 04/18/13 18:06, Sergey Bylokhov wrote:
>>>>> Hi, Anthony.
>>>>> Currently this method is called from the replaceSurfaceData, which
>>>>> usually is called on the appkit, but can be called on a other
>>>>> thread. So
>>>>> this change don't block other thread.
>>>>> If it was called on appkit it completes synchronously, or
>>>>> asynchronously
>>>>> on another thread.
>>>>>
>>>>> On 4/18/13 5:54 PM, Anthony Petrov wrote:
>>>>>> 219 [ThreadUtilities performOnMainThreadWaiting:[NSThread
>>>>>> isMainThread] block:^(){
>>>>>>
>>>>>> That's an interesting pattern, but it looks more like a workaround to
>>>>>> me, because the contract defined by the nativeSetScale is unclear
>>>>>> with
>>>>>> this implementation. Where do we call this method from? Can we ensure
>>>>>> all calls always occur on a specific thread?
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 04/17/13 13:42, Sergey Bylokhov wrote:
>>>>>>> Hello,
>>>>>>> Please review the fix for jdk 8.
>>>>>>> displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note
>>>>>>> that I move out unnecessary calls to the appkit thread(in
>>>>>>> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can
>>>>>>> cause
>>>>>>> a deadlock, when called from the non-appkit thread.
>>>>>>>
>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
>>>>>>> Webrev can be found at:
>>>>>>> http://cr.openjdk.java.net/~serb/8009012/webrev.00
>>>>>>>
>>>>>>> --
>>>>>>> Best regards, Sergey.
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

From Sergey.Bylokhov at oracle.com  Fri Apr 19 03:49:55 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 19 Apr 2013 14:49:55 +0400
Subject: <AWT Dev> [8] Request for review: 8009012 [macosx]
	DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <51711EC5.7060502@oracle.com>
References: <516E6E8C.9020506@oracle.com> <516FFB09.8080300@oracle.com>
	<516FFDEB.2000909@oracle.com> <516FFFA6.7020105@oracle.com>
	<5170070A.6060206@oracle.com> <51711868.7010709@oracle.com>
	<51711BE9.70207@oracle.com> <51711EC5.7060502@oracle.com>
Message-ID: <51712153.3030800@oracle.com>

Thanks for review. I'll add additional comment.

On 4/19/13 2:39 PM, Anthony Petrov wrote:
> Thanks for the explanation. Finally I understand why you need to use 
> this pattern.
>
> Since this is an exceptional use, could you please add comments (just 
> above the "performOnMainThreadWaiting:[NSThread
> isMainThread]" lines) to indicate why we do it this way? This would 
> resolve my concern.
>
> -- 
> best regards,
> Anthony
>
> On 04/19/2013 02:26 PM, Sergey Bylokhov wrote:
>> On 4/19/13 2:11 PM, Anthony Petrov wrote:
>>> I understand that. However, having methods producing different
>>> immediate results depending on what thread they are called on doesn't
>>> seem like a good design. It would be best to define explicit threading
>>> semantics where possible.
>> We already have it. We always call all setXX methods asynchronously,
>> exception is only in this method where I need to change native texture
>> size and layer's scale in one call on appkit, otherwise I'll get
>> window's contents blinking, during screen-2-screen moving.
>>>
>>> Since this task isn't directly related to 8009012 and may require a
>>> lot of code refactoring actually, I suggest to file a separate issue
>>> and evaluate it later, perhaps in a future release.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 04/18/2013 06:45 PM, Sergey Bylokhov wrote:
>>>> On 4/18/13 6:13 PM, Anthony Petrov wrote:
>>>>> I see. But this still looks fishy. Could you file a separate issue to
>>>>> investigate the replaceSurfaceData() calls and see if we can
>>>>> redispatch them all to the AppKit thread, thus clarifying the 
>>>>> contract
>>>>> for the nativeSetScale as well?
>>>> But this leads to the situation which I try to eliminate - never call
>>>> synchronously methods on a appkit, if possible.
>>>>>
>>>>> The fix looks good otherwise.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 04/18/13 18:06, Sergey Bylokhov wrote:
>>>>>> Hi, Anthony.
>>>>>> Currently this method is called from the replaceSurfaceData, which
>>>>>> usually is called on the appkit, but can be called on a other
>>>>>> thread. So
>>>>>> this change don't block other thread.
>>>>>> If it was called on appkit it completes synchronously, or
>>>>>> asynchronously
>>>>>> on another thread.
>>>>>>
>>>>>> On 4/18/13 5:54 PM, Anthony Petrov wrote:
>>>>>>> 219 [ThreadUtilities performOnMainThreadWaiting:[NSThread
>>>>>>> isMainThread] block:^(){
>>>>>>>
>>>>>>> That's an interesting pattern, but it looks more like a 
>>>>>>> workaround to
>>>>>>> me, because the contract defined by the nativeSetScale is unclear
>>>>>>> with
>>>>>>> this implementation. Where do we call this method from? Can we 
>>>>>>> ensure
>>>>>>> all calls always occur on a specific thread?
>>>>>>>
>>>>>>> -- 
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 04/17/13 13:42, Sergey Bylokhov wrote:
>>>>>>>> Hello,
>>>>>>>> Please review the fix for jdk 8.
>>>>>>>> displayChanged() was added to LWWindowPeer and CGraphicsDevice. 
>>>>>>>> Note
>>>>>>>> that I move out unnecessary calls to the appkit thread(in
>>>>>>>> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can
>>>>>>>> cause
>>>>>>>> a deadlock, when called from the non-appkit thread.
>>>>>>>>
>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
>>>>>>>> Webrev can be found at:
>>>>>>>> http://cr.openjdk.java.net/~serb/8009012/webrev.00
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Best regards, Sergey.
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>


-- 
Best regards, Sergey.


From hs at tagtraum.com  Mon Apr 22 00:47:23 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 22 Apr 2013 09:47:23 +0200
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <D066ECBB-5639-4691-8BB3-70B3E5250132@tagtraum.com>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
	<D066ECBB-5639-4691-8BB3-70B3E5250132@tagtraum.com>
Message-ID: <2DA30A13-A901-45DC-A3B9-B39F3E0E0BA8@tagtraum.com>

On Apr 18, 2013, at 10:33 AM, Hendrik Schreiber wrote:

>> ?I never get any results back. For example, entering "thread" or "scroll" into "keywords" turns up empty for me, which I cannot quite believe.
> 
> I just experienced the same thing, trying to check on progress regarding Retina support in Java8.
> 
> The database is apparently not searchable any more.
> Is this a new Oracle policy (learning how not to do it from Apple) or just a system error?

Seriously - what's the state of the Java bug database?
Not public anymore?

-hendrik

From Alan.Bateman at oracle.com  Mon Apr 22 02:19:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Apr 2013 10:19:56 +0100
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <2DA30A13-A901-45DC-A3B9-B39F3E0E0BA8@tagtraum.com>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
	<D066ECBB-5639-4691-8BB3-70B3E5250132@tagtraum.com>
	<2DA30A13-A901-45DC-A3B9-B39F3E0E0BA8@tagtraum.com>
Message-ID: <517500BC.3060307@oracle.com>

On 22/04/2013 08:47, Hendrik Schreiber wrote:
> :
> Seriously - what's the state of the Java bug database?
> Not public anymore?
>
> -hendrik
Joe Darcy has published a number of blogs on the big migration that has 
been going on, see:

https://blogs.oracle.com/darcy/entry/milestone_jira_system_of_record

https://blogs.oracle.com/darcy/entry/jdk_bug_migration_bugs_sun

There is of course a lot more that has to happen before we have a 
completely open bug database.

From hs at tagtraum.com  Mon Apr 22 02:30:12 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 22 Apr 2013 11:30:12 +0200
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <517500BC.3060307@oracle.com>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
	<D066ECBB-5639-4691-8BB3-70B3E5250132@tagtraum.com>
	<2DA30A13-A901-45DC-A3B9-B39F3E0E0BA8@tagtraum.com>
	<517500BC.3060307@oracle.com>
Message-ID: <E309631E-5B24-4D12-9585-868FEB7A447F@tagtraum.com>

On Apr 22, 2013, at 11:19 AM, Alan Bateman wrote:

> On 22/04/2013 08:47, Hendrik Schreiber wrote:
>> :
>> Seriously - what's the state of the Java bug database?
>> Not public anymore?
>> 
>> -hendrik
> Joe Darcy has published a number of blogs on the big migration that has been going on, see:
> 
> https://blogs.oracle.com/darcy/entry/milestone_jira_system_of_record
> 
> https://blogs.oracle.com/darcy/entry/jdk_bug_migration_bugs_sun
> 
> There is of course a lot more that has to happen before we have a completely open bug database.

Thanks, Alan.

Looks like you are migrating the system. And it's planned to keep it open. Sweet.

Unfortunately, right now, it's not searchable :-(
Why? Any idea when it will be functional again?

Thank you,

-hendrik

From private at claudio.ch  Mon Apr 22 03:06:48 2013
From: private at claudio.ch (Claudio Nieder)
Date: Mon, 22 Apr 2013 12:06:48 +0200
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <E309631E-5B24-4D12-9585-868FEB7A447F@tagtraum.com>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
	<D066ECBB-5639-4691-8BB3-70B3E5250132@tagtraum.com>
	<2DA30A13-A901-45DC-A3B9-B39F3E0E0BA8@tagtraum.com>
	<517500BC.3060307@oracle.com>
	<E309631E-5B24-4D12-9585-868FEB7A447F@tagtraum.com>
Message-ID: <BE0FCB2A-3178-49B3-B688-C7BE4F793D7C@claudio.ch>

Hi,

> Unfortunately, right now, it's not searchable :-(

As a workaround search on google like this:

site:bugs.sun.com your search terms

claudio
-- 
Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch





From hs at tagtraum.com  Mon Apr 22 03:22:10 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 22 Apr 2013 12:22:10 +0200
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <BE0FCB2A-3178-49B3-B688-C7BE4F793D7C@claudio.ch>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
	<D066ECBB-5639-4691-8BB3-70B3E5250132@tagtraum.com>
	<2DA30A13-A901-45DC-A3B9-B39F3E0E0BA8@tagtraum.com>
	<517500BC.3060307@oracle.com>
	<E309631E-5B24-4D12-9585-868FEB7A447F@tagtraum.com>
	<BE0FCB2A-3178-49B3-B688-C7BE4F793D7C@claudio.ch>
Message-ID: <0D0892CC-901E-4D45-995A-5BC917FB513A@tagtraum.com>

On Apr 22, 2013, at 12:06 PM, Claudio Nieder wrote:
> 
>> Unfortunately, right now, it's not searchable :-(
> 
> As a workaround search on google like this:
> 
> site:bugs.sun.com your search terms

Cool - thanks, Claudio!
Appreciate it.

-hendrik

From joe.darcy at oracle.com  Mon Apr 22 11:08:41 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Apr 2013 11:08:41 -0700
Subject: Showstopper-bugs, bug-database not searchable
In-Reply-To: <E309631E-5B24-4D12-9585-868FEB7A447F@tagtraum.com>
References: <E792B6D9-D436-40AB-AACF-3D43183CE865@gmx.de>
	<D066ECBB-5639-4691-8BB3-70B3E5250132@tagtraum.com>
	<2DA30A13-A901-45DC-A3B9-B39F3E0E0BA8@tagtraum.com>
	<517500BC.3060307@oracle.com>
	<E309631E-5B24-4D12-9585-868FEB7A447F@tagtraum.com>
Message-ID: <51757CA9.7060209@oracle.com>

On 04/22/2013 02:30 AM, Hendrik Schreiber wrote:
> On Apr 22, 2013, at 11:19 AM, Alan Bateman wrote:
>
>> On 22/04/2013 08:47, Hendrik Schreiber wrote:
>>> :
>>> Seriously - what's the state of the Java bug database?
>>> Not public anymore?
>>>
>>> -hendrik
>> Joe Darcy has published a number of blogs on the big migration that has been going on, see:
>>
>> https://blogs.oracle.com/darcy/entry/milestone_jira_system_of_record
>>
>> https://blogs.oracle.com/darcy/entry/jdk_bug_migration_bugs_sun
>>
>> There is of course a lot more that has to happen before we have a completely open bug database.
> Thanks, Alan.
>
> Looks like you are migrating the system. And it's planned to keep it open. Sweet.
>
> Unfortunately, right now, it's not searchable :-(
> Why? Any idea when it will be functional again?
>
> Thank you,
>
> -hendrik

Hello,

Searching by a particular bug number does work, but we are aware there 
is more work do to on the bugs.sun.com front.  For general searches, in 
the meantime using a query like

     site:bugs.sun.com $TERMS_OF_INTEREST

in your favorite web search engine may let you find what you are looking 
for.

HTH,

-Joe

From hs at tagtraum.com  Tue Apr 23 06:09:44 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 23 Apr 2013 15:09:44 +0200
Subject: umlauts in File names
Message-ID: <564E683D-9D45-4688-9C62-8C2436177A11@tagtraum.com>

Hi,

does anybody know the status/bug id of the "Umlauts in filenames lead to FileNotFoundException"-bug.
I was unable to find it via "site:bugs.sun.com apple file umlaut". http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193966 seems related, but not spot on.

I'm using 1.7.0_21 and it looks like the bug is still present.

Thanks,

-hendrik


From Sergey.Bylokhov at oracle.com  Tue Apr 23 06:18:05 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 23 Apr 2013 17:18:05 +0400
Subject: [8] Request for review: 7161575 [macosx] On MacOSX port
	java.awt.Toolkit.is/setDynamicLayout() are not consistent
Message-ID: <51768A0D.7000405@oracle.com>

Hello,
Please review the fix for jdk 8.
DynamicLayout functionality was added to the LWToolkit. All new methods 
just a stubs, because on macosx "live-resize" is always enabled.
But I have doubts about isDynamicLayoutActive. Because according to the 
javadoc:
"Returns whether dynamic layout of Containers on resize is currently 
active (both set in program ( |isDynamicLayoutSet()| ) , and supported 
by the underlying operating system and/or window manager)."
And in the javadoc of setDynamicLayout:
"On these platforms where dynamic layout during resizing is not 
supported (or is always supported), setting this property has no effect."

In the current fix i assume that we can ignore user's data in 
isDynamicLayoutActive if DynamicLayout is always supported.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161575
Webrev can be found at: http://cr.openjdk.java.net/~serb/7161575/webrev.00/

-- 
Best regards, Sergey.


From Alan.Bateman at oracle.com  Tue Apr 23 06:32:59 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Apr 2013 14:32:59 +0100
Subject: umlauts in File names
In-Reply-To: <564E683D-9D45-4688-9C62-8C2436177A11@tagtraum.com>
References: <564E683D-9D45-4688-9C62-8C2436177A11@tagtraum.com>
Message-ID: <51768D8B.2030602@oracle.com>

On 23/04/2013 14:09, Hendrik Schreiber wrote:
> Hi,
>
> does anybody know the status/bug id of the "Umlauts in filenames lead to FileNotFoundException"-bug.
> I was unable to find it via "site:bugs.sun.com apple file umlaut". http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193966 seems related, but not spot on.
>
> I'm using 1.7.0_21 and it looks like the bug is still present.
>
> Thanks,
>
> -hendrik
I don't think there are any 7uX builds with the changes that help this. 
The changes have been in jdk8 for some time. Can you try a preview build 
of jdk8 and see if that addresses the issues you are seeing?

-Alan

From superstippi at gmx.de  Tue Apr 23 07:11:28 2013
From: superstippi at gmx.de (=?ISO-8859-1?Q?Stephan_A=DFmus?=)
Date: Tue, 23 Apr 2013 16:11:28 +0200
Subject: umlauts in File names
In-Reply-To: <51768D8B.2030602@oracle.com>
References: <564E683D-9D45-4688-9C62-8C2436177A11@tagtraum.com>
	<51768D8B.2030602@oracle.com>
Message-ID: <51769690.2070308@gmx.de>

Hi Alan,

On 23.04.2013 15:32, Alan Bateman wrote:
> On 23/04/2013 14:09, Hendrik Schreiber wrote:
>> does anybody know the status/bug id of the "Umlauts in filenames lead
>> to FileNotFoundException"-bug.
>> I was unable to find it via "site:bugs.sun.com apple file umlaut".
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193966 seems
>> related, but not spot on.
>>
>> I'm using 1.7.0_21 and it looks like the bug is still present.
>
> I don't think there are any 7uX builds with the changes that help this.
> The changes have been in jdk8 for some time. Can you try a preview build
> of jdk8 and see if that addresses the issues you are seeing?

I just realized that our conversation was off-list. :-\ Sorry, I meant 
to reply to the list.

I just looked and there doesn't seem to be an option to convince 
Thunderbird to reply to all recipients of the original mail by default.

In any case, I can confirm the problem exists in JDK 7u21 and is fixed 
in JDK8.

Best regards,
-Stephan



From hs at tagtraum.com  Tue Apr 23 07:46:42 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 23 Apr 2013 16:46:42 +0200
Subject: umlauts in File names
In-Reply-To: <51769690.2070308@gmx.de>
References: <564E683D-9D45-4688-9C62-8C2436177A11@tagtraum.com>
	<51768D8B.2030602@oracle.com> <51769690.2070308@gmx.de>
Message-ID: <F1496083-1EE0-46D6-A26A-78C1DA678D7E@tagtraum.com>

On Apr 23, 2013, at 4:11 PM, Stephan A?mus wrote:

> 
> In any case, I can confirm the problem exists in JDK 7u21 and is fixed in JDK8.

I can confirm the same (JDK8b86).

But to be honest - I was more interested in tracking whether there will be a shippable Java 7 for OS X.
Obviously, a software platform that can't read files is not shippable.

Do you know, whether corresponding fixes will be back-ported to Java 7?

Thanks,

-hendrik

From anthony.petrov at oracle.com  Tue Apr 23 07:51:31 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 23 Apr 2013 18:51:31 +0400
Subject: [8] Request for review: 7161575 [macosx] On MacOSX port
	java.awt.Toolkit.is/setDynamicLayout() are not consistent
In-Reply-To: <51768A0D.7000405@oracle.com>
References: <51768A0D.7000405@oracle.com>
Message-ID: <51769FF3.10108@oracle.com>

Looks fine to me.

--
best regards,
Anthony

On 04/23/2013 05:18 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 8.
> DynamicLayout functionality was added to the LWToolkit. All new methods
> just a stubs, because on macosx "live-resize" is always enabled.
> But I have doubts about isDynamicLayoutActive. Because according to the
> javadoc:
> "Returns whether dynamic layout of Containers on resize is currently
> active (both set in program ( |isDynamicLayoutSet()| ) , and supported
> by the underlying operating system and/or window manager)."
> And in the javadoc of setDynamicLayout:
> "On these platforms where dynamic layout during resizing is not
> supported (or is always supported), setting this property has no effect."
>
> In the current fix i assume that we can ignore user's data in
> isDynamicLayoutActive if DynamicLayout is always supported.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161575
> Webrev can be found at: http://cr.openjdk.java.net/~serb/7161575/webrev.00/
>
> --
> Best regards, Sergey.
>

From Alan.Bateman at oracle.com  Tue Apr 23 08:04:57 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Apr 2013 16:04:57 +0100
Subject: umlauts in File names
In-Reply-To: <F1496083-1EE0-46D6-A26A-78C1DA678D7E@tagtraum.com>
References: <564E683D-9D45-4688-9C62-8C2436177A11@tagtraum.com>
	<51768D8B.2030602@oracle.com> <51769690.2070308@gmx.de>
	<F1496083-1EE0-46D6-A26A-78C1DA678D7E@tagtraum.com>
Message-ID: <5176A319.1020004@oracle.com>

On 23/04/2013 15:46, Hendrik Schreiber wrote:
>
> I can confirm the same (JDK8b86).
>
> But to be honest - I was more interested in tracking whether there will be a shippable Java 7 for OS X.
> Obviously, a software platform that can't read files is not shippable.
>
> Do you know, whether corresponding fixes will be back-ported to Java 7?
>
It's already in jdk7u-dev.

-Alan

From hs at tagtraum.com  Tue Apr 23 08:05:45 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 23 Apr 2013 17:05:45 +0200
Subject: How will resolution independence be handled in jdk8?
Message-ID: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>

Hi,

I'm aware that there is an ongoing effort to support resolution independence in JDK 8.
E.g. http://bugs.sun.com/view_bug.do?bug_id=8000629 - I am assuming this will draw text and built-in UI elements with the native resolution.

What I wonder, how will we as developers be able to draw images with sub-pixel resolution?

Will we simply be able to call 

	graphics.drawImage(img, x, y, w, h, obs);

and if the image is twice the size of w/h (=4xarea) and a Retina display is present, the image is drawn with sub-pixel resolution? I.e. in effect not scaled, but simply drawn?

If so, will there be a way to find out the scale factor, i.e. the factor between pixel based resolution and true display sub-pixel capability? To illustrate, for Retina this factor is 2x. After all, we need to know, what kind of images to load for a high resolution capable app.

Last but not least, the bug mentioned above mentions the info.plist flag

<key>NSHighResolutionCapable</key><true/>

Will it be necessary to set this? What exactly does it do?

Thank you,

-hendrik

From hs at tagtraum.com  Tue Apr 23 08:07:47 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 23 Apr 2013 17:07:47 +0200
Subject: umlauts in File names
In-Reply-To: <5176A319.1020004@oracle.com>
References: <564E683D-9D45-4688-9C62-8C2436177A11@tagtraum.com>
	<51768D8B.2030602@oracle.com> <51769690.2070308@gmx.de>
	<F1496083-1EE0-46D6-A26A-78C1DA678D7E@tagtraum.com>
	<5176A319.1020004@oracle.com>
Message-ID: <DBD974A5-61EA-4F67-9310-7D88DFC53FD5@tagtraum.com>

On Apr 23, 2013, at 5:04 PM, Alan Bateman wrote:

> On 23/04/2013 15:46, Hendrik Schreiber wrote:
>> 
>> Do you know, whether corresponding fixes will be back-ported to Java 7?
>> 
> It's already in jdk7u-dev.

Thank you, Alan - that is great news!
Looking forward to seeing this live!

-hendrik

From swingler at apple.com  Tue Apr 23 08:11:16 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 23 Apr 2013 08:11:16 -0700
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
Message-ID: <EE02DC39-1DF0-4028-B0A4-A1EB89CF8A45@apple.com>

On Apr 23, 2013, at 8:05 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:

> Last but not least, the bug mentioned above mentions the info.plist flag
> 
> <key>NSHighResolutionCapable</key><true/>
> 
> Will it be necessary to set this? What exactly does it do?

This key is required by OS X, not the JVM. All Cocoa apps require this to be set by the developer to indicate that they are Retina-ready.

Regards,
Mike Swingler
Apple Inc.


From hs at tagtraum.com  Tue Apr 23 08:16:04 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 23 Apr 2013 17:16:04 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <EE02DC39-1DF0-4028-B0A4-A1EB89CF8A45@apple.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<EE02DC39-1DF0-4028-B0A4-A1EB89CF8A45@apple.com>
Message-ID: <0FD756AE-92A0-4F9E-B818-C99A3E5A3638@tagtraum.com>

On Apr 23, 2013, at 5:11 PM, Mike Swingler wrote:

> On Apr 23, 2013, at 8:05 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:
> 
>> Last but not least, the bug mentioned above mentions the info.plist flag
>> 
>> <key>NSHighResolutionCapable</key><true/>
>> 
>> Will it be necessary to set this? What exactly does it do?
> 
> This key is required by OS X, not the JVM. All Cocoa apps require this to be set by the developer to indicate that they are Retina-ready.

Was this necessary for Apple 6? It seemed to work without it..

-hendrik

From swingler at apple.com  Tue Apr 23 08:21:27 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 23 Apr 2013 08:21:27 -0700
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <0FD756AE-92A0-4F9E-B818-C99A3E5A3638@tagtraum.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<EE02DC39-1DF0-4028-B0A4-A1EB89CF8A45@apple.com>
	<0FD756AE-92A0-4F9E-B818-C99A3E5A3638@tagtraum.com>
Message-ID: <8F6D8670-592E-4FD7-8787-34830C9F17FF@apple.com>

On Apr 23, 2013, at 8:16 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:

> On Apr 23, 2013, at 5:11 PM, Mike Swingler wrote:
> 
>> On Apr 23, 2013, at 8:05 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:
>> 
>>> Last but not least, the bug mentioned above mentions the info.plist flag
>>> 
>>> <key>NSHighResolutionCapable</key><true/>
>>> 
>>> Will it be necessary to set this? What exactly does it do?
>> 
>> This key is required by OS X, not the JVM. All Cocoa apps require this to be set by the developer to indicate that they are Retina-ready.
> 
> Was this necessary for Apple 6? It seemed to work without it..

Only when launched from the command line. All bundled apps require it, Cocoa or otherwise.

Regards,
Mike Swingler
Apple Inc.


From superstippi at gmx.de  Tue Apr 23 08:33:13 2013
From: superstippi at gmx.de (=?ISO-8859-1?Q?Stephan_A=DFmus?=)
Date: Tue, 23 Apr 2013 17:33:13 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
Message-ID: <5176A9B9.1080808@gmx.de>

Hi,

On 23.04.2013 17:05, Hendrik Schreiber wrote:
> I'm aware that there is an ongoing effort to support resolution independence in JDK 8.
> E.g. http://bugs.sun.com/view_bug.do?bug_id=8000629 - I am assuming this will draw text and built-in UI elements with the native resolution.
>
> What I wonder, how will we as developers be able to draw images with sub-pixel resolution?
>
> Will we simply be able to call
>
> 	graphics.drawImage(img, x, y, w, h, obs);
>
> and if the image is twice the size of w/h (=4xarea) and a Retina display is present, the image is drawn with sub-pixel resolution? I.e. in effect not scaled, but simply drawn?
>
> If so, will there be a way to find out the scale factor, i.e. the factor between pixel based resolution and true display sub-pixel capability? To illustrate, for Retina this factor is 2x. After all, we need to know, what kind of images to load for a high resolution capable app.

There are situations in which it isn't so simple, unfortunately. Think 
of a window which is partly on a non-Retina-screen and partly on a 
Retina-screen. From when I have learned thus far about the Cocoa APIs, 
they will handle this situation.

> Last but not least, the bug mentioned above mentions the info.plist flag
>
> <key>NSHighResolutionCapable</key><true/>
>
> Will it be necessary to set this? What exactly does it do?

Can't remember all the details, but you can search the Mac Dev Center, 
there are some good articles on it there.

I know for a fact that you don't /need/ to set this flag to prevent your 
app to be "up-scaled". That is if you use SWT at least. Anything that 
draws into an Image to avoid flickering or somesuch will be scaled, but 
anything "directly" drawn to the screen will not be "up-scaled". Of 
cource nothing flickers in OS X, but in some instances, I had such code 
in place to avoid flickering in my Windows version.

I think this flag might be needed in relation to graphics resources 
included in your bundle.

Best regards,
-Stephan



From Sergey.Bylokhov at oracle.com  Tue Apr 23 10:03:29 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 23 Apr 2013 21:03:29 +0400
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
Message-ID: <5176BEE1.9000609@oracle.com>

Hi, Hendrik.
On 23.04.2013 19:05, Hendrik Schreiber wrote:
> Will we simply be able to call
>
> 	graphics.drawImage(img, x, y, w, h, obs);
>
> and if the image is twice the size of w/h (=4xarea) and a Retina display is present, the image is drawn with sub-pixel resolution? I.e. in effect not scaled, but simply drawn?
Yes, it should work in this way.
> If so, will there be a way to find out the scale factor, i.e. the factor between pixel based resolution and true display sub-pixel capability? To illustrate, for Retina this factor is 2x. After all, we need to know, what kind of images to load for a high resolution capable app.
Currently there is no such info, but it will be added. Therefore while 
it is not implemented, any suggestions are welcome.
> -hendrik


-- 
Best regards, Sergey.


From hs at tagtraum.com  Tue Apr 23 11:55:43 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 23 Apr 2013 20:55:43 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <5176BEE1.9000609@oracle.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
Message-ID: <9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>

On Apr 23, 2013, at 7:03 PM, Sergey Bylokhov wrote:

> Hi, Hendrik.
> On 23.04.2013 19:05, Hendrik Schreiber wrote:
>> Will we simply be able to call
>> 
>> 	graphics.drawImage(img, x, y, w, h, obs);
>> 
>> and if the image is twice the size of w/h (=4xarea) and a Retina display is present, the image is drawn with sub-pixel resolution? I.e. in effect not scaled, but simply drawn?
> Yes, it should work in this way.
>> If so, will there be a way to find out the scale factor, i.e. the factor between pixel based resolution and true display sub-pixel capability? To illustrate, for Retina this factor is 2x. After all, we need to know, what kind of images to load for a high resolution capable app.
> Currently there is no such info, but it will be added. Therefore while it is not implemented, any suggestions are welcome.

In the Apple 6 JVM this was available as 

final Float scaleFactor = (Float) Toolkit.getDefaultToolkit().getDesktopProperty("apple.awt.contentScaleFactor");

I'd prefer this to be exposed via a method, perhaps in java.awt.GraphicsDevice - looks like sun.awt.CGraphicsDevice already has a method called:

public int getScaleFactor();

Perhaps it makes sense to make this public through java.awt.GraphicsDevice? Should it be int? Or float?

In any case, the Apple JVM was lacking the ability to detect changes. I.e. there was no way to be notified when the user changed from Retina mode to regular mode. But there should be some kind of property change support.

Back to loading and drawing images.

Apple supported the @2x hack. That is, one could load images using a resource name (e.g. "image") and the system would use automatically either "image.png" or "image at 2x.png" when drawing, depending on the current scale factor. Perhaps this kind of Image class that is backed by multiple resolution optimized Images and a corresponding loading mechanism is something nice to have, too. Mike Swingler can describe the mechanism probably much better...

Something else missing from the (public) Apple implementation was the ability to create such multiresolution images programmatically. I.e. something like new MultiResImage(regImage, hiResImage);
To make this kind of API complete, you might also want to add a property scaleFactor to the Image class (or a subclass), which is honored by graphics.drawImage(img, x, y, obs), so one does not always have to specify width and height, but scaling is done automatically for you...

Well, as you probably realized by now, I am no expert when it comes to resolution independence, nor have I thought this all the way through - but I guess it's a start...

-hendrik

From krueger at lesspain.de  Fri Apr 26 09:37:33 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 26 Apr 2013 18:37:33 +0200
Subject: Thanks for the retina fix!
Message-ID: <CAEnqZEXChk8natn5WGNEufmf8z=xb3eSOhVdq1wYds-T19XD3w@mail.gmail.com>

Hi,

I just tried our swing application with a fresh build of OpenJDK 8 on a
retina display to test the recently committed retina fix and the overall
look of the application is now brilliant, i.e. like it is using Apple JDK
6. There are minor problems with Nimbus L&F that were there with JDK 6 that
now seem to have worsened a bit but that is probably a Nimbus bug anyway
and probably can be worked around.

Thanks a million for listening to the application developers and making
this happen!

The only thing that still is noticeable is that component repainting during
resizing still does not seem to be synchronized with window resizing making
the components "jump around" a bit during the resize but that is something
that we can probably live with for a while.

This gives us a chance to attempt a smooth migration to JFX while
maintaining the application's functionality which was an essential step on
the road to independence from Apple's JDK (which still will require some
work but now feels doable).

Can't wait to test this more thoroughly but the first impression made me
happy and want to thank you for your hard work.

Best regards,

Robert

From andrew.brygin at oracle.com  Fri Apr 26 11:52:11 2013
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Fri, 26 Apr 2013 22:52:11 +0400
Subject: [8] Request for review: 8009012 [macosx] DisplayChangedListener
	is not implemented in LWWindowPeer/CGraphicsEnvironment
In-Reply-To: <516E6E8C.9020506@oracle.com>
References: <516E6E8C.9020506@oracle.com>
Message-ID: <517ACCDB.6030400@oracle.com>

Hello Sergey,

  the fix looks fine to me.

Thanks,
Andrew.

On 4/17/2013 1:42 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 8.
> displayChanged() was added to LWWindowPeer and CGraphicsDevice. Note 
> that I move out unnecessary calls to the appkit thread(in 
> CGLayer.nativeSetScale() and CGraphicsDevice.getX), because it can 
> cause a deadlock, when called from the non-appkit thread.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009012
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8009012/webrev.00
> -- 
> Best regards, Sergey.


From hs at tagtraum.com  Fri Apr 26 14:42:01 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 26 Apr 2013 23:42:01 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
Message-ID: <09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>

On Apr 23, 2013, at 8:55 PM, Hendrik Schreiber wrote:

> [...]
> Back to loading and drawing images.
> 
> Apple supported the @2x hack. That is, one could load images using a resource name (e.g. "image") and the system would use automatically either "image.png" or "image at 2x.png" when drawing, depending on the current scale factor. Perhaps this kind of Image class that is backed by multiple resolution optimized Images and a corresponding loading mechanism is something nice to have, too. Mike Swingler can describe the mechanism probably much better...

BTW - something like this will be a necessity. Just think of images in JButtons. You have to be able to pass some image into the button, and the button needs to be able to correctly draw either a low or a high resolution version. Automatically. Because it is close to impossible to mess around with the actual drawing mechanism inside of the ButtonUI...

-hendrik

From krueger at lesspain.de  Sat Apr 27 04:50:53 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sat, 27 Apr 2013 13:50:53 +0200
Subject: Status/outlook resizing performance (bug 7198229)
Message-ID: <CAEnqZEUje_8UgNU=7Jsx5coXp-RqjA_sbmx+CF4Oxan3hcVUpw@mail.gmail.com>

I noticed that that bug has been marked as fixed.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229

However, a JDK 8 build from a few days ago has the same problems for the
Swing application I have been testing it for, i.e. the components inside
the window appear to be jumping around during the resize which they are not
when starting the application with Apple's JDK6. In our case it is a bottom
status bar that changes is distance from the window edge significantly
(which should be zero at all time) during the resize operation. With Apple
JDK6 it is stays exactly at the window edge. I am testing on a 2013 Retina
MBP (however the general problem is also still visible on non-Retina
displays, so that is not the reason), so this is really not a slow
computer.

Is there anything to be expected in terms of improvements for JDK 8 or is
this it now and we need to look for workarounds or live with it? If it is
the latter, any hints what we could do in our application to work around
that?

Thanks in advance,

Robert

From krueger at lesspain.de  Sat Apr 27 04:58:45 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sat, 27 Apr 2013 13:58:45 +0200
Subject: Splash screen border
Message-ID: <CAEnqZEXwe6P02Lp_n1jxAGmTEw01zgverf6xQTPHF=DjmxF5-A@mail.gmail.com>

Hi,

there is a difference between JDK6 (Apple) and OpenJDK8. The splash screen
has a border when starting with the Apple JDK and it has not for OpenJDK.
Of course, this is really easy to work around by adding the border to the
splash screen image. I would only like to know if this is a conscious
decision or an oversight (maybe even with a bug id that I can track) or if
I should do anything differently (like setting a parameter somewhere).

Thanks,

Robert

From krueger at lesspain.de  Sat Apr 27 08:39:00 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sat, 27 Apr 2013 17:39:00 +0200
Subject: Animations not disabled for CALayers used via JAWT
Message-ID: <CAEnqZEVFUb_0D8M+-RzttBAd5i38+h_7Mzp5xV+MTgbCxRZM-g@mail.gmail.com>

Hi,

while trying to port our application from Apple JDK6 to OpenJDK 8 (built
from current source) we ran into the following issue:

We use jawt to integrate a native CALayer to do some OpenGL rendering in it
for a video player which works very well with JDK 6. It does work with JDK
8 as well but when the canvas is made visible there is an unwanted
animation that looks like the canvas is created in the lower left corner of
the containing frame and then flies/scales up to assume its correct
position.

We have looked at our native code, if we could disable the animation there
but could not find a way. Is this something that would have to be done in
the JAWT code in the JDK? If so, could you give us a hint where we should
look?

Thanks in advance,

Robert

From Sergey.Bylokhov at oracle.com  Sat Apr 27 15:12:22 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 28 Apr 2013 02:12:22 +0400
Subject: Animations not disabled for CALayers used via JAWT
In-Reply-To: <CAEnqZEVFUb_0D8M+-RzttBAd5i38+h_7Mzp5xV+MTgbCxRZM-g@mail.gmail.com>
References: <CAEnqZEVFUb_0D8M+-RzttBAd5i38+h_7Mzp5xV+MTgbCxRZM-g@mail.gmail.com>
Message-ID: <517C4D46.9050505@oracle.com>

Hi, Robert.
Please file a bug at http://bugreport.sun.com/bugreport
Please provide testcase. Also check how it works on jdk 7. Send assigned 
bugid here.

Thanks.

On 27.04.2013 19:39, Robert Kr?ger wrote:
> Hi,
>
> while trying to port our application from Apple JDK6 to OpenJDK 8 (built
> from current source) we ran into the following issue:
>
> We use jawt to integrate a native CALayer to do some OpenGL rendering in it
> for a video player which works very well with JDK 6. It does work with JDK
> 8 as well but when the canvas is made visible there is an unwanted
> animation that looks like the canvas is created in the lower left corner of
> the containing frame and then flies/scales up to assume its correct
> position.
>
> We have looked at our native code, if we could disable the animation there
> but could not find a way. Is this something that would have to be done in
> the JAWT code in the JDK? If so, could you give us a hint where we should
> look?
>
> Thanks in advance,
>
> Robert


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Sat Apr 27 15:16:56 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 28 Apr 2013 02:16:56 +0400
Subject: Status/outlook resizing performance (bug 7198229)
In-Reply-To: <CAEnqZEUje_8UgNU=7Jsx5coXp-RqjA_sbmx+CF4Oxan3hcVUpw@mail.gmail.com>
References: <CAEnqZEUje_8UgNU=7Jsx5coXp-RqjA_sbmx+CF4Oxan3hcVUpw@mail.gmail.com>
Message-ID: <517C4E58.7070300@oracle.com>

Hi, Robert.
Is it reproducible on the demos? Like Java2dDemo and SwingSet2/3?

Please file a bug at http://bugreport.sun.com/bugreport
Please provide testcase. Also check how it works on jdk 7. Send assigned 
bugid here.

Thanks!

On 27.04.2013 15:50, Robert Kr?ger wrote:
> I noticed that that bug has been marked as fixed.
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229
>
> However, a JDK 8 build from a few days ago has the same problems for the
> Swing application I have been testing it for, i.e. the components inside
> the window appear to be jumping around during the resize which they are not
> when starting the application with Apple's JDK6. In our case it is a bottom
> status bar that changes is distance from the window edge significantly
> (which should be zero at all time) during the resize operation. With Apple
> JDK6 it is stays exactly at the window edge. I am testing on a 2013 Retina
> MBP (however the general problem is also still visible on non-Retina
> displays, so that is not the reason), so this is really not a slow
> computer.
>
> Is there anything to be expected in terms of improvements for JDK 8 or is
> this it now and we need to look for workarounds or live with it? If it is
> the latter, any hints what we could do in our application to work around
> that?
>
> Thanks in advance,
>
> Robert


-- 
Best regards, Sergey.


From hs at tagtraum.com  Sun Apr 28 00:21:14 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Sun, 28 Apr 2013 09:21:14 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
	<09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
Message-ID: <CAC09C80-CE28-4D1B-B30C-3650ADB2487B@tagtraum.com>

On Apr 26, 2013, at 11:42 PM, Hendrik Schreiber wrote:

> On Apr 23, 2013, at 8:55 PM, Hendrik Schreiber wrote:
> 
>> [...]
>> Back to loading and drawing images.
>> 
>> Apple supported the @2x hack. That is, one could load images using a resource name (e.g. "image") and the system would use automatically either "image.png" or "image at 2x.png" when drawing, depending on the current scale factor. Perhaps this kind of Image class that is backed by multiple resolution optimized Images and a corresponding loading mechanism is something nice to have, too. Mike Swingler can describe the mechanism probably much better...
> 
> BTW - something like this will be a necessity. Just think of images in JButtons. You have to be able to pass some image into the button, and the button needs to be able to correctly draw either a low or a high resolution version. Automatically. Because it is close to impossible to mess around with the actual drawing mechanism inside of the ButtonUI...

Any opinion on this, Sergey?

-hendrik

From krueger at lesspain.de  Sun Apr 28 12:02:29 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sun, 28 Apr 2013 21:02:29 +0200
Subject: Status/outlook resizing performance (bug 7198229)
In-Reply-To: <517C4E58.7070300@oracle.com>
References: <CAEnqZEUje_8UgNU=7Jsx5coXp-RqjA_sbmx+CF4Oxan3hcVUpw@mail.gmail.com>
	<517C4E58.7070300@oracle.com>
Message-ID: <CAEnqZEU1TUJCAGM=nsNWCMnurkomC6V-0dx6mAsPcrrTk+VskA@mail.gmail.com>

No, with SwingSet3 it does not happen. It also happens with JDK7 update 21.
I'll try to build a simple test case.


On Sun, Apr 28, 2013 at 12:16 AM, Sergey Bylokhov <
Sergey.Bylokhov at oracle.com> wrote:

> Hi, Robert.
> Is it reproducible on the demos? Like Java2dDemo and SwingSet2/3?
>
> Please file a bug at http://bugreport.sun.com/**bugreport<http://bugreport.sun.com/bugreport>
> Please provide testcase. Also check how it works on jdk 7. Send assigned
> bugid here.
>
> Thanks!
>
>
> On 27.04.2013 15:50, Robert Kr?ger wrote:
>
>> I noticed that that bug has been marked as fixed.
>>
>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7198229<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229>
>>
>> However, a JDK 8 build from a few days ago has the same problems for the
>> Swing application I have been testing it for, i.e. the components inside
>> the window appear to be jumping around during the resize which they are
>> not
>> when starting the application with Apple's JDK6. In our case it is a
>> bottom
>> status bar that changes is distance from the window edge significantly
>> (which should be zero at all time) during the resize operation. With Apple
>> JDK6 it is stays exactly at the window edge. I am testing on a 2013 Retina
>> MBP (however the general problem is also still visible on non-Retina
>> displays, so that is not the reason), so this is really not a slow
>> computer.
>>
>> Is there anything to be expected in terms of improvements for JDK 8 or is
>> this it now and we need to look for workarounds or live with it? If it is
>> the latter, any hints what we could do in our application to work around
>> that?
>>
>> Thanks in advance,
>>
>> Robert
>>
>
>
> --
> Best regards, Sergey.
>
>

From Sergey.Bylokhov at oracle.com  Sun Apr 28 12:47:38 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 28 Apr 2013 23:47:38 +0400
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <CAC09C80-CE28-4D1B-B30C-3650ADB2487B@tagtraum.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
	<09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
	<CAC09C80-CE28-4D1B-B30C-3650ADB2487B@tagtraum.com>
Message-ID: <517D7CDA.8010006@oracle.com>

On 28.04.2013 11:21, Hendrik Schreiber wrote:
> BTW - something like this will be a necessity. Just think of images in JButtons. You have to be able to pass some image into the button, and the button needs to be able to correctly draw either a low or a high resolution version. Automatically. Because it is close to impossible to mess around with the actual drawing mechanism inside of the ButtonUI...
> Any opinion on this, Sergey?
I agree that it is a good idea. We have some ideas how it can be done. 
But it will not appear in the near future.
>
> -hendrik


-- 
Best regards, Sergey.


From hs at tagtraum.com  Mon Apr 29 02:36:43 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 29 Apr 2013 11:36:43 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <517D7CDA.8010006@oracle.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
	<09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
	<CAC09C80-CE28-4D1B-B30C-3650ADB2487B@tagtraum.com>
	<517D7CDA.8010006@oracle.com>
Message-ID: <6E6D5F50-C228-41DE-A474-2BDA544A2979@tagtraum.com>

On Apr 28, 2013, at 9:47 PM, Sergey Bylokhov wrote:

> On 28.04.2013 11:21, Hendrik Schreiber wrote:
>> BTW - something like this will be a necessity. Just think of images in JButtons. You have to be able to pass some image into the button, and the button needs to be able to correctly draw either a low or a high resolution version. Automatically. Because it is close to impossible to mess around with the actual drawing mechanism inside of the ButtonUI...
>> Any opinion on this, Sergey?
> I agree that it is a good idea. We have some ideas how it can be done. But it will not appear in the near future.

Can you define "near future"?
In your opinion, will something like this make it into Java8?

In the same context, I wouldn't be surprised if Apple stopped making non-Retina laptops this or early next year.

-hendrik


From artem.ananiev at oracle.com  Mon Apr 29 03:15:58 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 29 Apr 2013 14:15:58 +0400
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
	<09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
Message-ID: <517E485E.9060800@oracle.com>


On 4/27/2013 1:42 AM, Hendrik Schreiber wrote:
> On Apr 23, 2013, at 8:55 PM, Hendrik Schreiber wrote:
>
>> [...]
>> Back to loading and drawing images.
>>
>> Apple supported the @2x hack. That is, one could load images using
>> a resource name (e.g. "image") and the system would use
>> automatically either "image.png" or "image at 2x.png" when drawing,
>> depending on the current scale factor. Perhaps this kind of Image
>> class that is backed by multiple resolution optimized Images and a
>> corresponding loading mechanism is something nice to have, too.
>> Mike Swingler can describe the mechanism probably much better...
>
> BTW - something like this will be a necessity. Just think of images
> in JButtons. You have to be able to pass some image into the button,
> and the button needs to be able to correctly draw either a low or a
> high resolution version. Automatically. Because it is close to
> impossible to mess around with the actual drawing mechanism inside of
> the ButtonUI...

As you wrote above, @2x looks like a hack. Although we can support 
something like this in JDK7/8, I would prefer to have clear API to 
handle different scale factors. For example, API to listen for Window's 
graphics configuration changes and getter for the current scale factor 
value. In this case, application will be able to load a new image for 
the new scale factor and assign it to the button. A little piece of 
trivial code vs magic NSImage:// images.

Of course, if we decide to provide any new public APIs, it can only be 
done in JDK8 or later. JDK7 API is frozen.

Thanks,

Artem

> -hendrik

From hs at tagtraum.com  Mon Apr 29 03:26:54 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 29 Apr 2013 12:26:54 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <517E485E.9060800@oracle.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
	<09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
	<517E485E.9060800@oracle.com>
Message-ID: <88BA10A3-2F29-4F83-986E-B3EFA6AFEF0A@tagtraum.com>

On Apr 29, 2013, at 12:15 PM, Artem Ananiev wrote:

> 
> On 4/27/2013 1:42 AM, Hendrik Schreiber wrote:
>> On Apr 23, 2013, at 8:55 PM, Hendrik Schreiber wrote:
>> 
>> BTW - something like this will be a necessity. Just think of images
>> in JButtons. You have to be able to pass some image into the button,
>> and the button needs to be able to correctly draw either a low or a
>> high resolution version. Automatically. Because it is close to
>> impossible to mess around with the actual drawing mechanism inside of
>> the ButtonUI...
> 
> As you wrote above, @2x looks like a hack. Although we can support something like this in JDK7/8, I would prefer to have clear API to handle different scale factors. For example, API to listen for Window's graphics configuration changes and getter for the current scale factor value. In this case, application will be able to load a new image for the new scale factor and assign it to the button. A little piece of trivial code vs magic NSImage:// images.
> 
> Of course, if we decide to provide any new public APIs, it can only be done in JDK8 or later. JDK7 API is frozen.

Sure a nice API is always preferable. But please don't forget to build in something that solves the JButton use case described above. You simply don't always have a way to manipulate the drawing pipeline, i.e. the Graphics2D object, when you are using Swing. Often you can only pass in an Image without being able to specify width and height.

It would be nice, if this made it into Java8. Then I wouldn't have to skip Java7 *and* Java8 to ship an app that looks decent on Retina.

Thank you.

-hendrik

From hs at tagtraum.com  Mon Apr 29 03:45:37 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 29 Apr 2013 12:45:37 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <517E485E.9060800@oracle.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
	<09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
	<517E485E.9060800@oracle.com>
Message-ID: <5C502077-E009-4A9E-84D8-61CD50A8EEFC@tagtraum.com>



Am 29.04.2013 um 12:15 schrieb Artem Ananiev <artem.ananiev at oracle.com>:

> 
> On 4/27/2013 1:42 AM, Hendrik Schreiber wrote:
>> On Apr 23, 2013, at 8:55 PM, Hendrik Schreiber wrote:
>> 
>>> [...]
>>> Back to loading and drawing images.
>>> 
>>> Apple supported the @2x hack. That is, one could load images using
>>> a resource name (e.g. "image") and the system would use
>>> automatically either "image.png" or "image at 2x.png" when drawing,
>>> depending on the current scale factor. Perhaps this kind of Image
>>> class that is backed by multiple resolution optimized Images and a
>>> corresponding loading mechanism is something nice to have, too.
>>> Mike Swingler can describe the mechanism probably much better...
>> 
>> BTW - something like this will be a necessity. Just think of images
>> in JButtons. You have to be able to pass some image into the button,
>> and the button needs to be able to correctly draw either a low or a
>> high resolution version. Automatically. Because it is close to
>> impossible to mess around with the actual drawing mechanism inside of
>> the ButtonUI...
> 
> As you wrote above, @2x looks like a hack. Although we can support something like this in JDK7/8, I would prefer to have clear API to handle different scale factors. For example, API to listen for Window's graphics configuration changes and getter for the current scale factor value. In this case, application will be able to load a new image for the new scale factor and assign it to the button. A little piece of trivial code vs magic NSImage:// images.
> 

It would be much preferable, if the app provided multiple resolutions at creation time of the button and the button always picked the best one when it's drawn. Like in Cocoa's NSImage class. Saves the programmer a lot of trouble...

Seriously, as an application programmer, do you really want to keep track of every image in your app, to replace it when the GraphicsDevice changes...? That would be really cumbersome...

-hendrik

From superstippi at gmx.de  Mon Apr 29 03:53:01 2013
From: superstippi at gmx.de (=?ISO-8859-1?Q?Stephan_A=DFmus?=)
Date: Mon, 29 Apr 2013 12:53:01 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <517E485E.9060800@oracle.com>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
	<09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
	<517E485E.9060800@oracle.com>
Message-ID: <517E510D.2070107@gmx.de>

On 29.04.2013 12:15, Artem Ananiev wrote:
> As you wrote above, @2x looks like a hack. Although we can support
> something like this in JDK7/8, I would prefer to have clear API to
> handle different scale factors. For example, API to listen for Window's
> graphics configuration changes and getter for the current scale factor
> value. In this case, application will be able to load a new image for
> the new scale factor and assign it to the button. A little piece of
> trivial code vs magic NSImage:// images.
>
> Of course, if we decide to provide any new public APIs, it can only be
> done in JDK8 or later. JDK7 API is frozen.

 From what I read about the Swing and Graphics2D APIs, it would appear 
to me that all that is already supported since ages. There is a virtual, 
point-based coordinate system in which all drawing commands are 
interpreted, and there is API to get to the current scaling factor and 
actual device resolution. I.e. a way to convert between virtual 
coordinates and pixels.

There are two problems:

1) This stuff doesn't actually appear to be used. The documentation says 
that unit to pixel conversion is 1:1 for monitors which have a 
resolution close to 72 dpi. This simply isn't true, I never saw anything 
else besides 1:1, even though I have monitors well above 72 dpi.

2) There is a certain appeal to being able to specify multiple 
resultions for a bitmap based graphics resource, and have the system 
choose the appropriate resource depending on the needs - automatically. 
I think this what the JButton use-case would need.

Best regards,
-Stephan




From anthony.petrov at oracle.com  Mon Apr 29 04:50:52 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 29 Apr 2013 15:50:52 +0400
Subject: Splash screen border
In-Reply-To: <CAEnqZEXwe6P02Lp_n1jxAGmTEw01zgverf6xQTPHF=DjmxF5-A@mail.gmail.com>
References: <CAEnqZEXwe6P02Lp_n1jxAGmTEw01zgverf6xQTPHF=DjmxF5-A@mail.gmail.com>
Message-ID: <517E5E9C.9050102@oracle.com>

Hi Robert,

OpenJDK has never displayed a border for splash screens on any 
platforms. This is because a splash screen image may not be rectangular, 
may be colored differently in various applications, or even be 
semi-transparent. Showing a solid rectangular border around it might not 
look good in all cases.

When porting OpenJDK to the Mac platform we decided to keep this 
behavior in order to allow Java applications to look the same on all 
platforms supported by OpenJDK. If your application requires a border 
around your splash screen, then you should update the images you use to 
display the splash screen.

--
best regards,
Anthony

On 04/27/13 15:58, Robert Kr?ger wrote:
> Hi,
>
> there is a difference between JDK6 (Apple) and OpenJDK8. The splash screen
> has a border when starting with the Apple JDK and it has not for OpenJDK.
> Of course, this is really easy to work around by adding the border to the
> splash screen image. I would only like to know if this is a conscious
> decision or an oversight (maybe even with a bug id that I can track) or if
> I should do anything differently (like setting a parameter somewhere).
>
> Thanks,
>
> Robert

From hs at tagtraum.com  Mon Apr 29 05:39:20 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 29 Apr 2013 14:39:20 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <517E510D.2070107@gmx.de>
References: <659051EF-8F61-48E8-BEF9-CEC775F1FA84@tagtraum.com>
	<5176BEE1.9000609@oracle.com>
	<9E5EE24E-9C29-4395-AEA2-31A8BC0FA4AC@tagtraum.com>
	<09BC1245-B95F-4514-81EE-C59E501D61FE@tagtraum.com>
	<517E485E.9060800@oracle.com> <517E510D.2070107@gmx.de>
Message-ID: <0CE17EA2-B485-4F88-8582-AEBA810AFE9A@tagtraum.com>

On Apr 29, 2013, at 12:53 PM, Stephan A?mus wrote:
> 
> 2) There is a certain appeal to being able to specify multiple resultions for a bitmap based graphics resource, and have the system choose the appropriate resource depending on the needs - automatically. I think this what the JButton use-case would need.

+1
Exactly.

-hendrik

From matt at thebishops.org  Mon Apr 29 12:08:24 2013
From: matt at thebishops.org (Matthew Bishop)
Date: Mon, 29 Apr 2013 12:08:24 -0700
Subject: How will resolution independence be handled in jdk8?
Message-ID: <CAEvuJbbXWmUpn2AigeO=wbFhrh83XfUqK1Kxi+oosVV0AgN_2Q@mail.gmail.com>

Has anyone tried SVG images as icons for JButtons? It may be easier than
trying to figure out which bitmap to use:

http://stackoverflow.com/questions/2495501/swing-batik-create-an-imageicon-from-an-svg-file

From swpalmer at gmail.com  Mon Apr 29 17:09:09 2013
From: swpalmer at gmail.com (Scott Palmer)
Date: Mon, 29 Apr 2013 20:09:09 -0400
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <CAEvuJbbXWmUpn2AigeO=wbFhrh83XfUqK1Kxi+oosVV0AgN_2Q@mail.gmail.com>
References: <CAEvuJbbXWmUpn2AigeO=wbFhrh83XfUqK1Kxi+oosVV0AgN_2Q@mail.gmail.com>
Message-ID: <CAL3e5iFZi+BhGcQWYokD=OQrWd_D_Y7Kmkmej1HJORfyxJ9uxQ@mail.gmail.com>

Keep in mind that all this effort to support Swing JButton images or
whatever is really only going to be useful for backward compatiblity with
Swing.  All of the development effort at Oracle appears to be targeting
JavaFX. Therefore if a solution requires API changes to Swing, it is mostly
a waste of time.  JavaFX is the way forward and that is where the
development effort will be concentrated.
As far as I can tell, Swing is in maintenance mode... I doubt any
new development will happen in Swing with the exception of security issues
and bug fixes.

Scott


On Mon, Apr 29, 2013 at 3:08 PM, Matthew Bishop <matt at thebishops.org> wrote:

> Has anyone tried SVG images as icons for JButtons? It may be easier than
> trying to figure out which bitmap to use:
>
>
> http://stackoverflow.com/questions/2495501/swing-batik-create-an-imageicon-from-an-svg-file
>

From hs at tagtraum.com  Mon Apr 29 23:58:52 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 30 Apr 2013 08:58:52 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <CAL3e5iFZi+BhGcQWYokD=OQrWd_D_Y7Kmkmej1HJORfyxJ9uxQ@mail.gmail.com>
References: <CAEvuJbbXWmUpn2AigeO=wbFhrh83XfUqK1Kxi+oosVV0AgN_2Q@mail.gmail.com>
	<CAL3e5iFZi+BhGcQWYokD=OQrWd_D_Y7Kmkmej1HJORfyxJ9uxQ@mail.gmail.com>
Message-ID: <24EAAD82-74C6-4641-88BB-A5EFE10C2E4D@tagtraum.com>

On Apr 30, 2013, at 2:09 AM, Scott Palmer wrote:

> Keep in mind that all this effort to support Swing JButton images or
> whatever is really only going to be useful for backward compatiblity with
> Swing.  All of the development effort at Oracle appears to be targeting
> JavaFX. Therefore if a solution requires API changes to Swing, it is mostly
> a waste of time.  JavaFX is the way forward and that is where the
> development effort will be concentrated.
> As far as I can tell, Swing is in maintenance mode... I doubt any
> new development will happen in Swing with the exception of security issues
> and bug fixes.

Providing multi-resolution images and a Graphics2D that honors them is actually not very Swing specific. It's AWT.
JButton is just an example..

-hendrik

From krueger at lesspain.de  Tue Apr 30 01:13:22 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Tue, 30 Apr 2013 10:13:22 +0200
Subject: JLabel preferred size incorrect on retina displays when other than
	default font size is used
Message-ID: <CAEnqZEV3rwFXRGmqA92ncFZjZEzVsX=PKYk6sx0eGqF5e_Ur+g@mail.gmail.com>

Hi,

when running the following code on a retina display and on a non-retina,
you will see the problem:


import java.awt.Container;
import java.awt.FlowLayout;
import java.awt.Font;

import javax.swing.BorderFactory;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.WindowConstants;

public class JLabelDemo {

    public static void main(String[] args) {

        JFrame frame = new JFrame("JLabel Demo");
        Container contentPane = frame.getContentPane();
        contentPane.setLayout(new FlowLayout());
        final JLabel label = new JLabel(
                "This is a monstrous mmmmmega label text which will not
fit");
        label.setBorder(BorderFactory.createEtchedBorder());
        label.setFont(new Font(label.getFont().getName(),
label.getFont().getStyle(), 11));
        contentPane.add(label);
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        frame.pack();
        frame.setVisible(true);

    }

}


On retina the text will be cut off because the preferred width calculation
appears to be wrong. When connecting a retina MBP to a non-retina monitor
it is also possible to drag the frame between the two windows and see how
the text is cut off on one and isn't on the other.

This happens with OpenJDK 8 from recent source (a week ago) and doesn't
with JDK7u21 (which does not have hires graphics support). Note that it
also happens with Apple's JDK6.

Is this a known issue or should I submit a bug report?

From Sergey.Bylokhov at oracle.com  Tue Apr 30 02:45:07 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Apr 2013 13:45:07 +0400
Subject: JLabel preferred size incorrect on retina displays when other
	than default font size is used
In-Reply-To: <CAEnqZEV3rwFXRGmqA92ncFZjZEzVsX=PKYk6sx0eGqF5e_Ur+g@mail.gmail.com>
References: <CAEnqZEV3rwFXRGmqA92ncFZjZEzVsX=PKYk6sx0eGqF5e_Ur+g@mail.gmail.com>
Message-ID: <517F92A3.1010109@oracle.com>

Hi, Robert.
On 30.04.2013 12:13, Robert Kr?ger wrote:
> Is this a known issue or should I submit a bug report?
This is an unknown problem. Submita new bug report.
Thanks.

-- 
Best regards, Sergey.


From krueger at lesspain.de  Tue Apr 30 04:19:36 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Tue, 30 Apr 2013 13:19:36 +0200
Subject: JLabel preferred size incorrect on retina displays when other
	than default font size is used
In-Reply-To: <517F92A3.1010109@oracle.com>
References: <CAEnqZEV3rwFXRGmqA92ncFZjZEzVsX=PKYk6sx0eGqF5e_Ur+g@mail.gmail.com>
	<517F92A3.1010109@oracle.com>
Message-ID: <CAEnqZEVQOq=enB-3O2n1yRwXWHKgwmiQzgwSQw8siW9Qfuj-Zw@mail.gmail.com>

OK, it is now

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9002202


On Tue, Apr 30, 2013 at 11:45 AM, Sergey Bylokhov <
Sergey.Bylokhov at oracle.com> wrote:

> Hi, Robert.
>
> On 30.04.2013 12:13, Robert Kr?ger wrote:
>
>> Is this a known issue or should I submit a bug report?
>>
> This is an unknown problem. Submita new bug report.
> Thanks.
>
> --
> Best regards, Sergey.
>
>

From swpalmer at gmail.com  Tue Apr 30 04:19:42 2013
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 30 Apr 2013 07:19:42 -0400
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <24EAAD82-74C6-4641-88BB-A5EFE10C2E4D@tagtraum.com>
References: <CAEvuJbbXWmUpn2AigeO=wbFhrh83XfUqK1Kxi+oosVV0AgN_2Q@mail.gmail.com>
	<CAL3e5iFZi+BhGcQWYokD=OQrWd_D_Y7Kmkmej1HJORfyxJ9uxQ@mail.gmail.com>
	<24EAAD82-74C6-4641-88BB-A5EFE10C2E4D@tagtraum.com>
Message-ID: <265E3AE7-C65A-44DE-AB93-D13FC6257AD5@gmail.com>

On 2013-04-30, at 2:58 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:

> On Apr 30, 2013, at 2:09 AM, Scott Palmer wrote:
> 
>> Keep in mind that all this effort to support Swing JButton images or
>> whatever is really only going to be useful for backward compatiblity with
>> Swing.  All of the development effort at Oracle appears to be targeting
>> JavaFX. Therefore if a solution requires API changes to Swing, it is mostly
>> a waste of time.  JavaFX is the way forward and that is where the
>> development effort will be concentrated.
>> As far as I can tell, Swing is in maintenance mode... I doubt any
>> new development will happen in Swing with the exception of security issues
>> and bug fixes.
> 
> Providing multi-resolution images and a Graphics2D that honors them is actually not very Swing specific. It's AWT.
> JButton is just an example..
> 
> -hendrik

AWT isn't used by JavaFX either.  I'm not suggesting the issue of resolution dependence doesn't need to be addressed. I'm just pointing out that it is far more likely to get addressed in JavaFX APIs.

Scott


From hs at tagtraum.com  Tue Apr 30 04:22:13 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 30 Apr 2013 13:22:13 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <265E3AE7-C65A-44DE-AB93-D13FC6257AD5@gmail.com>
References: <CAEvuJbbXWmUpn2AigeO=wbFhrh83XfUqK1Kxi+oosVV0AgN_2Q@mail.gmail.com>
	<CAL3e5iFZi+BhGcQWYokD=OQrWd_D_Y7Kmkmej1HJORfyxJ9uxQ@mail.gmail.com>
	<24EAAD82-74C6-4641-88BB-A5EFE10C2E4D@tagtraum.com>
	<265E3AE7-C65A-44DE-AB93-D13FC6257AD5@gmail.com>
Message-ID: <8E993728-82B7-49A7-BD6A-7CB1633701D7@tagtraum.com>


On Apr 30, 2013, at 1:19 PM, Scott Palmer wrote:

>> 
>> Providing multi-resolution images and a Graphics2D that honors them is actually not very Swing specific. It's AWT.
>> JButton is just an example..
>> 
>> -hendrik
> 
> AWT isn't used by JavaFX either.  I'm not suggesting the issue of resolution dependence doesn't need to be addressed. I'm just pointing out that it is far more likely to get addressed in JavaFX APIs.

Point taken. I and fear you are correct.

-hendrik

From superstippi at gmx.de  Tue Apr 30 06:00:55 2013
From: superstippi at gmx.de (=?ISO-8859-1?Q?Stephan_A=DFmus?=)
Date: Tue, 30 Apr 2013 15:00:55 +0200
Subject: How will resolution independence be handled in jdk8?
In-Reply-To: <265E3AE7-C65A-44DE-AB93-D13FC6257AD5@gmail.com>
References: <CAEvuJbbXWmUpn2AigeO=wbFhrh83XfUqK1Kxi+oosVV0AgN_2Q@mail.gmail.com>
	<CAL3e5iFZi+BhGcQWYokD=OQrWd_D_Y7Kmkmej1HJORfyxJ9uxQ@mail.gmail.com>
	<24EAAD82-74C6-4641-88BB-A5EFE10C2E4D@tagtraum.com>
	<265E3AE7-C65A-44DE-AB93-D13FC6257AD5@gmail.com>
Message-ID: <517FC087.8070109@gmx.de>

Am 30.04.2013 13:19, schrieb Scott Palmer:
> On 2013-04-30, at 2:58 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:
>> On Apr 30, 2013, at 2:09 AM, Scott Palmer wrote:
>>> Keep in mind that all this effort to support Swing JButton images or
>>> whatever is really only going to be useful for backward compatiblity with
>>> Swing.  All of the development effort at Oracle appears to be targeting
>>> JavaFX. Therefore if a solution requires API changes to Swing, it is mostly
>>> a waste of time.  JavaFX is the way forward and that is where the
>>> development effort will be concentrated.
>>> As far as I can tell, Swing is in maintenance mode... I doubt any
>>> new development will happen in Swing with the exception of security issues
>>> and bug fixes.
>>
>> Providing multi-resolution images and a Graphics2D that honors them is actually not very Swing specific. It's AWT.
>> JButton is just an example..
>>
>> -hendrik
>
> AWT isn't used by JavaFX either.  I'm not suggesting the issue of resolution dependence doesn't need to be addressed. I'm just pointing out that it is far more likely to get addressed in JavaFX APIs.

What's unfortunate is that the API is already present in AWT. See 
Graphics2D.getDeviceConfiguration() and and 
GraphicsConfiguration.getNormalizingTransform().

This is the introduction to Graphics2D:

"When creating a Graphics2D object, the GraphicsConfiguration specifies 
the default transform for the target of the Graphics2D (a Component or 
Image). [...] The scaling of the default transform is set to identity 
for those devices that are close to 72 dpi, such as screen devices. The 
scaling of the default transform is set to approximately 72 user space 
coordinates per square inch for high resolution devices, such as 
printers. For image buffers, the default transform is the Identity 
transform."

There doesn't need to be any new APIs it would seem. All that's needed 
is that screens don't get the identity transform regardless of their 
actual resolution, even when it is far, far away from 72 units per inch.

With the notion of "user space" coordinates versus "device space" 
coordinates, AWT always has been "resolution independent"

That being said, I am aware that it can be problematic if the majority 
of applications assumes "unit == pixel". But from my own very limited 
experience when trying to work with AWT, my expectation was that it 
would work exactly like advertised. But I was disappointed to find out 
an identity transform is always used for screens regardless.

Best regards,
-Stephan


From swingler at apple.com  Tue Apr 30 08:03:39 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 30 Apr 2013 08:03:39 -0700
Subject: Splash screen border
In-Reply-To: <517E5E9C.9050102@oracle.com>
References: <CAEnqZEXwe6P02Lp_n1jxAGmTEw01zgverf6xQTPHF=DjmxF5-A@mail.gmail.com>
	<517E5E9C.9050102@oracle.com>
Message-ID: <D8A7EC03-7FBA-41B8-9DFC-342F5A3290EA@apple.com>

Are you talking about a stroked line border, or the shadow put on the window by the OS?

Regards,
Mike Swingler
Apple Inc.

On Apr 29, 2013, at 4:50 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Robert,
> 
> OpenJDK has never displayed a border for splash screens on any platforms. This is because a splash screen image may not be rectangular, may be colored differently in various applications, or even be semi-transparent. Showing a solid rectangular border around it might not look good in all cases.
> 
> When porting OpenJDK to the Mac platform we decided to keep this behavior in order to allow Java applications to look the same on all platforms supported by OpenJDK. If your application requires a border around your splash screen, then you should update the images you use to display the splash screen.
> 
> --
> best regards,
> Anthony
> 
> On 04/27/13 15:58, Robert Kr?ger wrote:
>> Hi,
>> 
>> there is a difference between JDK6 (Apple) and OpenJDK8. The splash screen
>> has a border when starting with the Apple JDK and it has not for OpenJDK.
>> Of course, this is really easy to work around by adding the border to the
>> splash screen image. I would only like to know if this is a conscious
>> decision or an oversight (maybe even with a bug id that I can track) or if
>> I should do anything differently (like setting a parameter somewhere).
>> 
>> Thanks,
>> 
>> Robert


From superstippi at gmx.de  Tue Apr 30 08:19:13 2013
From: superstippi at gmx.de (=?iso-8859-1?Q?Stephan_A=DFmus?=)
Date: Tue, 30 Apr 2013 17:19:13 +0200
Subject: Splash screen border
In-Reply-To: <D8A7EC03-7FBA-41B8-9DFC-342F5A3290EA@apple.com>
References: <CAEnqZEXwe6P02Lp_n1jxAGmTEw01zgverf6xQTPHF=DjmxF5-A@mail.gmail.com>
	<517E5E9C.9050102@oracle.com>
	<D8A7EC03-7FBA-41B8-9DFC-342F5A3290EA@apple.com>
Message-ID: <AE261E13-0133-4ADD-9B83-54753BDFF1B8@gmx.de>

Hi,

Am 30.04.2013 um 17:03 schrieb Mike Swingler <swingler at apple.com>:
> Are you talking about a stroked line border, or the shadow put on the window by the OS?

I can confirm that the Apple Java SE 6 puts a single pixel wide border around the splash-screen with an additional drop-shadow.

Best regards,
-Stephan

> On Apr 29, 2013, at 4:50 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> OpenJDK has never displayed a border for splash screens on any platforms. This is because a splash screen image may not be rectangular, may be colored differently in various applications, or even be semi-transparent. Showing a solid rectangular border around it might not look good in all cases.
>> 
>> When porting OpenJDK to the Mac platform we decided to keep this behavior in order to allow Java applications to look the same on all platforms supported by OpenJDK. If your application requires a border around your splash screen, then you should update the images you use to display the splash screen.
>> 
>> On 04/27/13 15:58, Robert Kr?ger wrote:
>>> there is a difference between JDK6 (Apple) and OpenJDK8. The splash screen
>>> has a border when starting with the Apple JDK and it has not for OpenJDK.
>>> Of course, this is really easy to work around by adding the border to the
>>> splash screen image. I would only like to know if this is a conscious
>>> decision or an oversight (maybe even with a bug id that I can track) or if
>>> I should do anything differently (like setting a parameter somewhere).



From swingler at apple.com  Tue Apr 30 08:24:11 2013
From: swingler at apple.com (Mike Swingler)
Date: Tue, 30 Apr 2013 08:24:11 -0700
Subject: Splash screen border
In-Reply-To: <AE261E13-0133-4ADD-9B83-54753BDFF1B8@gmx.de>
References: <CAEnqZEXwe6P02Lp_n1jxAGmTEw01zgverf6xQTPHF=DjmxF5-A@mail.gmail.com>
	<517E5E9C.9050102@oracle.com>
	<D8A7EC03-7FBA-41B8-9DFC-342F5A3290EA@apple.com>
	<AE261E13-0133-4ADD-9B83-54753BDFF1B8@gmx.de>
Message-ID: <4C4BA160-4CAD-44FA-8567-60EE49984B54@apple.com>

On Apr 30, 2013, at 8:19 AM, Stephan A?mus <superstippi at gmx.de> wrote:

> Hi,
> 
> Am 30.04.2013 um 17:03 schrieb Mike Swingler <swingler at apple.com>:
>> Are you talking about a stroked line border, or the shadow put on the window by the OS?
> 
> I can confirm that the Apple Java SE 6 puts a single pixel wide border around the splash-screen with an additional drop-shadow.

That single line is actually 50% transparent, and effectively part of the shadow drawn by the OS - so, it may be worth requesting that the standard OS window shadow be applied to the window.

>> On Apr 29, 2013, at 4:50 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>> OpenJDK has never displayed a border for splash screens on any platforms. This is because a splash screen image may not be rectangular, may be colored differently in various applications, or even be semi-transparent. Showing a solid rectangular border around it might not look good in all cases.
>>> 
>>> When porting OpenJDK to the Mac platform we decided to keep this behavior in order to allow Java applications to look the same on all platforms supported by OpenJDK. If your application requires a border around your splash screen, then you should update the images you use to display the splash screen.
>>> 
>>> On 04/27/13 15:58, Robert Kr?ger wrote:
>>>> there is a difference between JDK6 (Apple) and OpenJDK8. The splash screen
>>>> has a border when starting with the Apple JDK and it has not for OpenJDK.
>>>> Of course, this is really easy to work around by adding the border to the
>>>> splash screen image. I would only like to know if this is a conscious
>>>> decision or an oversight (maybe even with a bug id that I can track) or if
>>>> I should do anything differently (like setting a parameter somewhere).

Regards,
Mike Swingler
Apple Inc.


From anthony.petrov at oracle.com  Tue Apr 30 09:20:31 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 30 Apr 2013 20:20:31 +0400
Subject: Splash screen border
In-Reply-To: <4C4BA160-4CAD-44FA-8567-60EE49984B54@apple.com>
References: <CAEnqZEXwe6P02Lp_n1jxAGmTEw01zgverf6xQTPHF=DjmxF5-A@mail.gmail.com>
	<517E5E9C.9050102@oracle.com>
	<D8A7EC03-7FBA-41B8-9DFC-342F5A3290EA@apple.com>
	<AE261E13-0133-4ADD-9B83-54753BDFF1B8@gmx.de>
	<4C4BA160-4CAD-44FA-8567-60EE49984B54@apple.com>
Message-ID: <517FEF4F.9050403@oracle.com>

Indeed, OpenJDK doesn't call setHasShadow:YES for the window that 
displays a splash screen.

Please feel free to file an RFE at http://bugs.sun.com (or go ahead, fix 
this issue, and post your patch here for a review).

--
best regards,
Anthony

On 04/30/2013 07:24 PM, Mike Swingler wrote:
> On Apr 30, 2013, at 8:19 AM, Stephan A?mus <superstippi at gmx.de> wrote:
>
>> Hi,
>>
>> Am 30.04.2013 um 17:03 schrieb Mike Swingler <swingler at apple.com>:
>>> Are you talking about a stroked line border, or the shadow put on the window by the OS?
>>
>> I can confirm that the Apple Java SE 6 puts a single pixel wide border around the splash-screen with an additional drop-shadow.
>
> That single line is actually 50% transparent, and effectively part of the shadow drawn by the OS - so, it may be worth requesting that the standard OS window shadow be applied to the window.
>
>>> On Apr 29, 2013, at 4:50 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>> OpenJDK has never displayed a border for splash screens on any platforms. This is because a splash screen image may not be rectangular, may be colored differently in various applications, or even be semi-transparent. Showing a solid rectangular border around it might not look good in all cases.
>>>>
>>>> When porting OpenJDK to the Mac platform we decided to keep this behavior in order to allow Java applications to look the same on all platforms supported by OpenJDK. If your application requires a border around your splash screen, then you should update the images you use to display the splash screen.
>>>>
>>>> On 04/27/13 15:58, Robert Kr?ger wrote:
>>>>> there is a difference between JDK6 (Apple) and OpenJDK8. The splash screen
>>>>> has a border when starting with the Apple JDK and it has not for OpenJDK.
>>>>> Of course, this is really easy to work around by adding the border to the
>>>>> splash screen image. I would only like to know if this is a conscious
>>>>> decision or an oversight (maybe even with a bug id that I can track) or if
>>>>> I should do anything differently (like setting a parameter somewhere).
>
> Regards,
> Mike Swingler
> Apple Inc.
>