From hs at tagtraum.com  Thu May  2 03:55:33 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 2 May 2013 12:55:33 +0200
Subject: apple.awt.documentModalSheet - support for sheets?
Message-ID: <EC45B86E-F48F-46F2-BC2B-19DEBAFB3E1A@tagtraum.com>

Hi,

does anybody know, whether Java7 will eventually honor the "apple.awt.documentModalSheet" swing property for showing dialogs as sheets?
Currently it leads to "broken" behavior: http://bugs.sun.com/view_bug.do?bug_id=8010197

Thanks,

-hendrik

From Sergey.Bylokhov at oracle.com  Thu May  2 14:48:22 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 03 May 2013 01:48:22 +0400
Subject: [8] Request for review: 8013841 [macosx] Animations not disabled
	for CALayers used via JAWT
Message-ID: <5182DF26.4040607@oracle.com>

Hello, please review the fix for jdk 8.

Report about the problem:
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005572.html

In the fix, live-resize animation was disabled, just to be backward 
compatible with jdk6.

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

-- 
Best regards, Sergey.


From terry at trwarren.com  Sun May  5 12:11:37 2013
From: terry at trwarren.com (Terry Warren)
Date: Sun, 5 May 2013 12:11:37 -0700
Subject: appbundle
Message-ID: <BAD8D45F-C64C-4CFA-95FF-355B397C162A@trwarren.com>

Hi -

I am trying to do something that I thought would be very simple: create a mac os x app bundle using the oracle appbundler-1.0.jar file. The project was created and built via Netbeans IDE with the appbundler jarfile copied into a directory named libs in the main project directory along with a simple .xml script based on the documentation for using the appbundler. I am using the latest oracle jdk for mac and mac os x version is 10.8.3. When I run the script (either via commandline after changing into the project directory) or via Netbeans IDE, it fails with the message:

taskdef A class needed by class com.oracle.appbundler.AppBundlerTask cannot be found: org/apache/tools/ant/Task
 using the classloader AntClassLoader[/Users/twarren/NetBeansProjects/Sample2/libs/appbundler-1.0.jar]

(the directory listed above in the second line is the correct one for the jarfile)

The script is (located in file bundleApp.xml):

<project name="AppBundle" default="default" basedir=".">
    <description>Builds app Bundle for project Sample2.</description>
    
<taskdef
    name="bundleapp"
    classname="com.oracle.appbundler.AppBundlerTask"
    classpath="libs/appbundler-1.0.jar" />

<target name="bundle">
        <bundleapp outputdirectory="${user.home}/Desktop/Builds"
            name="PuzzleViewer"
            displayname="Java Puzzle Viewer"
            identifier="sample2.JPuzzleViewer"
            shortversion="1.2.5"
            copyright="Copyright 2013 - Terry Warren. All rights reserved."
            applicationCategory="public.app-category.puzzle-gamess"
            icon="${user.home}/Desktop/builds/icons/puzzleviewer/puzzleviewer.icns"
            mainClassName="sample2/JPuzzleViewer">
            <classpath file="dist/Sample2.jar"/>
            <option value="-Dapple.laf.useScreenMenuBar=true"/>
        </bundleapp>
</target> 
</project>

command line invocation: ant -f bundleApp.xml bundle 

I would appreciate any thoughts as to why this won't work.

thanks
Terry Warren



From mik3hall at gmail.com  Sun May  5 16:19:19 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 5 May 2013 18:19:19 -0500
Subject: appbundle
In-Reply-To: <BAD8D45F-C64C-4CFA-95FF-355B397C162A@trwarren.com>
References: <BAD8D45F-C64C-4CFA-95FF-355B397C162A@trwarren.com>
Message-ID: <8A6F0CDF-94A6-4CE9-8FEB-A9EB18DB8EC8@gmail.com>

On May 5, 2013, at 2:11 PM, Terry Warren wrote:

> taskdef A class needed by class com.oracle.appbundler.AppBundlerTask cannot be found: org/apache/tools/ant/Task
> using the classloader AntClassLoader[/Users/twarren/NetBeansProjects/Sample2/libs/appbundler-1.0.jar]
> 
> (the directory listed above in the second line is the correct one for the jarfile)
> 
> The script is (located in file bundleApp.xml):
> 
> <project name="AppBundle" default="default" basedir=".">
>    <description>Builds app Bundle for project Sample2.</description>
> 
> <taskdef
>    name="bundleapp"
>    classname="com.oracle.appbundler.AppBundlerTask"
>    classpath="libs/appbundler-1.0.jar" />

jar -tvf libs/appbundler-1.0.jar | grep AppBundlerTask 
shows what?

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 artem.ananiev at oracle.com  Mon May  6 02:46:17 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 06 May 2013 13:46:17 +0400
Subject: [8] Request for review: 7161575 [macosx] On MacOSX port
	java.awt.Toolkit.is/setDynamicLayout() are not consistent
In-Reply-To: <51769FF3.10108@oracle.com>
References: <51768A0D.7000405@oracle.com> <51769FF3.10108@oracle.com>
Message-ID: <51877BE9.20803@oracle.com>


Looks fine to me as well.

Thanks,

Artem

On 4/23/2013 6:51 PM, Anthony Petrov wrote:
> 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 hs at tagtraum.com  Mon May  6 05:09:22 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 6 May 2013 14:09:22 +0200
Subject: apple.awt.documentModalSheet - support for sheets?
In-Reply-To: <EC45B86E-F48F-46F2-BC2B-19DEBAFB3E1A@tagtraum.com>
References: <EC45B86E-F48F-46F2-BC2B-19DEBAFB3E1A@tagtraum.com>
Message-ID: <EE21F91B-7C43-4236-8BDD-7513031E59AA@tagtraum.com>

On May 2, 2013, at 12:55 PM, Hendrik Schreiber wrote:

> does anybody know, whether Java7 will eventually honor the "apple.awt.documentModalSheet" swing property for showing dialogs as sheets?
> Currently it leads to "broken" behavior: http://bugs.sun.com/view_bug.do?bug_id=8010197

Nobody knows this?

-hendrik

From Sergey.Bylokhov at oracle.com  Mon May  6 05:32:46 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 06 May 2013 16:32:46 +0400
Subject: apple.awt.documentModalSheet - support for sheets?
In-Reply-To: <EE21F91B-7C43-4236-8BDD-7513031E59AA@tagtraum.com>
References: <EC45B86E-F48F-46F2-BC2B-19DEBAFB3E1A@tagtraum.com>
	<EE21F91B-7C43-4236-8BDD-7513031E59AA@tagtraum.com>
Message-ID: <5187A2EE.30303@oracle.com>

Hi, Hendrik.
This bug is assigned to me, but I still didn't look at it and have no 
information when it can be fixed.
But, if anyone wants to contribute a patch - you're very welcome.

On 06.05.2013 16:09, Hendrik Schreiber wrote:
> On May 2, 2013, at 12:55 PM, Hendrik Schreiber wrote:
>
>> does anybody know, whether Java7 will eventually honor the "apple.awt.documentModalSheet" swing property for showing dialogs as sheets?
>> Currently it leads to "broken" behavior: http://bugs.sun.com/view_bug.do?bug_id=8010197
> Nobody knows this?
>
> -hendrik


-- 
Best regards, Sergey.


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

I just submitted another bug report that looks related (9002404
Cursor Position in JTextfield wrong for non-default font size on retina
displays). This one is more severe as I cannot think of a workaround.


On Tue, Apr 30, 2013 at 1:19 PM, Robert Kr?ger <krueger at lesspain.de> wrote:

> 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 david.holmes at oracle.com  Tue May  7 04:54:21 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 07 May 2013 21:54:21 +1000
Subject: Exporting symbols on OSX ?
Message-ID: <5188EB6D.7050100@oracle.com>

We just discovered that every symbol is libjvm is being exported on OSX. 
The OSX/BSD makefiles were copied from the linux ones and so have the 
options for linker scripts and mapfiles, but as OSX doesn't support 
linker scripts this is disabled by setting LDNOMAP=true - hence all 
symbols are exported.

However the OSX linker does support -exported_symbols_list

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html

so I was wondering why the build wasn't modified to use that so that we 
only export the JVM symbols we intend to export? (That's a question for 
the macosx-port-dev folk :) ).

Does anyone have experience using this such that we can get the hotspot 
build fixed?

Thanks,
David

From hs at tagtraum.com  Tue May  7 04:54:43 2013
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 7 May 2013 13:54:43 +0200
Subject: apple.awt.documentModalSheet - support for sheets?
In-Reply-To: <5187A2EE.30303@oracle.com>
References: <EC45B86E-F48F-46F2-BC2B-19DEBAFB3E1A@tagtraum.com>
	<EE21F91B-7C43-4236-8BDD-7513031E59AA@tagtraum.com>
	<5187A2EE.30303@oracle.com>
Message-ID: <E22390DF-D194-49A9-AAFB-04328C094D4E@tagtraum.com>

On May 6, 2013, at 2:32 PM, Sergey Bylokhov wrote:

> This bug is assigned to me, but I still didn't look at it and have no information when it can be fixed.
> But, if anyone wants to contribute a patch - you're very welcome.

Thanks, Sergey, for the feedback.

So this is still on the todo list, though understandably not very high.
I'd also appreciate, if some generous and knowledgable person finds the time to fix this and contributes the fix.

Thank you.

-hendrik

From alexandr.scherbatiy at oracle.com  Tue May  7 06:47:32 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 07 May 2013 17:47:32 +0400
Subject: <AWT Dev> [8] Request for review: 8013841 [macosx] Animations
	not disabled for CALayers used via JAWT
In-Reply-To: <5182DF26.4040607@oracle.com>
References: <5182DF26.4040607@oracle.com>
Message-ID: <518905F4.2010504@oracle.com>


   The fix looks good for me.

   Thanks,
   Alexandr.

On 5/3/2013 1:48 AM, Sergey Bylokhov wrote:
> Hello, please review the fix for jdk 8.
>
> Report about the problem:
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005572.html 
>
>
> In the fix, live-resize animation was disabled, just to be backward 
> compatible with jdk6.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013841
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8013841/webrev.00
>


From david.dehaven at oracle.com  Tue May  7 09:55:04 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 7 May 2013 09:55:04 -0700
Subject: Exporting symbols on OSX ?
In-Reply-To: <5188EB6D.7050100@oracle.com>
References: <5188EB6D.7050100@oracle.com>
Message-ID: <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com>


> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported.
> 
> However the OSX linker does support -exported_symbols_list
> 
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html
> 
> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ).
> 
> Does anyone have experience using this such that we can get the hotspot build fixed?

Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling.

Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not.

-DrD-


From daniel.daugherty at oracle.com  Tue May  7 10:05:01 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 07 May 2013 11:05:01 -0600
Subject: Exporting symbols on OSX ?
In-Reply-To: <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com>
References: <5188EB6D.7050100@oracle.com>
	<4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com>
Message-ID: <5189343D.10403@oracle.com>


On 5/7/13 10:55 AM, David DeHaven wrote:
>> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported.
>>
>> However the OSX linker does support -exported_symbols_list
>>
>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html
>>
>> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ).
>>
>> Does anyone have experience using this such that we can get the hotspot build fixed?
> Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling.
>
> Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not.
>
> -DrD-
>
The HotSpot fix is being reviewed on hotspot-runtime-dev at openjdk.java.net
under the following subject line:

Review request for JDK-8009729: Refix hotspot jni_<cpu>.h JNIEXPORT and 
JNIIMPORT definitions to match jdk version

Dan

From david.dehaven at oracle.com  Tue May  7 11:12:12 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 7 May 2013 11:12:12 -0700
Subject: Exporting symbols on OSX ?
In-Reply-To: <5189343D.10403@oracle.com>
References: <5188EB6D.7050100@oracle.com>
	<4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com>
	<5189343D.10403@oracle.com>
Message-ID: <CFEEDBFC-8963-4772-B2FA-AE190495A95E@oracle.com>


>>> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported.
>>> 
>>> However the OSX linker does support -exported_symbols_list
>>> 
>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html
>>> 
>>> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ).
>>> 
>>> Does anyone have experience using this such that we can get the hotspot build fixed?
>> Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling.
>> 
>> Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not.
>> 
>> -DrD-
>> 
> The HotSpot fix is being reviewed on hotspot-runtime-dev at openjdk.java.net
> under the following subject line:
> 
> Review request for JDK-8009729: Refix hotspot jni_<cpu>.h JNIEXPORT and JNIIMPORT definitions to match jdk version

Ok, good. The next step would be to modify the build system to set -fvisibility=hidden in the CFLAGS. There were a couple issues in jdk with this, but they should be easily resolved (some might have been already along with the JNIEXPORT patch). (Insert standard disclaimer of needing a full round of SQE testing, etc, so on and so forth, yadda yadda yadda...)

I'm curious how much this will shrink the JRE image... two level namespace symbols can take up quite a bit of space.

-DrD-


From anthony.petrov at oracle.com  Tue May  7 12:46:38 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 07 May 2013 23:46:38 +0400
Subject: [8] Request for review: 8013841 [macosx] Animations not disabled
	for CALayers used via JAWT
In-Reply-To: <5182DF26.4040607@oracle.com>
References: <5182DF26.4040607@oracle.com>
Message-ID: <51895A1E.9000906@oracle.com>

Hi Sergey,

The code changes look good to me.

--
best regards,
Anthony

On 05/03/2013 01:48 AM, Sergey Bylokhov wrote:
> Hello, please review the fix for jdk 8.
>
> Report about the problem:
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005572.html
>
>
> In the fix, live-resize animation was disabled, just to be backward
> compatible with jdk6.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013841
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8013841/webrev.00
>

From david.holmes at oracle.com  Tue May  7 16:00:33 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 08 May 2013 09:00:33 +1000
Subject: Exporting symbols on OSX ?
In-Reply-To: <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com>
References: <5188EB6D.7050100@oracle.com>
	<4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com>
Message-ID: <51898791.1090305@oracle.com>

On 8/05/2013 2:55 AM, David DeHaven wrote:
>
>> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported.
>>
>> However the OSX linker does support -exported_symbols_list
>>
>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html
>>
>> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ).
>>
>> Does anyone have experience using this such that we can get the hotspot build fixed?
>
> Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling.
>
> Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not.

The visibility setting changes should aid with the primary exported 
interfaces (JNI_ and JVM_) but looking at the build there are other 
symbols (for Serviceability Agent I think) that get dynamically added to 
the mapfiles - so I'm not sure if the visibility setting alone will help 
here. I think we will still want the "exported_symbol_file" (but it 
seems whatever ld we are using for OSX builds doesn't actually recognize 
that option ?? :(  Or I'm doing something wrong in trying to pass it)

Thanks,
David

> -DrD-
>

From david.dehaven at oracle.com  Tue May  7 16:53:49 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 7 May 2013 16:53:49 -0700
Subject: Exporting symbols on OSX ?
In-Reply-To: <51898791.1090305@oracle.com>
References: <5188EB6D.7050100@oracle.com>
	<4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com>
	<51898791.1090305@oracle.com>
Message-ID: <4FF40AC6-E30A-4D5D-9115-D68206954247@oracle.com>


>>> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported.
>>> 
>>> However the OSX linker does support -exported_symbols_list
>>> 
>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html
>>> 
>>> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ).
>>> 
>>> Does anyone have experience using this such that we can get the hotspot build fixed?
>> 
>> Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling.
>> 
>> Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not.
> 
> The visibility setting changes should aid with the primary exported interfaces (JNI_ and JVM_) but looking at the build there are other symbols (for Serviceability Agent I think) that get dynamically added to the mapfiles - so I'm not sure if the visibility setting alone will help here. I think we will still want the "exported_symbol_file" (but it seems whatever ld we are using for OSX builds doesn't actually recognize that option ?? :(  Or I'm doing something wrong in trying to pass it)

Apple's ld supports "-exported_symbols_list filename" which is similar to (but not the same as) export map files for GNU ld. I don't know if the use of that argument overrides the -fvisibility setting though. Some minor experimentation should provide answers to that question...

Can those symbols just be marked with JNIEXPORT or some similar macro?

-DrD-


From Sergey.Bylokhov at oracle.com  Wed May  8 05:14:50 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 08 May 2013 16:14:50 +0400
Subject: JLabel preferred size incorrect on retina displays when other
	than default font size is used
In-Reply-To: <CAEnqZEX6Mfi7b62k5rAGWh+LiAaS5FWeqapaLAjt56mWPRq5Eg@mail.gmail.com>
References: <CAEnqZEV3rwFXRGmqA92ncFZjZEzVsX=PKYk6sx0eGqF5e_Ur+g@mail.gmail.com>
	<517F92A3.1010109@oracle.com>
	<CAEnqZEVQOq=enB-3O2n1yRwXWHKgwmiQzgwSQw8siW9Qfuj-Zw@mail.gmail.com>
	<CAEnqZEX6Mfi7b62k5rAGWh+LiAaS5FWeqapaLAjt56mWPRq5Eg@mail.gmail.com>
Message-ID: <518A41BA.9090707@oracle.com>

Hi, Robert.
Thanks for the report, you can track status of this CR here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014069

On 07.05.2013 14:55, Robert Kr?ger wrote:
> I just submitted another bug report that looks related (9002404
> Cursor Position in JTextfield wrong for non-default font size on 
> retina displays). This one is more severe as I cannot think of a 
> workaround.
>
>
> On Tue, Apr 30, 2013 at 1:19 PM, Robert Kr?ger <krueger at lesspain.de 
> <mailto:krueger at lesspain.de>> wrote:
>
>     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 <mailto: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.
>
>
>


-- 
Best regards, Sergey.


From krueger at lesspain.de  Wed May  8 06:12:38 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 8 May 2013 15:12:38 +0200
Subject: JLabel preferred size incorrect on retina displays when other
	than default font size is used
In-Reply-To: <518A4C15.3090609@oracle.com>
References: <CAEnqZEV3rwFXRGmqA92ncFZjZEzVsX=PKYk6sx0eGqF5e_Ur+g@mail.gmail.com>
	<517F92A3.1010109@oracle.com>
	<CAEnqZEVQOq=enB-3O2n1yRwXWHKgwmiQzgwSQw8siW9Qfuj-Zw@mail.gmail.com>
	<CAEnqZEX6Mfi7b62k5rAGWh+LiAaS5FWeqapaLAjt56mWPRq5Eg@mail.gmail.com>
	<518A41BA.9090707@oracle.com>
	<CAEnqZEUKz6HjCuNoXsd6uOKAsUatAv-5spF_qwcLSekZb7ONew@mail.gmail.com>
	<518A4C15.3090609@oracle.com>
Message-ID: <CAEnqZEVih7LouaFT1Eq4NQ0arMB2_TOOy8yGjYCHCg6NzrsXKw@mail.gmail.com>

ah, great!

Thanks again,

Robert


On Wed, May 8, 2013 at 2:59 PM, Sergey Bylokhov
<Sergey.Bylokhov at oracle.com>wrote:

>  On 08.05.2013 16:52, Robert Kr?ger wrote:
>
> Hi Sergey,
>
>  thanks a lot!
>
>  Any particular reason 9002202 is still not visible? Is this still being
> evaluated?
>
> Yes, it was evaluated and now it:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013569
>
>
>  Cheers,
>
>  Robert
>
>
> On Wed, May 8, 2013 at 2:14 PM, Sergey Bylokhov <
> Sergey.Bylokhov at oracle.com> wrote:
>
>>  Hi, Robert.
>> Thanks for the report, you can track status of this CR here:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014069
>>
>>
>> On 07.05.2013 14:55, Robert Kr?ger wrote:
>>
>> I just submitted another bug report that looks related (9002404
>> Cursor Position in JTextfield wrong for non-default font size on retina
>> displays). This one is more severe as I cannot think of a workaround.
>>
>>
>> On Tue, Apr 30, 2013 at 1:19 PM, Robert Kr?ger <krueger at lesspain.de>wrote:
>>
>>> 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.
>>>>
>>>>
>>>
>>
>>
>>   --
>> Best regards, Sergey.
>>
>>
>
>
> --
> Best regards, Sergey.
>
>

From java3 at segal.org  Thu May  9 06:55:44 2013
From: java3 at segal.org (Mickey Segal)
Date: Thu, 9 May 2013 09:55:44 -0400
Subject: Intermittent display problems in JRE 7
Message-ID: <000601ce4cbc$e725a650$b570f2f0$@segal.org>

I?m new to this group, but have been a member of Apple?s Java-Dev group since the late 1990s.  The Macintosh users of our large medical diagnosis applet have begun pointing out intermittent display problems in JRE 7, and we are able to reproduce these problems.  It is not clear with which version of Java the problem started; we had not been doing much Macintosh testing recently since everything seemed to be fine.  We have seen no similar issues on Windows. 

 

The behavior we see is that screen re-draw stops intermittently, leaving parts of the screen displaying the previous screen?s contents.  The problem is not component by component, instead it seems to involve screen regions.  Forcing a screen redraw by widening the Frame in which the applet runs or putting the mouse over a component with a ToolTip causes the screen to be redrawn correctly.   

 

Is this a known problem, or do I need to reproduce it in a tiny applet to get this fixed?  Is there some simple workaround?  I?ve tried various invalidate / validate approaches without success.  

 

During the era in which Apple did its own version of Java and kept bug reports secret, I posted a large number of test applets used for bug reports by me and others at http://www.segal.org/java/.  I?ve started looking through those applets to see if I already have a test applet that illustrates the current problems.  I?ve quickly found one bug that illustrates a different display problem in which random contents of the browser cache get inserted into the applet display area.  This is a different problem from the main problem I?m trying to solve, but I thought I?d post that for comment before submitting a bug report since I?ve found that other people on groups such as this often have comments and suggestions that improve a bug report.  This applet, entitled ?Applets on MacOS over 800 pixels high have display problems?, is at www.segal.org/java/refresh.  I?d be grateful for comments on this, and will submit an official bug report.  

 

But my main goal is to solve the screen re-draw issue and I?d appreciate feedback from others as to whether this is a known issue.  So far our only workarounds are to tell people to force a screen re-draw or switch to Windows.  However, I imagine we are not the only ones seeing this problem and we should be able to get Java on the Macintosh working better than that.

 

 


From java3 at segal.org  Thu May  9 08:58:48 2013
From: java3 at segal.org (Mickey Segal)
Date: Thu, 9 May 2013 11:58:48 -0400
Subject: Applet won't run first time on Safari
Message-ID: <000301ce4cce$185af070$4910d150$@segal.org>

I find that a Java applet typically won?t run the first time on MacOS / JRE7 / Safari after selecting ?I accept the risk and want to run this app?.  I am able to reproduce this problem using the ?Hello world? applet at http://www.segal.org/Hello/.  The applet will run immediately if the page is refreshed, but the problem occurs again unless ?Do not show this again for this app? was selected.

 

Going to ?System Preferences | Java | General | Temporary Internet Files | Settings | Delete Files? and checking ?Installed Applications and Applets? clears the effect of  ?Do not show this again for this app? and the problem occurs again.

 

Everything is fine on Firefox for MacOS and on Windows.  

 

We see the same behavior on our huge applet, and it is off-putting to users.

 

It seems like others are likely to experience the same problem, so I?m surprised to find that it is broken.  

 

Since it is Safari-specific, should this be reported to Apple or Oracle?


From swingler at apple.com  Thu May  9 09:19:43 2013
From: swingler at apple.com (Mike Swingler)
Date: Thu, 09 May 2013 09:19:43 -0700
Subject: Applet won't run first time on Safari
In-Reply-To: <000301ce4cce$185af070$4910d150$@segal.org>
References: <000301ce4cce$185af070$4910d150$@segal.org>
Message-ID: <F16F8CB3-9452-46EE-879A-FD565837D551@apple.com>

On May 9, 2013, at 8:58 AM, Mickey Segal <java3 at segal.org> wrote:

> I find that a Java applet typically won?t run the first time on MacOS / JRE7 / Safari after selecting ?I accept the risk and want to run this app?.  I am able to reproduce this problem using the ?Hello world? applet at http://www.segal.org/Hello/.  The applet will run immediately if the page is refreshed, but the problem occurs again unless ?Do not show this again for this app? was selected.
> 
> 
> 
> Going to ?System Preferences | Java | General | Temporary Internet Files | Settings | Delete Files? and checking ?Installed Applications and Applets? clears the effect of  ?Do not show this again for this app? and the problem occurs again.
> 
> 
> 
> Everything is fine on Firefox for MacOS and on Windows.  
> 
> 
> 
> We see the same behavior on our huge applet, and it is off-putting to users.
> 
> 
> 
> It seems like others are likely to experience the same problem, so I?m surprised to find that it is broken.  
> 
> 
> 
> Since it is Safari-specific, should this be reported to Apple or Oracle?

I'd suggest filing a bug at <http://bugreporter.apple.com>, provide a link to an applet which reproduces this with the latest version of the Oracle Java 7 applet plug-in, and clearly state that it's a Safari only problem so that the Safari team can investigate it.

Regards,
Mike Swingler
Apple Inc.


From david.dehaven at oracle.com  Thu May  9 10:52:52 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 9 May 2013 10:52:52 -0700
Subject: Intermittent display problems in JRE 7
In-Reply-To: <000601ce4cbc$e725a650$b570f2f0$@segal.org>
References: <000601ce4cbc$e725a650$b570f2f0$@segal.org>
Message-ID: <E7604374-7030-4934-B01D-25045F7C49B0@oracle.com>


> Is this a known problem, or do I need to reproduce it in a tiny applet to get this fixed?  Is there some simple workaround?  I?ve tried various invalidate / validate approaches without success.  

I don't know that it's a known problem or not. If you can generate a small sample that reproduces the issue, please file a bug at http://bugs.sun.com, some engineer will at least be able to test the bug against the current state of 7u-dev. There are numerous fixes for Mac OS X that will be released with 7u40, currently due in August.

I also strongly encourage you to try the JDK 8 early access (at http://jdk8.java.net) to see if the problem still exists or if it's just in the current 7u line.

-DrD-


From java3 at segal.org  Thu May  9 11:13:22 2013
From: java3 at segal.org (Mickey Segal)
Date: Thu, 9 May 2013 14:13:22 -0400
Subject: Intermittent display problems in JRE 7
In-Reply-To: <E7604374-7030-4934-B01D-25045F7C49B0@oracle.com>
References: <000601ce4cbc$e725a650$b570f2f0$@segal.org>
	<E7604374-7030-4934-B01D-25045F7C49B0@oracle.com>
Message-ID: <000301ce4ce0$e52f2320$af8d6960$@segal.org>

I will try to generate a new test applet for the display problem in our huge applet if I can't find a suitable applet from the large numbers of test applets at http://www.segal.org/java/.  I'm going through the collection of test applets and finding various problems.  

At Mike Swingler's suggestion I've already filed a bug report with Apple about the issue in the "Applet won't run first time on Safari" issue, and will add the details to http://www.segal.org/java/Hello/ URL.  I will file a report on the bug at http://www.segal.org/java/refresh/ with Oracle.    

If I install JRE 8, can I toggle between 7 and 8?  How close are we to the time that 7 users will get pushed to 8?  Our huge applet is in wide use for key medical decisions and we can't just tell everyone to wait or switch to Windows.

-----Original Message-----
From: David DeHaven [mailto:david.dehaven at oracle.com] 
Sent: Thursday, May 09, 2013 1:53 PM
To: Mickey Segal
Cc: macosx-port-dev at openjdk.java.net
Subject: Re: Intermittent display problems in JRE 7


> Is this a known problem, or do I need to reproduce it in a tiny applet to get this fixed?  Is there some simple workaround?  I?ve tried various invalidate / validate approaches without success.  

I don't know that it's a known problem or not. If you can generate a small sample that reproduces the issue, please file a bug at http://bugs.sun.com, some engineer will at least be able to test the bug against the current state of 7u-dev. There are numerous fixes for Mac OS X that will be released with 7u40, currently due in August.

I also strongly encourage you to try the JDK 8 early access (at http://jdk8.java.net) to see if the problem still exists or if it's just in the current 7u line.

-DrD-


From java3 at segal.org  Thu May  9 11:35:47 2013
From: java3 at segal.org (Mickey Segal)
Date: Thu, 9 May 2013 14:35:47 -0400
Subject: Applet won't run first time on Safari
In-Reply-To: <F16F8CB3-9452-46EE-879A-FD565837D551@apple.com>
References: <000301ce4cce$185af070$4910d150$@segal.org>
	<F16F8CB3-9452-46EE-879A-FD565837D551@apple.com>
Message-ID: <000701ce4ce4$069e5fa0$13db1ee0$@segal.org>

As suggested, I've filed this bug with Apple.  I've also included the details of the bug report and the bug report number along with the simple applet at http://www.segal.org/java/Hello/.  I will keep that version updated with any additions that are made to the official Apple version of the bug report.  

 

It seems that accepting one Java applet may allow others to get past this bug, so it is not just a first run of an applet problem, it is a first run of a first applet problem. Unless you start with the step detailed in the next paragraph you may not see the problem, which might explain how such a basic malfunction could have escaped notice:

 

In "System Preferences | Java | General | Settings | Delete Files" check "Installed Applications and Applets" in addition to the other two checkboxes checked by default. Then click OK. Sometimes clicking OK doesn't work, and if so one must persevere until it does work to get the computer to the Java-na?ve state of a new user.

 

I have the feeling we will need to hack through several layers of problems to fix all the issues I?ve run across.  We?ve done stuff like that in the past.  

 

Mike Swingler [mailto:swingler at apple.com] wrote: 



I'd suggest filing a bug at < <http://bugreporter.apple.com> http://bugreporter.apple.com>, provide a link to an applet which reproduces this with the latest version of the Oracle Java 7 applet plug-in, and clearly state that it's a Safari only problem so that the Safari team can investigate it.


From david.dehaven at oracle.com  Thu May  9 12:11:22 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 9 May 2013 12:11:22 -0700
Subject: Intermittent display problems in JRE 7
In-Reply-To: <000301ce4ce0$e52f2320$af8d6960$@segal.org>
References: <000601ce4cbc$e725a650$b570f2f0$@segal.org>
	<E7604374-7030-4934-B01D-25045F7C49B0@oracle.com>
	<000301ce4ce0$e52f2320$af8d6960$@segal.org>
Message-ID: <B3C2F628-EBFF-41C7-954E-BBADBEDDA9EF@oracle.com>


> I will try to generate a new test applet for the display problem in our huge applet if I can't find a suitable applet from the large numbers of test applets at http://www.segal.org/java/.  I'm going through the collection of test applets and finding various problems.  
> 
> At Mike Swingler's suggestion I've already filed a bug report with Apple about the issue in the "Applet won't run first time on Safari" issue, and will add the details to http://www.segal.org/java/Hello/ URL.  I will file a report on the bug at http://www.segal.org/java/refresh/ with Oracle.    
> 
> If I install JRE 8, can I toggle between 7 and 8?  How close are we to the time that 7 users will get pushed to 8?  Our huge applet is in wide use for key medical decisions and we can't just tell everyone to wait or switch to Windows.

The main reason I suggested testing with 8 is there's currently no preview for 7u40 and frequently (at least in OpenJDK) fixes bake in 8 before being backported to 7u. There's generally a good chance that both versions will have the same fixes in cases like this.

For web applets, install 7 then move the plugin somewhere, install 8 and move to a similar location. Once you have both plugins, create a symlink in /Library/Internet\ Plug-Ins pointing to the version you want to run. That's how I juggle versions for testing...

Example (irrelevant parts removed for brevity):
$ ls -l ~/java
...
drwxr-xr-x   4 daved  staff        136 Apr 24 13:42 7u13
drwxr-xr-x   4 daved  staff        136 Apr 24 13:43 7u17
drwxr-xr-x   4 daved  staff        136 Apr 24 13:43 7u21
...
$ ls -l /Library/Internet\ Plug-Ins
...
lrwxr-xr-x   1 daved  wheel    100 Apr 26 12:03 JavaAppletPlugin.plugin -> /Users/daved/java/7u21/JavaAppletPlugin.plugin
...


If you can run standalone then just set JAVA_HOME and the stub /usr/bin/java launcher will honor it. This *should* also work for javaws too when launched from the command line (not for double-clicking!), or you can just call it directly instead of using the launcher stubs in /usr/bin.

-DrD-


From java3 at segal.org  Thu May  9 12:43:45 2013
From: java3 at segal.org (Mickey Segal)
Date: Thu, 9 May 2013 15:43:45 -0400
Subject: Intermittent display problems in JRE 7
In-Reply-To: <B3C2F628-EBFF-41C7-954E-BBADBEDDA9EF@oracle.com>
References: <000601ce4cbc$e725a650$b570f2f0$@segal.org>
	<E7604374-7030-4934-B01D-25045F7C49B0@oracle.com>
	<000301ce4ce0$e52f2320$af8d6960$@segal.org>
	<B3C2F628-EBFF-41C7-954E-BBADBEDDA9EF@oracle.com>
Message-ID: <000b01ce4ced$8566f3c0$9034db40$@segal.org>

I'm not nearly as familiar with the Macintosh as with Windows and couldn't figure out how to keep both JRE 7 and JRE 8, so I installed JRE 8 and the problem at http://www.segal.org/java/refresh goes away.  Unfortunately, the main screen painting display problem I actually care about is still there in JRE 8.  The Safari-specific bug at http://www.segal.org/java/Hello/ is still in JRE 8, but it sounds like that is something Apple needs to fix. 

I don't know how hard it will be to make a simple applet that demonstrates the problem.  I'm still going through my existing test applets, up to the letter H so far, and found the two other problems discussed above but not the most important one.  Hopefully I'll luck out and find a simple way to reproduce this in a simple applet.

If the folks at Oracle want to see the bug in the huge applet, I'd be glad to give access information and waive the requirement to be a medical professional to get access.  I can also show the problem via WebEx.  


From krueger at lesspain.de  Fri May 10 05:57:10 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 10 May 2013 14:57:10 +0200
Subject: Splash screen border
In-Reply-To: <517FEF4F.9050403@oracle.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>
	<517FEF4F.9050403@oracle.com>
Message-ID: <CAEnqZEUfiOqt+NqRAxiWA6Bx61yLKS23FgrF8xhWkrinomGoow@mail.gmail.com>

has anyone done this? I haven't as I felt the comment was addressed to Mike.


On Tue, Apr 30, 2013 at 6:20 PM, Anthony Petrov
<anthony.petrov at oracle.com>wrote:

> 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.
>>
>>

From krueger at lesspain.de  Fri May 10 07:25:58 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 10 May 2013 16:25:58 +0200
Subject: ComponentHidden fired before ComponentShown
Message-ID: <CAEnqZEVqFB_OTvBmB+rxLDcP0tNitQt3MsGY3QYwFkU308DNLQ@mail.gmail.com>

Hi,

I am experiencing problems in our app (using the latest OpenJDK8 build)
where under certain circumstances a ComponentHidden event is fired before
the component has been shown for the first time, breaking our app (because
it relies on the fact that this event only occurs after the component has
been shown). Before I start building a reproducible test case (about which
my gut feeling is, that this may be a lot of effort because the app is
rather complex) I would like to ask if there are any known problems in this
area.

Best regards,

Robert

From swingler at apple.com  Fri May 10 08:31:52 2013
From: swingler at apple.com (Mike Swingler)
Date: Fri, 10 May 2013 08:31:52 -0700
Subject: Splash screen border
In-Reply-To: <CAEnqZEUfiOqt+NqRAxiWA6Bx61yLKS23FgrF8xhWkrinomGoow@mail.gmail.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>
	<517FEF4F.9050403@oracle.com>
	<CAEnqZEUfiOqt+NqRAxiWA6Bx61yLKS23FgrF8xhWkrinomGoow@mail.gmail.com>
Message-ID: <D1AFAFC2-28AC-40B0-8AAD-2850E27389A4@apple.com>

I have not, because this issue is not impacting my work.

You are the one who found the issue, you are the one with an impacted app, and I imagine you have really good test case you can provide, so why don't you file the bug?

Thanks,
Mike Swingler
Apple Inc.

On May 10, 2013, at 5:57 AM, Robert Kr?ger <krueger at lesspain.de> wrote:

> has anyone done this? I haven't as I felt the comment was addressed to Mike.
> 
> 
> On Tue, Apr 30, 2013 at 6:20 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
> 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.
> 
> 


From java3 at segal.org  Fri May 10 10:21:32 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 10 May 2013 13:21:32 -0400
Subject: ComponentHidden fired before ComponentShown
Message-ID: <001801ce4da2$d1c62eb0$75528c10$@segal.org>

This sounds like it may be related to the problem I discussed in the ?Intermittent display problems in JRE 7? thread.  I?ve posted some screenshots of the display refresh problems we are seeing in our large applet at http://segal.org/java/refresh3/.  Robert: do the problems that you see seem similar?

 

Robert Kr?ger wrote:

I am experiencing problems in our app (using the latest OpenJDK8 build)

where under certain circumstances a ComponentHidden event is fired before

the component has been shown for the first time, breaking our app (because

it relies on the fact that this event only occurs after the component has

been shown). Before I start building a reproducible test case (about which

my gut feeling is, that this may be a lot of effort because the app is

rather complex) I would like to ask if there are any known problems in this

area.

 


From java3 at segal.org  Fri May 10 10:31:19 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 10 May 2013 13:31:19 -0400
Subject: Intermittent display problems in JRE 7
References: <000601ce4cbc$e725a650$b570f2f0$@segal.org>
	<E7604374-7030-4934-B01D-25045F7C49B0@oracle.com> 
Message-ID: <001d01ce4da4$2f5b4910$8e11db30$@segal.org>

I?ve posted some screenshots of the display refresh problems we are seeing in our large applet at http://segal.org/java/refresh3/. This occurs also in Java 8 build 88.  Hopefully that will help people converge on the likely underlying problem.  

I will still try to find or create a test applet to reproduce this problem in a simpler context.  

The separate problem illustrated at http://segal.org/java/refresh/ is fixed by Java 8 build 88, and since it got fixed in version 8 and doesn't affect our real applet, it is fine to ignore that.  Unfortunately, the bug report is not available for me to post that update.  I understand that bug reports can take a few days to appear, but when I filed the bug report at http://www.segal.org/java/SigningTestApple/ the report never appeared (although I haven't seen the problem in in the most recent JRE 7 version so it may be that my report or a similar report from others was acted upon.



From java3 at segal.org  Fri May 10 11:39:34 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 10 May 2013 14:39:34 -0400
Subject: Simple applet that may reproduce the key screen refresh problem
Message-ID: <000001ce4dad$b87b6aa0$29723fe0$@segal.org>

In my efforts to find a simple applet to demonstrate the screen refresh problem in a large applet with illustrative screenshots at http://www.segal.org/java/refresh3/, I?ve been going through the various test applets at http://www.segal.org/java/ and found one that may reproduce the key problem.  I?ve put it at http://www.segal.org/java/refresh4/, with full source code and a working applet.  

 

I will file this soon as an Oracle bug, but since the bugs disappear after one files them I wanted to see if others had comments so I could file a more complete report.

 

This not necessarily the same problem as the one I need fixed, so I will continue trying my existing test applets.  I?ve gone through 40% of them so far and found 3 bugs so it seems worth doing even if I?ve found a simple applet that has the same problem as our large applet.


From java3 at segal.org  Fri May 10 11:42:09 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 10 May 2013 14:42:09 -0400
Subject: Simple applet that may reproduce the key screen refresh problem
Message-ID: <000001ce4dae$14a8fb30$3dfaf190$@segal.org>

I?m reposting this because I see that a comma after a hyperlink gets put into the hyperlink by this forum software.  I?ve removed the offending commas.

 

In my efforts to find a simple applet to demonstrate the screen refresh problem in a large applet with illustrative screenshots at http://www.segal.org/java/refresh3/ I?ve been going through the various test applets at http://www.segal.org/java/ and found one that may reproduce the key problem.  I?ve put it at http://www.segal.org/java/refresh4/ with full source code and a working applet.  

 

I will file this soon as an Oracle bug, but since the bugs disappear after one files them I wanted to see if others had comments so I could file a more complete report.

 

This not necessarily the same problem as the one I need fixed, so I will continue trying my existing test applets.  I?ve gone through 40% of them so far and found 3 bugs so it seems worth doing even if I?ve found a simple applet that has the same problem as our large applet.


From Sergey.Bylokhov at oracle.com  Fri May 10 12:20:56 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 10 May 2013 23:20:56 +0400
Subject: Simple applet that may reproduce the key screen refresh problem
In-Reply-To: <000001ce4dad$b87b6aa0$29723fe0$@segal.org>
References: <000001ce4dad$b87b6aa0$29723fe0$@segal.org>
Message-ID: <518D4898.6040404@oracle.com>

Hi, Mickey.
I'll look at this problem. Thanks for your report.

On 10.05.2013 22:39, Mickey Segal wrote:
> In my efforts to find a simple applet to demonstrate the screen refresh problem in a large applet with illustrative screenshots at http://www.segal.org/java/refresh3/, I?ve been going through the various test applets at http://www.segal.org/java/ and found one that may reproduce the key problem.  I?ve put it at http://www.segal.org/java/refresh4/, with full source code and a working applet.
>
>   
>
> I will file this soon as an Oracle bug, but since the bugs disappear after one files them I wanted to see if others had comments so I could file a more complete report.
>
>   
>
> This not necessarily the same problem as the one I need fixed, so I will continue trying my existing test applets.  I?ve gone through 40% of them so far and found 3 bugs so it seems worth doing even if I?ve found a simple applet that has the same problem as our large applet.
>


-- 
Best regards, Sergey.


From java3 at segal.org  Fri May 10 12:42:47 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 10 May 2013 15:42:47 -0400
Subject: Simple applet that may reproduce the key screen refresh problem
In-Reply-To: <518D4898.6040404@oracle.com>
References: <000001ce4dad$b87b6aa0$29723fe0$@segal.org>
	<518D4898.6040404@oracle.com>
Message-ID: <000301ce4db6$8d0ba3e0$a722eba0$@segal.org>

I found another of our test applets that shows similar component refresh problems.  I posted a working copy and full source code at http://www.segal.org/java/refresh5/

 

Is it better to combine this and the other version in one report or do two separate reports?  It is always hard to tell whether it is the same bug or different ones.  This version has some history in triggering two bugs years ago, as I detailed on http://www.segal.org/java/refresh5/

 

I?m about 80% through our collection of test applets from http://www.segal.org/java/ and it seems worth checking the others to see if there are other problems to fix.  It should be possible to get Java on Macintosh as solid as Java on Windows.

 

Sergey Bylokhov wrote: 



I'll look at this problem. Thanks for your report.

 


From java3 at segal.org  Fri May 10 13:14:31 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 10 May 2013 16:14:31 -0400
Subject: Applet won't run first time on Safari
References: <000301ce4cce$185af070$4910d150$@segal.org>
	<F16F8CB3-9452-46EE-879A-FD565837D551@apple.com> 
Message-ID: <000301ce4dba$fc22adb0$f4680910$@segal.org>

In addition to the main demonstration of this problem at http://www.segal.org/java/Hello/ I?ve demonstrated at http://www.segal.org/java/HelloFrame/ that even though the applet is not displaying, it can pop up a Frame with a name (full source code and working applet). 

 

I?ve added this to the Apple bug report.


From krueger at lesspain.de  Fri May 10 13:22:34 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 10 May 2013 22:22:34 +0200
Subject: Splash screen border
In-Reply-To: <D1AFAFC2-28AC-40B0-8AAD-2850E27389A4@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>
	<517FEF4F.9050403@oracle.com>
	<CAEnqZEUfiOqt+NqRAxiWA6Bx61yLKS23FgrF8xhWkrinomGoow@mail.gmail.com>
	<D1AFAFC2-28AC-40B0-8AAD-2850E27389A4@apple.com>
Message-ID: <CAEnqZEWX9DR-W-X5FcWHyNSi3czCvYA8DK-yymbacPjx=T-_DA@mail.gmail.com>

I will do that then. Just wanted to ask to know if someone has already done
that to avoid duplication.


On Fri, May 10, 2013 at 5:31 PM, Mike Swingler <swingler at apple.com> wrote:

> I have not, because this issue is not impacting my work.
>
> You are the one who found the issue, you are the one with an impacted app,
> and I imagine you have really good test case you can provide, so why don't
> you file the bug?
>
> Thanks,
> Mike Swingler
> Apple Inc.
>
> On May 10, 2013, at 5:57 AM, Robert Kr?ger <krueger at lesspain.de> wrote:
>
> has anyone done this? I haven't as I felt the comment was addressed to
> Mike.
>
>
> On Tue, Apr 30, 2013 at 6:20 PM, Anthony Petrov <anthony.petrov at oracle.com
> > wrote:
>
>> 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.
>>>
>>>
>
>

From krueger at lesspain.de  Fri May 10 13:25:59 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 10 May 2013 22:25:59 +0200
Subject: ComponentHidden fired before ComponentShown
In-Reply-To: <001801ce4da2$d1c62eb0$75528c10$@segal.org>
References: <001801ce4da2$d1c62eb0$75528c10$@segal.org>
Message-ID: <CAEnqZEV3QWO5Uo8T4BM_CnGRvPLT2K55rNNBxSxpybeE2VnkWQ@mail.gmail.com>

at first glance I fail to see how these two are related. Could you
elaborate?


On Fri, May 10, 2013 at 7:21 PM, Mickey Segal <java3 at segal.org> wrote:

> This sounds like it may be related to the problem I discussed in the
> ?Intermittent display problems in JRE 7? thread.  I?ve posted some
> screenshots of the display refresh problems we are seeing in our large
> applet at http://segal.org/java/refresh3/.  Robert: do the problems that
> you see seem similar?****
>
> ** **
>
> Robert Kr?ger wrote:****
>
> I am experiencing problems in our app (using the latest OpenJDK8 build)***
> *
>
> where under certain circumstances a ComponentHidden event is fired before*
> ***
>
> the component has been shown for the first time, breaking our app (because
> ****
>
> it relies on the fact that this event only occurs after the component has*
> ***
>
> been shown). Before I start building a reproducible test case (about which
> ****
>
> my gut feeling is, that this may be a lot of effort because the app is****
>
> rather complex) I would like to ask if there are any known problems in this
> ****
>
> area.****
>
> ** **
>

From java3 at segal.org  Fri May 10 13:34:07 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 10 May 2013 16:34:07 -0400
Subject: ComponentHidden fired before ComponentShown
In-Reply-To: <CAEnqZEV3QWO5Uo8T4BM_CnGRvPLT2K55rNNBxSxpybeE2VnkWQ@mail.gmail.com>
References: <001801ce4da2$d1c62eb0$75528c10$@segal.org>
	<CAEnqZEV3QWO5Uo8T4BM_CnGRvPLT2K55rNNBxSxpybeE2VnkWQ@mail.gmail.com>
Message-ID: <000301ce4dbd$b9600b00$2c202100$@segal.org>

I was just thinking that a problem with keeping track of which components are shown could be related to the one you described.  But I now have screen shots of the problem in our large applet at http://www.segal.org/java/refresh3/ and two small applets that show similar problems at http://www.segal.org/java/refresh4/ and http://www.segal.org/java/refresh5/ so hopefully we can get this figured out.

 

Robert Kr?ger wrote:

 

at first glance I fail to see how these two are related. Could you elaborate?

 

On Fri, May 10, 2013 at 7:21 PM, Mickey Segal <java3 at segal.org> wrote:

This sounds like it may be related to the problem I discussed in the ?Intermittent display problems in JRE 7? thread.  I?ve posted some screenshots of the display refresh problems we are seeing in our large applet at http://segal.org/java/refresh3/.  Robert: do the problems that you see seem similar?


From david.dehaven at oracle.com  Fri May 10 13:51:40 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 10 May 2013 13:51:40 -0700
Subject: Simple applet that may reproduce the key screen refresh problem
In-Reply-To: <000301ce4db6$8d0ba3e0$a722eba0$@segal.org>
References: <000001ce4dad$b87b6aa0$29723fe0$@segal.org>
	<518D4898.6040404@oracle.com>
	<000301ce4db6$8d0ba3e0$a722eba0$@segal.org>
Message-ID: <521EA3A9-5927-477B-BBC4-506C2D299008@oracle.com>


> I found another of our test applets that shows similar component refresh problems.  I posted a working copy and full source code at http://www.segal.org/java/refresh5/
> 
> 
> 
> Is it better to combine this and the other version in one report or do two separate reports?  It is always hard to tell whether it is the same bug or different ones.  This version has some history in triggering two bugs years ago, as I detailed on http://www.segal.org/java/refresh5/
> 
> 
> 
> I?m about 80% through our collection of test applets from http://www.segal.org/java/ and it seems worth checking the others to see if there are other problems to fix.  It should be possible to get Java on Macintosh as solid as Java on Windows.

Personally, I'd file two bugs if they're behaving differently. One can always be closed as a duplicate if it's determined to be.

-DrD-


From java3 at segal.org  Fri May 10 14:25:36 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 10 May 2013 17:25:36 -0400
Subject: Simple applet that may reproduce the key screen refresh problem
In-Reply-To: <521EA3A9-5927-477B-BBC4-506C2D299008@oracle.com>
References: <000001ce4dad$b87b6aa0$29723fe0$@segal.org>
	<518D4898.6040404@oracle.com>
	<000301ce4db6$8d0ba3e0$a722eba0$@segal.org>
	<521EA3A9-5927-477B-BBC4-506C2D299008@oracle.com>
Message-ID: <000e01ce4dc4$ea613150$bf2393f0$@segal.org>

Oops.  I decided to get this submitted before the end of the day on the east coast and a few minutes ago submitted as one bug report since the two applets were so similar.  

The bug ID is 9002524.  I'll be keeping current the list of relevant bugs at http://www.segal.org/java/oracle/ and keeping current individual bug demo pages such as http://www.segal.org/java/refresh4/ and http://www.segal.org/java/refresh5/ by adding additional observations as appropriate.

BTW, in the process of submitting the bug reports it was difficult to choose accurate options for MacOS version (10.7 was most recent) and it was not clear how to indicate a bug in JRE 8 (I chose to call this 7.0_21 since I don't know if Java 8 versions are part of OpenJDK).  I'd appreciate if this report could be routed appropriately despite my shoehorning it into existing categories, and it would be helpful if the MacOS choices could be brought up to date.

David DeHaven wrote:

Personally, I'd file two bugs if they're behaving differently. One can always be closed as a duplicate if it's determined to be.


From roger.lewis at oracle.com  Fri May 10 14:52:40 2013
From: roger.lewis at oracle.com (Roger Lewis)
Date: Fri, 10 May 2013 14:52:40 -0700
Subject: Simple applet that may reproduce the key screen refresh problem
In-Reply-To: <000e01ce4dc4$ea613150$bf2393f0$@segal.org>
References: <000001ce4dad$b87b6aa0$29723fe0$@segal.org>
	<518D4898.6040404@oracle.com>
	<000301ce4db6$8d0ba3e0$a722eba0$@segal.org>
	<521EA3A9-5927-477B-BBC4-506C2D299008@oracle.com>
	<000e01ce4dc4$ea613150$bf2393f0$@segal.org>
Message-ID: <518D6C28.6010203@oracle.com>


On 5/10/13 2:25 PM, Mickey Segal wrote:
>
> BTW, in the process of submitting the bug reports it was difficult to choose accurate options for MacOS version (10.7 was most recent) and it was not clear how to indicate a bug in JRE 8 (I chose to call this 7.0_21 since I don't know if Java 8 versions are part of OpenJDK).  I'd appreciate if this report could be routed appropriately despite my shoehorning it into existing categories, and it would be helpful if the MacOS choices could be brought up to date.
Hi Mickey,
       I will update your bug as well ensure that the form is updated 
with values. Thanks for pointing out the oversight!

-Roger



>
> David DeHaven wrote:
>
> Personally, I'd file two bugs if they're behaving differently. One can always be closed as a duplicate if it's determined to be.
>


From krueger at lesspain.de  Sat May 11 01:45:56 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sat, 11 May 2013 10:45:56 +0200
Subject: ComponentHidden fired before ComponentShown
In-Reply-To: <000301ce4dbd$b9600b00$2c202100$@segal.org>
References: <001801ce4da2$d1c62eb0$75528c10$@segal.org>
	<CAEnqZEV3QWO5Uo8T4BM_CnGRvPLT2K55rNNBxSxpybeE2VnkWQ@mail.gmail.com>
	<000301ce4dbd$b9600b00$2c202100$@segal.org>
Message-ID: <CAEnqZEXwOrKDn0k+=y-bwxjcRW6nfO_8HVxXYD4COaxLC6wVRg@mail.gmail.com>

I think I see what you mean. There could be something but I feel far from
being able to say how likely that is.


On Fri, May 10, 2013 at 10:34 PM, Mickey Segal <java3 at segal.org> wrote:

> I was just thinking that a problem with keeping track of which components
> are shown could be related to the one you described.  But I now have screen
> shots of the problem in our large applet at
> http://www.segal.org/java/refresh3/ and two small applets that show
> similar problems at http://www.segal.org/java/refresh4/ and
> http://www.segal.org/java/refresh5/ so hopefully we can get this figured
> out.****
>
> ** **
>
> Robert Kr?ger wrote:****
>
> ** **
>
> at first glance I fail to see how these two are related. Could you
> elaborate?****
>
> ** **
>
> On Fri, May 10, 2013 at 7:21 PM, Mickey Segal <java3 at segal.org> wrote:****
>
> This sounds like it may be related to the problem I discussed in the
> ?Intermittent display problems in JRE 7? thread.  I?ve posted some
> screenshots of the display refresh problems we are seeing in our large
> applet at http://segal.org/java/refresh3/.  Robert: do the problems that
> you see seem similar?****
>

From krueger at lesspain.de  Sat May 11 01:49:34 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sat, 11 May 2013 10:49:34 +0200
Subject: ComponentHidden fired before ComponentShown
In-Reply-To: <CAEnqZEVqFB_OTvBmB+rxLDcP0tNitQt3MsGY3QYwFkU308DNLQ@mail.gmail.com>
References: <CAEnqZEVqFB_OTvBmB+rxLDcP0tNitQt3MsGY3QYwFkU308DNLQ@mail.gmail.com>
Message-ID: <CAEnqZEWYd7mHCZ5YSz5s2J0nncd9WcPSGrbboa9g5LK4gRzqRg@mail.gmail.com>

just in case someone else is struggling with this. I worked around it by
ignoring any component hidden event that occurs before a component shown
event has occurred, I basically track the visibility in a private variable
in the component listener. That does it for me in this particular case.
Will try to make it reproducible though.


On Fri, May 10, 2013 at 4:25 PM, Robert Kr?ger <krueger at lesspain.de> wrote:

> Hi,
>
> I am experiencing problems in our app (using the latest OpenJDK8 build)
> where under certain circumstances a ComponentHidden event is fired before
> the component has been shown for the first time, breaking our app (because
> it relies on the fact that this event only occurs after the component has
> been shown). Before I start building a reproducible test case (about which
> my gut feeling is, that this may be a lot of effort because the app is
> rather complex) I would like to ask if there are any known problems in this
> area.
>
> Best regards,
>
> Robert
>
>
>

From Sergey.Bylokhov at oracle.com  Tue May 14 05:27:26 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 14 May 2013 16:27:26 +0400
Subject: [8] Request for review: 8014423 [macosx] The scrollbar's block
	increment performs incorrectly
Message-ID: <51922DAE.2000801@oracle.com>

Hello,
Please review the fix for jdk 8.
ScrollBarPeer is not properly initialized on macosx. unitIncrement and 
blockIncrement were missing.

Bug(will be available soon): 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014423
Webrev can be found at: http://cr.openjdk.java.net/~serb/8014423/webrev.00

-- 
Best regards, Sergey.


From artem.ananiev at oracle.com  Tue May 14 05:25:13 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Tue, 14 May 2013 16:25:13 +0400
Subject: [8] Request for review: 8014423 [macosx] The scrollbar's block
	increment performs incorrectly
In-Reply-To: <51922DAE.2000801@oracle.com>
References: <51922DAE.2000801@oracle.com>
Message-ID: <51922D29.70405@oracle.com>


Looks fine.

Thanks,

Artem

On 5/14/2013 4:27 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 8.
> ScrollBarPeer is not properly initialized on macosx. unitIncrement and
> blockIncrement were missing.
>
> Bug(will be available soon):
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014423
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8014423/webrev.00
>

From anthony.petrov at oracle.com  Tue May 14 05:46:31 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 14 May 2013 16:46:31 +0400
Subject: [8] Request for review: 8014423 [macosx] The scrollbar's block
	increment performs incorrectly
In-Reply-To: <51922D29.70405@oracle.com>
References: <51922DAE.2000801@oracle.com> <51922D29.70405@oracle.com>
Message-ID: <51923227.1080406@oracle.com>

+1

--
best regards,
Anthony

On 05/14/2013 04:25 PM, Artem Ananiev wrote:
>
> Looks fine.
>
> Thanks,
>
> Artem
>
> On 5/14/2013 4:27 PM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk 8.
>> ScrollBarPeer is not properly initialized on macosx. unitIncrement and
>> blockIncrement were missing.
>>
>> Bug(will be available soon):
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014423
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8014423/webrev.00
>>

From cedric.chaveriat at fondationbiodiversite.fr  Tue May 14 06:06:07 2013
From: cedric.chaveriat at fondationbiodiversite.fr (=?ISO-8859-1?Q?C=E9dric_Chav=E9riat?=)
Date: Tue, 14 May 2013 15:06:07 +0200
Subject: [8] Request for review: 8014423 [macosx] The scrollbar's block
	increment performs incorrectly
In-Reply-To: <51922DAE.2000801@oracle.com>
References: <51922DAE.2000801@oracle.com>
Message-ID: <8B3CEF02-3818-4EA8-9209-4253A9E0F652@fondationbiodiversite.fr>

Hello,

I'm realy sorry to disturb you, but could you tell me how can I  
unsuscribe to this mailling list ?
I susrible by mistake, I've search on oracle web site but I don't find  
anything to unsuscribe

Thank you in advance,
good continuation,
C?dric Chaveriat


Le 14 mai 13 ? 14:27, Sergey Bylokhov a ?crit :

> Hello,
> Please review the fix for jdk 8.
> ScrollBarPeer is not properly initialized on macosx. unitIncrement  
> and blockIncrement were missing.
>
> Bug(will be available soon): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014423
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8014423/webrev.00
>
> -- 
> Best regards, Sergey.
>

C?dric Chav?riat
Fondation pour la Recherche sur la Biodiversit?
Charg? de mission :
Base de donn?es nationale des acteurs de la recherche sur la  
biodiversit?
01 80 05 89 25
cedric.chaveriat at fondationbiodiversite.fr

http://www.fondationbiodiversite.fr/
http://www.fondationbiodiversite.fr/portailbasededonnees













From anthony.petrov at oracle.com  Tue May 14 06:16:09 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 14 May 2013 17:16:09 +0400
Subject: [8] Request for review: 8014423 [macosx] The scrollbar's block
	increment performs incorrectly
In-Reply-To: <8B3CEF02-3818-4EA8-9209-4253A9E0F652@fondationbiodiversite.fr>
References: <51922DAE.2000801@oracle.com>
	<8B3CEF02-3818-4EA8-9209-4253A9E0F652@fondationbiodiversite.fr>
Message-ID: <51923919.804@oracle.com>

Check out http://mail.openjdk.java.net/mailman/listinfo/macosx-port-dev

--
best regards,
Anthony

On 05/14/2013 05:06 PM, C?dric Chav?riat wrote:
> Hello,
>
> I'm realy sorry to disturb you, but could you tell me how can I
> unsuscribe to this mailling list ?
> I susrible by mistake, I've search on oracle web site but I don't find
> anything to unsuscribe
>
> Thank you in advance,
> good continuation,
> C?dric Chaveriat
>
>
> Le 14 mai 13 ? 14:27, Sergey Bylokhov a ?crit :
>
>> Hello,
>> Please review the fix for jdk 8.
>> ScrollBarPeer is not properly initialized on macosx. unitIncrement and
>> blockIncrement were missing.
>>
>> Bug(will be available soon):
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014423
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8014423/webrev.00
>>
>> --
>> Best regards, Sergey.
>>
>
> C?dric Chav?riat
> Fondation pour la Recherche sur la Biodiversit?
> Charg? de mission :
> Base de donn?es nationale des acteurs de la recherche sur la biodiversit?
> 01 80 05 89 25
> cedric.chaveriat at fondationbiodiversite.fr
> <mailto:cedric.chaveriat at fondationbiodiversite.fr>
>
> http://www.fondationbiodiversite.fr/
> http://www.fondationbiodiversite.fr/portailbasededonnees
>
>
>
>
>
>
>
>
>
>
>
>

From java3 at segal.org  Tue May 14 08:24:11 2013
From: java3 at segal.org (Mickey Segal)
Date: Tue, 14 May 2013 11:24:11 -0400
Subject: How do you add a comment to a Sun/Oracle bug report?
Message-ID: <000b01ce50b7$1640dd30$42c29790$@segal.org>

One of my MacOS bug reports has appeared at http://bugs.sun.com/view_bug.do?bug_id=8014369.  I don?t see how to add a comment or log-in to add a comment.  Could someone tell me how?  

 

Several of the other bug reports were assigned numbers, some weeks ago, but have never appeared in the bug database.  As an example, the one described at http://www.segal.org/java/SigningTestApple/ never appeared at the number I was given, and http://bugs.sun.com/view_bug.do?bug_id=8014369 got assigned a different number from the one I was sent immediately.  In general, how does one find bug reports after they are submitted?


From roger.lewis at oracle.com  Tue May 14 09:01:01 2013
From: roger.lewis at oracle.com (Roger Lewis)
Date: Tue, 14 May 2013 09:01:01 -0700
Subject: How do you add a comment to a Sun/Oracle bug report?
In-Reply-To: <000b01ce50b7$1640dd30$42c29790$@segal.org>
References: <000b01ce50b7$1640dd30$42c29790$@segal.org>
Message-ID: <51925FBD.8020209@oracle.com>

Hi Mickey,
      Unfortunately that functionality is not currently available and 
have not been for a while.  The login service that bugs.sun.com utilized 
is no longer available. Steps are in place to allow comments to be added 
to bugs.

In the meantime, for this bug, please send me your comments/changes and 
I will see that it is updated.

-Roger

On 5/14/13 8:24 AM, Mickey Segal wrote:
> One of my MacOS bug reports has appeared at http://bugs.sun.com/view_bug.do?bug_id=8014369.  I don?t see how to add a comment or log-in to add a comment.  Could someone tell me how?
>
>   
>
> Several of the other bug reports were assigned numbers, some weeks ago, but have never appeared in the bug database.  As an example, the one described at http://www.segal.org/java/SigningTestApple/ never appeared at the number I was given, and http://bugs.sun.com/view_bug.do?bug_id=8014369 got assigned a different number from the one I was sent immediately.  In general, how does one find bug reports after they are submitted?
>


From philip.race at oracle.com  Tue May 14 09:27:15 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 May 2013 09:27:15 -0700
Subject: How do you add a comment to a Sun/Oracle bug report?
In-Reply-To: <51925FBD.8020209@oracle.com>
References: <000b01ce50b7$1640dd30$42c29790$@segal.org>
	<51925FBD.8020209@oracle.com>
Message-ID: <519265E3.4020308@oracle.com>

That comment functionality wasn't as useful as you might think if
the intention was to let the resp. engineer see it.  Since I look at the
bug tool, not the web page I would never see the comment anyway.
There is no linkage between the two.
Once upon a time (8+ yrs ago) I used to get an email when someone
added a comment showing the new comment. But that applied only
to bugs assigned to me and eventually that functionality broke more
than once and then seemed gone forever.
Basically the problem is "information in 2 places"  and a lack of
transparency to the external commenter that this was no more
than a blog comment not a bug database update.

It would be "nice" if our shiny new bug system  could have a
a link to "external comments" and that it would notify me via
email when new comments are added.

-phil.


On 5/14/2013 9:01 AM, Roger Lewis wrote:
> Hi Mickey,
>      Unfortunately that functionality is not currently available and 
> have not been for a while.  The login service that bugs.sun.com 
> utilized is no longer available. Steps are in place to allow comments 
> to be added to bugs.
>
> In the meantime, for this bug, please send me your comments/changes 
> and I will see that it is updated.
>
> -Roger
>
> On 5/14/13 8:24 AM, Mickey Segal wrote:
>> One of my MacOS bug reports has appeared at 
>> http://bugs.sun.com/view_bug.do?bug_id=8014369.  I don?t see how to 
>> add a comment or log-in to add a comment.  Could someone tell me how?
>>
>>
>> Several of the other bug reports were assigned numbers, some weeks 
>> ago, but have never appeared in the bug database.  As an example, the 
>> one described at http://www.segal.org/java/SigningTestApple/ never 
>> appeared at the number I was given, and 
>> http://bugs.sun.com/view_bug.do?bug_id=8014369 got assigned a 
>> different number from the one I was sent immediately.  In general, 
>> how does one find bug reports after they are submitted?
>>
>


From java3 at segal.org  Tue May 14 09:59:01 2013
From: java3 at segal.org (Mickey Segal)
Date: Tue, 14 May 2013 12:59:01 -0400
Subject: How do you add a comment to a Sun/Oracle bug report?
In-Reply-To: <51925FBD.8020209@oracle.com>
References: <000b01ce50b7$1640dd30$42c29790$@segal.org>
	<51925FBD.8020209@oracle.com>
Message-ID: <000601ce50c4$5652eb90$02f8c2b0$@segal.org>

Actually my comments are about two bugs, one of which I've never found in the database despite getting an email that it was accepted, and the other is about a Windows pen-input bug.

 

One that never appeared: the bug I describe at http://www.segal.org/java/SigningTestApple/ for which I was given a URL for a bug report months ago, but the report hasn't appeared and I think the problem may have been solved since I stopped seeing it after recent updates.

 

Windows pen-input bug: the bug described at http://www.segal.org/java/just_checkbox/ for which the bug did appear at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6494360.  This bug remains labeled as Unresolved, but I tested it today since we are buffing up our support for the Windows pen-input environment and it is fixed and I wanted to pass along that information so the bug report could be listed as fixed and closed.

 

In general, how are we supposed to provide such feedback now?

 

Roger Lewis wrote:



      Unfortunately that functionality is not currently available and 

have not been for a while.  The login service that bugs.sun.com utilized 

is no longer available. Steps are in place to allow comments to be added 

to bugs.

 

In the meantime, for this bug, please send me your comments/changes and 

I will see that it is updated.

 

-Roger

 

On 5/14/13 8:24 AM, Mickey Segal wrote:

> One of my MacOS bug reports has appeared at  <http://bugs.sun.com/view_bug.do?bug_id=8014369> http://bugs.sun.com/view_bug.do?bug_id=8014369.  I don?t see how to add a comment or log-in to add a comment.  Could someone tell me how?

> 

>   

> 

> Several of the other bug reports were assigned numbers, some weeks ago, but have never appeared in the bug database.  As an example, the one described at  <http://www.segal.org/java/SigningTestApple/> http://www.segal.org/java/SigningTestApple/ never appeared at the number I was given, and  <http://bugs.sun.com/view_bug.do?bug_id=8014369> http://bugs.sun.com/view_bug.do?bug_id=8014369 got assigned a different number from the one I was sent immediately.  In general, how does one find bug reports after they are submitted?

> 


From dclunie at dclunie.com  Tue May 14 18:10:31 2013
From: dclunie at dclunie.com (David Clunie)
Date: Tue, 14 May 2013 21:10:31 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <5192DFF7.80501@dclunie.com>
References: <5192DFF7.80501@dclunie.com>
Message-ID: <5192E087.50503@dclunie.com>

Hi all

I wanted to build the OpenJDK for MacOSX.

I was trying to follow the instructions at:

   https://wiki.openjdk.java.net/display/MacOSXPort/Main

but having fetched the code, the build step fails.

The make complains there is no configuration ("No configurations
found for ...").

By comparison, I fetched jdk7u-dev, and a "make" of that works
just fine, with no need for a configure step.

I tried "bash ./configure", but it fails with problems related
to the X11 stuff.

Any advice would be appreciated, since I could spend a while on this
and it is presumably something everyone else has already solved.

I have OS 10.8.3 and XQuartz 2.7.4 and Xcode 4.6.2 installed.

David







From weijun.wang at oracle.com  Tue May 14 18:22:37 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 15 May 2013 09:22:37 +0800
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <5192E087.50503@dclunie.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
Message-ID: <5192E35D.2070709@oracle.com>

Yes, there is a big change in jdk8, you have to use configure now.

I have Xcode 4.6 and XQuartz 2.7.4, and I can build. What does configure 
says about X11?

-Max

On 5/15/13 9:10 AM, David Clunie wrote:
> Hi all
>
> I wanted to build the OpenJDK for MacOSX.
>
> I was trying to follow the instructions at:
>
>    https://wiki.openjdk.java.net/display/MacOSXPort/Main
>
> but having fetched the code, the build step fails.
>
> The make complains there is no configuration ("No configurations
> found for ...").
>
> By comparison, I fetched jdk7u-dev, and a "make" of that works
> just fine, with no need for a configure step.
>
> I tried "bash ./configure", but it fails with problems related
> to the X11 stuff.
>
> Any advice would be appreciated, since I could spend a while on this
> and it is presumably something everyone else has already solved.
>
> I have OS 10.8.3 and XQuartz 2.7.4 and Xcode 4.6.2 installed.
>
> David
>
>
>
>
>
>

From dclunie at dclunie.com  Wed May 15 04:03:02 2013
From: dclunie at dclunie.com (David Clunie)
Date: Wed, 15 May 2013 07:03:02 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <5192E35D.2070709@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com>
Message-ID: <51936B66.3070608@dclunie.com>

Hi Max

If I run "bash ./configure" it complains about not finding the
X11 headers in the configure step; adding "--with-x" as is
suggested in README-build.html does not help.

Trying

   bash ./configure CPATH="/usr/X11/include"

also fails, complaining about not finding the XRender extensions,
so I found that I had to:

   bash ./configure CPATH="/opt/X11/include"

instead, to get past the configure step.

However, when I did that, when I ran "make" it reported:

"Building OpenJDK for target 'default' in configuration 
'macosx-x86_64-normal-server-release'"

and ran until it got to a failure building Solaris X11 stuff,
which seemed strange since we are not targeting Solaris, and
we do have the XRender extensions including XTest.h:

/Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c:501: 
warning: assignment makes integer from pointer without a cast
/Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/xawt/XToolkit.c:47:34: 
warning: X11/extensions/XTest.h: No such file or directory
...
/Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/xawt/XToolkit.c:1031: 
error: ?XDeviceInfo? undeclared (first use in this function)

and at that point I am stumped.

The XRender header extensions are present on the system, e.g.,

   % find /opt/X11 -name XTest.h
   /opt/X11/include/X11/extensions/XTest.h

but then I am not sure that these are even required for the Mac?

I have tried feeding various combinations of "--with-x=/opt/X11" and
CPPFLAGS="-I/opt/X11/include" and even OPENWIN_HOME="/opt/X11" based
on what I see in the generated Makefile.

But I gave up after I realized that it probably shouldn't be trying to
compile the jdk/src/solaris/native sub-tree in the first place, just
the share and the macosx trees, right? And I couldn't figure out where
in the make or configure it decides to do this or not.

David

PS. It would be nice if the page of instructions for building the MacOSX
port could be updated to mention the need for the configure step, and
what arguments to give it, and the make step.

On 5/14/13 9:22 PM, Weijun Wang wrote:
> Yes, there is a big change in jdk8, you have to use configure now.
>
> I have Xcode 4.6 and XQuartz 2.7.4, and I can build. What does configure
> says about X11?
>
> -Max
>
> On 5/15/13 9:10 AM, David Clunie wrote:
>> Hi all
>>
>> I wanted to build the OpenJDK for MacOSX.
>>
>> I was trying to follow the instructions at:
>>
>>    https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>
>> but having fetched the code, the build step fails.
>>
>> The make complains there is no configuration ("No configurations
>> found for ...").
>>
>> By comparison, I fetched jdk7u-dev, and a "make" of that works
>> just fine, with no need for a configure step.
>>
>> I tried "bash ./configure", but it fails with problems related
>> to the X11 stuff.
>>
>> Any advice would be appreciated, since I could spend a while on this
>> and it is presumably something everyone else has already solved.
>>
>> I have OS 10.8.3 and XQuartz 2.7.4 and Xcode 4.6.2 installed.
>>
>> David
>>
>>
>>
>>
>>
>>
>
>

From dclunie at dclunie.com  Wed May 15 04:09:17 2013
From: dclunie at dclunie.com (David Clunie)
Date: Wed, 15 May 2013 07:09:17 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51936B66.3070608@dclunie.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
Message-ID: <51936CDD.2080900@dclunie.com>

By the way, the configure output was as follows:

% bash configure | grep X11
checking what is not needed on an X11 build on MacOSX?... alsa pulse
checking for X11/extensions/shape.h... yes
checking for X11/extensions/Xrender.h... yes
checking for X11/extensions/XTest.h... no
configure: error: Could not find all X11 headers (shape.h Xrender.h 
XTest.h).

% bash ./configure --with-x="/opt/X11" | grep X11
checking what is not needed on an X11 build on MacOSX?... alsa pulse
checking for X11/extensions/shape.h... yes
checking for X11/extensions/Xrender.h... yes
checking for X11/extensions/XTest.h... no
configure: error: Could not find all X11 headers (shape.h Xrender.h 
XTest.h).

% bash ./configure CPATH="/opt/X11/include" | grep X11
checking what is not needed on an X11 build on MacOSX?... alsa pulse
checking for X11/extensions/shape.h... yes
checking for X11/extensions/Xrender.h... yes
checking for X11/extensions/XTest.h... yes
using configure arguments 'CPATH=/opt/X11/include'.

David

On 5/15/13 7:03 AM, David Clunie wrote:
> Hi Max
>
> If I run "bash ./configure" it complains about not finding the
> X11 headers in the configure step; adding "--with-x" as is
> suggested in README-build.html does not help.
>
> Trying
>
>    bash ./configure CPATH="/usr/X11/include"
>
> also fails, complaining about not finding the XRender extensions,
> so I found that I had to:
>
>    bash ./configure CPATH="/opt/X11/include"
>
> instead, to get past the configure step.
>
> However, when I did that, when I ran "make" it reported:
>
> "Building OpenJDK for target 'default' in configuration
> 'macosx-x86_64-normal-server-release'"
>
> and ran until it got to a failure building Solaris X11 stuff,
> which seemed strange since we are not targeting Solaris, and
> we do have the XRender extensions including XTest.h:
>
> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c:501:
> warning: assignment makes integer from pointer without a cast
> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/xawt/XToolkit.c:47:34:
> warning: X11/extensions/XTest.h: No such file or directory
> ...
> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/xawt/XToolkit.c:1031:
> error: ?XDeviceInfo? undeclared (first use in this function)
>
> and at that point I am stumped.
>
> The XRender header extensions are present on the system, e.g.,
>
>    % find /opt/X11 -name XTest.h
>    /opt/X11/include/X11/extensions/XTest.h
>
> but then I am not sure that these are even required for the Mac?
>
> I have tried feeding various combinations of "--with-x=/opt/X11" and
> CPPFLAGS="-I/opt/X11/include" and even OPENWIN_HOME="/opt/X11" based
> on what I see in the generated Makefile.
>
> But I gave up after I realized that it probably shouldn't be trying to
> compile the jdk/src/solaris/native sub-tree in the first place, just
> the share and the macosx trees, right? And I couldn't figure out where
> in the make or configure it decides to do this or not.
>
> David
>
> PS. It would be nice if the page of instructions for building the MacOSX
> port could be updated to mention the need for the configure step, and
> what arguments to give it, and the make step.
>
> On 5/14/13 9:22 PM, Weijun Wang wrote:
>> Yes, there is a big change in jdk8, you have to use configure now.
>>
>> I have Xcode 4.6 and XQuartz 2.7.4, and I can build. What does configure
>> says about X11?
>>
>> -Max
>>
>> On 5/15/13 9:10 AM, David Clunie wrote:
>>> Hi all
>>>
>>> I wanted to build the OpenJDK for MacOSX.
>>>
>>> I was trying to follow the instructions at:
>>>
>>>    https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>
>>> but having fetched the code, the build step fails.
>>>
>>> The make complains there is no configuration ("No configurations
>>> found for ...").
>>>
>>> By comparison, I fetched jdk7u-dev, and a "make" of that works
>>> just fine, with no need for a configure step.
>>>
>>> I tried "bash ./configure", but it fails with problems related
>>> to the X11 stuff.
>>>
>>> Any advice would be appreciated, since I could spend a while on this
>>> and it is presumably something everyone else has already solved.
>>>
>>> I have OS 10.8.3 and XQuartz 2.7.4 and Xcode 4.6.2 installed.
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>

From weijun.wang at oracle.com  Wed May 15 04:29:25 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 15 May 2013 19:29:25 +0800
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51936CDD.2080900@dclunie.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com>
Message-ID: <51937195.6050401@oracle.com>

My output looks like

$ bash ../../configure | grep X11
checking what is not needed on an X11 build on MacOSX?... alsa pulse
checking for X... libraries /usr/X11/lib, headers /usr/X11/include
checking for X11/extensions/shape.h... yes
checking for X11/extensions/Xrender.h... yes
checking for X11/extensions/XTest.h... yes

Notice the extra "checking for X" line.

-Max


On 5/15/13 7:09 PM, David Clunie wrote:
> By the way, the configure output was as follows:
>
> % bash configure | grep X11
> checking what is not needed on an X11 build on MacOSX?... alsa pulse
> checking for X11/extensions/shape.h... yes
> checking for X11/extensions/Xrender.h... yes
> checking for X11/extensions/XTest.h... no
> configure: error: Could not find all X11 headers (shape.h Xrender.h
> XTest.h).
>
> % bash ./configure --with-x="/opt/X11" | grep X11
> checking what is not needed on an X11 build on MacOSX?... alsa pulse
> checking for X11/extensions/shape.h... yes
> checking for X11/extensions/Xrender.h... yes
> checking for X11/extensions/XTest.h... no
> configure: error: Could not find all X11 headers (shape.h Xrender.h
> XTest.h).
>
> % bash ./configure CPATH="/opt/X11/include" | grep X11
> checking what is not needed on an X11 build on MacOSX?... alsa pulse
> checking for X11/extensions/shape.h... yes
> checking for X11/extensions/Xrender.h... yes
> checking for X11/extensions/XTest.h... yes
> using configure arguments 'CPATH=/opt/X11/include'.
>
> David
>
> On 5/15/13 7:03 AM, David Clunie wrote:
>> Hi Max
>>
>> If I run "bash ./configure" it complains about not finding the
>> X11 headers in the configure step; adding "--with-x" as is
>> suggested in README-build.html does not help.
>>
>> Trying
>>
>>    bash ./configure CPATH="/usr/X11/include"
>>
>> also fails, complaining about not finding the XRender extensions,
>> so I found that I had to:
>>
>>    bash ./configure CPATH="/opt/X11/include"
>>
>> instead, to get past the configure step.
>>
>> However, when I did that, when I ran "make" it reported:
>>
>> "Building OpenJDK for target 'default' in configuration
>> 'macosx-x86_64-normal-server-release'"
>>
>> and ran until it got to a failure building Solaris X11 stuff,
>> which seemed strange since we are not targeting Solaris, and
>> we do have the XRender extensions including XTest.h:
>>
>> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c:501:
>>
>> warning: assignment makes integer from pointer without a cast
>> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/xawt/XToolkit.c:47:34:
>>
>> warning: X11/extensions/XTest.h: No such file or directory
>> ...
>> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/xawt/XToolkit.c:1031:
>>
>> error: ?XDeviceInfo? undeclared (first use in this function)
>>
>> and at that point I am stumped.
>>
>> The XRender header extensions are present on the system, e.g.,
>>
>>    % find /opt/X11 -name XTest.h
>>    /opt/X11/include/X11/extensions/XTest.h
>>
>> but then I am not sure that these are even required for the Mac?
>>
>> I have tried feeding various combinations of "--with-x=/opt/X11" and
>> CPPFLAGS="-I/opt/X11/include" and even OPENWIN_HOME="/opt/X11" based
>> on what I see in the generated Makefile.
>>
>> But I gave up after I realized that it probably shouldn't be trying to
>> compile the jdk/src/solaris/native sub-tree in the first place, just
>> the share and the macosx trees, right? And I couldn't figure out where
>> in the make or configure it decides to do this or not.
>>
>> David
>>
>> PS. It would be nice if the page of instructions for building the MacOSX
>> port could be updated to mention the need for the configure step, and
>> what arguments to give it, and the make step.
>>
>> On 5/14/13 9:22 PM, Weijun Wang wrote:
>>> Yes, there is a big change in jdk8, you have to use configure now.
>>>
>>> I have Xcode 4.6 and XQuartz 2.7.4, and I can build. What does configure
>>> says about X11?
>>>
>>> -Max
>>>
>>> On 5/15/13 9:10 AM, David Clunie wrote:
>>>> Hi all
>>>>
>>>> I wanted to build the OpenJDK for MacOSX.
>>>>
>>>> I was trying to follow the instructions at:
>>>>
>>>>    https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>>
>>>> but having fetched the code, the build step fails.
>>>>
>>>> The make complains there is no configuration ("No configurations
>>>> found for ...").
>>>>
>>>> By comparison, I fetched jdk7u-dev, and a "make" of that works
>>>> just fine, with no need for a configure step.
>>>>
>>>> I tried "bash ./configure", but it fails with problems related
>>>> to the X11 stuff.
>>>>
>>>> Any advice would be appreciated, since I could spend a while on this
>>>> and it is presumably something everyone else has already solved.
>>>>
>>>> I have OS 10.8.3 and XQuartz 2.7.4 and Xcode 4.6.2 installed.
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>

From dclunie at dclunie.com  Wed May 15 05:15:56 2013
From: dclunie at dclunie.com (David Clunie)
Date: Wed, 15 May 2013 08:15:56 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51937195.6050401@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
Message-ID: <51937C7C.1010907@dclunie.com>

Ok:

% bash configure | grep X
configure: Resolving CXX (as /usr/bin/g++) failed, using /usr/bin/g++ 
directly.
checking resolved symbolic links for CXX... 
/usr/llvm-gcc-4.2/bin/llvm-g++-4.2
checking if CXX is disguised ccache... no, keeping CXX
configure: Resolving CXXCPP (as /usr/llvm-gcc-4.2/bin/llvm-g++-4.2) 
failed, using /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 directly.
checking what is not needed on MacOSX?... alsa pulse x11
checking what is not needed on an X11 build on MacOSX?... alsa pulse
checking for X... libraries /opt/local/lib, headers /opt/local/include
checking for X11/extensions/shape.h... yes
checking for X11/extensions/Xrender.h... yes
checking for X11/extensions/XTest.h... no
configure: error: Could not find all X11 headers (shape.h Xrender.h 
XTest.h).

SO it is not finding X11 in the checking for X step.

Also, what directory are you running this in? I ask because of
the "../.." in your example; I guessed "common/autoconf", but
got the same result:

% ( cd common/autoconf ; bash ../../configure ) | grep X
configure: Resolving CXX (as /usr/bin/g++) failed, using /usr/bin/g++ 
directly.
checking resolved symbolic links for CXX... 
/usr/llvm-gcc-4.2/bin/llvm-g++-4.2
checking if CXX is disguised ccache... no, keeping CXX
configure: Resolving CXXCPP (as /usr/llvm-gcc-4.2/bin/llvm-g++-4.2) 
failed, using /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 directly.
checking what is not needed on MacOSX?... alsa pulse x11
checking what is not needed on an X11 build on MacOSX?... alsa pulse
checking for X... libraries /opt/local/lib, headers /opt/local/include
checking for X11/extensions/shape.h... yes
checking for X11/extensions/Xrender.h... yes
checking for X11/extensions/XTest.h... no
configure: error: Could not find all X11 headers (shape.h Xrender.h 
XTest.h).

David

On 5/15/13 7:29 AM, Weijun Wang wrote:
> My output looks like
>
> $ bash ../../configure | grep X11
> checking what is not needed on an X11 build on MacOSX?... alsa pulse
> checking for X... libraries /usr/X11/lib, headers /usr/X11/include
> checking for X11/extensions/shape.h... yes
> checking for X11/extensions/Xrender.h... yes
> checking for X11/extensions/XTest.h... yes
>
> Notice the extra "checking for X" line.
>
> -Max
>
>
> On 5/15/13 7:09 PM, David Clunie wrote:
>> By the way, the configure output was as follows:
>>
>> % bash configure | grep X11
>> checking what is not needed on an X11 build on MacOSX?... alsa pulse
>> checking for X11/extensions/shape.h... yes
>> checking for X11/extensions/Xrender.h... yes
>> checking for X11/extensions/XTest.h... no
>> configure: error: Could not find all X11 headers (shape.h Xrender.h
>> XTest.h).
>>
>> % bash ./configure --with-x="/opt/X11" | grep X11
>> checking what is not needed on an X11 build on MacOSX?... alsa pulse
>> checking for X11/extensions/shape.h... yes
>> checking for X11/extensions/Xrender.h... yes
>> checking for X11/extensions/XTest.h... no
>> configure: error: Could not find all X11 headers (shape.h Xrender.h
>> XTest.h).
>>
>> % bash ./configure CPATH="/opt/X11/include" | grep X11
>> checking what is not needed on an X11 build on MacOSX?... alsa pulse
>> checking for X11/extensions/shape.h... yes
>> checking for X11/extensions/Xrender.h... yes
>> checking for X11/extensions/XTest.h... yes
>> using configure arguments 'CPATH=/opt/X11/include'.
>>
>> David
>>
>> On 5/15/13 7:03 AM, David Clunie wrote:
>>> Hi Max
>>>
>>> If I run "bash ./configure" it complains about not finding the
>>> X11 headers in the configure step; adding "--with-x" as is
>>> suggested in README-build.html does not help.
>>>
>>> Trying
>>>
>>>    bash ./configure CPATH="/usr/X11/include"
>>>
>>> also fails, complaining about not finding the XRender extensions,
>>> so I found that I had to:
>>>
>>>    bash ./configure CPATH="/opt/X11/include"
>>>
>>> instead, to get past the configure step.
>>>
>>> However, when I did that, when I ran "make" it reported:
>>>
>>> "Building OpenJDK for target 'default' in configuration
>>> 'macosx-x86_64-normal-server-release'"
>>>
>>> and ran until it got to a failure building Solaris X11 stuff,
>>> which seemed strange since we are not targeting Solaris, and
>>> we do have the XRender extensions including XTest.h:
>>>
>>> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c:501:
>>>
>>>
>>> warning: assignment makes integer from pointer without a cast
>>> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/xawt/XToolkit.c:47:34:
>>>
>>>
>>> warning: X11/extensions/XTest.h: No such file or directory
>>> ...
>>> /Users/dclunie/Distributions/java/OpenJDK/jdk8/jdk/src/solaris/native/sun/xawt/XToolkit.c:1031:
>>>
>>>
>>> error: ?XDeviceInfo? undeclared (first use in this function)
>>>
>>> and at that point I am stumped.
>>>
>>> The XRender header extensions are present on the system, e.g.,
>>>
>>>    % find /opt/X11 -name XTest.h
>>>    /opt/X11/include/X11/extensions/XTest.h
>>>
>>> but then I am not sure that these are even required for the Mac?
>>>
>>> I have tried feeding various combinations of "--with-x=/opt/X11" and
>>> CPPFLAGS="-I/opt/X11/include" and even OPENWIN_HOME="/opt/X11" based
>>> on what I see in the generated Makefile.
>>>
>>> But I gave up after I realized that it probably shouldn't be trying to
>>> compile the jdk/src/solaris/native sub-tree in the first place, just
>>> the share and the macosx trees, right? And I couldn't figure out where
>>> in the make or configure it decides to do this or not.
>>>
>>> David
>>>
>>> PS. It would be nice if the page of instructions for building the MacOSX
>>> port could be updated to mention the need for the configure step, and
>>> what arguments to give it, and the make step.
>>>
>>> On 5/14/13 9:22 PM, Weijun Wang wrote:
>>>> Yes, there is a big change in jdk8, you have to use configure now.
>>>>
>>>> I have Xcode 4.6 and XQuartz 2.7.4, and I can build. What does
>>>> configure
>>>> says about X11?
>>>>
>>>> -Max
>>>>
>>>> On 5/15/13 9:10 AM, David Clunie wrote:
>>>>> Hi all
>>>>>
>>>>> I wanted to build the OpenJDK for MacOSX.
>>>>>
>>>>> I was trying to follow the instructions at:
>>>>>
>>>>>    https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>>>
>>>>> but having fetched the code, the build step fails.
>>>>>
>>>>> The make complains there is no configuration ("No configurations
>>>>> found for ...").
>>>>>
>>>>> By comparison, I fetched jdk7u-dev, and a "make" of that works
>>>>> just fine, with no need for a configure step.
>>>>>
>>>>> I tried "bash ./configure", but it fails with problems related
>>>>> to the X11 stuff.
>>>>>
>>>>> Any advice would be appreciated, since I could spend a while on this
>>>>> and it is presumably something everyone else has already solved.
>>>>>
>>>>> I have OS 10.8.3 and XQuartz 2.7.4 and Xcode 4.6.2 installed.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>
>

From weijun.wang at oracle.com  Wed May 15 06:43:50 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 15 May 2013 21:43:50 +0800
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51937C7C.1010907@dclunie.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com>
Message-ID: <51939116.4080308@oracle.com>

On 5/15/13 8:15 PM, David Clunie wrote:
> Also, what directory are you running this in?

It's still the one in the root repo. I just created an empty directory 
and run configure inside it. This would generate the Makefile in the 
directory so you can maintain multiple styles of builds.

-Max

From dclunie at dclunie.com  Wed May 15 07:14:53 2013
From: dclunie at dclunie.com (David Clunie)
Date: Wed, 15 May 2013 10:14:53 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51939116.4080308@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <51939116.4080308@oracle.com>
Message-ID: <5193985D.9070100@dclunie.com>

Do you have any insight into why it is working for you and
not for me?

David

On 5/15/13 9:43 AM, Weijun Wang wrote:
> On 5/15/13 8:15 PM, David Clunie wrote:
>> Also, what directory are you running this in?
>
> It's still the one in the root repo. I just created an empty directory
> and run configure inside it. This would generate the Makefile in the
> directory so you can maintain multiple styles of builds.
>
> -Max
>
>

From weijun.wang at oracle.com  Wed May 15 07:21:52 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 15 May 2013 22:21:52 +0800
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <5193985D.9070100@dclunie.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <51939116.4080308@oracle.com>
	<5193985D.9070100@dclunie.com>
Message-ID: <51939A00.1040307@oracle.com>



On 5/15/13 10:14 PM, David Clunie wrote:
> Do you have any insight into why it is working for you and
> not for me?

No.

-Max

>
> David
>
> On 5/15/13 9:43 AM, Weijun Wang wrote:
>> On 5/15/13 8:15 PM, David Clunie wrote:
>>> Also, what directory are you running this in?
>>
>> It's still the one in the root repo. I just created an empty directory
>> and run configure inside it. This would generate the Makefile in the
>> directory so you can maintain multiple styles of builds.
>>
>> -Max
>>
>>

From pranav.bhat at oracle.com  Wed May 15 07:40:33 2013
From: pranav.bhat at oracle.com (Pranav Bhat)
Date: Wed, 15 May 2013 10:40:33 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51939A00.1040307@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <51939116.4080308@oracle.com>
	<5193985D.9070100@dclunie.com> <51939A00.1040307@oracle.com>
Message-ID: <8D88731A-7F6E-4E43-8ABA-1C0109CD44B3@oracle.com>

David,

Please see the system setup section on the openJDK 8 read me file - http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#setup

I am not aware of this specific X11 error but have setup several macs using the information as-is mentioned in the above page and it has always worked (for me!)

Hope this helps.

my two cents,
- Pranav

P.S: Also, please note that this page is a more up to date page for openJDK 8 builds (including information for configure and make) as compared to the MacOSX port page.

On May 15, 2013, at 10:21 AM, Weijun Wang <weijun.wang at oracle.com> wrote:

> 
> 
> On 5/15/13 10:14 PM, David Clunie wrote:
>> Do you have any insight into why it is working for you and
>> not for me?
> 
> No.
> 
> -Max
> 
>> 
>> David
>> 
>> On 5/15/13 9:43 AM, Weijun Wang wrote:
>>> On 5/15/13 8:15 PM, David Clunie wrote:
>>>> Also, what directory are you running this in?
>>> 
>>> It's still the one in the root repo. I just created an empty directory
>>> and run configure inside it. This would generate the Makefile in the
>>> directory so you can maintain multiple styles of builds.
>>> 
>>> -Max
>>> 
>>> 


From dclunie at dclunie.com  Wed May 15 08:05:59 2013
From: dclunie at dclunie.com (David Clunie)
Date: Wed, 15 May 2013 11:05:59 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <8D88731A-7F6E-4E43-8ABA-1C0109CD44B3@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <51939116.4080308@oracle.com>
	<5193985D.9070100@dclunie.com> <51939A00.1040307@oracle.com>
	<8D88731A-7F6E-4E43-8ABA-1C0109CD44B3@oracle.com>
Message-ID: <5193A457.3060708@dclunie.com>

Yep, read that, tried it plain and with the --with-x option, to
no avail.

David

On 5/15/13 10:40 AM, Pranav Bhat wrote:
> David,
>
> Please see the system setup section on the openJDK 8 read me file - http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#setup
>
> I am not aware of this specific X11 error but have setup several macs using the information as-is mentioned in the above page and it has always worked (for me!)
>
> Hope this helps.
>
> my two cents,
> - Pranav
>
> P.S: Also, please note that this page is a more up to date page for openJDK 8 builds (including information for configure and make) as compared to the MacOSX port page.
>
> On May 15, 2013, at 10:21 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>
>>
>>
>> On 5/15/13 10:14 PM, David Clunie wrote:
>>> Do you have any insight into why it is working for you and
>>> not for me?
>>
>> No.
>>
>> -Max
>>
>>>
>>> David
>>>
>>> On 5/15/13 9:43 AM, Weijun Wang wrote:
>>>> On 5/15/13 8:15 PM, David Clunie wrote:
>>>>> Also, what directory are you running this in?
>>>>
>>>> It's still the one in the root repo. I just created an empty directory
>>>> and run configure inside it. This would generate the Makefile in the
>>>> directory so you can maintain multiple styles of builds.
>>>>
>>>> -Max
>>>>
>>>>
>
>
>

From dbp at stanford.edu  Wed May 15 12:10:02 2013
From: dbp at stanford.edu (Dave Barker-Plummer)
Date: Wed, 15 May 2013 12:10:02 -0700
Subject: Problems building OpenJDK 8 for MacOSX
Message-ID: <409D909B-D8D9-4E3D-9142-52BB41DAEBDB@stanford.edu>

The X11 application and libraries are not part of Mac OS X Mountain Lion (10.8.x).

Apparently, the libraries are available from the XQuartz project.  See http://support.apple.com/kb/ht5293.

-- Dave




From dclunie at dclunie.com  Wed May 15 15:14:58 2013
From: dclunie at dclunie.com (David Clunie)
Date: Wed, 15 May 2013 18:14:58 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <409D909B-D8D9-4E3D-9142-52BB41DAEBDB@stanford.edu>
References: <409D909B-D8D9-4E3D-9142-52BB41DAEBDB@stanford.edu>
Message-ID: <519408E2.9000701@dclunie.com>

Yes, quite. These are already installed and working on the system
I am using.

The problem seems to be getting the OpenJDK configure to find them
and also not build the Solaris stuff.

David

On 5/15/13 3:10 PM, Dave Barker-Plummer wrote:
> The X11 application and libraries are not part of Mac OS X Mountain Lion (10.8.x).
>
> Apparently, the libraries are available from the XQuartz project.  See http://support.apple.com/kb/ht5293.

From david.dehaven at oracle.com  Wed May 15 16:12:06 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 15 May 2013 16:12:06 -0700
Subject: xawt??
Message-ID: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>


Is there any particular reason xawt (and awt/X11) is being built on Mac?
Is anyone actually using it or is this just some vestige of the initial port that wasn't shut off?

To me it just looks like a whole mass of dead code wasting space in the JRE.

More importantly, it's getting in the way of fixing the Mac OS X jawt_md.h so it's actually usable...

-DrD-


From philip.race at oracle.com  Wed May 15 16:39:15 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 15 May 2013 16:39:15 -0700
Subject: xawt??
In-Reply-To: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
Message-ID: <51941CA3.3040805@oracle.com>

I am pretty sure there is an open bug to stop it building .. although I 
can't locate it.

-phil.

On 5/15/13 4:12 PM, David DeHaven wrote:
> Is there any particular reason xawt (and awt/X11) is being built on Mac?
> Is anyone actually using it or is this just some vestige of the initial port that wasn't shut off?
>
> To me it just looks like a whole mass of dead code wasting space in the JRE.
>
> More importantly, it's getting in the way of fixing the Mac OS X jawt_md.h so it's actually usable...
>
> -DrD-
>


From david.dehaven at oracle.com  Wed May 15 20:24:40 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 15 May 2013 20:24:40 -0700
Subject: xawt??
In-Reply-To: <51941CA3.3040805@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<51941CA3.3040805@oracle.com>
Message-ID: <D05CB554-054A-42B8-B7DD-5A3CA190B058@oracle.com>


That would be good. I'll rummage around and see if I can find it. If I can't find one I may just file a new bug. I got xawt to stop building but there's other X11 code still being compiled.

-DrD-

> I am pretty sure there is an open bug to stop it building .. although I can't locate it.
> 
> -phil.
> 
> On 5/15/13 4:12 PM, David DeHaven wrote:
>> Is there any particular reason xawt (and awt/X11) is being built on Mac?
>> Is anyone actually using it or is this just some vestige of the initial port that wasn't shut off?
>> 
>> To me it just looks like a whole mass of dead code wasting space in the JRE.
>> 
>> More importantly, it's getting in the way of fixing the Mac OS X jawt_md.h so it's actually usable...
>> 
>> -DrD-
>> 
> 


From Sergey.Bylokhov at oracle.com  Thu May 16 04:13:28 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 16 May 2013 15:13:28 +0400
Subject: xawt??
In-Reply-To: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
Message-ID: <5194BF58.7000702@oracle.com>

Hi, David.
Yes there is a bug on it for jdk8. The reason why it is exists, is used 
for comparing of a rendering of aqua/xawt.

On 16.05.2013 3:12, David DeHaven wrote:
> Is there any particular reason xawt (and awt/X11) is being built on Mac?
> Is anyone actually using it or is this just some vestige of the initial port that wasn't shut off?
>
> To me it just looks like a whole mass of dead code wasting space in the JRE.
>
> More importantly, it's getting in the way of fixing the Mac OS X jawt_md.h so it's actually usable...
>
> -DrD-
>


-- 
Best regards, Sergey.


From dclunie at dclunie.com  Thu May 16 07:55:44 2013
From: dclunie at dclunie.com (David Clunie)
Date: Thu, 16 May 2013 10:55:44 -0400
Subject: xawt??
In-Reply-To: <5194BF58.7000702@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
Message-ID: <5194F370.90308@dclunie.com>

Since it is blocking my ability to compile OpenJDK 8 at all
(because the configure script cannot find the X11 stuff on my
system even though it is there), is there a way to turn it off
in configuration?

David

On 5/16/13 7:13 AM, Sergey Bylokhov wrote:
> Hi, David.
> Yes there is a bug on it for jdk8. The reason why it is exists, is used
> for comparing of a rendering of aqua/xawt.
>
> On 16.05.2013 3:12, David DeHaven wrote:
>> Is there any particular reason xawt (and awt/X11) is being built on Mac?
>> Is anyone actually using it or is this just some vestige of the
>> initial port that wasn't shut off?
>>
>> To me it just looks like a whole mass of dead code wasting space in
>> the JRE.
>>
>> More importantly, it's getting in the way of fixing the Mac OS X
>> jawt_md.h so it's actually usable...
>>
>> -DrD-
>>
>
>

From Sergey.Bylokhov at oracle.com  Thu May 16 08:02:48 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 16 May 2013 19:02:48 +0400
Subject: xawt??
In-Reply-To: <5194F370.90308@dclunie.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com> <5194F370.90308@dclunie.com>
Message-ID: <5194F518.1060007@oracle.com>

Hi.
Did you follow the  rules from this page?

https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port

On 16.05.2013 18:55, David Clunie wrote:
> Since it is blocking my ability to compile OpenJDK 8 at all
> (because the configure script cannot find the X11 stuff on my
> system even though it is there), is there a way to turn it off
> in configuration?
>
> David
>
> On 5/16/13 7:13 AM, Sergey Bylokhov wrote:
>> Hi, David.
>> Yes there is a bug on it for jdk8. The reason why it is exists, is used
>> for comparing of a rendering of aqua/xawt.
>>
>> On 16.05.2013 3:12, David DeHaven wrote:
>>> Is there any particular reason xawt (and awt/X11) is being built on 
>>> Mac?
>>> Is anyone actually using it or is this just some vestige of the
>>> initial port that wasn't shut off?
>>>
>>> To me it just looks like a whole mass of dead code wasting space in
>>> the JRE.
>>>
>>> More importantly, it's getting in the way of fixing the Mac OS X
>>> jawt_md.h so it's actually usable...
>>>
>>> -DrD-
>>>
>>
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu May 16 08:13:56 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 16 May 2013 19:13:56 +0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51937C7C.1010907@dclunie.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com>
Message-ID: <5194F7B4.6070700@oracle.com>

On 15.05.2013 16:15, David Clunie wrote:
> Ok:
>
> % bash configure | grep X
> configure: Resolving CXX (as /usr/bin/g++) failed, using /usr/bin/g++ 
> directly.
> checking resolved symbolic links for CXX... 
> /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
> checking if CXX is disguised ccache... no, keeping CXX
> configure: Resolving CXXCPP (as /usr/llvm-gcc-4.2/bin/llvm-g++-4.2) 
> failed, using /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 directly.
> checking what is not needed on MacOSX?... alsa pulse x11
> checking what is not needed on an X11 build on MacOSX?... alsa pulse
> checking for X... libraries /opt/local/lib, headers /opt/local/include
> checking for X11/extensions/shape.h... yes
> checking for X11/extensions/Xrender.h... yes
> checking for X11/extensions/XTest.h... no
> configure: error: Could not find all X11 headers (shape.h Xrender.h 
> XTest.h).
What version of xquartz did you use? I suppose it should include 
XTest.h, Xreneder.

-- 
Best regards, Sergey.


From david.dehaven at oracle.com  Thu May 16 08:36:18 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 16 May 2013 08:36:18 -0700
Subject: xawt??
In-Reply-To: <5194BF58.7000702@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
Message-ID: <1C04C514-D23E-448D-BDC7-0F06B8E7F20C@oracle.com>


I found about four issues pertaining to this particular problem (including the one I'm working on). I think ideally, it should be a configure switch so if someone wants to build it then they can, but for production purposes it should be off.

I was hoping to fix jawt_md.h for 7u40 though...

-DrD-

> Hi, David.
> Yes there is a bug on it for jdk8. The reason why it is exists, is used for comparing of a rendering of aqua/xawt.
> 
> On 16.05.2013 3:12, David DeHaven wrote:
>> Is there any particular reason xawt (and awt/X11) is being built on Mac?
>> Is anyone actually using it or is this just some vestige of the initial port that wasn't shut off?
>> 
>> To me it just looks like a whole mass of dead code wasting space in the JRE.
>> 
>> More importantly, it's getting in the way of fixing the Mac OS X jawt_md.h so it's actually usable...
>> 
>> -DrD-
>> 
> 
> 
> -- 
> Best regards, Sergey.
> 


From davmac at davmac.org  Thu May 16 08:36:41 2013
From: davmac at davmac.org (Davin McCall)
Date: Thu, 16 May 2013 16:36:41 +0100
Subject: Java app uses own launcher and bundles JDK but OS X still insists
	that Java SE 6 be installed
Message-ID: <5194FD09.2070307@davmac.org>

Hi,

I am responsible for a Java application which is deployed on multiple 
platforms including OS X. With recent versions of the application we 
distribute two separate bundles for OS X - one which uses the 
JavaApplicationStub provided by Apple, and another one which includes a 
bundled JDK 7 and uses a launcher produced in-house (a modification of 
Oracle's JavaAppLauncher).

The issue is, with the latter bundle, Mac OS X still insists on you 
having Java 6 installed if you try to run the application. Specifically 
the message says:

"To open (application), you need a Java SE 6 runtime. Would you like to 
install one now?"

If you don't install Java SE 6, you are unable to run the application, 
despite the fact that JDK 7 is bundled (and, if you do install Java 6, 
it nevertheless runs with the bundled Java 7).

What I'm struggling to figure out is how OS X decides that the 
application requires Java? I've tried renaming the 'Java' dictionary in 
the Info.plist file, and renaming the Java subfolder within the 
Resources folder, without success. Does anyone have any ideas? Surely 
it's possible to have an application with a bundled JDK run without 
requiring a system JDK to be installed?

I've also asked this on StackOverflow:
http://stackoverflow.com/questions/16591780/how-does-mac-os-x-determine-that-an-application-needs-java

Thanks to anyone who can insist,

Davin


From private at claudio.ch  Thu May 16 08:44:55 2013
From: private at claudio.ch (Claudio Nieder)
Date: Thu, 16 May 2013 17:44:55 +0200
Subject: xawt??
In-Reply-To: <5194BF58.7000702@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
Message-ID: <C2D50D64-830A-4E26-AE51-D06D4D158827@claudio.ch>

Hi,

> (because the configure script cannot find the X11 stuff on my
> system even though it is there), is there a way to turn it off

Can you check if you have /opt/X11/include and /opt/X11/lib on your system? They should be installed there by XQuartz.

Furthermore can you check if there is a link like this:

$ ls -l /usr/X11
lrwxr-xr-x  1 root  wheel  8 Jul 28  2012 /usr/X11 -> /opt/X11

pointing from /usr/X11 to /opt/X11.

I wrote weeks ago the attached script to fetch and compile JDK8 (it will do all in $HOME/Dowloads/JDK8). I tried it just a few minutes ago and it works provided XQuartz is available as described above.

Here the script in the hope it can help you build JDK8.


-------------- next part --------------


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





From swingler at apple.com  Thu May 16 08:51:53 2013
From: swingler at apple.com (Mike Swingler)
Date: Thu, 16 May 2013 08:51:53 -0700
Subject: Java app uses own launcher and bundles JDK but OS X still insists
	that Java SE 6 be installed
In-Reply-To: <5194FD09.2070307@davmac.org>
References: <5194FD09.2070307@davmac.org>
Message-ID: <66A6B3F9-E133-4BD8-B4D2-0C3AB137B524@apple.com>

On May 16, 2013, at 8:36 AM, Davin McCall <davmac at davmac.org> wrote:

> Hi,
> 
> I am responsible for a Java application which is deployed on multiple platforms including OS X. With recent versions of the application we distribute two separate bundles for OS X - one which uses the JavaApplicationStub provided by Apple, and another one which includes a bundled JDK 7 and uses a launcher produced in-house (a modification of Oracle's JavaAppLauncher).
> 
> The issue is, with the latter bundle, Mac OS X still insists on you having Java 6 installed if you try to run the application. Specifically the message says:
> 
> "To open (application), you need a Java SE 6 runtime. Would you like to install one now?"
> 
> If you don't install Java SE 6, you are unable to run the application, despite the fact that JDK 7 is bundled (and, if you do install Java 6, it nevertheless runs with the bundled Java 7).
> 
> What I'm struggling to figure out is how OS X decides that the application requires Java? I've tried renaming the 'Java' dictionary in the Info.plist file, and renaming the Java subfolder within the Resources folder, without success. Does anyone have any ideas? Surely it's possible to have an application with a bundled JDK run without requiring a system JDK to be installed?
> 
> I've also asked this on StackOverflow:
> http://stackoverflow.com/questions/16591780/how-does-mac-os-x-determine-that-an-application-needs-java

OS X uses the "Java" dictionary in the .app's Info.plist before the executable is launched.

Afterwards, if you have a primary executable or a library that loads before HotSpot which is linked against the JavaVM.framework, that will also kill the app, and trigger the Install-on-Demand experience.

I'd suggest checking your binaries with "otool -L".

Regards,
Mike Swingler
Apple Inc.

From artem.ananiev at oracle.com  Thu May 16 08:58:55 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 16 May 2013 19:58:55 +0400
Subject: xawt??
In-Reply-To: <1C04C514-D23E-448D-BDC7-0F06B8E7F20C@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
	<1C04C514-D23E-448D-BDC7-0F06B8E7F20C@oracle.com>
Message-ID: <5195023F.7090203@oracle.com>


On 5/16/2013 7:36 PM, David DeHaven wrote:
>
> I found about four issues pertaining to this particular problem (including the one I'm working on). I think ideally, it should be a configure switch so if someone wants to build it then they can, but for production purposes it should be off.
>
> I was hoping to fix jawt_md.h for 7u40 though...

Such a change as removing XAWT should be done in major releases. When a 
component becomes obsolete, it is first made non-default, then 
deprecated in the next major release, then removed in the next next 
major release. This is what we did for MToolkit, for example.

So let us get rid of XAWT in JDK8, not 7uX.

Thanks,

Artem

> -DrD-
>
>> Hi, David.
>> Yes there is a bug on it for jdk8. The reason why it is exists, is used for comparing of a rendering of aqua/xawt.
>>
>> On 16.05.2013 3:12, David DeHaven wrote:
>>> Is there any particular reason xawt (and awt/X11) is being built on Mac?
>>> Is anyone actually using it or is this just some vestige of the initial port that wasn't shut off?
>>>
>>> To me it just looks like a whole mass of dead code wasting space in the JRE.
>>>
>>> More importantly, it's getting in the way of fixing the Mac OS X jawt_md.h so it's actually usable...
>>>
>>> -DrD-
>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>

From davmac at davmac.org  Thu May 16 09:11:03 2013
From: davmac at davmac.org (Davin McCall)
Date: Thu, 16 May 2013 17:11:03 +0100
Subject: Java app uses own launcher and bundles JDK but OS X still insists
	that Java SE 6 be installed
In-Reply-To: <66A6B3F9-E133-4BD8-B4D2-0C3AB137B524@apple.com>
References: <5194FD09.2070307@davmac.org>
	<66A6B3F9-E133-4BD8-B4D2-0C3AB137B524@apple.com>
Message-ID: <51950517.1090901@davmac.org>

On 16/05/13 16:51, Mike Swingler wrote:
> OS X uses the "Java" dictionary in the .app's Info.plist before the executable is launched.
>
> Afterwards, if you have a primary executable or a library that loads before HotSpot which is linked against the JavaVM.framework, that will also kill the app, and trigger the Install-on-Demand experience.
>
> I'd suggest checking your binaries with "otool -L".

Mike, thanks for your reply. I've renamed the "Java" dictionary to 
"XXXX" but I still get the dialog requesting that I install Java 6.

If I run "otool -L" I get:

BlueJ.app/Contents/MacOS/JavaAppLauncher:
     /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 17.0.0)
     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 159.1.0)
     /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current 
version 228.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 635.21.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 833.25.0)
     /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
(compatibility version 45.0.0, current version 1138.47.0)

As you can see, the executable isn't linked against the JavaVM.framework 
(it loads it dynamically, and I'm confident that it's loading the 
bundled one).

When I run the app directly from the terminal, I don't get the dialog 
requesting Java 6.

Any other suggestions?

Davin


From davmac at davmac.org  Thu May 16 09:29:01 2013
From: davmac at davmac.org (Davin McCall)
Date: Thu, 16 May 2013 17:29:01 +0100
Subject: Java app uses own launcher and bundles JDK but OS X still insists
	that Java SE 6 be installed
In-Reply-To: <51950517.1090901@davmac.org>
References: <5194FD09.2070307@davmac.org>
	<66A6B3F9-E133-4BD8-B4D2-0C3AB137B524@apple.com>
	<51950517.1090901@davmac.org>
Message-ID: <5195094D.5070409@davmac.org>

On 16/05/13 17:11, Davin McCall wrote:
>
> Any other suggestions?
>

Ah, never mind. It seems that the system is doing some caching here; if 
I download a fresh copy of the app, and change the Java dictionary name 
before the first attempt to open the app, it doesn't request Java 6.

So, problem solved - thanks for your help.

Davin


From dclunie at dclunie.com  Thu May 16 09:54:07 2013
From: dclunie at dclunie.com (David Clunie)
Date: Thu, 16 May 2013 12:54:07 -0400
Subject: xawt??
In-Reply-To: <C2D50D64-830A-4E26-AE51-D06D4D158827@claudio.ch>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
	<C2D50D64-830A-4E26-AE51-D06D4D158827@claudio.ch>
Message-ID: <51950F2F.1050204@dclunie.com>

Hi Claudio

Thanks, but there was no script attached, unfortunately.

Yes, I have all those, and the current version of XQuartz:

% ls -l /opt/X11/include
total 96
drwxr-xr-x   23 root      wheel    782 Jan 18 17:09 GL
drwxr-xr-x    6 root      wheel    204 Jan 18 17:09 VG
drwxr-xr-x   88 root      wheel   2992 Jan 18 17:09 X11
-r--r--r--    1 root      wheel  25545 Sep 27  2012 Xplugin.h
drwxr-xr-x   18 root      wheel    612 Jan 18 17:09 cairo
drwxr-xr-x    5 root      wheel    170 Jan 18 17:09 fontconfig
drwxr-xr-x    3 root      wheel    102 Dec 19  2010 freetype2
-rw-r--r--    1 root      wheel   3890 Sep 27  2012 ft2build.h
drwxr-xr-x    5 root      wheel    170 Jan 18 17:09 libpng15
drwxr-xr-x    4 root      wheel    136 Jan 18 17:09 pixman-1
lrwxr-xr-x    1 macports  wheel     14 Jan 18 17:09 png.h -> libpng15/png.h
lrwxr-xr-x    1 macports  wheel     18 Jan 18 17:09 pngconf.h -> 
libpng15/pngconf.h
lrwxr-xr-x    1 macports  wheel     21 Jan 18 17:09 pnglibconf.h -> 
libpng15/pnglibconf.h
drwxr-xr-x   42 root      wheel   1428 Jan 18 17:09 xcb
drwxr-xr-x  162 root      wheel   5508 Jan 18 17:09 xorg
-rw-r--r--    1 root      wheel    518 Sep 27  2012 xpyb.h

% ls -l /usr/X11
lrwxr-xr-x  1 root  wheel  8 Jan 18 17:09 /usr/X11 -> /opt/X11


On 5/16/13 11:44 AM, Claudio Nieder wrote:
> Hi,
>
>> (because the configure script cannot find the X11 stuff on my
>> system even though it is there), is there a way to turn it off
>
> Can you check if you have /opt/X11/include and /opt/X11/lib on your system? They should be installed there by XQuartz.
>
> Furthermore can you check if there is a link like this:
>
> $ ls -l /usr/X11
> lrwxr-xr-x  1 root  wheel  8 Jul 28  2012 /usr/X11 -> /opt/X11
>
> pointing from /usr/X11 to /opt/X11.
>
> I wrote weeks ago the attached script to fetch and compile JDK8 (it will do all in $HOME/Dowloads/JDK8). I tried it just a few minutes ago and it works provided XQuartz is available as described above.
>
> Here the script in the hope it can help you build JDK8.
>
>
>
>
>
>
> claudio
>

From philip.race at oracle.com  Thu May 16 09:57:03 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 16 May 2013 09:57:03 -0700
Subject: xawt??
In-Reply-To: <5195023F.7090203@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
	<1C04C514-D23E-448D-BDC7-0F06B8E7F20C@oracle.com>
	<5195023F.7090203@oracle.com>
Message-ID: <51950FDF.4090902@oracle.com>

Artem,

Is http://bugs.sun.com/view_bug.do?bug_id=8001338
[macosx] -Dawt.toolkit=sun.awt.X11.XToolkit option does not work

considered to be the right bug to track this, since the last comment is

"I think that we should not support XToolkit on Mac OS X." ?

-phil.

On 5/16/2013 8:58 AM, Artem Ananiev wrote:
>
> On 5/16/2013 7:36 PM, David DeHaven wrote:
>>
>> I found about four issues pertaining to this particular problem 
>> (including the one I'm working on). I think ideally, it should be a 
>> configure switch so if someone wants to build it then they can, but 
>> for production purposes it should be off.
>>
>> I was hoping to fix jawt_md.h for 7u40 though...
>
> Such a change as removing XAWT should be done in major releases. When 
> a component becomes obsolete, it is first made non-default, then 
> deprecated in the next major release, then removed in the next next 
> major release. This is what we did for MToolkit, for example.
>
> So let us get rid of XAWT in JDK8, not 7uX.
>
> Thanks,
>
> Artem
>
>> -DrD-
>>
>>> Hi, David.
>>> Yes there is a bug on it for jdk8. The reason why it is exists, is 
>>> used for comparing of a rendering of aqua/xawt.
>>>
>>> On 16.05.2013 3:12, David DeHaven wrote:
>>>> Is there any particular reason xawt (and awt/X11) is being built on 
>>>> Mac?
>>>> Is anyone actually using it or is this just some vestige of the 
>>>> initial port that wasn't shut off?
>>>>
>>>> To me it just looks like a whole mass of dead code wasting space in 
>>>> the JRE.
>>>>
>>>> More importantly, it's getting in the way of fixing the Mac OS X 
>>>> jawt_md.h so it's actually usable...
>>>>
>>>> -DrD-
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>>


From dclunie at dclunie.com  Thu May 16 09:55:36 2013
From: dclunie at dclunie.com (David Clunie)
Date: Thu, 16 May 2013 12:55:36 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <5194F7B4.6070700@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <5194F7B4.6070700@oracle.com>
Message-ID: <51950F88.6070503@dclunie.com>

XQuartz is 2.7.4.

% find /opt/X11 -name XTest.h
/opt/X11/include/X11/extensions/XTest.h

% find /opt/X11 -name Xrender.h
/opt/X11/include/X11/extensions/Xrender.h

David

On 5/16/13 11:13 AM, Sergey Bylokhov wrote:
> On 15.05.2013 16:15, David Clunie wrote:
>> Ok:
>>
>> % bash configure | grep X
>> configure: Resolving CXX (as /usr/bin/g++) failed, using /usr/bin/g++
>> directly.
>> checking resolved symbolic links for CXX...
>> /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
>> checking if CXX is disguised ccache... no, keeping CXX
>> configure: Resolving CXXCPP (as /usr/llvm-gcc-4.2/bin/llvm-g++-4.2)
>> failed, using /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 directly.
>> checking what is not needed on MacOSX?... alsa pulse x11
>> checking what is not needed on an X11 build on MacOSX?... alsa pulse
>> checking for X... libraries /opt/local/lib, headers /opt/local/include
>> checking for X11/extensions/shape.h... yes
>> checking for X11/extensions/Xrender.h... yes
>> checking for X11/extensions/XTest.h... no
>> configure: error: Could not find all X11 headers (shape.h Xrender.h
>> XTest.h).
> What version of xquartz did you use? I suppose it should include
> XTest.h, Xreneder.
>

From artem.ananiev at oracle.com  Thu May 16 10:04:01 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 16 May 2013 21:04:01 +0400
Subject: xawt??
In-Reply-To: <51950FDF.4090902@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
	<1C04C514-D23E-448D-BDC7-0F06B8E7F20C@oracle.com>
	<5195023F.7090203@oracle.com> <51950FDF.4090902@oracle.com>
Message-ID: <51951181.3080602@oracle.com>


On 5/16/2013 8:57 PM, Phil Race wrote:
> Artem,
>
> Is http://bugs.sun.com/view_bug.do?bug_id=8001338
> [macosx] -Dawt.toolkit=sun.awt.X11.XToolkit option does not work
>
> considered to be the right bug to track this, since the last comment is
>
> "I think that we should not support XToolkit on Mac OS X." ?

No, it's a separate issue. As written in the bug comments, XToolkit 
works on OS X in general, it just doesn't start if only awt.toolkit is 
specified. If, in addition to awt.toolkit, you also specify the right 
java.awt.graphicsenv, it will launch.

The comment is correct, but it doesn't say anything about what JDK 
version XToolkit should not be supported in :) As I wrote in the 
previous email, my vote is JDK8.

Thanks,

Artem

> -phil.
>
> On 5/16/2013 8:58 AM, Artem Ananiev wrote:
>>
>> On 5/16/2013 7:36 PM, David DeHaven wrote:
>>>
>>> I found about four issues pertaining to this particular problem
>>> (including the one I'm working on). I think ideally, it should be a
>>> configure switch so if someone wants to build it then they can, but
>>> for production purposes it should be off.
>>>
>>> I was hoping to fix jawt_md.h for 7u40 though...
>>
>> Such a change as removing XAWT should be done in major releases. When
>> a component becomes obsolete, it is first made non-default, then
>> deprecated in the next major release, then removed in the next next
>> major release. This is what we did for MToolkit, for example.
>>
>> So let us get rid of XAWT in JDK8, not 7uX.
>>
>> Thanks,
>>
>> Artem
>>
>>> -DrD-
>>>
>>>> Hi, David.
>>>> Yes there is a bug on it for jdk8. The reason why it is exists, is
>>>> used for comparing of a rendering of aqua/xawt.
>>>>
>>>> On 16.05.2013 3:12, David DeHaven wrote:
>>>>> Is there any particular reason xawt (and awt/X11) is being built on
>>>>> Mac?
>>>>> Is anyone actually using it or is this just some vestige of the
>>>>> initial port that wasn't shut off?
>>>>>
>>>>> To me it just looks like a whole mass of dead code wasting space in
>>>>> the JRE.
>>>>>
>>>>> More importantly, it's getting in the way of fixing the Mac OS X
>>>>> jawt_md.h so it's actually usable...
>>>>>
>>>>> -DrD-
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>>
>>>
>

From Sergey.Bylokhov at oracle.com  Thu May 16 10:18:26 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 16 May 2013 21:18:26 +0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51937C7C.1010907@dclunie.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com>
Message-ID: <519514E2.7080402@oracle.com>

On 15.05.2013 16:15, David Clunie wrote:
> Ok:
>
> % bash configure | grep X
> configure: Resolving CXX (as /usr/bin/g++) failed, using /usr/bin/g++ 
> directly.
> checking resolved symbolic links for CXX... 
> /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
> checking if CXX is disguised ccache... no, keeping CXX
> configure: Resolving CXXCPP (as /usr/llvm-gcc-4.2/bin/llvm-g++-4.2) 
> failed, using /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 directly.
> checking what is not needed on MacOSX?... alsa pulse x11
> checking what is not needed on an X11 build on MacOSX?... alsa pulse
> checking for X... libraries /opt/local/lib, headers /opt/local/include
Looks like this path is incorrect /opt/local/include.
There is no such paths on my system.
It should be
checking for X... libraries /usr/X11/lib, headers /usr/X11/include

-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu May 16 10:23:01 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 16 May 2013 10:23:01 -0700
Subject: xawt??
In-Reply-To: <51951181.3080602@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
	<1C04C514-D23E-448D-BDC7-0F06B8E7F20C@oracle.com>
	<5195023F.7090203@oracle.com> <51950FDF.4090902@oracle.com>
	<51951181.3080602@oracle.com>
Message-ID: <519515F5.60203@oracle.com>

On 5/16/2013 10:04 AM, Artem Ananiev wrote:
>
> On 5/16/2013 8:57 PM, Phil Race wrote:
>> Artem,
>>
>> Is http://bugs.sun.com/view_bug.do?bug_id=8001338
>> [macosx] -Dawt.toolkit=sun.awt.X11.XToolkit option does not work
>>
>> considered to be the right bug to track this, since the last comment is
>>
>> "I think that we should not support XToolkit on Mac OS X." ?
>
> No, it's a separate issue. As written in the bug comments, XToolkit 
> works on OS X in general, it just doesn't start if only awt.toolkit is 
> specified. If, in addition to awt.toolkit, you also specify the right 
> java.awt.graphicsenv, it will launch.
>
> The comment is correct, but it doesn't say anything about what JDK 
> version XToolkit should not be supported in :) As I wrote in the 
> previous email, my vote is JDK8.

Artem,

I know that. What I am asking is what is the bug id used to track the 
build change ?
I spent a while searching and that's the closest match I found.

-phil.

>
> Thanks,
>
> Artem
>
>> -phil.
>>
>> On 5/16/2013 8:58 AM, Artem Ananiev wrote:
>>>
>>> On 5/16/2013 7:36 PM, David DeHaven wrote:
>>>>
>>>> I found about four issues pertaining to this particular problem
>>>> (including the one I'm working on). I think ideally, it should be a
>>>> configure switch so if someone wants to build it then they can, but
>>>> for production purposes it should be off.
>>>>
>>>> I was hoping to fix jawt_md.h for 7u40 though...
>>>
>>> Such a change as removing XAWT should be done in major releases. When
>>> a component becomes obsolete, it is first made non-default, then
>>> deprecated in the next major release, then removed in the next next
>>> major release. This is what we did for MToolkit, for example.
>>>
>>> So let us get rid of XAWT in JDK8, not 7uX.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> -DrD-
>>>>
>>>>> Hi, David.
>>>>> Yes there is a bug on it for jdk8. The reason why it is exists, is
>>>>> used for comparing of a rendering of aqua/xawt.
>>>>>
>>>>> On 16.05.2013 3:12, David DeHaven wrote:
>>>>>> Is there any particular reason xawt (and awt/X11) is being built on
>>>>>> Mac?
>>>>>> Is anyone actually using it or is this just some vestige of the
>>>>>> initial port that wasn't shut off?
>>>>>>
>>>>>> To me it just looks like a whole mass of dead code wasting space in
>>>>>> the JRE.
>>>>>>
>>>>>> More importantly, it's getting in the way of fixing the Mac OS X
>>>>>> jawt_md.h so it's actually usable...
>>>>>>
>>>>>> -DrD-
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>>
>>>>
>>


From david.dehaven at oracle.com  Thu May 16 10:29:23 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 16 May 2013 10:29:23 -0700
Subject: xawt??
In-Reply-To: <51951181.3080602@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
	<1C04C514-D23E-448D-BDC7-0F06B8E7F20C@oracle.com>
	<5195023F.7090203@oracle.com> <51950FDF.4090902@oracle.com>
	<51951181.3080602@oracle.com>
Message-ID: <8B3F605E-0D28-4C51-990D-252A332FAAA4@oracle.com>


>> Artem,
>> 
>> Is http://bugs.sun.com/view_bug.do?bug_id=8001338
>> [macosx] -Dawt.toolkit=sun.awt.X11.XToolkit option does not work
>> 
>> considered to be the right bug to track this, since the last comment is
>> 
>> "I think that we should not support XToolkit on Mac OS X." ?
> 
> No, it's a separate issue. As written in the bug comments, XToolkit works on OS X in general, it just doesn't start if only awt.toolkit is specified. If, in addition to awt.toolkit, you also specify the right java.awt.graphicsenv, it will launch.
> 
> The comment is correct, but it doesn't say anything about what JDK version XToolkit should not be supported in :) As I wrote in the previous email, my vote is JDK8.

Ok, I'll skip disabling xawt on Mac for 7u (it's a lot of work mangling the old build system anyways :). 

I guess if xawt is being built (and can actually be *used*) then maybe I should leave the X11 bits inside the header, but make them opt-in (via macros) with a note that the X11 interface is deprecated on Mac so as to not require developers to have the X11 headers just to use the CALayer DrawingSurface stuff. For JDK8 the X11 bits will be removed when xawt is properly disabled. This should require only minor changes to the build system...

-DrD-


From david.dehaven at oracle.com  Thu May 16 10:34:34 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 16 May 2013 10:34:34 -0700
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <519514E2.7080402@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <519514E2.7080402@oracle.com>
Message-ID: <74AA9F37-3D02-4728-B097-2AC7EC5D735F@oracle.com>


>> % bash configure | grep X
>> configure: Resolving CXX (as /usr/bin/g++) failed, using /usr/bin/g++ directly.
>> checking resolved symbolic links for CXX... /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
>> checking if CXX is disguised ccache... no, keeping CXX
>> configure: Resolving CXXCPP (as /usr/llvm-gcc-4.2/bin/llvm-g++-4.2) failed, using /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 directly.
>> checking what is not needed on MacOSX?... alsa pulse x11
>> checking what is not needed on an X11 build on MacOSX?... alsa pulse
>> checking for X... libraries /opt/local/lib, headers /opt/local/include
> Looks like this path is incorrect /opt/local/include.
> There is no such paths on my system.
> It should be
> checking for X... libraries /usr/X11/lib, headers /usr/X11/include

/opt/local is where the MacPorts headers and lib would be located. Maybe try deactivating XFree86 in MacPorts first.

-DrD-


From private at claudio.ch  Thu May 16 12:43:42 2013
From: private at claudio.ch (Claudio Nieder)
Date: Thu, 16 May 2013 21:43:42 +0200
Subject: xawt??
In-Reply-To: <C2D50D64-830A-4E26-AE51-D06D4D158827@claudio.ch>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
	<C2D50D64-830A-4E26-AE51-D06D4D158827@claudio.ch>
Message-ID: <6116EB60-9A37-4DE7-ADA5-019A11EDCA79@claudio.ch>

Hi,

> Thanks, but there was no script attached, unfortunately.

It looks like the list stripped it away. Here now in the mail:


#!/bin/bash -x

if ! type -p hg; then
 echo "Need mercurial to check out."
 exit 1
fi

logfile='/tmp/JDKLOG.txt'

echo "Output redirected to /tmp/JDKLOG.txt"
exec >"$logfile" 2>&1

JDK8DIRNAME=jdk8-build
WORKDIR="$HOME/Downloads/JDK8"
JDK8DIR="$WORKDIR/$JDK8DIRNAME"
HSDISDIR="${JDK8DIR}/hotspot/src/share/tools/hsdis"

APPDIR="$HOME/Applications"
DESTDIR="$APPDIR/JDK8"
DESTDIR_FASTDEBUG="$APPDIR/JDK8_fastdebug"

BUILDDIR="${JDK8DIR}/build"
BUNDLEDIR="$BUILDDIR/macosx-x86_64-normal-server-release/images/j2sdk-bundle/jdk1.8.0.jdk"
BUNDLEDIR_FASTDEBUG="$BUILDDIR/macosx-x86_64-normal-server-fastdebug/images/j2sdk-bundle/jdk1.8.0.jdk"

JAVA='Contents/Home/bin/java'

RSYNC_FLAGS='-FFHSacy --delete --partial'

# Fetch/Update source (includes macosx-port)

if [ ! -d "${JDK8DIR}" ]; then
 mkdir -p "$WORKDIR"
 cd "$WORKDIR"
 hg clone http://hg.openjdk.java.net/jdk8/build "$JDK8DIRNAME"
fi
cd "${JDK8DIR}"
. get_source.sh

cd "${HSDISDIR}"
BINUTILS_VER=binutils-2.22
rsync -Pavz "rsync://ftp.gnu.org/ftp/binutils/${BINUTILS_VER}.tar.bz2" .
mkdir -p build
tar xf "${BINUTILS_VER}.tar.bz2" -C build -s"/${BINUTILS_VER}/binutils/"
make all64
# make demo64 && ./build/macosx-amd64/hsdis-demo

cd "${JDK8DIR}"

lastTag=$(hg tags | grep '^jdk' | head -1 | perl -pe 's/.*-(b\d+).*/$1/')
CONFFLAGS="--enable-unlimited-crypto --with-build-number=$lastTag"

bash ./configure ${CONFFLAGS}
bash ./configure ${CONFFLAGS} --with-debug-level=fastdebug

if make CONF=macosx-x86_64-normal-server-release all; then
 if time "$BUNDLEDIR/$JAVA" -version; then
  cp -v "$HSDISDIR/build/macosx-amd64/hsdis-amd64.dylib" "$BUNDLEDIR/Contents/Home/jre/lib/"
#  mkdir -p "$DESTDIR"
#  rsync $RSYNC_FLAGS "$BUNDLEDIR_FASTDEBUG" "$DESTDIR"
 fi
fi
if make CONF=macosx-x86_64-normal-server-fastdebug all; then
 if time "$BUNDLEDIR_FASTDEBUG/$JAVA" -version; then
  cp -v "$HSDISDIR/build/macosx-amd64/hsdis-amd64.dylib" "$BUNDLEDIR_FASTDEBUG/Contents/Home/jre/lib/"
#  mkdir -p "$DESTDIR_FASTDEBUG"
#  rsync $RSYNC_FLAGS "$BUNDLEDIR_FASTDEBUG" "$DESTDIR_FASTDEBUG"
 fi
fi

exit 0

# New try to force new version number.

export BUNDLE_VENDOR="Claudio"

lastTag=$(hg tags | grep '^jdk' | head -1 | perl -pe 's/ .*//s; s/-//')

lastTagArr=$(echo "${lastTag}" | perl -ne 'if (m"(\d+)u(\d+)b(\d+)") { print("$1 $2 $3"); } elsif (m"(\d+)-b(\d+)") { print("$1,$2")}')
buildDate=$(date +%Y%m%dT%H%M)

export BUNDLE_VERSION=$(perl -e 'if(@ARGV==2){$f="1.%d.0-b%d";}else{$f="1.%d.0_%02d-b%d";} printf($f, at ARGV)' $lastTagArr)
#export BUILD_NUMBER=$(echo ${BUNDLE_VERSION}|sed -e 's/.*b/b/')

export BUNDLE_INFO_JRE="${BUNDLE_VENDOR}-JRE (${BUNDLE_VERSION})"
export BUNDLE_INFO_JDK="${BUNDLE_VENDOR}-JDK (${BUNDLE_VERSION})"
export BUNDLE_NAME_JRE="${BUNDLE_VENDOR}-JRE ${BUNDLE_VERSION}"
export BUNDLE_NAME_JDK="${BUNDLE_VENDOR}-JDK ${BUNDLE_VERSION}"

export USER_RELEASE_SUFFIX="claudio_${lastTag}_${buildDate}"

echo "${USER_RELEASE_SUFFIX}"

find "$BUILDDIR" -name 'Version.*' -exec touch {} \; 
find "$BUILDDIR" -name 'main.?' -exec touch {} \; 
sleep 2
touch jdk/src/share/classes/sun/misc/Version.java.template jdk/src/share/bin/main.c



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





From swingler at apple.com  Thu May 16 12:48:02 2013
From: swingler at apple.com (Mike Swingler)
Date: Thu, 16 May 2013 12:48:02 -0700
Subject: Java app uses own launcher and bundles JDK but OS X still insists
	that Java SE 6 be installed
In-Reply-To: <5195094D.5070409@davmac.org>
References: <5194FD09.2070307@davmac.org>
	<66A6B3F9-E133-4BD8-B4D2-0C3AB137B524@apple.com>
	<51950517.1090901@davmac.org> <5195094D.5070409@davmac.org>
Message-ID: <6F952CB1-D9CA-4CE2-8BA4-23BBC86A90A3@apple.com>

On May 16, 2013, at 9:29 AM, Davin McCall <davmac at davmac.org> wrote:

> On 16/05/13 17:11, Davin McCall wrote:
>> 
>> Any other suggestions?
> 
> Ah, never mind. It seems that the system is doing some caching here; if I download a fresh copy of the app, and change the Java dictionary name before the first attempt to open the app, it doesn't request Java 6.
> 
> So, problem solved - thanks for your help.

Just renaming the app, and then renaming it back to the original name should flush the cached entry in the LaunchServices database.

Glad you got it figured out,
Mike Swingler
Apple Inc.


From dclunie at dclunie.com  Thu May 16 14:16:05 2013
From: dclunie at dclunie.com (David Clunie)
Date: Thu, 16 May 2013 17:16:05 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <74AA9F37-3D02-4728-B097-2AC7EC5D735F@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <519514E2.7080402@oracle.com>
	<74AA9F37-3D02-4728-B097-2AC7EC5D735F@oracle.com>
Message-ID: <51954C95.8080408@dclunie.com>

Hi David

Thanks, that was it.

Though I did not have port XFree86 installed, there were a bunch of
other X11 related packages installed in support of other ports.

So I just moved "/opt/local" out of the way temporarily, and then
a "bash configure" and "make all" worked.

It would be nice if:

- the configure scripts could run despite there being X11 related ports
   and could prioritize /opt/X11 over /opt/local

- the page at

   "https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port"

   could be updated to reference

 
"http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#setup"

   as well as be specific about needing the "bash configure" step, and
   needing "make all" or "make images" not just plain make (else no
   bundle is built), and that the bundle to copy to JavaVirtualMachines
   will be built in:

 
"build/macosx-x86_64-normal-server-release/images/j2sdk-bundle/jdk1.8.0.jdk"

It would be even nicer if binary builds were distributed so that one
would not have to spend time getting it to build to be able to test
it. I can't imagine how many folks must be put off testing by this
process.

David

On 5/16/13 1:34 PM, David DeHaven wrote:
>
>>> % bash configure | grep X
>>> configure: Resolving CXX (as /usr/bin/g++) failed, using /usr/bin/g++ directly.
>>> checking resolved symbolic links for CXX... /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
>>> checking if CXX is disguised ccache... no, keeping CXX
>>> configure: Resolving CXXCPP (as /usr/llvm-gcc-4.2/bin/llvm-g++-4.2) failed, using /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 directly.
>>> checking what is not needed on MacOSX?... alsa pulse x11
>>> checking what is not needed on an X11 build on MacOSX?... alsa pulse
>>> checking for X... libraries /opt/local/lib, headers /opt/local/include
>> Looks like this path is incorrect /opt/local/include.
>> There is no such paths on my system.
>> It should be
>> checking for X... libraries /usr/X11/lib, headers /usr/X11/include
>
> /opt/local is where the MacPorts headers and lib would be located. Maybe try deactivating XFree86 in MacPorts first.
>
> -DrD-
>
>
>

From philip.race at oracle.com  Thu May 16 14:31:59 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 16 May 2013 14:31:59 -0700
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <51954C95.8080408@dclunie.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <519514E2.7080402@oracle.com>
	<74AA9F37-3D02-4728-B097-2AC7EC5D735F@oracle.com>
	<51954C95.8080408@dclunie.com>
Message-ID: <5195504F.8030305@oracle.com>

On 5/16/2013 2:16 PM, David Clunie wrote:
>
> It would be even nicer if binary builds were distributed so that one
> would not have to spend time getting it to build to be able to test
> it. I can't imagine how many folks must be put off testing by this
> process.
>

But they are ! Every week we create a build from the main JDK master
forest and publish it : https://jdk8.java.net/download.html

-phil.

From dclunie at dclunie.com  Thu May 16 16:44:22 2013
From: dclunie at dclunie.com (David Clunie)
Date: Thu, 16 May 2013 19:44:22 -0400
Subject: Problems building OpenJDK 8 for MacOSX
In-Reply-To: <5195504F.8030305@oracle.com>
References: <5192DFF7.80501@dclunie.com> <5192E087.50503@dclunie.com>
	<5192E35D.2070709@oracle.com> <51936B66.3070608@dclunie.com>
	<51936CDD.2080900@dclunie.com> <51937195.6050401@oracle.com>
	<51937C7C.1010907@dclunie.com> <519514E2.7080402@oracle.com>
	<74AA9F37-3D02-4728-B097-2AC7EC5D735F@oracle.com>
	<51954C95.8080408@dclunie.com> <5195504F.8030305@oracle.com>
Message-ID: <51956F56.6000506@dclunie.com>

Oh, that's good, thanks Phil.

It wasn't clear from the OpenJDK MacOSX port pages that such
things existed (couldn't find a current link), or that these are
built from the same source as OpenJDK, as opposed to being something
Oracle internal (as I guess is the case with Java 7).

There seem to be a lot of stale web pages and links related to
this project.

David

PS. Remember JAI and JIIO ? I am still interested in getting Mac
native codecs for those many codecs that don't have pure Java
equivalents (esp. lossless JPEG and JPEG-LS); is there any
chance of Oracle providing the source of whatever is necessary
to reactivate this as an open cross-platform project?

On 5/16/13 5:31 PM, Phil Race wrote:
> On 5/16/2013 2:16 PM, David Clunie wrote:
>>
>> It would be even nicer if binary builds were distributed so that one
>> would not have to spend time getting it to build to be able to test
>> it. I can't imagine how many folks must be put off testing by this
>> process.
>>
>
> But they are ! Every week we create a build from the main JDK master
> forest and publish it : https://jdk8.java.net/download.html
>
> -phil.
>
>

From david.dehaven at oracle.com  Thu May 16 16:53:01 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 16 May 2013 16:53:01 -0700
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk is
	outdated
Message-ID: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>


Here's (the start of) a proposed fix for getting the correct jawt_md.h header in the JDK. I already see a couple things that need to be changed, most notably AWTSurfaceLayers.m (possibly others) still imports JavaVM/jawt_md.h, but I want to get this out there and get some feedback on it.

Rather than complicate the build system more than necessary, I just copied jvm_md.h and jni_md.h verbatim from the solaris sources.

Since I'm not a jdk7u-dev committer, I'll need someone (Sergey?) to sponsor this change.

I have not done much testing and still need to dust off the cryptic pile of JPRT notes to kick off a JPRT run.


Webrev:
http://cr.openjdk.java.net/~ddehaven/7181710/jdk.0/

Issue:
http://bugs.sun.com/view_bug.do?bug_id=7181710

-DrD-


From anthony.petrov at oracle.com  Fri May 17 03:01:11 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 14:01:11 +0400
Subject: xawt??
In-Reply-To: <519515F5.60203@oracle.com>
References: <4F66163B-1266-464C-8003-4CDE54A39DF2@oracle.com>
	<5194BF58.7000702@oracle.com>
	<1C04C514-D23E-448D-BDC7-0F06B8E7F20C@oracle.com>
	<5195023F.7090203@oracle.com> <51950FDF.4090902@oracle.com>
	<51951181.3080602@oracle.com> <519515F5.60203@oracle.com>
Message-ID: <5195FFE7.3020205@oracle.com>

Hi Phil,

Is it 8005491 what you're looking for?

--
best regards,
Anthony

On 05/16/2013 09:23 PM, Phil Race wrote:
> On 5/16/2013 10:04 AM, Artem Ananiev wrote:
>>
>> On 5/16/2013 8:57 PM, Phil Race wrote:
>>> Artem,
>>>
>>> Is http://bugs.sun.com/view_bug.do?bug_id=8001338
>>> [macosx] -Dawt.toolkit=sun.awt.X11.XToolkit option does not work
>>>
>>> considered to be the right bug to track this, since the last comment is
>>>
>>> "I think that we should not support XToolkit on Mac OS X." ?
>>
>> No, it's a separate issue. As written in the bug comments, XToolkit
>> works on OS X in general, it just doesn't start if only awt.toolkit is
>> specified. If, in addition to awt.toolkit, you also specify the right
>> java.awt.graphicsenv, it will launch.
>>
>> The comment is correct, but it doesn't say anything about what JDK
>> version XToolkit should not be supported in :) As I wrote in the
>> previous email, my vote is JDK8.
>
> Artem,
>
> I know that. What I am asking is what is the bug id used to track the
> build change ?
> I spent a while searching and that's the closest match I found.
>
> -phil.
>
>>
>> Thanks,
>>
>> Artem
>>
>>> -phil.
>>>
>>> On 5/16/2013 8:58 AM, Artem Ananiev wrote:
>>>>
>>>> On 5/16/2013 7:36 PM, David DeHaven wrote:
>>>>>
>>>>> I found about four issues pertaining to this particular problem
>>>>> (including the one I'm working on). I think ideally, it should be a
>>>>> configure switch so if someone wants to build it then they can, but
>>>>> for production purposes it should be off.
>>>>>
>>>>> I was hoping to fix jawt_md.h for 7u40 though...
>>>>
>>>> Such a change as removing XAWT should be done in major releases. When
>>>> a component becomes obsolete, it is first made non-default, then
>>>> deprecated in the next major release, then removed in the next next
>>>> major release. This is what we did for MToolkit, for example.
>>>>
>>>> So let us get rid of XAWT in JDK8, not 7uX.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>> -DrD-
>>>>>
>>>>>> Hi, David.
>>>>>> Yes there is a bug on it for jdk8. The reason why it is exists, is
>>>>>> used for comparing of a rendering of aqua/xawt.
>>>>>>
>>>>>> On 16.05.2013 3:12, David DeHaven wrote:
>>>>>>> Is there any particular reason xawt (and awt/X11) is being built on
>>>>>>> Mac?
>>>>>>> Is anyone actually using it or is this just some vestige of the
>>>>>>> initial port that wasn't shut off?
>>>>>>>
>>>>>>> To me it just looks like a whole mass of dead code wasting space in
>>>>>>> the JRE.
>>>>>>>
>>>>>>> More importantly, it's getting in the way of fixing the Mac OS X
>>>>>>> jawt_md.h so it's actually usable...
>>>>>>>
>>>>>>> -DrD-
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>>>
>>>>>
>>>
>

From anthony.petrov at oracle.com  Fri May 17 04:38:07 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 15:38:07 +0400
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk
	is outdated
In-Reply-To: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
Message-ID: <5196169F.1020505@oracle.com>

Hi David,

The fix looks good to me. Only one question:

src/macosx/javavm/export/jni_md.h
>   29 #define JNIEXPORT

Does the empty #define imply that when building a jni lib on Mac, it 
should export all of its symbols by default?

--
best regards,
Anthony

On 05/17/2013 03:53 AM, David DeHaven wrote:
>
> Here's (the start of) a proposed fix for getting the correct jawt_md.h header in the JDK. I already see a couple things that need to be changed, most notably AWTSurfaceLayers.m (possibly others) still imports JavaVM/jawt_md.h, but I want to get this out there and get some feedback on it.
>
> Rather than complicate the build system more than necessary, I just copied jvm_md.h and jni_md.h verbatim from the solaris sources.
>
> Since I'm not a jdk7u-dev committer, I'll need someone (Sergey?) to sponsor this change.
>
> I have not done much testing and still need to dust off the cryptic pile of JPRT notes to kick off a JPRT run.
>
>
> Webrev:
> http://cr.openjdk.java.net/~ddehaven/7181710/jdk.0/
>
> Issue:
> http://bugs.sun.com/view_bug.do?bug_id=7181710
>
> -DrD-
>

From anthony.petrov at oracle.com  Fri May 17 05:49:22 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 16:49:22 +0400
Subject: Java Preferences won't start
Message-ID: <51962752.1080001@oracle.com>

Hello,

My ls -l /Library/Java/JavaVirtualMachines/ looks like this:

total 0
drwxr-xr-x  3 root  wheel  102 Mar 28  2012 1.6.0_31-b04-413.jdk
drwxr-xr-x  3 root  wheel  102 Aug 24  2012 jdk1.7.0_06.jdk
drwxr-xr-x  3 root  wheel  102 Sep 18  2012 jdk1.7.0_10.jdk
drwxr-xr-x  3 root  wheel  102 May 17 15:51 jdk1.8.0.jdk

All the JDKs are usable when I run commands specifying their full path 
names. Also, the "default" jdk is the 7u10 one, so that running 'java 
-version' in the command line will say "1.7.0_10". The 1.8 is b90 
installed just now.

However, when I'm trying to start Java Preferences in order to select 
the default JDK for the command-line use, I get a small dialog box with 
an error saying:

Cannot launch "Java Preferences"
No compatible version of Java 1.5+ is available.

After I click Quit, the console output is as follows:

[JavaAppLauncher] Requested [1.5+], launching in [(null)] instead.
[JavaAppLauncher Error] unable to find a version of Java to launch

I tried searching this on the Internet but didn't find anything useful.

I don't even want to run this GUI tool actually. Is there a way to 
switch the default JDK from command line? (Yes, I know I can modify my 
PATH and JAVA_HOME, but I actually want to do the same thing that the 
Java Preferences tool does).

Any tips?

--
best regards,
Anthony

From davmac at davmac.org  Fri May 17 06:04:53 2013
From: davmac at davmac.org (Davin McCall)
Date: Fri, 17 May 2013 14:04:53 +0100
Subject: JavaFX Application hang when Toolkit.getDefaultToolkit() called before
	launch
Message-ID: <51962AF5.7090202@davmac.org>

Hi,

I have come across a bug when trying to run some JavaFX code. What it 
boils down to is that the javafx.application.Application's 
launch(String...) method hangs if Toolkit.getDefaultToolkit() is called 
previously.

Roughly:

     public static void main(String[] args)
     {
         Toolkit toolkit = Toolkit.getDefaultToolkit();
         launch(args);
     }

... is enough to cause the problem. The launch method hangs and the 
application's start(Stage) method doesn't get called. I have a complete 
test case (36 lines of code) if anyone is interested.

Is this a known bug? Should I file a bug report?

Thanks

Davin


From anthony.petrov at oracle.com  Fri May 17 06:15:00 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 17:15:00 +0400
Subject: Java Preferences won't start
In-Reply-To: <FEA945C7-9AE9-4122-8F19-AE180AFB2768@kaon.com>
References: <51962752.1080001@oracle.com>
	<FEA945C7-9AE9-4122-8F19-AE180AFB2768@kaon.com>
Message-ID: <51962D54.1040405@oracle.com>

Thanks Joshua. The Java Control Panel in System Preferences does indeed 
exist and runs fine. However, it won't let me choose the default JDK, it 
only manages JREs, and by definition, there's only one JRE in the system.

--
best regards,
Anthony

On 05/17/2013 05:07 PM, Joshua Smith wrote:
> Java preferences moved to the System Preferences panel. Looks to me like you are trying to run the old pre-oracle one.
>
> On May 17, 2013, at 8:49 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hello,
>>
>> My ls -l /Library/Java/JavaVirtualMachines/ looks like this:
>>
>> total 0
>> drwxr-xr-x  3 root  wheel  102 Mar 28  2012 1.6.0_31-b04-413.jdk
>> drwxr-xr-x  3 root  wheel  102 Aug 24  2012 jdk1.7.0_06.jdk
>> drwxr-xr-x  3 root  wheel  102 Sep 18  2012 jdk1.7.0_10.jdk
>> drwxr-xr-x  3 root  wheel  102 May 17 15:51 jdk1.8.0.jdk
>>
>> All the JDKs are usable when I run commands specifying their full path names. Also, the "default" jdk is the 7u10 one, so that running 'java -version' in the command line will say "1.7.0_10". The 1.8 is b90 installed just now.
>>
>> However, when I'm trying to start Java Preferences in order to select the default JDK for the command-line use, I get a small dialog box with an error saying:
>>
>> Cannot launch "Java Preferences"
>> No compatible version of Java 1.5+ is available.
>>
>> After I click Quit, the console output is as follows:
>>
>> [JavaAppLauncher] Requested [1.5+], launching in [(null)] instead.
>> [JavaAppLauncher Error] unable to find a version of Java to launch
>>
>> I tried searching this on the Internet but didn't find anything useful.
>>
>> I don't even want to run this GUI tool actually. Is there a way to switch the default JDK from command line? (Yes, I know I can modify my PATH and JAVA_HOME, but I actually want to do the same thing that the Java Preferences tool does).
>>
>> Any tips?
>>
>> --
>> best regards,
>> Anthony
>

From pranav.bhat at oracle.com  Fri May 17 06:16:16 2013
From: pranav.bhat at oracle.com (Pranav Bhat)
Date: Fri, 17 May 2013 09:16:16 -0400
Subject: Java Preferences won't start
In-Reply-To: <51962752.1080001@oracle.com>
References: <51962752.1080001@oracle.com>
Message-ID: <7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>


On May 17, 2013, at 8:49 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hello,
> 
> My ls -l /Library/Java/JavaVirtualMachines/ looks like this:
> 
> total 0
> drwxr-xr-x  3 root  wheel  102 Mar 28  2012 1.6.0_31-b04-413.jdk
> drwxr-xr-x  3 root  wheel  102 Aug 24  2012 jdk1.7.0_06.jdk
> drwxr-xr-x  3 root  wheel  102 Sep 18  2012 jdk1.7.0_10.jdk
> drwxr-xr-x  3 root  wheel  102 May 17 15:51 jdk1.8.0.jdk
> 
> All the JDKs are usable when I run commands specifying their full path names. Also, the "default" jdk is the 7u10 one, so that running 'java -version' in the command line will say "1.7.0_10". The 1.8 is b90 installed just now.
> 
> However, when I'm trying to start Java Preferences in order to select the default JDK for the command-line use, I get a small dialog box with an error saying:
> 
> Cannot launch "Java Preferences"
> No compatible version of Java 1.5+ is available.
> 
> After I click Quit, the console output is as follows:
> 
> [JavaAppLauncher] Requested [1.5+], launching in [(null)] instead.
> [JavaAppLauncher Error] unable to find a version of Java to launch
> 
> I tried searching this on the Internet but didn't find anything useful.
> 
> I don't even want to run this GUI tool actually. Is there a way to switch the default JDK from command line?

Yes.

/usr/libexec/java_home 

See the man pages for java_home at http://www.unix.com/man-page/all/1/java_home/

Thanks,
- Pranav

> (Yes, I know I can modify my PATH and JAVA_HOME, but I actually want to do the same thing that the Java Preferences tool does).
> 
> Any tips?
> 
> --
> best regards,
> Anthony


From anthony.petrov at oracle.com  Fri May 17 06:18:57 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 17:18:57 +0400
Subject: Java Preferences won't start
In-Reply-To: <7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>
References: <51962752.1080001@oracle.com>
	<7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>
Message-ID: <51962E41.5010008@oracle.com>

On 05/17/2013 05:16 PM, Pranav Bhat wrote:
>
> On May 17, 2013, at 8:49 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> Hello,
>>
>> My ls -l /Library/Java/JavaVirtualMachines/ looks like this:
>>
>> total 0
>> drwxr-xr-x  3 root  wheel  102 Mar 28  2012 1.6.0_31-b04-413.jdk
>> drwxr-xr-x  3 root  wheel  102 Aug 24  2012 jdk1.7.0_06.jdk
>> drwxr-xr-x  3 root  wheel  102 Sep 18  2012 jdk1.7.0_10.jdk
>> drwxr-xr-x  3 root  wheel  102 May 17 15:51 jdk1.8.0.jdk
>>
>> All the JDKs are usable when I run commands specifying their full path names. Also, the "default" jdk is the 7u10 one, so that running 'java -version' in the command line will say "1.7.0_10". The 1.8 is b90 installed just now.
>>
>> However, when I'm trying to start Java Preferences in order to select the default JDK for the command-line use, I get a small dialog box with an error saying:
>>
>> Cannot launch "Java Preferences"
>> No compatible version of Java 1.5+ is available.
>>
>> After I click Quit, the console output is as follows:
>>
>> [JavaAppLauncher] Requested [1.5+], launching in [(null)] instead.
>> [JavaAppLauncher Error] unable to find a version of Java to launch
>>
>> I tried searching this on the Internet but didn't find anything useful.
>>
>> I don't even want to run this GUI tool actually. Is there a way to switch the default JDK from command line?
>
> Yes.
>
> /usr/libexec/java_home
>
> See the man pages for java_home at http://www.unix.com/man-page/all/1/java_home/

This tool returns the default value for JAVA_HOME, and in my case it 
returns the path to the 7u10 JDK. But the java_home can't change the 
default value. Where does this tool get it from and how do I change it?

--
best regards,
Anthony

>
> Thanks,
> - Pranav
>
>> (Yes, I know I can modify my PATH and JAVA_HOME, but I actually want to do the same thing that the Java Preferences tool does).
>>
>> Any tips?
>>
>> --
>> best regards,
>> Anthony
>

From anthony.petrov at oracle.com  Fri May 17 06:35:11 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 17:35:11 +0400
Subject: JavaFX Application hang when Toolkit.getDefaultToolkit() called
	before launch
In-Reply-To: <51962AF5.7090202@davmac.org>
References: <51962AF5.7090202@davmac.org>
Message-ID: <5196320F.1020309@oracle.com>

Hi Davin,

Yes, this is a known issue. If you ultimately have to initialize AWT 
before starting FX, then you should set the javafx.macosx.embedded 
system property to true (e.g. -Djavafx.macosx.embedded=true on the 
command-line).

Another option is to upgrade to FX8 where this issue is resolved.

--
best regards,
Anthony

On 05/17/2013 05:04 PM, Davin McCall wrote:
> Hi,
>
> I have come across a bug when trying to run some JavaFX code. What it
> boils down to is that the javafx.application.Application's
> launch(String...) method hangs if Toolkit.getDefaultToolkit() is called
> previously.
>
> Roughly:
>
>      public static void main(String[] args)
>      {
>          Toolkit toolkit = Toolkit.getDefaultToolkit();
>          launch(args);
>      }
>
> ... is enough to cause the problem. The launch method hangs and the
> application's start(Stage) method doesn't get called. I have a complete
> test case (36 lines of code) if anyone is interested.
>
> Is this a known bug? Should I file a bug report?
>
> Thanks
>
> Davin
>

From david.dehaven at oracle.com  Fri May 17 07:25:27 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 17 May 2013 07:25:27 -0700
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk is
	outdated
In-Reply-To: <5196169F.1020505@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
	<5196169F.1020505@oracle.com>
Message-ID: <1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>



> Hi David,
> 
> The fix looks good to me. Only one question:
> 
> src/macosx/javavm/export/jni_md.h
>>  29 #define JNIEXPORT
> 
> Does the empty #define imply that when building a jni lib on Mac, it should export all of its symbols by default?

It depends on gcc's visibility setting, but yes, by default all symbols are exported.

JDK8 has a better jni_md.h that sets JNIEXPORT to __attribute__(visibility(("default"))). That change should be backported, but should probably need to be done under a different bug ID. I suppose I could sneak it in here :)

-DrD-


From david.dehaven at oracle.com  Fri May 17 07:36:01 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 17 May 2013 07:36:01 -0700
Subject: Java Preferences won't start
In-Reply-To: <51962E41.5010008@oracle.com>
References: <51962752.1080001@oracle.com>
	<7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>
	<51962E41.5010008@oracle.com>
Message-ID: <4B26B879-4F3D-4D66-8BDC-F54CCCC89BAE@oracle.com>


>>> Hello,
>>> 
>>> My ls -l /Library/Java/JavaVirtualMachines/ looks like this:
>>> 
>>> total 0
>>> drwxr-xr-x  3 root  wheel  102 Mar 28  2012 1.6.0_31-b04-413.jdk
>>> drwxr-xr-x  3 root  wheel  102 Aug 24  2012 jdk1.7.0_06.jdk
>>> drwxr-xr-x  3 root  wheel  102 Sep 18  2012 jdk1.7.0_10.jdk
>>> drwxr-xr-x  3 root  wheel  102 May 17 15:51 jdk1.8.0.jdk
>>> 
>>> All the JDKs are usable when I run commands specifying their full path names. Also, the "default" jdk is the 7u10 one, so that running 'java -version' in the command line will say "1.7.0_10". The 1.8 is b90 installed just now.
>>> 
>>> However, when I'm trying to start Java Preferences in order to select the default JDK for the command-line use, I get a small dialog box with an error saying:
>>> 
>>> Cannot launch "Java Preferences"
>>> No compatible version of Java 1.5+ is available.

The old /Applications/Utilities/Java Preferences is no longer useful.


>>> After I click Quit, the console output is as follows:
>>> 
>>> [JavaAppLauncher] Requested [1.5+], launching in [(null)] instead.
>>> [JavaAppLauncher Error] unable to find a version of Java to launch
>>> 
>>> I tried searching this on the Internet but didn't find anything useful.
>>> 
>>> I don't even want to run this GUI tool actually. Is there a way to switch the default JDK from command line?
>> 
>> Yes.
>> 
>> /usr/libexec/java_home
>> 
>> See the man pages for java_home at http://www.unix.com/man-page/all/1/java_home/
> 
> This tool returns the default value for JAVA_HOME, and in my case it returns the path to the 7u10 JDK. But the java_home can't change the default value. Where does this tool get it from and how do I change it?

There isn't any mechanism to set the order. When you request a specific major version, java_home will give you the latest version it finds. IOW, if you call /usr/libexec/java_home -v 1.7 it would return /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk. Without args it should return the latest major version which is jdk1.8.0.jdk. You'll have to use JAVA_HOME or explicit paths to pick a particular version.

I thought someone had a shell script to use the output of java_home to build a list of JDKs to choose from, then set JAVA_HOME from that... maybe that was just wishful thinking, it doesn't seem like it'd be too difficult to write.

-DrD-


From anthony.petrov at oracle.com  Fri May 17 07:40:26 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 18:40:26 +0400
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk
	is outdated
In-Reply-To: <1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
	<5196169F.1020505@oracle.com>
	<1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>
Message-ID: <5196415A.7020807@oracle.com>

On 05/17/2013 06:25 PM, David DeHaven wrote:
>> The fix looks good to me. Only one question:
>>
>> src/macosx/javavm/export/jni_md.h
>>>   29 #define JNIEXPORT
>>
>> Does the empty #define imply that when building a jni lib on Mac, it should export all of its symbols by default?
>
> It depends on gcc's visibility setting, but yes, by default all symbols are exported.
>
> JDK8 has a better jni_md.h that sets JNIEXPORT to __attribute__(visibility(("default"))). That change should be backported, but should probably need to be done under a different bug ID. I suppose I could sneak it in here :)

IIRC, Martin Buchholz's fix only updated the jni_md.h for Solaris, so 
the Mac's one is unlikely to change even if his fix is back-ported. 
Hence I'd vote for adding the __attribute__(visibility(("default"))) in 
your fix (unless this can break anything - recall the changes needed in 
awt_LoadLibrary.c where the JNIEXPORT was used in a typedef).

Also, I assume you're going to forward-port your fix to JDK 8 at some point?

--
best regards,
Anthony

From anthony.petrov at oracle.com  Fri May 17 07:47:09 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 18:47:09 +0400
Subject: Java Preferences won't start
In-Reply-To: <4B26B879-4F3D-4D66-8BDC-F54CCCC89BAE@oracle.com>
References: <51962752.1080001@oracle.com>
	<7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>
	<51962E41.5010008@oracle.com>
	<4B26B879-4F3D-4D66-8BDC-F54CCCC89BAE@oracle.com>
Message-ID: <519642ED.4060803@oracle.com>

On 05/17/2013 06:36 PM, David DeHaven wrote:
>
>>>> Hello,
>>>>
>>>> My ls -l /Library/Java/JavaVirtualMachines/ looks like this:
>>>>
>>>> total 0
>>>> drwxr-xr-x  3 root  wheel  102 Mar 28  2012 1.6.0_31-b04-413.jdk
>>>> drwxr-xr-x  3 root  wheel  102 Aug 24  2012 jdk1.7.0_06.jdk
>>>> drwxr-xr-x  3 root  wheel  102 Sep 18  2012 jdk1.7.0_10.jdk
>>>> drwxr-xr-x  3 root  wheel  102 May 17 15:51 jdk1.8.0.jdk
>>>>
>>>> All the JDKs are usable when I run commands specifying their full path names. Also, the "default" jdk is the 7u10 one, so that running 'java -version' in the command line will say "1.7.0_10". The 1.8 is b90 installed just now.
>>>>
>>>> However, when I'm trying to start Java Preferences in order to select the default JDK for the command-line use, I get a small dialog box with an error saying:
>>>>
>>>> Cannot launch "Java Preferences"
>>>> No compatible version of Java 1.5+ is available.
>
> The old /Applications/Utilities/Java Preferences is no longer useful.
>
>
>>>> After I click Quit, the console output is as follows:
>>>>
>>>> [JavaAppLauncher] Requested [1.5+], launching in [(null)] instead.
>>>> [JavaAppLauncher Error] unable to find a version of Java to launch
>>>>
>>>> I tried searching this on the Internet but didn't find anything useful.
>>>>
>>>> I don't even want to run this GUI tool actually. Is there a way to switch the default JDK from command line?
>>>
>>> Yes.
>>>
>>> /usr/libexec/java_home
>>>
>>> See the man pages for java_home at http://www.unix.com/man-page/all/1/java_home/
>>
>> This tool returns the default value for JAVA_HOME, and in my case it returns the path to the 7u10 JDK. But the java_home can't change the default value. Where does this tool get it from and how do I change it?
>
> There isn't any mechanism to set the order. When you request a specific major version, java_home will give you the latest version it finds. IOW, if you call /usr/libexec/java_home -v 1.7 it would return /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk. Without args it should return the latest major version which is jdk1.8.0.jdk. You'll have to use JAVA_HOME or explicit paths to pick a particular version.

Indeed, there's JAVA_HOME set in my environment. However, even if I 
unset this variable, /usr/libexec/java_home still returns the path to 
7u10 even though I have the 1.8 installed. This is strange. (I haven't 
restarted my Mac after installing JDK8 though, perhaps this might help).

> I thought someone had a shell script to use the output of java_home to build a list of JDKs to choose from, then set JAVA_HOME from that... maybe that was just wishful thinking, it doesn't seem like it'd be too difficult to write.

In my .bash_profile I just have the following:

export JAVA_HOME=`/usr/libexec/java_home`

--
best regards,
Anthony

>
> -DrD-
>

From david.dehaven at oracle.com  Fri May 17 08:00:09 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 17 May 2013 08:00:09 -0700
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk is
	outdated
In-Reply-To: <5196415A.7020807@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
	<5196169F.1020505@oracle.com>
	<1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>
	<5196415A.7020807@oracle.com>
Message-ID: <E97BB6DE-0114-4DFD-A87F-F78B112B53B5@oracle.com>


>>> The fix looks good to me. Only one question:
>>> 
>>> src/macosx/javavm/export/jni_md.h
>>>>  29 #define JNIEXPORT
>>> 
>>> Does the empty #define imply that when building a jni lib on Mac, it should export all of its symbols by default?
>> 
>> It depends on gcc's visibility setting, but yes, by default all symbols are exported.
>> 
>> JDK8 has a better jni_md.h that sets JNIEXPORT to __attribute__(visibility(("default"))). That change should be backported, but should probably need to be done under a different bug ID. I suppose I could sneak it in here :)
> 
> IIRC, Martin Buchholz's fix only updated the jni_md.h for Solaris, so the Mac's one is unlikely to change even if his fix is back-ported. Hence I'd vote for adding the __attribute__(visibility(("default"))) in your fix (unless this can break anything - recall the changes needed in awt_LoadLibrary.c where the JNIEXPORT was used in a typedef).

The Mac builds currently use the solaris headers in both versions (which is why I was so interested in helping him). I haven't tried building 7u-dev with the attribute set yet, so I'm not sure of the consequences in JDK7. I can give it a try, if it's too ugly I'll file a separate issue to do the backport.


> Also, I assume you're going to forward-port your fix to JDK 8 at some point?

Yes, that's my plan.

-DrD-


From david.dehaven at oracle.com  Fri May 17 08:05:07 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 17 May 2013 08:05:07 -0700
Subject: Java Preferences won't start
In-Reply-To: <519642ED.4060803@oracle.com>
References: <51962752.1080001@oracle.com>
	<7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>
	<51962E41.5010008@oracle.com>
	<4B26B879-4F3D-4D66-8BDC-F54CCCC89BAE@oracle.com>
	<519642ED.4060803@oracle.com>
Message-ID: <F7AA9AA6-F6A8-4D90-A33E-D1DFCE27DBE0@oracle.com>


>>>> /usr/libexec/java_home
>>>> 
>>>> See the man pages for java_home at http://www.unix.com/man-page/all/1/java_home/
>>> 
>>> This tool returns the default value for JAVA_HOME, and in my case it returns the path to the 7u10 JDK. But the java_home can't change the default value. Where does this tool get it from and how do I change it?
>> 
>> There isn't any mechanism to set the order. When you request a specific major version, java_home will give you the latest version it finds. IOW, if you call /usr/libexec/java_home -v 1.7 it would return /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk. Without args it should return the latest major version which is jdk1.8.0.jdk. You'll have to use JAVA_HOME or explicit paths to pick a particular version.
> 
> Indeed, there's JAVA_HOME set in my environment. However, even if I unset this variable, /usr/libexec/java_home still returns the path to 7u10 even though I have the 1.8 installed. This is strange. (I haven't restarted my Mac after installing JDK8 though, perhaps this might help).

No, restarting shouldn't have any effect since the JDKs are scanned dynamically. That is odd. I have 1.8 b67 and it chooses that over the two JDK7 builds in there if no version is given. I haven't tried with a more recent build yet.

-DrD-


From anthony.petrov at oracle.com  Fri May 17 08:09:49 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 17 May 2013 19:09:49 +0400
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk
	is outdated
In-Reply-To: <E97BB6DE-0114-4DFD-A87F-F78B112B53B5@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
	<5196169F.1020505@oracle.com>
	<1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>
	<5196415A.7020807@oracle.com>
	<E97BB6DE-0114-4DFD-A87F-F78B112B53B5@oracle.com>
Message-ID: <5196483D.4040106@oracle.com>

Thanks. I'm OK if this will be a separate bug.

--
best regards,
Anthony

On 05/17/2013 07:00 PM, David DeHaven wrote:
>
>>>> The fix looks good to me. Only one question:
>>>>
>>>> src/macosx/javavm/export/jni_md.h
>>>>>   29 #define JNIEXPORT
>>>>
>>>> Does the empty #define imply that when building a jni lib on Mac, it should export all of its symbols by default?
>>>
>>> It depends on gcc's visibility setting, but yes, by default all symbols are exported.
>>>
>>> JDK8 has a better jni_md.h that sets JNIEXPORT to __attribute__(visibility(("default"))). That change should be backported, but should probably need to be done under a different bug ID. I suppose I could sneak it in here :)
>>
>> IIRC, Martin Buchholz's fix only updated the jni_md.h for Solaris, so the Mac's one is unlikely to change even if his fix is back-ported. Hence I'd vote for adding the __attribute__(visibility(("default"))) in your fix (unless this can break anything - recall the changes needed in awt_LoadLibrary.c where the JNIEXPORT was used in a typedef).
>
> The Mac builds currently use the solaris headers in both versions (which is why I was so interested in helping him). I haven't tried building 7u-dev with the attribute set yet, so I'm not sure of the consequences in JDK7. I can give it a try, if it's too ugly I'll file a separate issue to do the backport.
>
>
>> Also, I assume you're going to forward-port your fix to JDK 8 at some point?
>
> Yes, that's my plan.
>
> -DrD-
>

From mik3hall at gmail.com  Fri May 17 14:30:55 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 17 May 2013 16:30:55 -0500
Subject: Java Preferences won't start
In-Reply-To: <519642ED.4060803@oracle.com>
References: <51962752.1080001@oracle.com>
	<7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>
	<51962E41.5010008@oracle.com>
	<4B26B879-4F3D-4D66-8BDC-F54CCCC89BAE@oracle.com>
	<519642ED.4060803@oracle.com>
Message-ID: <60569270-5A96-4B67-AE89-403CACD3D770@gmail.com>

On May 17, 2013, at 9:47 AM, Anthony Petrov wrote:

> In my .bash_profile I just have the following:
> 
> export JAVA_HOME=`/usr/libexec/java_home`

Why do you have that?
If you comment it out and then start a new shell window, or quit and restart Terminal, what happens?
I know you said you did unset but who knows?

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.dehaven at oracle.com  Fri May 17 21:35:30 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 17 May 2013 21:35:30 -0700
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk is
	outdated
In-Reply-To: <5196483D.4040106@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
	<5196169F.1020505@oracle.com>
	<1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>
	<5196415A.7020807@oracle.com>
	<E97BB6DE-0114-4DFD-A87F-F78B112B53B5@oracle.com>
	<5196483D.4040106@oracle.com>
Message-ID: <B7B5CFE3-F041-47D5-BC4D-D2F70CFE37C9@oracle.com>


Incidentally, I tried compiling with the JDK8 jni_md.h and it built fine... I didn't think the related changes were backported, or were they?

Either way, I think it needs to be a separate issue. Not that it matters, I'm off chasing fires with buckets of gasoline again... :(

-DrD-

> Thanks. I'm OK if this will be a separate bug.
> 
> --
> best regards,
> Anthony
> 
> On 05/17/2013 07:00 PM, David DeHaven wrote:
>> 
>>>>> The fix looks good to me. Only one question:
>>>>> 
>>>>> src/macosx/javavm/export/jni_md.h
>>>>>>  29 #define JNIEXPORT
>>>>> 
>>>>> Does the empty #define imply that when building a jni lib on Mac, it should export all of its symbols by default?
>>>> 
>>>> It depends on gcc's visibility setting, but yes, by default all symbols are exported.
>>>> 
>>>> JDK8 has a better jni_md.h that sets JNIEXPORT to __attribute__(visibility(("default"))). That change should be backported, but should probably need to be done under a different bug ID. I suppose I could sneak it in here :)
>>> 
>>> IIRC, Martin Buchholz's fix only updated the jni_md.h for Solaris, so the Mac's one is unlikely to change even if his fix is back-ported. Hence I'd vote for adding the __attribute__(visibility(("default"))) in your fix (unless this can break anything - recall the changes needed in awt_LoadLibrary.c where the JNIEXPORT was used in a typedef).
>> 
>> The Mac builds currently use the solaris headers in both versions (which is why I was so interested in helping him). I haven't tried building 7u-dev with the attribute set yet, so I'm not sure of the consequences in JDK7. I can give it a try, if it's too ugly I'll file a separate issue to do the backport.
>> 
>> 
>>> Also, I assume you're going to forward-port your fix to JDK 8 at some point?
>> 
>> Yes, that's my plan.
>> 
>> -DrD-
>> 


From mik3hall at gmail.com  Sat May 18 09:43:28 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 18 May 2013 11:43:28 -0500
Subject: Problem with javaws, Mountain Lion, Oracle, Apple
In-Reply-To: <29F236EE-8943-4779-B85B-D0B03D5E01A5@gmail.com>
References: <20130517225516.GA2699@arlut.utexas.edu>
	<9793B03E-41A1-4175-B713-BA54DBAE86FB@gmail.com>
	<29F236EE-8943-4779-B85B-D0B03D5E01A5@gmail.com>
Message-ID: <96E44313-A64C-4635-A811-2BD25605FFED@gmail.com>




> On May 17, 2013, at 5:55 PM, Jonathan Abbey wrote:
> 
>> In each case, I get a pop-up message warning me that I need to install
>> the Java Runtime, despite it already being installed.
> 
> If you do this from Terminal what do you get?
> 
> /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/javaws -viewer
> 
> Works for me but oddly enough in Terminal I get. 
>  2013-05-17 18:48:55.261 java[1602:707] Sparkle Error: An error occurred in retrieving update information. Please try again later.
> 2013-05-17 18:48:55.263 java[1602:707] Sparkle Error (continued): An error occurred while parsing the update feed.
> 
> anyone know where I might be getting this Sparkle error from. Looks like it might of prevented clean shutdown of the preferences app.



On May 18, 2013, at 10:25 AM, Marian Bou?ek wrote:

> Hello Mike.
> 
> I just looked to Disabled.plist and Enabled.plist files contained in  /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents. I sudo edited Disabled.plist file which contains error in SUFeedURL. The value of this property contained double dot '..' - once I repaired it, javaws no longer printed error for me. Maybe this can help you a bit.

Thanks but for me both the disabled and enabled plist files and the Info.plist as well
all appear to show...
http://download.java.net/jdk8/mac/au/au.xml

That file doesn't appear to exist
curl http://download.java.net/jdk8/mac/au/au.xml
<HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=ISO-8859-1"><TITLE>Not Found</TITLE></HEAD>
<H1>Not Found</H1> The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it. 

Checking from the browser it appears there is a http://download.java.net/jdk8 directory but it contains no mac directory.

So it doesn't seem to be a valid url for me but if it is the problem I don't know what to change it to in order to fix it.
I am going to cross-post this one to macosx-port
 

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 pranav.bhat at oracle.com  Sat May 18 10:44:02 2013
From: pranav.bhat at oracle.com (Pranav Bhat)
Date: Sat, 18 May 2013 13:44:02 -0400
Subject: Problem with javaws, Mountain Lion, Oracle, Apple
In-Reply-To: <96E44313-A64C-4635-A811-2BD25605FFED@gmail.com>
References: <20130517225516.GA2699@arlut.utexas.edu>
	<9793B03E-41A1-4175-B713-BA54DBAE86FB@gmail.com>
	<29F236EE-8943-4779-B85B-D0B03D5E01A5@gmail.com>
	<96E44313-A64C-4635-A811-2BD25605FFED@gmail.com>
Message-ID: <02F80F73-8CDA-4C69-947C-ECEEDE9C5A57@oracle.com>



On May 18, 2013, at 12:43 PM, Michael Hall <mik3hall at gmail.com> wrote:

> 
> 
> 
>> On May 17, 2013, at 5:55 PM, Jonathan Abbey wrote:
>> 
>>> In each case, I get a pop-up message warning me that I need to install
>>> the Java Runtime, despite it already being installed.
>> 
>> If you do this from Terminal what do you get?
>> 
>> /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/javaws -viewer
>> 
>> Works for me but oddly enough in Terminal I get. 
>> 2013-05-17 18:48:55.261 java[1602:707] Sparkle Error: An error occurred in retrieving update information. Please try again later.
>> 2013-05-17 18:48:55.263 java[1602:707] Sparkle Error (continued): An error occurred while parsing the update feed.
>> 
>> anyone know where I might be getting this Sparkle error from. Looks like it might of prevented clean shutdown of the preferences app.
> 
> 
> 
> On May 18, 2013, at 10:25 AM, Marian Bou?ek wrote:
> 
>> Hello Mike.
>> 
>> I just looked to Disabled.plist and Enabled.plist files contained in  /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents. I sudo edited Disabled.plist file which contains error in SUFeedURL. The value of this property contained double dot '..' - once I repaired it, javaws no longer printed error for me. Maybe this can help you a bit.
> 
> Thanks but for me both the disabled and enabled plist files and the Info.plist as well
> all appear to show...
> http://download.java.net/jdk8/mac/au/au.xml
> 
> That file doesn't appear to exist
> curl http://download.java.net/jdk8/mac/au/au.xml

Hello Michael,

Looking into this - Will update this thread when I have more information. I didn't get a version/build information from this email thread - I assume, based on this URL, this is an EA build for JDK8, correct? 

Thanks,
- Pranav

> <HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=ISO-8859-1"><TITLE>Not Found</TITLE></HEAD>
> <H1>Not Found</H1> The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it. 
> 
> Checking from the browser it appears there is a http://download.java.net/jdk8 directory but it contains no mac directory.
> 
> So it doesn't seem to be a valid url for me but if it is the problem I don't know what to change it to in order to fix it.
> I am going to cross-post this one to macosx-port
> 
> 
> 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 mik3hall at gmail.com  Sat May 18 11:12:25 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 18 May 2013 13:12:25 -0500
Subject: Problem with javaws, Mountain Lion, Oracle, Apple
In-Reply-To: <02F80F73-8CDA-4C69-947C-ECEEDE9C5A57@oracle.com>
References: <20130517225516.GA2699@arlut.utexas.edu>
	<9793B03E-41A1-4175-B713-BA54DBAE86FB@gmail.com>
	<29F236EE-8943-4779-B85B-D0B03D5E01A5@gmail.com>
	<96E44313-A64C-4635-A811-2BD25605FFED@gmail.com>
	<02F80F73-8CDA-4C69-947C-ECEEDE9C5A57@oracle.com>
Message-ID: <87AC265D-363C-4890-ACE2-333633218E12@gmail.com>

On May 18, 2013, at 12:44 PM, Pranav Bhat wrote:

> Hello Michael,
> 
> Looking into this - Will update this thread when I have more information. I didn't get a version/build information from this email thread - I assume, based on this URL, this is an EA build for JDK8, correct? 

/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b90)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b32, mixed mode)

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.dehaven at oracle.com  Sun May 19 10:06:40 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Sun, 19 May 2013 10:06:40 -0700
Subject: Problem with javaws, Mountain Lion, Oracle, Apple
In-Reply-To: <96E44313-A64C-4635-A811-2BD25605FFED@gmail.com>
References: <20130517225516.GA2699@arlut.utexas.edu>
	<9793B03E-41A1-4175-B713-BA54DBAE86FB@gmail.com>
	<29F236EE-8943-4779-B85B-D0B03D5E01A5@gmail.com>
	<96E44313-A64C-4635-A811-2BD25605FFED@gmail.com>
Message-ID: <3FDD470F-CA50-4875-90B2-6D4F011ED46C@oracle.com>


> Thanks but for me both the disabled and enabled plist files and the Info.plist as well
> all appear to show...
> http://download.java.net/jdk8/mac/au/au.xml

Because auto update for JDK8 doesn't exist yet, it hasn't even been released! :)

-DrD-


From mik3hall at gmail.com  Sun May 19 11:07:34 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 19 May 2013 13:07:34 -0500
Subject: Problem with javaws, Mountain Lion, Oracle, Apple
In-Reply-To: <3FDD470F-CA50-4875-90B2-6D4F011ED46C@oracle.com>
References: <20130517225516.GA2699@arlut.utexas.edu>
	<9793B03E-41A1-4175-B713-BA54DBAE86FB@gmail.com>
	<29F236EE-8943-4779-B85B-D0B03D5E01A5@gmail.com>
	<96E44313-A64C-4635-A811-2BD25605FFED@gmail.com>
	<3FDD470F-CA50-4875-90B2-6D4F011ED46C@oracle.com>
Message-ID: <A3EA6FE2-C25F-40A1-A34C-3449D6B5F379@gmail.com>

On May 19, 2013, at 12:06 PM, David DeHaven wrote:

> 
>> Thanks but for me both the disabled and enabled plist files and the Info.plist as well
>> all appear to show...
>> http://download.java.net/jdk8/mac/au/au.xml
> 
> Because auto update for JDK8 doesn't exist yet, it hasn't even been released! :)

Thats all right I wasn't worried about it yet either. 

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 mik3hall at gmail.com  Sun May 19 11:13:22 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 19 May 2013 13:13:22 -0500
Subject: Problem with javaws, Mountain Lion, Oracle, Apple
In-Reply-To: <3FDD470F-CA50-4875-90B2-6D4F011ED46C@oracle.com>
References: <20130517225516.GA2699@arlut.utexas.edu>
	<9793B03E-41A1-4175-B713-BA54DBAE86FB@gmail.com>
	<29F236EE-8943-4779-B85B-D0B03D5E01A5@gmail.com>
	<96E44313-A64C-4635-A811-2BD25605FFED@gmail.com>
	<3FDD470F-CA50-4875-90B2-6D4F011ED46C@oracle.com>
Message-ID: <67E8812B-7DCB-4F34-A386-A8213B8EAD61@gmail.com>

On May 19, 2013, at 12:06 PM, David DeHaven wrote:

> 
>> Thanks but for me both the disabled and enabled plist files and the Info.plist as well
>> all appear to show...
>> http://download.java.net/jdk8/mac/au/au.xml
> 
> Because auto update for JDK8 doesn't exist yet, it hasn't even been released! :)

It does show that installing Java 8 ea was actually working better than I expected. Or at least in places I hadn't really thought about it working - yet.

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 anthony.petrov at oracle.com  Mon May 20 06:04:08 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 20 May 2013 17:04:08 +0400
Subject: Java Preferences won't start
In-Reply-To: <60569270-5A96-4B67-AE89-403CACD3D770@gmail.com>
References: <51962752.1080001@oracle.com>	<7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>	<51962E41.5010008@oracle.com>	<4B26B879-4F3D-4D66-8BDC-F54CCCC89BAE@oracle.com>	<519642ED.4060803@oracle.com>
	<60569270-5A96-4B67-AE89-403CACD3D770@gmail.com>
Message-ID: <519A1F48.9010004@oracle.com>

I've tried that to no avail. I've even restarted my Mac, still the same 
issue - java_home only sees the 7u10 by default. I.e.:

[anthony at mac ~]$ set | grep JAVA
[anthony at mac ~]$ /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home
[anthony at mac ~]$ /usr/libexec/java_home -v 1.8
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home

So, it does see the 1.8 installation when requested explicitly, but 
won't choose it by default for some reason.

Any clues?

PS. My PATH doesn't contain anything suspicious either:

[anthony at mac ~]$ set | grep PATH
PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/export/anthony/bin/mac:/export/anthony/bin

--
best regards,
Anthony

On 05/18/13 01:30, Michael Hall wrote:
> On May 17, 2013, at 9:47 AM, Anthony Petrov wrote:
>
>> In my .bash_profile I just have the following:
>>
>> export JAVA_HOME=`/usr/libexec/java_home`
>
> Why do you have that?
> If you comment it out and then start a new shell window, or quit and restart Terminal, what happens?
> I know you said you did unset but who knows?
>
> 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 swingler at apple.com  Mon May 20 08:01:24 2013
From: swingler at apple.com (Mike Swingler)
Date: Mon, 20 May 2013 08:01:24 -0700
Subject: Java Preferences won't start
In-Reply-To: <519A1F48.9010004@oracle.com>
References: <51962752.1080001@oracle.com>
	<7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>
	<51962E41.5010008@oracle.com>
	<4B26B879-4F3D-4D66-8BDC-F54CCCC89BAE@oracle.com>
	<519642ED.4060803@oracle.com>
	<60569270-5A96-4B67-AE89-403CACD3D770@gmail.com>
	<519A1F48.9010004@oracle.com>
Message-ID: <A072B4CB-8F42-4F67-83BB-9B1FA64A6BBE@apple.com>

What does "/usr/libexec/java_home -V" say? If 1.8 isn't in there, try "/usr/libexec/java_home -X".

Regards,
Mike Swingler
Apple Inc.

On May 20, 2013, at 6:04 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> I've tried that to no avail. I've even restarted my Mac, still the same issue - java_home only sees the 7u10 by default. I.e.:
> 
> [anthony at mac ~]$ set | grep JAVA
> [anthony at mac ~]$ /usr/libexec/java_home
> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home
> [anthony at mac ~]$ /usr/libexec/java_home -v 1.8
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
> 
> So, it does see the 1.8 installation when requested explicitly, but won't choose it by default for some reason.
> 
> Any clues?
> 
> PS. My PATH doesn't contain anything suspicious either:
> 
> [anthony at mac ~]$ set | grep PATH
> PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/export/anthony/bin/mac:/export/anthony/bin
> 
> --
> best regards,
> Anthony
> 
> On 05/18/13 01:30, Michael Hall wrote:
>> On May 17, 2013, at 9:47 AM, Anthony Petrov wrote:
>> 
>>> In my .bash_profile I just have the following:
>>> 
>>> export JAVA_HOME=`/usr/libexec/java_home`
>> 
>> Why do you have that?
>> If you comment it out and then start a new shell window, or quit and restart Terminal, what happens?
>> I know you said you did unset but who knows?
>> 
>> 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 anthony.petrov at oracle.com  Tue May 21 00:40:47 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 21 May 2013 11:40:47 +0400
Subject: Java Preferences won't start
In-Reply-To: <A072B4CB-8F42-4F67-83BB-9B1FA64A6BBE@apple.com>
References: <51962752.1080001@oracle.com>
	<7016B77F-FABA-4F8C-998B-922D99715651@oracle.com>
	<51962E41.5010008@oracle.com>
	<4B26B879-4F3D-4D66-8BDC-F54CCCC89BAE@oracle.com>
	<519642ED.4060803@oracle.com>
	<60569270-5A96-4B67-AE89-403CACD3D770@gmail.com>
	<519A1F48.9010004@oracle.com>
	<A072B4CB-8F42-4F67-83BB-9B1FA64A6BBE@apple.com>
Message-ID: <519B24FF.1060904@oracle.com>

Hi Mike,

Below is the output from both commands. Still, the 7u10 is preferred by 
this tool for some reason.

> [anthony at mac ~]$ /usr/libexec/java_home -V
> Matching Java Virtual Machines (3):
>     1.7.0_10, x86_64:	"Java SE 7"	/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home
>     1.8.0, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>     1.7.0_06, x86_64:	"Java SE 7"	/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home
>
> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home
> [anthony at mac ~]$ /usr/libexec/java_home -X
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
> <plist version="1.0">
> <array>
> 	<dict>
> 		<key>JVMArch</key>
> 		<string>x86_64</string>
> 		<key>JVMBlacklisted</key>
> 		<false/>
> 		<key>JVMBundleID</key>
> 		<string>com.oracle.java.7u10.jdk</string>
> 		<key>JVMEnabled</key>
> 		<true/>
> 		<key>JVMHomePath</key>
> 		<string>/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home</string>
> 		<key>JVMIsBuiltIn</key>
> 		<false/>
> 		<key>JVMName</key>
> 		<string>Java SE 7</string>
> 		<key>JVMPlatformVersion</key>
> 		<string>1.7</string>
> 		<key>JVMVendor</key>
> 		<string>Oracle Corporation</string>
> 		<key>JVMVersion</key>
> 		<string>1.7.0_10</string>
> 	</dict>
> 	<dict>
> 		<key>JVMArch</key>
> 		<string>x86_64</string>
> 		<key>JVMBlacklisted</key>
> 		<false/>
> 		<key>JVMBundleID</key>
> 		<string>com.oracle.java.8u.jdk</string>
> 		<key>JVMEnabled</key>
> 		<true/>
> 		<key>JVMHomePath</key>
> 		<string>/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home</string>
> 		<key>JVMIsBuiltIn</key>
> 		<false/>
> 		<key>JVMName</key>
> 		<string>Java SE 8</string>
> 		<key>JVMPlatformVersion</key>
> 		<string>1.8</string>
> 		<key>JVMVendor</key>
> 		<string>Oracle Corporation</string>
> 		<key>JVMVersion</key>
> 		<string>1.8.0</string>
> 	</dict>
> 	<dict>
> 		<key>JVMArch</key>
> 		<string>x86_64</string>
> 		<key>JVMBlacklisted</key>
> 		<false/>
> 		<key>JVMBundleID</key>
> 		<string>com.oracle.java.7u06.jdk</string>
> 		<key>JVMEnabled</key>
> 		<true/>
> 		<key>JVMHomePath</key>
> 		<string>/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home</string>
> 		<key>JVMIsBuiltIn</key>
> 		<false/>
> 		<key>JVMName</key>
> 		<string>Java SE 7</string>
> 		<key>JVMPlatformVersion</key>
> 		<string>1.7</string>
> 		<key>JVMVendor</key>
> 		<string>Oracle Corporation</string>
> 		<key>JVMVersion</key>
> 		<string>1.7.0_06</string>
> 	</dict>
> </array>
> </plist>


--
best regards,
Anthony

On 05/20/2013 07:01 PM, Mike Swingler wrote:
> What does "/usr/libexec/java_home -V" say? If 1.8 isn't in there, try "/usr/libexec/java_home -X".
>
> Regards,
> Mike Swingler
> Apple Inc.
>
> On May 20, 2013, at 6:04 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> I've tried that to no avail. I've even restarted my Mac, still the same issue - java_home only sees the 7u10 by default. I.e.:
>>
>> [anthony at mac ~]$ set | grep JAVA
>> [anthony at mac ~]$ /usr/libexec/java_home
>> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home
>> [anthony at mac ~]$ /usr/libexec/java_home -v 1.8
>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>
>> So, it does see the 1.8 installation when requested explicitly, but won't choose it by default for some reason.
>>
>> Any clues?
>>
>> PS. My PATH doesn't contain anything suspicious either:
>>
>> [anthony at mac ~]$ set | grep PATH
>> PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/export/anthony/bin/mac:/export/anthony/bin
>>
>> --
>> best regards,
>> Anthony
>>
>> On 05/18/13 01:30, Michael Hall wrote:
>>> On May 17, 2013, at 9:47 AM, Anthony Petrov wrote:
>>>
>>>> In my .bash_profile I just have the following:
>>>>
>>>> export JAVA_HOME=`/usr/libexec/java_home`
>>>
>>> Why do you have that?
>>> If you comment it out and then start a new shell window, or quit and restart Terminal, what happens?
>>> I know you said you did unset but who knows?
>>>
>>> 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 petr.pchelko at oracle.com  Tue May 21 04:07:47 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 21 May 2013 15:07:47 +0400
Subject: <AWT Dev> [8] Review Request for 8009911 : [macosx] SWT app
	freeze when going full screen using Java 7 on Mac
In-Reply-To: <519B1ABE.10303@oracle.com>
References: <E759EB08-CE28-48EB-B9CE-C5E941835022@oracle.com>
	<519B1ABE.10303@oracle.com>
Message-ID: <0578C755-5F93-403B-A872-84B9D0CAF20A@oracle.com>

Added macosx-port-dev

On May 21, 2013, at 10:57 AM, David Holmes wrote:

> Adding core-libs as this is actually a launcher change.
> 
> David
> 
> On 21/05/2013 4:36 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> http://bugs.sun.com/view_bug.do?bug_id=8009911
>> The webrev is available at:
>> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/
>> 
>> The problem:
>> When launching java with -XstatrOnFirstThread we were using dispatch_sync to start a Java main on the main thread. This blocked the main dispatch queue, so all the subsequent calls to GCD were never invoked. GCD is used a bit in our code, but it is used inside Cocoa, for example for fullscreen.
>> 
>> The solution:
>> We now launch Java main using a performSelectorOnMaintThread, so we do not block GCD.
>> 
>> Notes:
>> 1. This also fixes the following SWT bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886
>> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did not rename it to .m, because:
>> 	a. It is hard to update an old build system to compile with the new file name.
>> 	b. It is already compiled with -x objective-c, so I will compile
>> 	c. We would have lost all the hg history for this file.
>> 
>> With best regards. Petr.
>> 


From Sergey.Bylokhov at oracle.com  Tue May 21 12:40:25 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 21 May 2013 23:40:25 +0400
Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a JTabbedPane
	is incorrectly drawn
Message-ID: <519BCDA9.8080601@oracle.com>

Hello,
Please review the fix for jdk 8.
On OSX advanceY in the glyphInfo is inverted.
It is used to increment position when the glyph is drawn as part of a 
string of text:
@see DrawGlyphList.c.setupBlitVector():
     ....
     for (g=0; g<len; g++) {
         ginfo = (GlyphInfo*)imagePtrs[g];
         .....
         FLOOR_ASSIGN(gbv->glyphs[g].y, y + ginfo->topLeftY);
         .....
         y += ginfo->advanceY;
     }

advances are initialized in the CGGlyphImages.m via 
JRSFontGetAdvancesForGlyphsAndStyle().
Note that JRSFontGetAdvancesForGlyphsAndStyle use "strike->fTx" and the 
origin of this transform is relative to the bottom-left corner baseline. 
So we should pass "strike->fAltTx" to the 
JRSFontGetAdvancesForGlyphsAndStyle(Not sure is it ok or not) OR to 
invert the received advance.height.

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

-- 
Best regards, Sergey.


From philip.race at oracle.com  Tue May 21 14:27:02 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 21 May 2013 14:27:02 -0700
Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a
	JTabbedPane is incorrectly drawn
In-Reply-To: <519BCDA9.8080601@oracle.com>
References: <519BCDA9.8080601@oracle.com>
Message-ID: <519BE6A6.1010102@oracle.com>

I think this fix is fine. In the other rasteriser cases we use
(T2K, freetype) we also  flip the sign of the y advance as it is stored
as the image y advance. It looks like this was just missing here.
This change should then only affect the final glyph rendering.

-phil.

On 5/21/2013 12:40 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 8.
> On OSX advanceY in the glyphInfo is inverted.
> It is used to increment position when the glyph is drawn as part of a 
> string of text:
> @see DrawGlyphList.c.setupBlitVector():
>     ....
>     for (g=0; g<len; g++) {
>         ginfo = (GlyphInfo*)imagePtrs[g];
>         .....
>         FLOOR_ASSIGN(gbv->glyphs[g].y, y + ginfo->topLeftY);
>         .....
>         y += ginfo->advanceY;
>     }
>
> advances are initialized in the CGGlyphImages.m via 
> JRSFontGetAdvancesForGlyphsAndStyle().
> Note that JRSFontGetAdvancesForGlyphsAndStyle use "strike->fTx" and 
> the origin of this transform is relative to the bottom-left corner 
> baseline. So we should pass "strike->fAltTx" to the 
> JRSFontGetAdvancesForGlyphsAndStyle(Not sure is it ok or not) OR to 
> invert the received advance.height.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190349
> Webrev can be found at: http://cr.openjdk.java.net/~serb/7190349/webrev.00
>
> -- 
> Best regards, Sergey.
>


From philip.race at oracle.com  Tue May 21 16:47:41 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 21 May 2013 16:47:41 -0700
Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a
	JTabbedPane is incorrectly drawn
In-Reply-To: <519BE6A6.1010102@oracle.com>
References: <519BCDA9.8080601@oracle.com> <519BE6A6.1010102@oracle.com>
Message-ID: <519C079D.9070906@oracle.com>

Sergey,

This needs another look.  Although it fixed some clearly broken cases,
there is a rotated tab pane label option in SwingSet2, and it turns
out that at least for me that was working *before* the fix and now
its broken. So I suppose that there are 2 pieces of code interpreting
the sign of the advance with different expectations.

Since only Aqua does that rotation for the tab pane label, I think the
special case is there .. where it likely expected the original CT
coordinate system.

The bug report in the test case uses custom rendering so
won't fall into that case as had seemed likely from the synopsis.

-phil.

On 5/21/2013 2:27 PM, Phil Race wrote:
> I think this fix is fine. In the other rasteriser cases we use
> (T2K, freetype) we also  flip the sign of the y advance as it is stored
> as the image y advance. It looks like this was just missing here.
> This change should then only affect the final glyph rendering.
>
> -phil.
>
> On 5/21/2013 12:40 PM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk 8.
>> On OSX advanceY in the glyphInfo is inverted.
>> It is used to increment position when the glyph is drawn as part of a 
>> string of text:
>> @see DrawGlyphList.c.setupBlitVector():
>>     ....
>>     for (g=0; g<len; g++) {
>>         ginfo = (GlyphInfo*)imagePtrs[g];
>>         .....
>>         FLOOR_ASSIGN(gbv->glyphs[g].y, y + ginfo->topLeftY);
>>         .....
>>         y += ginfo->advanceY;
>>     }
>>
>> advances are initialized in the CGGlyphImages.m via 
>> JRSFontGetAdvancesForGlyphsAndStyle().
>> Note that JRSFontGetAdvancesForGlyphsAndStyle use "strike->fTx" and 
>> the origin of this transform is relative to the bottom-left corner 
>> baseline. So we should pass "strike->fAltTx" to the 
>> JRSFontGetAdvancesForGlyphsAndStyle(Not sure is it ok or not) OR to 
>> invert the received advance.height.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190349
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/7190349/webrev.00
>>
>> -- 
>> Best regards, Sergey.
>>
>


From Sergey.Bylokhov at oracle.com  Tue May 21 18:28:46 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 22 May 2013 05:28:46 +0400
Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a
	JTabbedPane is incorrectly drawn
In-Reply-To: <519C079D.9070906@oracle.com>
References: <519BCDA9.8080601@oracle.com> <519BE6A6.1010102@oracle.com>
	<519C079D.9070906@oracle.com>
Message-ID: <519C1F4E.8040302@oracle.com>

Hi, Phil.
Looks like there is workaround for this and now it should be removed. 
I'll take a look at it.

On 22.05.2013 3:47, Phil Race wrote:
> Sergey,
>
> This needs another look.  Although it fixed some clearly broken cases,
> there is a rotated tab pane label option in SwingSet2, and it turns
> out that at least for me that was working *before* the fix and now
> its broken. So I suppose that there are 2 pieces of code interpreting
> the sign of the advance with different expectations.
>
> Since only Aqua does that rotation for the tab pane label, I think the
> special case is there .. where it likely expected the original CT
> coordinate system.
>
> The bug report in the test case uses custom rendering so
> won't fall into that case as had seemed likely from the synopsis.
>
> -phil.
>
> On 5/21/2013 2:27 PM, Phil Race wrote:
>> I think this fix is fine. In the other rasteriser cases we use
>> (T2K, freetype) we also  flip the sign of the y advance as it is stored
>> as the image y advance. It looks like this was just missing here.
>> This change should then only affect the final glyph rendering.
>>
>> -phil.
>>
>> On 5/21/2013 12:40 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 8.
>>> On OSX advanceY in the glyphInfo is inverted.
>>> It is used to increment position when the glyph is drawn as part of 
>>> a string of text:
>>> @see DrawGlyphList.c.setupBlitVector():
>>>     ....
>>>     for (g=0; g<len; g++) {
>>>         ginfo = (GlyphInfo*)imagePtrs[g];
>>>         .....
>>>         FLOOR_ASSIGN(gbv->glyphs[g].y, y + ginfo->topLeftY);
>>>         .....
>>>         y += ginfo->advanceY;
>>>     }
>>>
>>> advances are initialized in the CGGlyphImages.m via 
>>> JRSFontGetAdvancesForGlyphsAndStyle().
>>> Note that JRSFontGetAdvancesForGlyphsAndStyle use "strike->fTx" and 
>>> the origin of this transform is relative to the bottom-left corner 
>>> baseline. So we should pass "strike->fAltTx" to the 
>>> JRSFontGetAdvancesForGlyphsAndStyle(Not sure is it ok or not) OR to 
>>> invert the received advance.height.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190349
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/7190349/webrev.00
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed May 22 10:42:54 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 22 May 2013 21:42:54 +0400
Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a
	JTabbedPane is incorrectly drawn
In-Reply-To: <519C079D.9070906@oracle.com>
References: <519BCDA9.8080601@oracle.com> <519BE6A6.1010102@oracle.com>
	<519C079D.9070906@oracle.com>
Message-ID: <519D039E.4030902@oracle.com>

Hi, Phil, Mike.
Looks like I found the root cause of this bug. It is caused by the 
different behavior of JRSFontGetAdvancesForGlyphsAndStyle when 
anti-aliasing is on/off.
Initial bug exists from the beginning of macosx-port: 
https://java.net/jira/browse/MACOSX_PORT-47. The root cause of this bug 
was not fixed(as a fix, all aqua rendering was changed to use 
antialiasing-on by default).
So all our components looks good, and custom components looks bad 
because in jdk6 anti-aliasing is on by default and in jdk 7 is off by 
default.

Here is a test which fail on jdk6 and jdk7:
http://cr.openjdk.java.net/~serb/7190349/webrev.00/raw_files/new/test/java/awt/Graphics2D/DrawString/DrawRotatedString.java
If you add "bg.setRenderingHint(KEY_TEXT_ANTIALIASING, 
VALUE_TEXT_ANTIALIAS_ON);" to the createBufferedImage() it is passed.

Some technical details:
  - In both cases we call  CGGlyphImages.m.CGGI_CreateGlyphInfos, which 
calls JRSFontGetAdvancesForGlyphsAndStyle
  - JRSFontGetAdvancesForGlyphsAndStyle is called with the same 
transform, len, glyphs, CTFontRef. Only JRSFontRenderingStyle is different.
  - JRSFontGetAdvancesForGlyphsAndStyle return inverted values when 
anti-aliasing is off.

Of course I can invert received AdvancesY, when anti-aliasing is off, 
but probably it is better to fix JRSFontGetAdvancesForGlyphsAndStyle and 
cover jdk6 and jdk7 in the same time?

Thanks.

On 22.05.2013 3:47, Phil Race wrote:
> Sergey,
>
> This needs another look.  Although it fixed some clearly broken cases,
> there is a rotated tab pane label option in SwingSet2, and it turns
> out that at least for me that was working *before* the fix and now
> its broken. So I suppose that there are 2 pieces of code interpreting
> the sign of the advance with different expectations.
>
> Since only Aqua does that rotation for the tab pane label, I think the
> special case is there .. where it likely expected the original CT
> coordinate system.
>
> The bug report in the test case uses custom rendering so
> won't fall into that case as had seemed likely from the synopsis.
>
> -phil.
>
> On 5/21/2013 2:27 PM, Phil Race wrote:
>> I think this fix is fine. In the other rasteriser cases we use
>> (T2K, freetype) we also  flip the sign of the y advance as it is stored
>> as the image y advance. It looks like this was just missing here.
>> This change should then only affect the final glyph rendering.
>>
>> -phil.
>>
>> On 5/21/2013 12:40 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 8.
>>> On OSX advanceY in the glyphInfo is inverted.
>>> It is used to increment position when the glyph is drawn as part of 
>>> a string of text:
>>> @see DrawGlyphList.c.setupBlitVector():
>>>     ....
>>>     for (g=0; g<len; g++) {
>>>         ginfo = (GlyphInfo*)imagePtrs[g];
>>>         .....
>>>         FLOOR_ASSIGN(gbv->glyphs[g].y, y + ginfo->topLeftY);
>>>         .....
>>>         y += ginfo->advanceY;
>>>     }
>>>
>>> advances are initialized in the CGGlyphImages.m via 
>>> JRSFontGetAdvancesForGlyphsAndStyle().
>>> Note that JRSFontGetAdvancesForGlyphsAndStyle use "strike->fTx" and 
>>> the origin of this transform is relative to the bottom-left corner 
>>> baseline. So we should pass "strike->fAltTx" to the 
>>> JRSFontGetAdvancesForGlyphsAndStyle(Not sure is it ok or not) OR to 
>>> invert the received advance.height.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190349
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/7190349/webrev.00
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>>
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed May 22 14:51:52 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 22 May 2013 14:51:52 -0700
Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a
	JTabbedPane is incorrectly drawn
In-Reply-To: <519D039E.4030902@oracle.com>
References: <519BCDA9.8080601@oracle.com> <519BE6A6.1010102@oracle.com>
	<519C079D.9070906@oracle.com> <519D039E.4030902@oracle.com>
Message-ID: <519D3DF8.307@oracle.com>

Sergey,

Mike is the one with picture about what's going on inside that API so
what we do will depend on what he thinks can be done there. My take
is that a fix in JRSFontGetAdvancesForGlyphsAndStyle() might be harder 
to deliver,
and I'm not sure how we would would know (at runtime) when its fixed.
In the interim we'd not be able to fix this bug. So lets workaround it and
note the inconsistencies in the code.

I don't know what underlying SPI is being used but that is where the changes
would be needed for JDK 6 which won't benefit from a fix in
JRSFontGetAdvancesForGlyphsAndStyle since that was invented for JDK 7.
And I doubt Apple want to fix JDK 6 now.

-phil.

On 5/22/2013 10:42 AM, Sergey Bylokhov wrote:
> Hi, Phil, Mike.
> Looks like I found the root cause of this bug. It is caused by the 
> different behavior of JRSFontGetAdvancesForGlyphsAndStyle when 
> anti-aliasing is on/off.
> Initial bug exists from the beginning of macosx-port: 
> https://java.net/jira/browse/MACOSX_PORT-47. The root cause of this 
> bug was not fixed(as a fix, all aqua rendering was changed to use 
> antialiasing-on by default).
> So all our components looks good, and custom components looks bad 
> because in jdk6 anti-aliasing is on by default and in jdk 7 is off by 
> default.
>
> Here is a test which fail on jdk6 and jdk7:
> http://cr.openjdk.java.net/~serb/7190349/webrev.00/raw_files/new/test/java/awt/Graphics2D/DrawString/DrawRotatedString.java 
>
> If you add "bg.setRenderingHint(KEY_TEXT_ANTIALIASING, 
> VALUE_TEXT_ANTIALIAS_ON);" to the createBufferedImage() it is passed.
>
> Some technical details:
>  - In both cases we call  CGGlyphImages.m.CGGI_CreateGlyphInfos, which 
> calls JRSFontGetAdvancesForGlyphsAndStyle
>  - JRSFontGetAdvancesForGlyphsAndStyle is called with the same 
> transform, len, glyphs, CTFontRef. Only JRSFontRenderingStyle is 
> different.
>  - JRSFontGetAdvancesForGlyphsAndStyle return inverted values when 
> anti-aliasing is off.
>
> Of course I can invert received AdvancesY, when anti-aliasing is off, 
> but probably it is better to fix JRSFontGetAdvancesForGlyphsAndStyle 
> and cover jdk6 and jdk7 in the same time?
>
> Thanks.
>
> On 22.05.2013 3:47, Phil Race wrote:
>> Sergey,
>>
>> This needs another look.  Although it fixed some clearly broken cases,
>> there is a rotated tab pane label option in SwingSet2, and it turns
>> out that at least for me that was working *before* the fix and now
>> its broken. So I suppose that there are 2 pieces of code interpreting
>> the sign of the advance with different expectations.
>>
>> Since only Aqua does that rotation for the tab pane label, I think the
>> special case is there .. where it likely expected the original CT
>> coordinate system.
>>
>> The bug report in the test case uses custom rendering so
>> won't fall into that case as had seemed likely from the synopsis.
>>
>> -phil.
>>
>> On 5/21/2013 2:27 PM, Phil Race wrote:
>>> I think this fix is fine. In the other rasteriser cases we use
>>> (T2K, freetype) we also  flip the sign of the y advance as it is stored
>>> as the image y advance. It looks like this was just missing here.
>>> This change should then only affect the final glyph rendering.
>>>
>>> -phil.
>>>
>>> On 5/21/2013 12:40 PM, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk 8.
>>>> On OSX advanceY in the glyphInfo is inverted.
>>>> It is used to increment position when the glyph is drawn as part of 
>>>> a string of text:
>>>> @see DrawGlyphList.c.setupBlitVector():
>>>>     ....
>>>>     for (g=0; g<len; g++) {
>>>>         ginfo = (GlyphInfo*)imagePtrs[g];
>>>>         .....
>>>>         FLOOR_ASSIGN(gbv->glyphs[g].y, y + ginfo->topLeftY);
>>>>         .....
>>>>         y += ginfo->advanceY;
>>>>     }
>>>>
>>>> advances are initialized in the CGGlyphImages.m via 
>>>> JRSFontGetAdvancesForGlyphsAndStyle().
>>>> Note that JRSFontGetAdvancesForGlyphsAndStyle use "strike->fTx" and 
>>>> the origin of this transform is relative to the bottom-left corner 
>>>> baseline. So we should pass "strike->fAltTx" to the 
>>>> JRSFontGetAdvancesForGlyphsAndStyle(Not sure is it ok or not) OR to 
>>>> invert the received advance.height.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190349
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/7190349/webrev.00
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed May 22 15:09:07 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 23 May 2013 02:09:07 +0400
Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a
	JTabbedPane is incorrectly drawn
In-Reply-To: <519D3DF8.307@oracle.com>
References: <519BCDA9.8080601@oracle.com> <519BE6A6.1010102@oracle.com>
	<519C079D.9070906@oracle.com> <519D039E.4030902@oracle.com>
	<519D3DF8.307@oracle.com>
Message-ID: <519D4203.4090205@oracle.com>

Hi, Phil.
I was under impression that jdk6 use the same java runtime support, 
because it has the same issue and because of this e-mail.
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005156.html
We can use workaround and catch possible future fix by the new test. I 
have just wanted to point to the problem.

On 23.05.2013 1:51, Phil Race wrote:
> Sergey,
>
> Mike is the one with picture about what's going on inside that API so
> what we do will depend on what he thinks can be done there. My take
> is that a fix in JRSFontGetAdvancesForGlyphsAndStyle() might be harder 
> to deliver,
> and I'm not sure how we would would know (at runtime) when its fixed.
> In the interim we'd not be able to fix this bug. So lets workaround it 
> and
> note the inconsistencies in the code.
>
> I don't know what underlying SPI is being used but that is where the 
> changes
> would be needed for JDK 6 which won't benefit from a fix in
> JRSFontGetAdvancesForGlyphsAndStyle since that was invented for JDK 7.
> And I doubt Apple want to fix JDK 6 now.
>
> -phil.
>
> On 5/22/2013 10:42 AM, Sergey Bylokhov wrote:
>> Hi, Phil, Mike.
>> Looks like I found the root cause of this bug. It is caused by the 
>> different behavior of JRSFontGetAdvancesForGlyphsAndStyle when 
>> anti-aliasing is on/off.
>> Initial bug exists from the beginning of macosx-port: 
>> https://java.net/jira/browse/MACOSX_PORT-47. The root cause of this 
>> bug was not fixed(as a fix, all aqua rendering was changed to use 
>> antialiasing-on by default).
>> So all our components looks good, and custom components looks bad 
>> because in jdk6 anti-aliasing is on by default and in jdk 7 is off by 
>> default.
>>
>> Here is a test which fail on jdk6 and jdk7:
>> http://cr.openjdk.java.net/~serb/7190349/webrev.00/raw_files/new/test/java/awt/Graphics2D/DrawString/DrawRotatedString.java 
>>
>> If you add "bg.setRenderingHint(KEY_TEXT_ANTIALIASING, 
>> VALUE_TEXT_ANTIALIAS_ON);" to the createBufferedImage() it is passed.
>>
>> Some technical details:
>>  - In both cases we call  CGGlyphImages.m.CGGI_CreateGlyphInfos, 
>> which calls JRSFontGetAdvancesForGlyphsAndStyle
>>  - JRSFontGetAdvancesForGlyphsAndStyle is called with the same 
>> transform, len, glyphs, CTFontRef. Only JRSFontRenderingStyle is 
>> different.
>>  - JRSFontGetAdvancesForGlyphsAndStyle return inverted values when 
>> anti-aliasing is off.
>>
>> Of course I can invert received AdvancesY, when anti-aliasing is off, 
>> but probably it is better to fix JRSFontGetAdvancesForGlyphsAndStyle 
>> and cover jdk6 and jdk7 in the same time?
>>
>> Thanks.
>>
>> On 22.05.2013 3:47, Phil Race wrote:
>>> Sergey,
>>>
>>> This needs another look.  Although it fixed some clearly broken cases,
>>> there is a rotated tab pane label option in SwingSet2, and it turns
>>> out that at least for me that was working *before* the fix and now
>>> its broken. So I suppose that there are 2 pieces of code interpreting
>>> the sign of the advance with different expectations.
>>>
>>> Since only Aqua does that rotation for the tab pane label, I think the
>>> special case is there .. where it likely expected the original CT
>>> coordinate system.
>>>
>>> The bug report in the test case uses custom rendering so
>>> won't fall into that case as had seemed likely from the synopsis.
>>>
>>> -phil.
>>>
>>> On 5/21/2013 2:27 PM, Phil Race wrote:
>>>> I think this fix is fine. In the other rasteriser cases we use
>>>> (T2K, freetype) we also  flip the sign of the y advance as it is 
>>>> stored
>>>> as the image y advance. It looks like this was just missing here.
>>>> This change should then only affect the final glyph rendering.
>>>>
>>>> -phil.
>>>>
>>>> On 5/21/2013 12:40 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> On OSX advanceY in the glyphInfo is inverted.
>>>>> It is used to increment position when the glyph is drawn as part 
>>>>> of a string of text:
>>>>> @see DrawGlyphList.c.setupBlitVector():
>>>>>     ....
>>>>>     for (g=0; g<len; g++) {
>>>>>         ginfo = (GlyphInfo*)imagePtrs[g];
>>>>>         .....
>>>>>         FLOOR_ASSIGN(gbv->glyphs[g].y, y + ginfo->topLeftY);
>>>>>         .....
>>>>>         y += ginfo->advanceY;
>>>>>     }
>>>>>
>>>>> advances are initialized in the CGGlyphImages.m via 
>>>>> JRSFontGetAdvancesForGlyphsAndStyle().
>>>>> Note that JRSFontGetAdvancesForGlyphsAndStyle use "strike->fTx" 
>>>>> and the origin of this transform is relative to the bottom-left 
>>>>> corner baseline. So we should pass "strike->fAltTx" to the 
>>>>> JRSFontGetAdvancesForGlyphsAndStyle(Not sure is it ok or not) OR 
>>>>> to invert the received advance.height.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190349
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/7190349/webrev.00
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Wed May 22 16:20:38 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 22 May 2013 16:20:38 -0700
Subject: [8] Request for review: 7190349 [macosx] Text (Label) in a
	JTabbedPane is incorrectly drawn
In-Reply-To: <519D4203.4090205@oracle.com>
References: <519BCDA9.8080601@oracle.com> <519BE6A6.1010102@oracle.com>
	<519C079D.9070906@oracle.com> <519D039E.4030902@oracle.com>
	<519D3DF8.307@oracle.com> <519D4203.4090205@oracle.com>
Message-ID: <519D52C6.1050006@oracle.com>

On 5/22/13 3:09 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> I was under impression that jdk6 use the same java runtime support, 
> because it has the same issue and because of this e-mail.
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005156.html 


I can't tell (from that email) if shipping JDK 6 for OS X really uses 
those APIs,
or if the mentioned re-implementation was just an experiement.
In any case the purpose of inventing them was to expose some non-public 
functionality.
So its unclear if the problem is in tha JRS layer itself or something 
else underneath.

-phil.



From java3 at segal.org  Thu May 23 06:21:42 2013
From: java3 at segal.org (Mickey Segal)
Date: Thu, 23 May 2013 09:21:42 -0400
Subject: How do you find out if a bug has been fixed?
Message-ID: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>

The bug ?Intermittently only some components refresh? at http://bugs.sun.com/view_bug.do?bug_id=8014369 shown at http://www.segal.org/java/refresh4/ seems fixed in JRE 8 early release build 90.  

 

In general, how does one learn a bug is fixed?  I was impressed with the level of interest shown in this bug by people at Oracle so I?ve been checking the JRE 8 early release builds and pleased to see that it seems to have gotten fixed so quickly.  Is that the only way one finds out a bug is fixed?  The Sun bug page still lists it as unresolved.

 

I?ll ask one of our users who has the problem worse than others check to see if the bug is gone for him too.  Presumably he has a slower computer and ran into the timing problem worse than others.  When the fix comes out in JRE 7, does he switch back to JRE 7 by removing all Java versions and installing the latest version of 7?

 

 

 


From philip.race at oracle.com  Thu May 23 10:40:14 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 23 May 2013 10:40:14 -0700
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
Message-ID: <519E547E.4050800@oracle.com>

It should show up at bugs.sun.com as resolved.
Since 8014369  bug is marked unresolved, its not likely its fixed,
unless by amazing chance it was fixed under a different bug ID
at around the same time you submitted your report.

-phil.

  On 5/23/2013 6:21 AM, Mickey Segal wrote:
> The bug ?Intermittently only some components refresh? at http://bugs.sun.com/view_bug.do?bug_id=8014369 shown at http://www.segal.org/java/refresh4/ seems fixed in JRE 8 early release build 90.
>
>   
>
> In general, how does one learn a bug is fixed?  I was impressed with the level of interest shown in this bug by people at Oracle so I?ve been checking the JRE 8 early release builds and pleased to see that it seems to have gotten fixed so quickly.  Is that the only way one finds out a bug is fixed?  The Sun bug page still lists it as unresolved.
>
>   
>
> I?ll ask one of our users who has the problem worse than others check to see if the bug is gone for him too.  Presumably he has a slower computer and ran into the timing problem worse than others.  When the fix comes out in JRE 7, does he switch back to JRE 7 by removing all Java versions and installing the latest version of 7?
>
>   
>
>   
>
>   
>


From jhuxhorn at googlemail.com  Thu May 23 11:18:18 2013
From: jhuxhorn at googlemail.com (=?iso-8859-1?Q?J=F6rn_Huxhorn?=)
Date: Thu, 23 May 2013 20:18:18 +0200
Subject: "(Java)App is damaged and can't be opened. You should move it to the
	Trash."
Message-ID: <D186B88A-225E-41F3-9BCD-A620EECC2A23@googlemail.com>

Is there any way to circumvent this strange situation described at http://lilithapp.com/osx.html (this is my own app).

The exact same thing does also happen with other Java apps, e.g. Minecraft, TV-Browser or jEdit.

My complaint is that it's not the usual "XYZ is from an unidentified developer" message but the misleading "XYZ is damaged". This does also prevent the user from starting it anyway using Alt-Open.

I read the corresponding article at http://support.apple.com/kb/HT5290 but that doesn't really provide any clue.

I also did quite a bit of searching beside that but other than the workaround I described in the link above (disable Gatekeeper, start app, re-enable Gatekeeper) no one seems to have a real fix.

So this list is pretty much my last resort. Do you have any idea?

This is the output of some otool for some of the JavaApplicationStub versions in use:

############################################################
otool -L /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub
/Applications/Lilith.app/Contents/MacOS/JavaApplicationStub (architecture ppc):
	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 676.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
/Applications/Lilith.app/Contents/MacOS/JavaApplicationStub (architecture i386):
	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 676.0.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
############################################################
otool -L /Applications/Minecraft.app/Contents/MacOS/JavaApplicationStub
/Applications/Minecraft.app/Contents/MacOS/JavaApplicationStub:
	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.42.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.42.0)
############################################################
otool -L /Applications/muCommander.app/Contents/MacOS/JavaApplicationStub
/Applications/muCommander.app/Contents/MacOS/JavaApplicationStub:
	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.0.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.0.0)
############################################################
otool -L /Applications/TV-Browser.app/Contents/MacOS/JavaApplicationStub
/Applications/TV-Browser.app/Contents/MacOS/JavaApplicationStub:
	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.1.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
############################################################
otool -L /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub
/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub:
	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.1.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
############################################################

Yes, Lilith is using a pretty old universal executable but the same issue also happens with the TV-Browser that is seemingly using the latest version.

Cheers,
J?rn.

From david.dehaven at oracle.com  Thu May 23 11:22:04 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 23 May 2013 11:22:04 -0700
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <519E547E.4050800@oracle.com>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
Message-ID: <F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>


I don't think it's fixed, I still see it with b90. In a lot of cases I don't even see the buttons to be able to click them.

-DrD-

> It should show up at bugs.sun.com as resolved.
> Since 8014369  bug is marked unresolved, its not likely its fixed,
> unless by amazing chance it was fixed under a different bug ID
> at around the same time you submitted your report.
> 
> -phil.
> 
> On 5/23/2013 6:21 AM, Mickey Segal wrote:
>> The bug ?Intermittently only some components refresh? at http://bugs.sun.com/view_bug.do?bug_id=8014369 shown at http://www.segal.org/java/refresh4/ seems fixed in JRE 8 early release build 90.
>> 
>>  
>> In general, how does one learn a bug is fixed?  I was impressed with the level of interest shown in this bug by people at Oracle so I?ve been checking the JRE 8 early release builds and pleased to see that it seems to have gotten fixed so quickly.  Is that the only way one finds out a bug is fixed?  The Sun bug page still lists it as unresolved.
>> 
>>  
>> I?ll ask one of our users who has the problem worse than others check to see if the bug is gone for him too.  Presumably he has a slower computer and ran into the timing problem worse than others.  When the fix comes out in JRE 7, does he switch back to JRE 7 by removing all Java versions and installing the latest version of 7?
>> 
>>  
>>  
>>  
> 


From roger.lewis at oracle.com  Thu May 23 11:34:53 2013
From: roger.lewis at oracle.com (Roger Lewis)
Date: Thu, 23 May 2013 11:34:53 -0700
Subject: "(Java)App is damaged and can't be opened. You should move it
	to the Trash."
In-Reply-To: <D186B88A-225E-41F3-9BCD-A620EECC2A23@googlemail.com>
References: <D186B88A-225E-41F3-9BCD-A620EECC2A23@googlemail.com>
Message-ID: <519E614D.9020909@oracle.com>

Starting with 7u21 additional security measures were put in place. The 
dialog(s) that you are seen with the applications mentioned are 
described here. There are multiple dialogs that you may be seeing:
   http://java.com/en/download/help/appsecuritydialogs.xml

-Roger


On 5/23/13 11:18 AM, J?rn Huxhorn wrote:
> Is there any way to circumvent this strange situation described at http://lilithapp.com/osx.html (this is my own app).
>
> The exact same thing does also happen with other Java apps, e.g. Minecraft, TV-Browser or jEdit.
>
> My complaint is that it's not the usual "XYZ is from an unidentified developer" message but the misleading "XYZ is damaged". This does also prevent the user from starting it anyway using Alt-Open.
>
> I read the corresponding article at http://support.apple.com/kb/HT5290 but that doesn't really provide any clue.
>
> I also did quite a bit of searching beside that but other than the workaround I described in the link above (disable Gatekeeper, start app, re-enable Gatekeeper) no one seems to have a real fix.
>
> So this list is pretty much my last resort. Do you have any idea?
>
> This is the output of some otool for some of the JavaApplicationStub versions in use:
>
> ############################################################
> otool -L /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub
> /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub (architecture ppc):
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 676.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
> /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub (architecture i386):
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 676.0.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
> ############################################################
> otool -L /Applications/Minecraft.app/Contents/MacOS/JavaApplicationStub
> /Applications/Minecraft.app/Contents/MacOS/JavaApplicationStub:
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.42.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.42.0)
> ############################################################
> otool -L /Applications/muCommander.app/Contents/MacOS/JavaApplicationStub
> /Applications/muCommander.app/Contents/MacOS/JavaApplicationStub:
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.0.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.0.0)
> ############################################################
> otool -L /Applications/TV-Browser.app/Contents/MacOS/JavaApplicationStub
> /Applications/TV-Browser.app/Contents/MacOS/JavaApplicationStub:
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.1.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
> ############################################################
> otool -L /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub
> /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub:
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.1.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
> ############################################################
>
> Yes, Lilith is using a pretty old universal executable but the same issue also happens with the TV-Browser that is seemingly using the latest version.
>
> Cheers,
> J?rn.


From jesmith at kaon.com  Thu May 23 11:39:01 2013
From: jesmith at kaon.com (Joshua Smith)
Date: Thu, 23 May 2013 14:39:01 -0400
Subject: "(Java)App is damaged and can't be opened. You should move it to
	the Trash."
In-Reply-To: <D186B88A-225E-41F3-9BCD-A620EECC2A23@googlemail.com>
References: <D186B88A-225E-41F3-9BCD-A620EECC2A23@googlemail.com>
Message-ID: <4C3C702C-51FB-4D54-A619-4AB7E016E5E7@kaon.com>

You need to sign the .app

My build script includes a line like this:

  export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"
  codesign -f -s "Developer ID Application: Kaon Interactive Inc." -v mesonInst.app

You'll need to do something similar.

You need to be a registered Apple developer to get the certificates that codesign needs.

On May 23, 2013, at 2:18 PM, J?rn Huxhorn <jhuxhorn at googlemail.com> wrote:

> Is there any way to circumvent this strange situation described at http://lilithapp.com/osx.html (this is my own app).
> 
> The exact same thing does also happen with other Java apps, e.g. Minecraft, TV-Browser or jEdit.
> 
> My complaint is that it's not the usual "XYZ is from an unidentified developer" message but the misleading "XYZ is damaged". This does also prevent the user from starting it anyway using Alt-Open.
> 
> I read the corresponding article at http://support.apple.com/kb/HT5290 but that doesn't really provide any clue.
> 
> I also did quite a bit of searching beside that but other than the workaround I described in the link above (disable Gatekeeper, start app, re-enable Gatekeeper) no one seems to have a real fix.
> 
> So this list is pretty much my last resort. Do you have any idea?
> 
> This is the output of some otool for some of the JavaApplicationStub versions in use:
> 
> ############################################################
> otool -L /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub
> /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub (architecture ppc):
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 676.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
> /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub (architecture i386):
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 676.0.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
> ############################################################
> otool -L /Applications/Minecraft.app/Contents/MacOS/JavaApplicationStub
> /Applications/Minecraft.app/Contents/MacOS/JavaApplicationStub:
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.42.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.42.0)
> ############################################################
> otool -L /Applications/muCommander.app/Contents/MacOS/JavaApplicationStub
> /Applications/muCommander.app/Contents/MacOS/JavaApplicationStub:
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.0.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.0.0)
> ############################################################
> otool -L /Applications/TV-Browser.app/Contents/MacOS/JavaApplicationStub
> /Applications/TV-Browser.app/Contents/MacOS/JavaApplicationStub:
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.1.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
> ############################################################
> otool -L /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub
> /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub:
> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.1.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
> ############################################################
> 
> Yes, Lilith is using a pretty old universal executable but the same issue also happens with the TV-Browser that is seemingly using the latest version.
> 
> Cheers,
> J?rn.


From david.dehaven at oracle.com  Thu May 23 12:17:05 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 23 May 2013 12:17:05 -0700
Subject: "(Java)App is damaged and can't be opened. You should move it to
	the Trash."
In-Reply-To: <519E614D.9020909@oracle.com>
References: <D186B88A-225E-41F3-9BCD-A620EECC2A23@googlemail.com>
	<519E614D.9020909@oracle.com>
Message-ID: <04D18B19-6E18-42A5-A0FB-07FAA74E1797@oracle.com>


No, this is a Gatekeeper issue, likely due to some signing problem in the app bundle. It's also using the old Java 6 launcher, all these apps need to be ported to Java 7 now :) With the upcoming 7u40 release (which now has an EA build posted, and which everyone should be testing) there should be few arguments against porting.

https://jdk7.java.net/download.html

-DrD-

> Starting with 7u21 additional security measures were put in place. The dialog(s) that you are seen with the applications mentioned are described here. There are multiple dialogs that you may be seeing:
>  http://java.com/en/download/help/appsecuritydialogs.xml
> 
> -Roger
> 
> 
> On 5/23/13 11:18 AM, J?rn Huxhorn wrote:
>> Is there any way to circumvent this strange situation described at http://lilithapp.com/osx.html (this is my own app).
>> 
>> The exact same thing does also happen with other Java apps, e.g. Minecraft, TV-Browser or jEdit.
>> 
>> My complaint is that it's not the usual "XYZ is from an unidentified developer" message but the misleading "XYZ is damaged". This does also prevent the user from starting it anyway using Alt-Open.
>> 
>> I read the corresponding article at http://support.apple.com/kb/HT5290 but that doesn't really provide any clue.
>> 
>> I also did quite a bit of searching beside that but other than the workaround I described in the link above (disable Gatekeeper, start app, re-enable Gatekeeper) no one seems to have a real fix.
>> 
>> So this list is pretty much my last resort. Do you have any idea?
>> 
>> This is the output of some otool for some of the JavaApplicationStub versions in use:
>> 
>> ############################################################
>> otool -L /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub
>> /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub (architecture ppc):
>> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
>> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 676.0.0)
>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
>> /Applications/Lilith.app/Contents/MacOS/JavaApplicationStub (architecture i386):
>> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
>> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 676.0.0)
>> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
>> ############################################################
>> otool -L /Applications/Minecraft.app/Contents/MacOS/JavaApplicationStub
>> /Applications/Minecraft.app/Contents/MacOS/JavaApplicationStub:
>> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
>> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.42.0)
>> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.42.0)
>> ############################################################
>> otool -L /Applications/muCommander.app/Contents/MacOS/JavaApplicationStub
>> /Applications/muCommander.app/Contents/MacOS/JavaApplicationStub:
>> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
>> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.0.0)
>> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.0.0)
>> ############################################################
>> otool -L /Applications/TV-Browser.app/Contents/MacOS/JavaApplicationStub
>> /Applications/TV-Browser.app/Contents/MacOS/JavaApplicationStub:
>> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
>> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.1.0)
>> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
>> ############################################################
>> otool -L /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub
>> /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub:
>> 	/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Versions/A/JavaApplicationLauncher (compatibility version 1.0.0, current version 1.0.0)
>> 	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.1.0)
>> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)
>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.0.0)
>> ############################################################
>> 
>> Yes, Lilith is using a pretty old universal executable but the same issue also happens with the TV-Browser that is seemingly using the latest version.
>> 
>> Cheers,
>> J?rn.
> 


From java3 at segal.org  Thu May 23 13:18:19 2013
From: java3 at segal.org (Mickey Segal)
Date: Thu, 23 May 2013 16:18:19 -0400
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
	<F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
Message-ID: <000a01ce57f2$ab7c3830$0274a890$@segal.org>

That's odd.  I haven't seen the bug once despite much testing with build 90, with the huge app this is meant to model and both of the demo apps (see http://www.segal.org/java/refresh4/).  Maybe something made it far less likely.  

I'll see what I hear from our user who was much affected by the problem, and await news that this is officially fixed.

-----Original Message-----
From: David DeHaven [mailto:david.dehaven at oracle.com] 
Sent: Thursday, May 23, 2013 2:22 PM
To: Phil Race
Cc: Mickey Segal; Java Port MacOS
Subject: Re: How do you find out if a bug has been fixed?


I don't think it's fixed, I still see it with b90. In a lot of cases I don't even see the buttons to be able to click them. 


From private at claudio.ch  Thu May 23 13:50:20 2013
From: private at claudio.ch (Claudio Nieder)
Date: Thu, 23 May 2013 22:50:20 +0200
Subject: "(Java)App is damaged and can't be opened. You should move it to
	the Trash."
In-Reply-To: <D186B88A-225E-41F3-9BCD-A620EECC2A23@googlemail.com>
References: <D186B88A-225E-41F3-9BCD-A620EECC2A23@googlemail.com>
Message-ID: <F33A031B-EADE-41BC-A753-329931FE389B@claudio.ch>

Hi,

I had recently the application is damaged issue with an eclipse release candidate and could fix it by performing xattr -rc Eclipse.app

claudio 

Von meinem iPhone gesendet

From java3 at segal.org  Fri May 24 12:17:31 2013
From: java3 at segal.org (Mickey Segal)
Date: Fri, 24 May 2013 15:17:31 -0400
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
	<F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
Message-ID: <000c01ce58b3$574ce310$05e6a930$@segal.org>

The problem with not seeing the buttons at all in an applet could be from the Safari bug "Java applet won't run first time on Safari (OK on Firefox)" (Apple bug ID #13850046) shown at http://www.segal.org/java/Hello/

David DeHaven wrote: 

I don't think it's fixed, I still see it with b90. In a lot of cases I don't even see the buttons to be able to click them.



From philip.race at oracle.com  Fri May 24 12:16:19 2013
From: philip.race at oracle.com (Phil Race)
Date: Fri, 24 May 2013 12:16:19 -0700
Subject: JDK 7/8 falling back to headless toolkit in ssh login session
Message-ID: <519FBC83.3050008@oracle.com>

When we ssh into an OS X system as the currently logged in user, we
would like to run automated tests that display on the screen. However
I found that I need to explicitly tell it the toolkit to use to get this to work
"AWT_TOOLKIT=CToolkit    java ..."

else it falls back into a path where it selects the headless toolkit
which then complains when we try to create a window :

java -jar SwingSet2.jar
Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
         at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77)
         at SwingSet2.main(SwingSet2.java:222)
....
The X11 message is a bit confusing but is basically the fallback code assuming
that the headful toolkit would have been X11.

And  SwingSet2 uses the SplashScreen API which displays an image before
AWT starts running, so we get the oddity that you see the splash screen displayed
for a moment before AWT decides that can't have been possible and shuts down :-)

The ultimate root of the problem is a function called "isInAquaSession" which uses
The OSX GetSessionInfo call. JFK checks the returned bit flag for sessionHasGraphicsAccessFlag
which is however "clear", even though as far as I can tell, it should be "set".
SwingSet2 seems to work just fine when run as
AWT_TOOLKIT=CToolkit    java -jar SwingSet2.jar
So it appears GetSessionInfo is unreliable, or maybe too picky over something
that doesn't matter ?

So are we required to forever use the workaround above, or is there something
we can do to get the right answer ?

-phil.


From nick at transparentech.com  Sun May 26 11:33:51 2013
From: nick at transparentech.com (Nicholas Rahn)
Date: Sun, 26 May 2013 20:33:51 +0200
Subject: <AWT Dev> [8] Review Request for 8009911 : [macosx] SWT app
	freeze when going full screen using Java 7 on Mac
In-Reply-To: <0578C755-5F93-403B-A872-84B9D0CAF20A@oracle.com>
References: <E759EB08-CE28-48EB-B9CE-C5E941835022@oracle.com>
	<519B1ABE.10303@oracle.com>
	<0578C755-5F93-403B-A872-84B9D0CAF20A@oracle.com>
Message-ID: <CAP3J-cO0PiDany_qM2Hc__nJOTO5DXUPGRpBuXQ+mnoke7pkTg@mail.gmail.com>

+1 for this patch. (Thanks, Petr!) I have tried it in the latest jdk8 (b91)
and it fixes both of the SWT+OpenJDK7&8 bugs that I submitted in the
Eclipse bugzilla. Would be great if this could be accepted at least for
jdk8 (if not jdk7u too).

Cheers,
Nick


On Tue, May 21, 2013 at 1:07 PM, Petr Pchelko <petr.pchelko at oracle.com>wrote:

> Added macosx-port-dev
>
> On May 21, 2013, at 10:57 AM, David Holmes wrote:
>
> > Adding core-libs as this is actually a launcher change.
> >
> > David
> >
> > On 21/05/2013 4:36 PM, Petr Pchelko wrote:
> >> Hello, AWT Team.
> >>
> >> Please review the fix for the issue:
> >> http://bugs.sun.com/view_bug.do?bug_id=8009911
> >> The webrev is available at:
> >> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/
> >>
> >> The problem:
> >> When launching java with -XstatrOnFirstThread we were using
> dispatch_sync to start a Java main on the main thread. This blocked the
> main dispatch queue, so all the subsequent calls to GCD were never invoked.
> GCD is used a bit in our code, but it is used inside Cocoa, for example for
> fullscreen.
> >>
> >> The solution:
> >> We now launch Java main using a performSelectorOnMaintThread, so we do
> not block GCD.
> >>
> >> Notes:
> >> 1. This also fixes the following SWT bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886
> >> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did
> not rename it to .m, because:
> >>      a. It is hard to update an old build system to compile with the
> new file name.
> >>      b. It is already compiled with -x objective-c, so I will compile
> >>      c. We would have lost all the hg history for this file.
> >>
> >> With best regards. Petr.
> >>
>
>

From java3 at segal.org  Sun May 26 12:28:59 2013
From: java3 at segal.org (Mickey Segal)
Date: Sun, 26 May 2013 15:28:59 -0400
Subject: How do you find out if a bug has been fixed?
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
	<F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com> 
Message-ID: <000801ce5a47$46435a00$d2ca0e00$@segal.org>

I heard back from our user who was most affected by the refresh problem and he continues to have the problem 80% of the time using JRE build 91 and http://www.segal.org/java/refresh4/.  I tested the Mac I?ve been using, which is 5 years old, and with build 90 was able to get the behavior 10% of the time only if I stressed the system by keeping lots of other stuff running.  I installed build 91 and got about the same.  

 

It sounds like some timing issue, though our user's computer is newer.  

His specs: 

?         mid 2012 MacBook Air

?         2 GHz Intel Core i7

?         8 GB 1600 MHz DDR3

?         Intel HD Graphics 4000 512 MB

My specs: 

?         2008 MacBook

?         2.4 GHz Intel Core 2 Duo

?         4 GB 1333 MHz DDR3

?         NVIDIA GeForce 9400M 256 MB  

 

I don?t know whether his 80% failure rate or my < 10% failure rate is more typical of the installed base.

 

I wrote:



That's odd.  I haven't seen the bug once despite much testing with build 90, with the huge app this is meant to model and both of the demo apps (see  <http://www.segal.org/java/refresh4/> http://www.segal.org/java/refresh4/).  Maybe something made it far less likely.  

 

I'll see what I hear from our user who was much affected by the problem, and await news that this is officially fixed.

 

David DeHaven wrote:

 

I don't think it's fixed, I still see it with b90. In a lot of cases I don't even see the buttons to be able to click them. 


From krueger at lesspain.de  Mon May 27 02:05:24 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Mon, 27 May 2013 11:05:24 +0200
Subject: Problems with FileDialog
Message-ID: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>

Hi,

I am using a native FileDialog as a directory chooser in our
application with code which looks like this

        FileDialog fileDialog = new FileDialog(appFrame, title, FileDialog.LOAD)

        try {
            System.setProperty("apple.awt.fileDialogForDirectories", "true");
            fileDialog.setVisible(true);
        } finally {
            System.setProperty("apple.awt.fileDialogForDirectories", "false");
        }

...

This works as expected with Apple's JDK6 but with current OpenJDK8 the
first time I open the dialog, it only shows the "Media" category in
the dialog's sidebar. Nothing else is visible but a progress indicator
is displayed next to the "new folder" button but it never stops.
Additionally it hangs when selecting folders and there sometimes is a
long (several seconds) delay until folder contents is displayed.

I could not reproduce this in a simple test application yet. That's
why I'm asking if anyone else had similar problems before I try to
dissect our rather complex app to produce a simple test case that
exhibits the same behavior.

Regards,

Robert

From superstippi at gmx.de  Mon May 27 02:13:33 2013
From: superstippi at gmx.de (=?UTF-8?B?U3RlcGhhbiBBw59tdXM=?=)
Date: Mon, 27 May 2013 11:13:33 +0200
Subject: Problems with FileDialog
In-Reply-To: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
Message-ID: <51A323BD.9050508@gmx.de>

Hi,

On 27.05.2013 11:05, Robert Kr?ger wrote:
> This works as expected with Apple's JDK6 but with current OpenJDK8 the
> first time I open the dialog, it only shows the "Media" category in
> the dialog's sidebar. Nothing else is visible but a progress indicator
> is displayed next to the "new folder" button but it never stops.
> Additionally it hangs when selecting folders and there sometimes is a
> long (several seconds) delay until folder contents is displayed.
>
> I could not reproduce this in a simple test application yet. That's
> why I'm asking if anyone else had similar problems before I try to
> dissect our rather complex app to produce a simple test case that
> exhibits the same behavior.

Yes, I have the same problem in my SWT application and I already filed a 
bug report. Exact same symptoms. Due to the problems with the bug 
website, I cannot give you the bug ID.

I believe it has to do with what thread the UI runs on. I haven't had 
the time yet, but from recent messages to this list, it may be that the 
latest OpenJDK 8 build contain a fix for this. If you give that a try 
and it works, I would be very interested to hear.

Best regards,
-Stephan




From krueger at lesspain.de  Mon May 27 02:28:27 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Mon, 27 May 2013 11:28:27 +0200
Subject: Problems with FileDialog
In-Reply-To: <51A323BD.9050508@gmx.de>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<51A323BD.9050508@gmx.de>
Message-ID: <CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>

On Mon, May 27, 2013 at 11:13 AM, Stephan A?mus <superstippi at gmx.de> wrote:
> Hi,
>
>
> On 27.05.2013 11:05, Robert Kr?ger wrote:
>>
>> This works as expected with Apple's JDK6 but with current OpenJDK8 the
>> first time I open the dialog, it only shows the "Media" category in
>> the dialog's sidebar. Nothing else is visible but a progress indicator
>> is displayed next to the "new folder" button but it never stops.
>> Additionally it hangs when selecting folders and there sometimes is a
>> long (several seconds) delay until folder contents is displayed.
>>
>> I could not reproduce this in a simple test application yet. That's
>> why I'm asking if anyone else had similar problems before I try to
>> dissect our rather complex app to produce a simple test case that
>> exhibits the same behavior.
>
>
> Yes, I have the same problem in my SWT application and I already filed a bug
> report. Exact same symptoms. Due to the problems with the bug website, I
> cannot give you the bug ID.
>
> I believe it has to do with what thread the UI runs on. I haven't had the
> time yet, but from recent messages to this list, it may be that the latest
> OpenJDK 8 build contain a fix for this. If you give that a try and it works,
> I would be very interested to hear.
>
I saw your post regarding this. Cool, I will check this out. You mean
the current weekly build?

Regards,

Robert

From niagarasoft20-macosxportdev at yahoo.com  Mon May 27 02:31:03 2013
From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com)
Date: Mon, 27 May 2013 02:31:03 -0700 (PDT)
Subject: Problems with FileDialog
In-Reply-To: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
Message-ID: <1369647063.33867.YahooMailNeo@web121801.mail.ne1.yahoo.com>

Robert, Are you invoking a splash screen at start up? Mike




>________________________________
> From: Robert Kr?ger <krueger at lesspain.de>
>To: "macosx-port-dev at openjdk.java.net" <macosx-port-dev at openjdk.java.net> 
>Sent: Monday, May 27, 2013 5:05 AM
>Subject: Problems with FileDialog
> 
>
>Hi,
>
>I am using a native FileDialog as a directory chooser in our
>application with code which looks like this
>
>? ? ? ? FileDialog fileDialog = new FileDialog(appFrame, title, FileDialog.LOAD)
>
>? ? ? ? try {
>? ? ? ? ? ? System.setProperty("apple.awt.fileDialogForDirectories", "true");
>? ? ? ? ? ? fileDialog.setVisible(true);
>? ? ? ? } finally {
>? ? ? ? ? ? System.setProperty("apple.awt.fileDialogForDirectories", "false");
>? ? ? ? }
>
>...
>
>This works as expected with Apple's JDK6 but with current OpenJDK8 the
>first time I open the dialog, it only shows the "Media" category in
>the dialog's sidebar. Nothing else is visible but a progress indicator
>is displayed next to the "new folder" button but it never stops.
>Additionally it hangs when selecting folders and there sometimes is a
>long (several seconds) delay until folder contents is displayed.
>
>I could not reproduce this in a simple test application yet. That's
>why I'm asking if anyone else had similar problems before I try to
>dissect our rather complex app to produce a simple test case that
>exhibits the same behavior.
>
>Regards,
>
>Robert
>
>
>

From superstippi at gmx.de  Mon May 27 02:41:36 2013
From: superstippi at gmx.de (=?UTF-8?B?U3RlcGhhbiBBw59tdXM=?=)
Date: Mon, 27 May 2013 11:41:36 +0200
Subject: Problems with FileDialog
In-Reply-To: <CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<51A323BD.9050508@gmx.de>
	<CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>
Message-ID: <51A32A50.30408@gmx.de>

Hi,

On 27.05.2013 11:28, Robert Kr?ger wrote:
> On Mon, May 27, 2013 at 11:13 AM, Stephan A?mus <superstippi at gmx.de> wrote:
>> On 27.05.2013 11:05, Robert Kr?ger wrote:
>>>
>>> This works as expected with Apple's JDK6 but with current OpenJDK8 the
>>> first time I open the dialog, it only shows the "Media" category in
>>> the dialog's sidebar. Nothing else is visible but a progress indicator
>>> is displayed next to the "new folder" button but it never stops.
>>> Additionally it hangs when selecting folders and there sometimes is a
>>> long (several seconds) delay until folder contents is displayed.
>>>
>>> I could not reproduce this in a simple test application yet. That's
>>> why I'm asking if anyone else had similar problems before I try to
>>> dissect our rather complex app to produce a simple test case that
>>> exhibits the same behavior.
>>
>>
>> Yes, I have the same problem in my SWT application and I already filed a bug
>> report. Exact same symptoms. Due to the problems with the bug website, I
>> cannot give you the bug ID.
>>
>> I believe it has to do with what thread the UI runs on. I haven't had the
>> time yet, but from recent messages to this list, it may be that the latest
>> OpenJDK 8 build contain a fix for this. If you give that a try and it works,
>> I would be very interested to hear.
>>
> I saw your post regarding this. Cool, I will check this out. You mean
> the current weekly build?

I specifically mean this message:

On 26.05.2013 20:33, Nicholas Rahn wrote:
 > +1 for this patch. (Thanks, Petr!) I have tried it in the latest jdk8 
 > (b91) and it fixes both of the SWT+OpenJDK7&8 bugs that I submitted
 > in the Eclipse bugzilla. Would be great if this could be accepted at
 > least for jdk8 (if not jdk7u too).

... in the thread "Re: <AWT Dev> [8] Review Request for 8009911 : 
[macosx] SWT app freeze when going full screen using Java 7 on Mac"

So that would be OpenJDK 8 "b91".

Best regards,
-Stephan


From private at claudio.ch  Mon May 27 02:55:42 2013
From: private at claudio.ch (Claudio Nieder)
Date: Mon, 27 May 2013 11:55:42 +0200
Subject: Problems with FileDialog
In-Reply-To: <CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<51A323BD.9050508@gmx.de>
	<CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>
Message-ID: <8EF4255D-C4B9-4175-BCEA-0C849E7C594E@claudio.ch>

Hi,

> I specifically mean this message:
> 
> On 26.05.2013 20:33, Nicholas Rahn wrote:
> > +1 for this patch. (Thanks, Petr!) I have tried it in the latest jdk8 > (b91) and it fixes both of the SWT+OpenJDK7&8 bugs that I submitted
> > in the Eclipse bugzilla. Would be great if this could be accepted at
> > least for jdk8 (if not jdk7u too).
> 
> ... in the thread "Re: <AWT Dev> [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac"
> 
> So that would be OpenJDK 8 "b91".

To me this sounds like Nicholas says that the patch once applied to the current JDK source will fix the issue, but not that the weekly build already contains the patch. In fact http://download.java.net/jdk8/changes/jdk8-b91.html?q=download/jdk8/changes/jdk8-b91.html doesn't list it as issue fixed in b91. 

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





From superstippi at gmx.de  Mon May 27 03:03:00 2013
From: superstippi at gmx.de (=?ISO-8859-1?Q?Stephan_A=DFmus?=)
Date: Mon, 27 May 2013 12:03:00 +0200
Subject: Problems with FileDialog
In-Reply-To: <8EF4255D-C4B9-4175-BCEA-0C849E7C594E@claudio.ch>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<51A323BD.9050508@gmx.de>
	<CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>
	<8EF4255D-C4B9-4175-BCEA-0C849E7C594E@claudio.ch>
Message-ID: <51A32F54.8000900@gmx.de>

Hi,

On 27.05.2013 11:55, Claudio Nieder wrote:
>> So that would be OpenJDK 8 "b91".
>
> To me this sounds like Nicholas says that the patch once applied to the current JDK source will fix the issue, but not that the weekly build already contains the patch. In fact http://download.java.net/jdk8/changes/jdk8-b91.html?q=download/jdk8/changes/jdk8-b91.html doesn't list it as issue fixed in b91.

Oh darn, you are right!

Best regards,
-Stephan



From nick at transparentech.com  Mon May 27 03:29:51 2013
From: nick at transparentech.com (Nicholas Rahn)
Date: Mon, 27 May 2013 12:29:51 +0200
Subject: Problems with FileDialog
In-Reply-To: <8EF4255D-C4B9-4175-BCEA-0C849E7C594E@claudio.ch>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<51A323BD.9050508@gmx.de>
	<CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>
	<8EF4255D-C4B9-4175-BCEA-0C849E7C594E@claudio.ch>
Message-ID: <CAP3J-cOW38uYxdEav2O0yGGE=g40_UsuHNfXh0zo2xWzfQkkbA@mail.gmail.com>

Hi. I do not know if the patch will fix the issue described by the OP. It
does fix the 2 SWT related bugs I submitted, however. If the OP's problem
is related to the UI thread, then it's possible it may also fix that one.

@OP I have also seen the behavior you describe. I'd suggest using the patch
from Petr and see if that helps. I have not tested my app long enough with
the patched version it to say if it fixes the problem you described because
the issue is very intermittent.


Nick


On Mon, May 27, 2013 at 11:55 AM, Claudio Nieder <private at claudio.ch> wrote:

> Hi,
>
> > I specifically mean this message:
> >
> > On 26.05.2013 20:33, Nicholas Rahn wrote:
> > > +1 for this patch. (Thanks, Petr!) I have tried it in the latest jdk8
> > (b91) and it fixes both of the SWT+OpenJDK7&8 bugs that I submitted
> > > in the Eclipse bugzilla. Would be great if this could be accepted at
> > > least for jdk8 (if not jdk7u too).
> >
> > ... in the thread "Re: <AWT Dev> [8] Review Request for 8009911 :
> [macosx] SWT app freeze when going full screen using Java 7 on Mac"
> >
> > So that would be OpenJDK 8 "b91".
>
> To me this sounds like Nicholas says that the patch once applied to the
> current JDK source will fix the issue, but not that the weekly build
> already contains the patch. In fact
> http://download.java.net/jdk8/changes/jdk8-b91.html?q=download/jdk8/changes/jdk8-b91.htmldoesn't list it as issue fixed in b91.
>
> claudio
> --
> Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743,
> www.claudio.ch
>
>
>
>
>

From petr.pchelko at oracle.com  Mon May 27 03:39:57 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 27 May 2013 14:39:57 +0400
Subject: Problems with FileDialog
In-Reply-To: <CAP3J-cOW38uYxdEav2O0yGGE=g40_UsuHNfXh0zo2xWzfQkkbA@mail.gmail.com>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<51A323BD.9050508@gmx.de>
	<CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>
	<8EF4255D-C4B9-4175-BCEA-0C849E7C594E@claudio.ch>
	<CAP3J-cOW38uYxdEav2O0yGGE=g40_UsuHNfXh0zo2xWzfQkkbA@mail.gmail.com>
Message-ID: <152A4748-6A11-43AF-8918-FF75C4ACE898@oracle.com>

Hello, everyone.

>> To me this sounds like Nicholas says that the patch once applied to the
>> current JDK source will fix the issue, but not that the weekly build
>> already contains the patch. In fact
>> http://download.java.net/jdk8/changes/jdk8-b91.html?q=download/jdk8/changes/jdk8-b91.htmldoesn't list it as issue fixed in b91
Yes, you are right. The patch was not officially approved yet, so it is not in the repo. I suppose I will be able to push it this week.

As for the FileDialog problem. I did not quite understand from the discussion if the problem is reproducible only with SWT or not?
If it is reproducible without SWT and -XstartOnFirstThread option, than it is definitely a separate issue and it will not be resolved by my fix.

With best regards. Petr.


27.05.2013, ? 14:29, Nicholas Rahn <nick at transparentech.com> ???????(?):

> Hi. I do not know if the patch will fix the issue described by the OP. It
> does fix the 2 SWT related bugs I submitted, however. If the OP's problem
> is related to the UI thread, then it's possible it may also fix that one.
> 
> @OP I have also seen the behavior you describe. I'd suggest using the patch
> from Petr and see if that helps. I have not tested my app long enough with
> the patched version it to say if it fixes the problem you described because
> the issue is very intermittent.
> 
> 
> Nick
> 
> 
> On Mon, May 27, 2013 at 11:55 AM, Claudio Nieder <private at claudio.ch> wrote:
> 
>> Hi,
>> 
>>> I specifically mean this message:
>>> 
>>> On 26.05.2013 20:33, Nicholas Rahn wrote:
>>>> +1 for this patch. (Thanks, Petr!) I have tried it in the latest jdk8
>>> (b91) and it fixes both of the SWT+OpenJDK7&8 bugs that I submitted
>>>> in the Eclipse bugzilla. Would be great if this could be accepted at
>>>> least for jdk8 (if not jdk7u too).
>>> 
>>> ... in the thread "Re: <AWT Dev> [8] Review Request for 8009911 :
>> [macosx] SWT app freeze when going full screen using Java 7 on Mac"
>>> 
>>> So that would be OpenJDK 8 "b91".
>> 
>> To me this sounds like Nicholas says that the patch once applied to the
>> current JDK source will fix the issue, but not that the weekly build
>> already contains the patch. In fact
>> http://download.java.net/jdk8/changes/jdk8-b91.html?q=download/jdk8/changes/jdk8-b91.htmldoesn't list it as issue fixed in b91.
>> 
>> claudio
>> --
>> Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743,
>> www.claudio.ch
>> 
>> 
>> 
>> 
>> 


From niagarasoft20-macosxportdev at yahoo.com  Mon May 27 07:10:26 2013
From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com)
Date: Mon, 27 May 2013 07:10:26 -0700 (PDT)
Subject: Problems with FileDialog
In-Reply-To: <152A4748-6A11-43AF-8918-FF75C4ACE898@oracle.com>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<51A323BD.9050508@gmx.de>
	<CAEnqZEUNucbLQKoUq5GVGHPizO-v+hP2ZQbR1OyH92CPZChKMg@mail.gmail.com>
	<8EF4255D-C4B9-4175-BCEA-0C849E7C594E@claudio.ch>
	<CAP3J-cOW38uYxdEav2O0yGGE=g40_UsuHNfXh0zo2xWzfQkkbA@mail.gmail.com>
	<152A4748-6A11-43AF-8918-FF75C4ACE898@oracle.com>
Message-ID: <1369663826.85966.YahooMailNeo@web121801.mail.ne1.yahoo.com>



I believe the bug ID for what he is describing is:? 8006420

Regards, Mike


>________________________________
> From: Petr Pchelko <petr.pchelko at oracle.com>
>To: Nicholas Rahn <nick at transparentech.com> 
>Cc: "macosx-port-dev at openjdk.java.net OS X" <macosx-port-dev at openjdk.java.net> 
>Sent: Monday, May 27, 2013 6:39 AM
>Subject: Re: Problems with FileDialog
> 
>
>Hello, everyone.
>
>>> To me this sounds like Nicholas says that the patch once applied to the
>>> current JDK source will fix the issue, but not that the weekly build
>>> already contains the patch. In fact
>>> http://download.java.net/jdk8/changes/jdk8-b91.html?q=download/jdk8/changes/jdk8-b91.htmldoesn't list it as issue fixed in b91
>Yes, you are right. The patch was not officially approved yet, so it is not in the repo. I suppose I will be able to push it this week.
>
>As for the FileDialog problem. I did not quite understand from the discussion if the problem is reproducible only with SWT or not?
>If it is reproducible without SWT and -XstartOnFirstThread option, than it is definitely a separate issue and it will not be resolved by my fix.
>
>With best regards. Petr.
>
>
>27.05.2013, ? 14:29, Nicholas Rahn <nick at transparentech.com> ???????(?):
>
>> Hi. I do not know if the patch will fix the issue described by the OP. It
>> does fix the 2 SWT related bugs I submitted, however. If the OP's problem
>> is related to the UI thread, then it's possible it may also fix that one.
>> 
>> @OP I have also seen the behavior you describe. I'd suggest using the patch
>> from Petr and see if that helps. I have not tested my app long enough with
>> the patched version it to say if it fixes the problem you described because
>> the issue is very intermittent.
>> 
>> 
>> Nick
>> 
>> 
>> On Mon, May 27, 2013 at 11:55 AM, Claudio Nieder <private at claudio.ch> wrote:
>> 
>>> Hi,
>>> 
>>>> I specifically mean this message:
>>>> 
>>>> On 26.05.2013 20:33, Nicholas Rahn wrote:
>>>>> +1 for this patch. (Thanks, Petr!) I have tried it in the latest jdk8
>>>> (b91) and it fixes both of the SWT+OpenJDK7&8 bugs that I submitted
>>>>> in the Eclipse bugzilla. Would be great if this could be accepted at
>>>>> least for jdk8 (if not jdk7u too).
>>>> 
>>>> ... in the thread "Re: <AWT Dev> [8] Review Request for 8009911 :
>>> [macosx] SWT app freeze when going full screen using Java 7 on Mac"
>>>> 
>>>> So that would be OpenJDK 8 "b91".
>>> 
>>> To me this sounds like Nicholas says that the patch once applied to the
>>> current JDK source will fix the issue, but not that the weekly build
>>> already contains the patch. In fact
>>> http://download.java.net/jdk8/changes/jdk8-b91.html?q=download/jdk8/changes/jdk8-b91.htmldoesn't list it as issue fixed in b91.
>>> 
>>> claudio
>>> --
>>> Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743,
>>> www.claudio.ch
>>> 
>>> 
>>> 
>>> 
>>> 
>
>
>

From anthony.petrov at oracle.com  Mon May 27 07:51:06 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 27 May 2013 18:51:06 +0400
Subject: JDK 7/8 falling back to headless toolkit in ssh login session
In-Reply-To: <519FBC83.3050008@oracle.com>
References: <519FBC83.3050008@oracle.com>
Message-ID: <51A372DA.5040908@oracle.com>

Hi Phil,

We explicitly decided to fall back to the headless mode when running 
over ssh. Please see this message:

http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001883.html

--
best regards,
Anthony

On 05/24/13 23:16, Phil Race wrote:
> When we ssh into an OS X system as the currently logged in user, we
> would like to run automated tests that display on the screen. However
> I found that I need to explicitly tell it the toolkit to use to get this
> to work
> "AWT_TOOLKIT=CToolkit java ..."
>
> else it falls back into a path where it selects the headless toolkit
> which then complains when we try to create a window :
>
> java -jar SwingSet2.jar
> Exception in thread "main" java.awt.HeadlessException:
> No X11 DISPLAY variable was set, but this program performed an operation
> which requires it.
> at
> sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77)
>
> at SwingSet2.main(SwingSet2.java:222)
> ....
> The X11 message is a bit confusing but is basically the fallback code
> assuming
> that the headful toolkit would have been X11.
>
> And SwingSet2 uses the SplashScreen API which displays an image before
> AWT starts running, so we get the oddity that you see the splash screen
> displayed
> for a moment before AWT decides that can't have been possible and shuts
> down :-)
>
> The ultimate root of the problem is a function called "isInAquaSession"
> which uses
> The OSX GetSessionInfo call. JFK checks the returned bit flag for
> sessionHasGraphicsAccessFlag
> which is however "clear", even though as far as I can tell, it should be
> "set".
> SwingSet2 seems to work just fine when run as
> AWT_TOOLKIT=CToolkit java -jar SwingSet2.jar
> So it appears GetSessionInfo is unreliable, or maybe too picky over
> something
> that doesn't matter ?
>
> So are we required to forever use the workaround above, or is there
> something
> we can do to get the right answer ?
>
> -phil.
>

From niagarasoft20-macosxportdev at yahoo.com  Mon May 27 10:07:18 2013
From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com)
Date: Mon, 27 May 2013 10:07:18 -0700 (PDT)
Subject: Problems with FileDialog
In-Reply-To: <CAEnqZEX6Z8g253q+-ZeaKZmj9vbK_2Hq51LhHSGgssOGFkvLKg@mail.gmail.com>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<1369647063.33867.YahooMailNeo@web121801.mail.ne1.yahoo.com>
	<CAEnqZEUcG=0WS0fH=7vTMSPeVnDaqwO_jW1Raf2XDNeFhm10Zg@mail.gmail.com>
	<CAEnqZEUdvcSYNS4UDDMuZgxW6ZMxdYGoZscxHdgvMsbF9p_vOg@mail.gmail.com>
	<1369663048.65121.YahooMailNeo@web121801.mail.ne1.yahoo.com>
	<CAEnqZEX6Z8g253q+-ZeaKZmj9vbK_2Hq51LhHSGgssOGFkvLKg@mail.gmail.com>
Message-ID: <1369674438.25124.YahooMailNeo@web121801.mail.ne1.yahoo.com>

Robert, The wording in the bug report is confusing, but means if a splash is displayed at program launch using the -splash param, either
in the app bundle launcher info.plist or from the command line.


The old fashion way of presenting a splash is the way we used to do this before this feature was introduced in Java 1.6 which was using a basic awt.Frame. This is the work around that I'm using for the Mac port. Windows, Linux & Solaris works as it should. Hope this saves you some time. Mike




>________________________________
> From: Robert Kr?ger <krueger at lesspain.de>
>To: "niagarasoft20-macosxportdev at yahoo.com" <niagarasoft20-macosxportdev at yahoo.com> 
>Sent: Monday, May 27, 2013 10:50 AM
>Subject: Re: Problems with FileDialog
> 
>
>On Mon, May 27, 2013 at 3:57 PM, niagarasoft20-macosxportdev at yahoo.com
><niagarasoft20-macosxportdev at yahoo.com> wrote:
>> Yes, see. http://bugs.sun.com/view_bug.do?bug_id=8006420
>>
>> Also:
>>
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-December/005245.html
>>
>> It was alot of work to figure out this connection. For now, I just create a
>> splash screen the old fashion way.
>>
>> Mike
>
>OK, thank you! To the Oracle engineers: The bug report states "The
>FileDialog won't work properly if it's shown while an AWT SplashScreen
>is showing". I don't know if that was meant literally but in my case
>the splash screen is long gone when this happens.
>
>By the old-fashioned way you mean displaying your own Frame for that
>when your application starts?
>
>Robert
>
>
>

From swingler at apple.com  Mon May 27 10:19:39 2013
From: swingler at apple.com (Mike Swingler)
Date: Mon, 27 May 2013 10:19:39 -0700
Subject: JDK 7/8 falling back to headless toolkit in ssh login session
In-Reply-To: <51A372DA.5040908@oracle.com>
References: <519FBC83.3050008@oracle.com> <51A372DA.5040908@oracle.com>
Message-ID: <022C09CB-D7CA-4EE5-99F7-0A2443D7FB75@apple.com>

Phil, the crux of the problem is that the session you get when you SSH in isn't an "Aqua" session - so while apps you launch may be able to connect to the window server and show a window, lots of subtle stuff is going to be broken that relies on the session:
* The connection to the pasteboard server -> DnD and some copy/paste operations won't function properly
* App foreground activation doesn't occur correctly (LaunchServices)
* The "robot" operations may also be busted, but I haven't checked recently.
* Any AppleScript events to or from the process

Since these are design issues that are unlikely to ever be addressed by Apple (they have been present since OS X 10.0) we decided for Java 7+ that we will not further the misconception that you can fully interact with the logged in user from an SSH session.

~Mike

On May 27, 2013, at 7:51 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Phil,
> 
> We explicitly decided to fall back to the headless mode when running over ssh. Please see this message:
> 
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001883.html
> 
> --
> best regards,
> Anthony
> 
> On 05/24/13 23:16, Phil Race wrote:
>> When we ssh into an OS X system as the currently logged in user, we
>> would like to run automated tests that display on the screen. However
>> I found that I need to explicitly tell it the toolkit to use to get this
>> to work
>> "AWT_TOOLKIT=CToolkit java ..."
>> 
>> else it falls back into a path where it selects the headless toolkit
>> which then complains when we try to create a window :
>> 
>> java -jar SwingSet2.jar
>> Exception in thread "main" java.awt.HeadlessException:
>> No X11 DISPLAY variable was set, but this program performed an operation
>> which requires it.
>> at
>> sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77)
>> 
>> at SwingSet2.main(SwingSet2.java:222)
>> ....
>> The X11 message is a bit confusing but is basically the fallback code
>> assuming
>> that the headful toolkit would have been X11.
>> 
>> And SwingSet2 uses the SplashScreen API which displays an image before
>> AWT starts running, so we get the oddity that you see the splash screen
>> displayed
>> for a moment before AWT decides that can't have been possible and shuts
>> down :-)
>> 
>> The ultimate root of the problem is a function called "isInAquaSession"
>> which uses
>> The OSX GetSessionInfo call. JFK checks the returned bit flag for
>> sessionHasGraphicsAccessFlag
>> which is however "clear", even though as far as I can tell, it should be
>> "set".
>> SwingSet2 seems to work just fine when run as
>> AWT_TOOLKIT=CToolkit java -jar SwingSet2.jar
>> So it appears GetSessionInfo is unreliable, or maybe too picky over
>> something
>> that doesn't matter ?
>> 
>> So are we required to forever use the workaround above, or is there
>> something
>> we can do to get the right answer ?
>> 
>> -phil.
>> 


From krueger at lesspain.de  Mon May 27 11:36:28 2013
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Mon, 27 May 2013 20:36:28 +0200
Subject: Problems with FileDialog
In-Reply-To: <1369674438.25124.YahooMailNeo@web121801.mail.ne1.yahoo.com>
References: <CAEnqZEUEpGMeDuJZySWqXk8dpZizTSdiirBaeiNiDqddTZPx_w@mail.gmail.com>
	<1369647063.33867.YahooMailNeo@web121801.mail.ne1.yahoo.com>
	<CAEnqZEUcG=0WS0fH=7vTMSPeVnDaqwO_jW1Raf2XDNeFhm10Zg@mail.gmail.com>
	<CAEnqZEUdvcSYNS4UDDMuZgxW6ZMxdYGoZscxHdgvMsbF9p_vOg@mail.gmail.com>
	<1369663048.65121.YahooMailNeo@web121801.mail.ne1.yahoo.com>
	<CAEnqZEX6Z8g253q+-ZeaKZmj9vbK_2Hq51LhHSGgssOGFkvLKg@mail.gmail.com>
	<1369674438.25124.YahooMailNeo@web121801.mail.ne1.yahoo.com>
Message-ID: <CAEnqZEXhv_Ldg5myYXmJ+3gxngKC1C=enUF3-Gax27dC4ChhKg@mail.gmail.com>

On Mon, May 27, 2013 at 7:07 PM, niagarasoft20-macosxportdev at yahoo.com
<niagarasoft20-macosxportdev at yahoo.com> wrote:
> Robert, The wording in the bug report is confusing, but means if a splash is
> displayed at program launch using the -splash param, either
> in the app bundle launcher info.plist or from the command line.

that's what I thought as it's exactly what I'm experiencing.

>
> The old fashion way of presenting a splash is the way we used to do this
> before this feature was introduced in Java 1.6 which was using a basic
> awt.Frame. This is the work around that I'm using for the Mac port. Windows,
> Linux & Solaris works as it should. Hope this saves you some time. Mike

It sure does and it saves me the headaches of having to worry about a
fix getting ready until we ship our app with Java 8.

Thanks a lot!

Robert

From Sergey.Bylokhov at oracle.com  Tue May 28 05:37:03 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 28 May 2013 16:37:03 +0400
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
	<F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
Message-ID: <51A4A4EF.3060609@oracle.com>

Hello.
I trace down this bug and found that part of the issue is in the CAlayer 
implementation. The reason is simple: setNeedsDisplay is not followed by 
the drawInGLContext.
The problem is not reproduced if i set layer.asynchronous from FALSE to YES.

On 23.05.2013 22:22, David DeHaven wrote:
> I don't think it's fixed, I still see it with b90. In a lot of cases I don't even see the buttons to be able to click them.
>
> -DrD-
>
>> It should show up at bugs.sun.com as resolved.
>> Since 8014369  bug is marked unresolved, its not likely its fixed,
>> unless by amazing chance it was fixed under a different bug ID
>> at around the same time you submitted your report.
>>
>> -phil.
>>
>> On 5/23/2013 6:21 AM, Mickey Segal wrote:
>>> The bug ?Intermittently only some components refresh? at http://bugs.sun.com/view_bug.do?bug_id=8014369 shown at http://www.segal.org/java/refresh4/ seems fixed in JRE 8 early release build 90.
>>>
>>>   
>>> In general, how does one learn a bug is fixed?  I was impressed with the level of interest shown in this bug by people at Oracle so I?ve been checking the JRE 8 early release builds and pleased to see that it seems to have gotten fixed so quickly.  Is that the only way one finds out a bug is fixed?  The Sun bug page still lists it as unresolved.
>>>
>>>   
>>> I?ll ask one of our users who has the problem worse than others check to see if the bug is gone for him too.  Presumably he has a slower computer and ran into the timing problem worse than others.  When the fix comes out in JRE 7, does he switch back to JRE 7 by removing all Java versions and installing the latest version of 7?
>>>
>>>   
>>>   
>>>   


-- 
Best regards, Sergey.


From java3 at segal.org  Tue May 28 06:08:41 2013
From: java3 at segal.org (Mickey Segal)
Date: Tue, 28 May 2013 09:08:41 -0400
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <51A4A4EF.3060609@oracle.com>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
	<F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
	<51A4A4EF.3060609@oracle.com>
Message-ID: <004101ce5ba4$7a9125e0$6fb371a0$@segal.org>

I am not familiar with the underlying details of the JRE.  Does this mean there is something an application programmer can set as a workaround, or does that mean that there is something that folks at Oracle can change to make a future JRE build not suffer from this problem?

 

I appreciate the attention to fixing this problem.  It reminds me of the time I mentioned a crash bug to Scott McNealy, who passed it on to the engineers, who later told me that this was something that was a big enough problem that they chose it as the first change to make in JRE 7.

 

Sergey Bylokhov wrote: 



I trace down this bug and found that part of the issue is in the CAlayer implementation. The reason is simple: setNeedsDisplay is not followed by the drawInGLContext.

The problem is not reproduced if i set layer.asynchronous from FALSE to YES.

 

On 23.05.2013 22:22, David DeHaven wrote:

> I don't think it's fixed, I still see it with b90. 

 

>> On 5/23/2013 6:21 AM, Mickey Segal wrote:

>>> The bug ?Intermittently only some components refresh? at  <http://bugs.sun.com/view_bug.do?bug_id=8014369> http://bugs.sun.com/view_bug.do?bug_id=8014369 shown at  <http://www.segal.org/java/refresh4/> http://www.segal.org/java/refresh4/ seems fixed in JRE 8 early release build 90.


From david.dehaven at oracle.com  Tue May 28 08:09:36 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 28 May 2013 08:09:36 -0700
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <004101ce5ba4$7a9125e0$6fb371a0$@segal.org>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
	<F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
	<51A4A4EF.3060609@oracle.com>
	<004101ce5ba4$7a9125e0$6fb371a0$@segal.org>
Message-ID: <D5F9676A-AF18-4FB6-8BC3-BF990262E9AB@oracle.com>


> I am not familiar with the underlying details of the JRE.  Does this mean there is something an application programmer can set as a workaround, or does that mean that there is something that folks at Oracle can change to make a future JRE build not suffer from this problem?

No, this has to be fixed in the code.

-DrD-


From david.dehaven at oracle.com  Tue May 28 08:16:24 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 28 May 2013 08:16:24 -0700
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk is
	outdated
In-Reply-To: <B7B5CFE3-F041-47D5-BC4D-D2F70CFE37C9@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
	<5196169F.1020505@oracle.com>
	<1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>
	<5196415A.7020807@oracle.com>
	<E97BB6DE-0114-4DFD-A87F-F78B112B53B5@oracle.com>
	<5196483D.4040106@oracle.com>
	<B7B5CFE3-F041-47D5-BC4D-D2F70CFE37C9@oracle.com>
Message-ID: <D82D1F0A-BCA7-4626-892A-15E0713109BD@oracle.com>


Should I post this to 7u-dev for approval? Can I get someone to sponsor this (since I'm not a committer...)?

-DrD-

> 
> Incidentally, I tried compiling with the JDK8 jni_md.h and it built fine... I didn't think the related changes were backported, or were they?
> 
> Either way, I think it needs to be a separate issue. Not that it matters, I'm off chasing fires with buckets of gasoline again... :(
> 
> -DrD-
> 
>> Thanks. I'm OK if this will be a separate bug.
>> 
>> --
>> best regards,
>> Anthony
>> 
>> On 05/17/2013 07:00 PM, David DeHaven wrote:
>>> 
>>>>>> The fix looks good to me. Only one question:
>>>>>> 
>>>>>> src/macosx/javavm/export/jni_md.h
>>>>>>> 29 #define JNIEXPORT
>>>>>> 
>>>>>> Does the empty #define imply that when building a jni lib on Mac, it should export all of its symbols by default?
>>>>> 
>>>>> It depends on gcc's visibility setting, but yes, by default all symbols are exported.
>>>>> 
>>>>> JDK8 has a better jni_md.h that sets JNIEXPORT to __attribute__(visibility(("default"))). That change should be backported, but should probably need to be done under a different bug ID. I suppose I could sneak it in here :)
>>>> 
>>>> IIRC, Martin Buchholz's fix only updated the jni_md.h for Solaris, so the Mac's one is unlikely to change even if his fix is back-ported. Hence I'd vote for adding the __attribute__(visibility(("default"))) in your fix (unless this can break anything - recall the changes needed in awt_LoadLibrary.c where the JNIEXPORT was used in a typedef).
>>> 
>>> The Mac builds currently use the solaris headers in both versions (which is why I was so interested in helping him). I haven't tried building 7u-dev with the attribute set yet, so I'm not sure of the consequences in JDK7. I can give it a try, if it's too ugly I'll file a separate issue to do the backport.
>>> 
>>> 
>>>> Also, I assume you're going to forward-port your fix to JDK 8 at some point?
>>> 
>>> Yes, that's my plan.
>>> 
>>> -DrD-
>>> 
> 


From Sergey.Bylokhov at oracle.com  Tue May 28 09:12:39 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 28 May 2013 20:12:39 +0400
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <004101ce5ba4$7a9125e0$6fb371a0$@segal.org>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
	<F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
	<51A4A4EF.3060609@oracle.com>
	<004101ce5ba4$7a9125e0$6fb371a0$@segal.org>
Message-ID: <51A4D777.3030909@oracle.com>

CAlayer is a part of OSX.(and a bug there), I'll try to create 
workaround for it, but not sure that it is possible.
In you application you can postpone repaint of applet after validation.

On 28.05.2013 17:08, Mickey Segal wrote:
>
> I am not familiar with the underlying details of the JRE.  Does this 
> mean there is something an application programmer can set as a 
> workaround, or does that mean that there is something that folks at 
> Oracle can change to make a future JRE build not suffer from this problem?
>
> I appreciate the attention to fixing this problem.  It reminds me of 
> the time I mentioned a crash bug to Scott McNealy, who passed it on to 
> the engineers, who later told me that this was something that was a 
> big enough problem that they chose it as the first change to make in 
> JRE 7.
>
> Sergey Bylokhov wrote:
>
> I trace down this bug and found that part of the issue is in the 
> CAlayer implementation. The reason is simple: setNeedsDisplay is not 
> followed by the drawInGLContext.
>
> The problem is not reproduced if i set layer.asynchronous from FALSE 
> to YES.
>
> On 23.05.2013 22:22, David DeHaven wrote:
>
> > I don't think it's fixed, I still see it with b90.
>
> >> On 5/23/2013 6:21 AM, Mickey Segal wrote:
>
> >>> The bug ?Intermittently only some components refresh? at 
> http://bugs.sun.com/view_bug.do?bug_id=8014369 shown at 
> http://www.segal.org/java/refresh4/ seems fixed in JRE 8 early release 
> build 90.
>


-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Tue May 28 09:55:11 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 28 May 2013 20:55:11 +0400
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk
	is outdated
In-Reply-To: <D82D1F0A-BCA7-4626-892A-15E0713109BD@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
	<5196169F.1020505@oracle.com>
	<1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>
	<5196415A.7020807@oracle.com>
	<E97BB6DE-0114-4DFD-A87F-F78B112B53B5@oracle.com>
	<5196483D.4040106@oracle.com>
	<B7B5CFE3-F041-47D5-BC4D-D2F70CFE37C9@oracle.com>
	<D82D1F0A-BCA7-4626-892A-15E0713109BD@oracle.com>
Message-ID: <51A4E16F.9070309@oracle.com>

Yes, you need a jdk7u-dev@ approval before this can be pushed to 7u-dev.

I can push your fix tomorrow (provided you get the approval by then). 
But AFAIK, nobody but me has reviewed it yet.

Can we get at least one more review please?

http://cr.openjdk.java.net/~ddehaven/7181710/jdk.0/

--
best regards,
Anthony

On 05/28/2013 07:16 PM, David DeHaven wrote:
>
> Should I post this to 7u-dev for approval? Can I get someone to sponsor this (since I'm not a committer...)?
>
> -DrD-
>
>>
>> Incidentally, I tried compiling with the JDK8 jni_md.h and it built fine... I didn't think the related changes were backported, or were they?
>>
>> Either way, I think it needs to be a separate issue. Not that it matters, I'm off chasing fires with buckets of gasoline again... :(
>>
>> -DrD-
>>
>>> Thanks. I'm OK if this will be a separate bug.
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 05/17/2013 07:00 PM, David DeHaven wrote:
>>>>
>>>>>>> The fix looks good to me. Only one question:
>>>>>>>
>>>>>>> src/macosx/javavm/export/jni_md.h
>>>>>>>> 29 #define JNIEXPORT
>>>>>>>
>>>>>>> Does the empty #define imply that when building a jni lib on Mac, it should export all of its symbols by default?
>>>>>>
>>>>>> It depends on gcc's visibility setting, but yes, by default all symbols are exported.
>>>>>>
>>>>>> JDK8 has a better jni_md.h that sets JNIEXPORT to __attribute__(visibility(("default"))). That change should be backported, but should probably need to be done under a different bug ID. I suppose I could sneak it in here :)
>>>>>
>>>>> IIRC, Martin Buchholz's fix only updated the jni_md.h for Solaris, so the Mac's one is unlikely to change even if his fix is back-ported. Hence I'd vote for adding the __attribute__(visibility(("default"))) in your fix (unless this can break anything - recall the changes needed in awt_LoadLibrary.c where the JNIEXPORT was used in a typedef).
>>>>
>>>> The Mac builds currently use the solaris headers in both versions (which is why I was so interested in helping him). I haven't tried building 7u-dev with the attribute set yet, so I'm not sure of the consequences in JDK7. I can give it a try, if it's too ugly I'll file a separate issue to do the backport.
>>>>
>>>>
>>>>> Also, I assume you're going to forward-port your fix to JDK 8 at some point?
>>>>
>>>> Yes, that's my plan.
>>>>
>>>> -DrD-
>>>>
>>
>

From dbp at stanford.edu  Tue May 28 10:01:07 2013
From: dbp at stanford.edu (Dave Barker-Plummer)
Date: Tue, 28 May 2013 10:01:07 -0700
Subject: Localization of bundled apps
Message-ID: <27D4001E-52B3-45A8-83A3-84AB0927FB1B@stanford.edu>

We have a Java application that is localized using the standard Java infrastructure.  However, menu items on the Application menu (Preferences, Quit, etc) are under the control of Mac OS X.  

For traditional, unbundled, apps with Java installed by Apple, it is sufficient to create folders in the app's Content/Resources folder for each known localization (E.g. zh.lproj).

However, for apps that carry their own JWN created by appbundler, the presence of these folders does not result in a localized application menu.

If this a bug in appbundler, or in the JDK?  Or has the mechanism for requesting a localized application men changed in JDK 1.7?

Anyone know?  Thanks in advance.

-- Dave




From java3 at segal.org  Tue May 28 10:41:39 2013
From: java3 at segal.org (Mickey Segal)
Date: Tue, 28 May 2013 13:41:39 -0400
Subject: How do you find out if a bug has been fixed?
In-Reply-To: <51A4D777.3030909@oracle.com>
References: <000001ce57b8$77e1f8a0$67a5e9e0$@segal.org>
	<519E547E.4050800@oracle.com>
	<F31B3CA4-EF1C-42D6-9DBB-74B34FA12E64@oracle.com>
	<51A4A4EF.3060609@oracle.com>
	<004101ce5ba4$7a9125e0$6fb371a0$@segal.org>
	<51A4D777.3030909@oracle.com>
Message-ID: <002701ce5bca$9c70c280$d5524780$@segal.org>

Do you mean postpone repaint of the applet until after validation?  I?d appreciate if someone could suggest how best to do that using the simple applet at http://www.segal.org/java/refresh4/ with code at http://www.segal.org/java/refresh4/CanvasTable3.java.  I haven?t been explicitly calling the component?s paint method; I?ve just relied on adding the components and validating to call paint.  

 

Do I need to file the CAlayer report with Apple or do the Oracle people do that?  I think my limited understanding of the innards of the JRE and OS X makes me not a good person to file such a report. 

 

Sergey Bylokhov wrote:

 

CAlayer is a part of OSX.(and a bug there), I'll try to create workaround for it, but not sure that it is possible.
In you application you can postpone repaint of applet after validation.