From anthony.petrov at oracle.com  Thu Nov  1 06:48:22 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 01 Nov 2012 17:48:22 +0400
Subject: [8] Review request for 7124310: [macosx] "opposite" seems always
	null in focus events
In-Reply-To: <962A66A3-1C8F-4649-98C1-82EE55D73DBE@oracle.com>
References: <962A66A3-1C8F-4649-98C1-82EE55D73DBE@oracle.com>
Message-ID: <50927DA6.5030408@oracle.com>

Hi Leonid,

src/macosx/classes/sun/lwawt/LWWindowPeer.java
>  686         Window oppositeWindow = (opposite == null)? null : getTarget();

I think this should read "opposite.getTarget()", no?

src/macosx/native/sun/awt/AWTWindow.m
>  60 static AWTWindow* lastKeyWindow = nil;

 From previous experience I can tell you that storing a pointer to an 
ObjC object w/o retaining it is pointless and may lead to bugs that are 
very hard to debug. Please add retain/release calls in the setter for 
this variable.

>  549     AWTWindow *opposite = nil;

>  521         jobject oppositeWindow = [opposite.javaPlatformWindow jObjectWithEnv:env];

At line 549 the opposite may be set to nil, however, at line 512 you're 
accessing it w/o a check for nil.

--
best regards,
Anthony

On 11/01/12 02:43, Leonid Romanov wrote:
> Hi,
> Please review a fix for 7124310: [macosx] "opposite" seems always null
> in focus events. It's not a real bug, but something that hasn't been
> implemented yet: Cocoa focus notifications don't have information about
> "opposite" window, so we have to track it ourselves.
>
> Webrev: http://cr.openjdk.java.net/~leonidr/7124310/webrev.00/
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124310
>
> Thanks,
> Leonid.

From scott.kovatch at oracle.com  Thu Nov  1 11:13:29 2012
From: scott.kovatch at oracle.com (Scott Kovatch)
Date: Thu, 1 Nov 2012 11:13:29 -0700
Subject: Build fails on vanilla Mountain Lion install
In-Reply-To: <1351653681.14528.YahooMailNeo@web121805.mail.ne1.yahoo.com>
References: <BA96900C-B6D3-448D-B365-F4CE31A1538A@rochester.rr.com>
	<508EB8A8.3050901@oracle.com>
	<1351646819.22341.YahooMailNeo@web121805.mail.ne1.yahoo.com>
	<509087D9.2000309@oracle.com>
	<1351653681.14528.YahooMailNeo@web121805.mail.ne1.yahoo.com>
Message-ID: <EAFA2407-A710-49B3-8E35-A1F0A7B61045@oracle.com>

I will update the wiki.

-- Scott K.

On Oct 30, 2012, at 8:21 PM, niagarasoft20-macosxportdev at yahoo.com wrote:

> 
> 
> Thanks that worked!
> 
> 
> 
> 
>> ________________________________
>> From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
>> To: "niagarasoft20-macosxportdev at yahoo.com" <niagarasoft20-macosxportdev at yahoo.com> 
>> Cc: "macosx-port-dev at openjdk.java.net" <macosx-port-dev at openjdk.java.net> 
>> Sent: Tuesday, October 30, 2012 10:07 PM
>> Subject: Re: Build fails on vanilla Mountain Lion install
>> 
>> Hello.
>> This steps works for me:
>> http://mail.openjdk.java.net/pipermail/build-dev/2012-July/006506.html
>> 
>> 31.10.2012 5:26, niagarasoft20-macosxportdev at yahoo.com wrote:
>>> I've followed the instructions described on the page but get stuck with a few errors regarding X11. I did install the XQuartz package and that got me a little further along however still getting errors as follows below. What am I missing?
>> 
>> 
>> -- Best regards, Sergey.
>> 
>> 
>> 
>> 


From jrh at theptrgroup.com  Thu Nov  1 12:20:32 2012
From: jrh at theptrgroup.com (Jamison Hope)
Date: Thu, 1 Nov 2012 15:20:32 -0400
Subject: jawt_md.h
Message-ID: <284DD453-06E0-4740-B73E-49F765500DEB@theptrgroup.com>

Has anybody looked at

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

lately? It's causing issues attempting to build JOGL on Mountain Lion.

We discussed it a little on Apple's Java-Dev a few days ago and Mike Swingler said that jawt_md.h should have the JAWT_SurfaceLayers ObjC protocol from <JavaVM/jawt_md.h> but not the JAWT_MacOSXDrawingSurfaceInfo struct. And it definitely should not include X11 headers or define JAWT_X11DrawingSurfaceInfo.

Thanks,
--
Jamison Hope
The PTR Group
www.theptrgroup.com




From ebailey at acuitus.com  Thu Nov  1 12:26:00 2012
From: ebailey at acuitus.com (Eric Bailey)
Date: Thu, 1 Nov 2012 19:26:00 +0000
Subject: FullScreen (Exclusive) Swing Components Fail to Receive Keyboard
	Input on Java 7 on Mac OS X (Mountain) Lion
Message-ID: <FA632D9E722BDD40A4A6775C710C9A6C68E33F37@HQ-EX02.corp.acuitus.com>

Hello,

My company has a Swing application that needs to run in both a windowed context and in a fullscreen, kiosk-like mode.

This application has worked fine for years on OS X, most recently targeting Java 6.  We've been looking to move to Java 7 and to incorporate JavaFX elements, driving us to do compatibility testing with the latest Mountain Lion release (10.8.2 Supplemental) and Oracle's JDK 7u9.  

Unfortunately, we noticed a glaring issue while in fullscreen mode: mouse movement and clicks work fine, but keyboard input is not delivered to the components.  Tab also does not work for focus traversal, though the focus subsystem appears to work properly according to FocusListeners and the KeyboardFocusManager.  Most key presses produce a system alert beep in response, though registered KeyListeners and key bindings receive no events.

I have a detailed issue and focused sample code on StackOverflow (I didn't want to burden the message with the 240 line sample):
http://stackoverflow.com/questions/13064607/fullscreen-swing-components-fail-to-receive-keyboard-input-on-java-7-on-mac-os-x

Digging deeper, we identified that the issue was introduced with 7u6, when JavaFX began its inclusion in the mainline distribution.  It remains in 7u7 and 7u9, and it affects both Lion 10.7 and Mountain Lion 10.8.  A coworker attributes this to a switch from an AWTView to a NSWindow in 7u6 as the backing for the fullscreen window.

I'll be filing an issue with Oracle soon, but I was hoping to hear of possible workarounds in the interim.

One alternative approach I was pursuing was incorporating com.apple.eawt.FullScreenUtilities.  This option has been included in my sample code, but I have found limited kiosking capabilities.  In particular, I'm hoping to eliminate access to Command-Tab app switching, Mission Control, and Launch Pad, effectively locking the user into my application (it's an education setting).   Unfortunately, the prevailing suggestions regarding disabling the Dock (which is responsible for those listed capabilities) revealed that the Dock also handles fullscreen apps, rendering the FullScreenUtilities calls inoperable.

All input is greatly appreciated.

Thank you,
Eric Bailey
Director, Content Engineering
Acuitus

From jcpalmer at rochester.rr.com  Thu Nov  1 15:09:56 2012
From: jcpalmer at rochester.rr.com (Jeff Palmer)
Date: Thu, 1 Nov 2012 18:09:56 -0400
Subject: Is there a 24 hr production release warning DL?
In-Reply-To: <mailman.0.1351537200.10131.macosx-port-dev@openjdk.java.net>
References: <mailman.0.1351537200.10131.macosx-port-dev@openjdk.java.net>
Message-ID: <F40FD3A2-4C5B-42B8-A583-EADA026DC39F@rochester.rr.com>

Dalibor,
Thanks for the information.  I added myself, and added a mail filter for [7u communication].  Looking through the archives, there are some good messages, like the 7u10 schedule link, http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-August/004228.html

Seems a little too informal though.  I found the release message for 7u6, http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-August/004059.html .  Nothing for 7u9.  The date on ire-7u9-macosx-x64.dmg is 2012-09-27 5:55PM & 2012-09-25 1:04PM for the file inside.  I find no message announcing it.  I find only 2 messages with 7u9 even in the title.  

This means I would been equally unprepared if I was monitoring back then, maybe unless a was reading the full text of every message.  To be fair, I did not even recognize I had a problem until one of the jars changed.  Testing on my side also needs to improve.

Saw, the doc about the quarterly security release, but this just a guideline.

I thought, ok just monitor http://www.java.com/en/download/manual.jsp a couple times a day with a production server, & send a sms-like Gmail if the page changes + server logging.  What's one more when it already monitors over 1500 pages now?  Problem is the meta date tag of the page says 2012-08-14,  the same day as 7u6 message from above.  The text it says Version 9, so the page looks wrong.

Should I submit a bug for the manual.jsp meta date tag?  Do I need to RegEx the text of the page and fish out version numbers (fragile)?  

Thanks,

Jeff

On Oct 29, 2012, at 3:00 PM, macosx-port-dev-request at openjdk.java.net wrote:

> From: Dalibor Topic <dalibor.topic at oracle.com>
> Subject: Re: Is there a 24 hr production release warning DL?
> Date: October 29, 2012 1:17:37 PM EDT
> To: macosx-port-dev at openjdk.java.net
> 
> 
> On 10/26/12 8:16 PM, Jeff Palmer wrote:
>> Well did eventually find the list of lists , http://mail.openjdk.java.net/mailman/listinfo .  The "announce" list might work, being tightly moderated.  There was a message in October, but the 7u9 ea's or release not it.  Anything wrong with using that one?
> 
> That list is for general, OpenJDK-wide announcements. Weekly builds of a specific project don't fit that bill.
> The list you're looking for is jdk7u-dev, which has announcements on schedules, etc. under subjects starting with 
> [7u communication]. No EA build announcements, though, since we don't actually provide builds in OpenJDK, but
> you can follow along with the commit messages to see when a particular build's sources have been tagged, and 
> attempt to build it yourself, if you like.
> 
> Here's an example tag commit message: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-September/004332.html
> 


From leonid.romanov at oracle.com  Thu Nov  1 15:20:30 2012
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Fri, 2 Nov 2012 02:20:30 +0400
Subject: [8] Review request for 7124310: [macosx] "opposite" seems always
	null in focus events
In-Reply-To: <50927DA6.5030408@oracle.com>
References: <962A66A3-1C8F-4649-98C1-82EE55D73DBE@oracle.com>
	<50927DA6.5030408@oracle.com>
Message-ID: <8B881CD8-996C-42B3-B297-0AD49618BFA8@oracle.com>


On Nov 1, 2012, at 5:48 PM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Leonid,
> 
> src/macosx/classes/sun/lwawt/LWWindowPeer.java
>> 686         Window oppositeWindow = (opposite == null)? null : getTarget();
> 
> I think this should read "opposite.getTarget()", no?
> 

Yes. Thanks for catching this. Apparently, our focus subsystem somehow been correcting this mistake, so resulting focus events received by frames in my test were fine.

> src/macosx/native/sun/awt/AWTWindow.m
>> 60 static AWTWindow* lastKeyWindow = nil;
> 
> From previous experience I can tell you that storing a pointer to an ObjC object w/o retaining it is pointless and may lead to bugs that are very hard to debug. Please add retain/release calls in the setter for this variable.

Done.


> 
>> 549     AWTWindow *opposite = nil;
> 
>> 521         jobject oppositeWindow = [opposite.javaPlatformWindow jObjectWithEnv:env];
> 
> At line 549 the opposite may be set to nil, however, at line 512 you're accessing it w/o a check for nil.
> 

Not necessary. Objective C allows sending messages to nil. The result is nil/FALSE.

Here is the new webrev:
http://cr.openjdk.java.net/~leonidr/7124310/webrev.01/


> --
> best regards,
> Anthony
> 
> On 11/01/12 02:43, Leonid Romanov wrote:
>> Hi,
>> Please review a fix for 7124310: [macosx] "opposite" seems always null
>> in focus events. It's not a real bug, but something that hasn't been
>> implemented yet: Cocoa focus notifications don't have information about
>> "opposite" window, so we have to track it ourselves.
>> 
>> Webrev: http://cr.openjdk.java.net/~leonidr/7124310/webrev.00/
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124310
>> 
>> Thanks,
>> Leonid.


From leonid.romanov at oracle.com  Thu Nov  1 16:07:34 2012
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Fri, 2 Nov 2012 03:07:34 +0400
Subject: [8] Review request for 8002114: fix failed for JDK-7160951: [macosx]
	ActionListener called twice for JMenuItem using ScreenMenuBar
Message-ID: <58FF5B6F-DE8F-429A-9582-40136F24A4F1@oracle.com>

Hi,
Please review a fix for 8002114: fix failed for JDK-7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002114
Webrev: http://cr.openjdk.java.net/~leonidr/8002114/webrev.00/

Thanks,
Leonid.


From dalibor.topic at oracle.com  Fri Nov  2 03:33:12 2012
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 02 Nov 2012 11:33:12 +0100
Subject: Is there a 24 hr production release warning DL?
In-Reply-To: <F40FD3A2-4C5B-42B8-A583-EADA026DC39F@rochester.rr.com>
References: <mailman.0.1351537200.10131.macosx-port-dev@openjdk.java.net>
	<F40FD3A2-4C5B-42B8-A583-EADA026DC39F@rochester.rr.com>
Message-ID: <5093A168.7000108@oracle.com>

On 11/1/12 11:09 PM, Jeff Palmer wrote:
> Nothing for 7u9. 

That's because 7u9 was a CPU. You can find more information about CPUs here: http://www.oracle.com/technetwork/topics/security/alerts-086861.html and you can find 
more information on how CPUs get integrated into OpenJDK 7 Updates here: openjdk.java.net/projects/jdk7u/qanda.html

See http://www.oracle.com/technetwork/topics/security/securityemail-090378.html for information on how to subscribe to Critical Patch Update Alert e-mails.

> I thought, ok just monitor http://www.java.com/en/download/manual.jsp a couple times a day with a production server, & send a sms-like Gmail if the page changes + server logging.  What's one more when it already monitors over 1500 pages now?  Problem is the meta date tag of the page says 2012-08-14,  the same day as 7u6 message from above.  The text it says Version 9, so the page looks wrong.
> 
> Should I submit a bug for the manual.jsp meta date tag? 

Sure - if you go to the download page, you'll see a feedback tab on your right, which you can use to provide feedback to the java.com page team.

cheers,
dalibor topic


-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

From anthony.petrov at oracle.com  Fri Nov  2 04:59:19 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 02 Nov 2012 15:59:19 +0400
Subject: [8] Review request for 7124310: [macosx] "opposite" seems always
	null in focus events
In-Reply-To: <8B881CD8-996C-42B3-B297-0AD49618BFA8@oracle.com>
References: <962A66A3-1C8F-4649-98C1-82EE55D73DBE@oracle.com>
	<50927DA6.5030408@oracle.com>
	<8B881CD8-996C-42B3-B297-0AD49618BFA8@oracle.com>
Message-ID: <5093B597.600@oracle.com>

Thanks. The new fix looks good.

--
best regards,
Anthony

On 11/2/2012 2:20 AM, Leonid Romanov wrote:
> 
> On Nov 1, 2012, at 5:48 PM, Anthony Petrov <anthony.petrov at oracle.com 
> <mailto:anthony.petrov at oracle.com>> wrote:
> 
>> Hi Leonid,
>>
>> src/macosx/classes/sun/lwawt/LWWindowPeer.java
>>> 686         Window oppositeWindow = (opposite == null)? null : 
>>> getTarget();
>>
>> I think this should read "opposite.getTarget()", no?
>>
> 
> Yes. Thanks for catching this. Apparently, our focus subsystem somehow 
> been correcting this mistake, so resulting focus events received by 
> frames in my test were fine.
> 
>> src/macosx/native/sun/awt/AWTWindow.m
>>> 60 static AWTWindow* lastKeyWindow = nil;
>>
>> From previous experience I can tell you that storing a pointer to an 
>> ObjC object w/o retaining it is pointless and may lead to bugs that 
>> are very hard to debug. Please add retain/release calls in the setter 
>> for this variable.
> 
> Done.
> 
> 
>>
>>> 549     AWTWindow *opposite = nil;
>>
>>> 521         jobject oppositeWindow = [opposite.javaPlatformWindow 
>>> jObjectWithEnv:env];
>>
>> At line 549 the opposite may be set to nil, however, at line 512 
>> you're accessing it w/o a check for nil.
>>
> 
> Not necessary. Objective C allows sending messages to nil. The result is 
> nil/FALSE.
> 
> Here is the new webrev:
> http://cr.openjdk.java.net/~leonidr/7124310/webrev.01/
> 
> 
>> --
>> best regards,
>> Anthony
>>
>> On 11/01/12 02:43, Leonid Romanov wrote:
>>> Hi,
>>> Please review a fix for 7124310: [macosx] "opposite" seems always null
>>> in focus events. It's not a real bug, but something that hasn't been
>>> implemented yet: Cocoa focus notifications don't have information about
>>> "opposite" window, so we have to track it ourselves.
>>>
>>> Webrev: http://cr.openjdk.java.net/~leonidr/7124310/webrev.00/
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124310
>>>
>>> Thanks,
>>> Leonid.
> 

From Sergey.Bylokhov at oracle.com  Fri Nov  2 06:08:17 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 02 Nov 2012 17:08:17 +0400
Subject: [8] Review request for 8002114: fix failed for JDK-7160951:
	[macosx] ActionListener called twice for JMenuItem using ScreenMenuBar
In-Reply-To: <58FF5B6F-DE8F-429A-9582-40136F24A4F1@oracle.com>
References: <58FF5B6F-DE8F-429A-9582-40136F24A4F1@oracle.com>
Message-ID: <5093C5C1.2040007@oracle.com>

Fix looks fine
02.11.2012 3:07, Leonid Romanov wrote:
> Hi,
> Please review a fix for 8002114: fix failed for JDK-7160951: [macosx] 
> ActionListener called twice for JMenuItem using ScreenMenuBar
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002114
> Webrev: http://cr.openjdk.java.net/~leonidr/8002114/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eleonidr/8002114/webrev.00/>
>
> Thanks,
> Leonid.
>


-- 
Best regards, Sergey.


From leonid.romanov at oracle.com  Fri Nov  2 11:37:21 2012
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Fri, 2 Nov 2012 22:37:21 +0400
Subject: FullScreen (Exclusive) Swing Components Fail to Receive Keyboard
	Input on Java 7 on Mac OS X (Mountain) Lion
In-Reply-To: <FA632D9E722BDD40A4A6775C710C9A6C68E33F37@HQ-EX02.corp.acuitus.com>
References: <FA632D9E722BDD40A4A6775C710C9A6C68E33F37@HQ-EX02.corp.acuitus.com>
Message-ID: <13134252-EB17-4265-801B-E912E39E285B@oracle.com>

Hi,
Confirming that this issue is reproducible on my Mac as well. Have you filled the bug yet?

Regards,
Leonid.  

On Nov 1, 2012, at 11:26 PM, Eric Bailey <ebailey at acuitus.com> wrote:

> Hello,
> 
> My company has a Swing application that needs to run in both a windowed context and in a fullscreen, kiosk-like mode.
> 
> This application has worked fine for years on OS X, most recently targeting Java 6.  We've been looking to move to Java 7 and to incorporate JavaFX elements, driving us to do compatibility testing with the latest Mountain Lion release (10.8.2 Supplemental) and Oracle's JDK 7u9.  
> 
> Unfortunately, we noticed a glaring issue while in fullscreen mode: mouse movement and clicks work fine, but keyboard input is not delivered to the components.  Tab also does not work for focus traversal, though the focus subsystem appears to work properly according to FocusListeners and the KeyboardFocusManager.  Most key presses produce a system alert beep in response, though registered KeyListeners and key bindings receive no events.
> 
> I have a detailed issue and focused sample code on StackOverflow (I didn't want to burden the message with the 240 line sample):
> http://stackoverflow.com/questions/13064607/fullscreen-swing-components-fail-to-receive-keyboard-input-on-java-7-on-mac-os-x
> 
> Digging deeper, we identified that the issue was introduced with 7u6, when JavaFX began its inclusion in the mainline distribution.  It remains in 7u7 and 7u9, and it affects both Lion 10.7 and Mountain Lion 10.8.  A coworker attributes this to a switch from an AWTView to a NSWindow in 7u6 as the backing for the fullscreen window.
> 
> I'll be filing an issue with Oracle soon, but I was hoping to hear of possible workarounds in the interim.
> 
> One alternative approach I was pursuing was incorporating com.apple.eawt.FullScreenUtilities.  This option has been included in my sample code, but I have found limited kiosking capabilities.  In particular, I'm hoping to eliminate access to Command-Tab app switching, Mission Control, and Launch Pad, effectively locking the user into my application (it's an education setting).   Unfortunately, the prevailing suggestions regarding disabling the Dock (which is responsible for those listed capabilities) revealed that the Dock also handles fullscreen apps, rendering the FullScreenUtilities calls inoperable.
> 
> All input is greatly appreciated.
> 
> Thank you,
> Eric Bailey
> Director, Content Engineering
> Acuitus


From leonid.romanov at oracle.com  Fri Nov  2 13:36:03 2012
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Sat, 3 Nov 2012 00:36:03 +0400
Subject: FullScreen (Exclusive) Swing Components Fail to Receive Keyboard
	Input on Java 7 on Mac OS X (Mountain) Lion
In-Reply-To: <13134252-EB17-4265-801B-E912E39E285B@oracle.com>
References: <FA632D9E722BDD40A4A6775C710C9A6C68E33F37@HQ-EX02.corp.acuitus.com>
	<13134252-EB17-4265-801B-E912E39E285B@oracle.com>
Message-ID: <9A7961C1-F4D6-4690-A5A2-940DC9F869AE@oracle.com>

Well, although I'm not 100% sure yet, but it looks like when we enter full screen some other window becomes the first responder, hence the beep. Could you please try the following workaround: after calling setFullScreenWindow() on a frame, call setVisible(false) followed by setVisible(true). This, in theory, should restore the correct first responder. 

On Nov 2, 2012, at 10:37 PM, Leonid Romanov <leonid.romanov at oracle.com> wrote:

> Hi,
> Confirming that this issue is reproducible on my Mac as well. Have you filled the bug yet?
> 
> Regards,
> Leonid.  
> 
> On Nov 1, 2012, at 11:26 PM, Eric Bailey <ebailey at acuitus.com> wrote:
> 
>> Hello,
>> 
>> My company has a Swing application that needs to run in both a windowed context and in a fullscreen, kiosk-like mode.
>> 
>> This application has worked fine for years on OS X, most recently targeting Java 6.  We've been looking to move to Java 7 and to incorporate JavaFX elements, driving us to do compatibility testing with the latest Mountain Lion release (10.8.2 Supplemental) and Oracle's JDK 7u9.  
>> 
>> Unfortunately, we noticed a glaring issue while in fullscreen mode: mouse movement and clicks work fine, but keyboard input is not delivered to the components.  Tab also does not work for focus traversal, though the focus subsystem appears to work properly according to FocusListeners and the KeyboardFocusManager.  Most key presses produce a system alert beep in response, though registered KeyListeners and key bindings receive no events.
>> 
>> I have a detailed issue and focused sample code on StackOverflow (I didn't want to burden the message with the 240 line sample):
>> http://stackoverflow.com/questions/13064607/fullscreen-swing-components-fail-to-receive-keyboard-input-on-java-7-on-mac-os-x
>> 
>> Digging deeper, we identified that the issue was introduced with 7u6, when JavaFX began its inclusion in the mainline distribution.  It remains in 7u7 and 7u9, and it affects both Lion 10.7 and Mountain Lion 10.8.  A coworker attributes this to a switch from an AWTView to a NSWindow in 7u6 as the backing for the fullscreen window.
>> 
>> I'll be filing an issue with Oracle soon, but I was hoping to hear of possible workarounds in the interim.
>> 
>> One alternative approach I was pursuing was incorporating com.apple.eawt.FullScreenUtilities.  This option has been included in my sample code, but I have found limited kiosking capabilities.  In particular, I'm hoping to eliminate access to Command-Tab app switching, Mission Control, and Launch Pad, effectively locking the user into my application (it's an education setting).   Unfortunately, the prevailing suggestions regarding disabling the Dock (which is responsible for those listed capabilities) revealed that the Dock also handles fullscreen apps, rendering the FullScreenUtilities calls inoperable.
>> 
>> All input is greatly appreciated.
>> 
>> Thank you,
>> Eric Bailey
>> Director, Content Engineering
>> Acuitus
> 


From ebailey at acuitus.com  Fri Nov  2 14:14:59 2012
From: ebailey at acuitus.com (Eric Bailey)
Date: Fri, 2 Nov 2012 21:14:59 +0000
Subject: FullScreen (Exclusive) Swing Components Fail to Receive
	Keyboard Input on Java 7 on Mac OS X (Mountain) Lion
In-Reply-To: <9A7961C1-F4D6-4690-A5A2-940DC9F869AE@oracle.com>
References: <FA632D9E722BDD40A4A6775C710C9A6C68E33F37@HQ-EX02.corp.acuitus.com>
	<13134252-EB17-4265-801B-E912E39E285B@oracle.com>
	<9A7961C1-F4D6-4690-A5A2-940DC9F869AE@oracle.com>
Message-ID: <FA632D9E722BDD40A4A6775C710C9A6C68E35A67@HQ-EX02.corp.acuitus.com>

Wow, thanks for the response!  At least in my test example, this indeed restores keyboard input.  I initially though I might have to resort to invokeLaters on the visibility calls, but immediately after works fine:

dev.setFullScreenWindow(f);
f.setVisible(false);
f.setVisible(true); 

I have yet to file a bug.  Would you like one based on this latest information?

Also, I'll be checking my larger app for functionality in a few minutes and will report back.

Thank you,
- Eric


On Nov 2, 2012, at 1:36 PM, Leonid Romanov wrote:

> Well, although I'm not 100% sure yet, but it looks like when we enter full screen some other window becomes the first responder, hence the beep. Could you please try the following workaround: after calling setFullScreenWindow() on a frame, call setVisible(false) followed by setVisible(true). This, in theory, should restore the correct first responder. 
> 
> On Nov 2, 2012, at 10:37 PM, Leonid Romanov <leonid.romanov at oracle.com> wrote:
> 
>> Hi,
>> Confirming that this issue is reproducible on my Mac as well. Have you filled the bug yet?
>> 
>> Regards,
>> Leonid.  
>> 
>> On Nov 1, 2012, at 11:26 PM, Eric Bailey <ebailey at acuitus.com> wrote:
>> 
>>> Hello,
>>> 
>>> My company has a Swing application that needs to run in both a windowed context and in a fullscreen, kiosk-like mode.
>>> 
>>> This application has worked fine for years on OS X, most recently targeting Java 6.  We've been looking to move to Java 7 and to incorporate JavaFX elements, driving us to do compatibility testing with the latest Mountain Lion release (10.8.2 Supplemental) and Oracle's JDK 7u9.  
>>> 
>>> Unfortunately, we noticed a glaring issue while in fullscreen mode: mouse movement and clicks work fine, but keyboard input is not delivered to the components.  Tab also does not work for focus traversal, though the focus subsystem appears to work properly according to FocusListeners and the KeyboardFocusManager.  Most key presses produce a system alert beep in response, though registered KeyListeners and key bindings receive no events.
>>> 
>>> I have a detailed issue and focused sample code on StackOverflow (I didn't want to burden the message with the 240 line sample):
>>> http://stackoverflow.com/questions/13064607/fullscreen-swing-components-fail-to-receive-keyboard-input-on-java-7-on-mac-os-x
>>> 
>>> Digging deeper, we identified that the issue was introduced with 7u6, when JavaFX began its inclusion in the mainline distribution.  It remains in 7u7 and 7u9, and it affects both Lion 10.7 and Mountain Lion 10.8.  A coworker attributes this to a switch from an AWTView to a NSWindow in 7u6 as the backing for the fullscreen window.
>>> 
>>> I'll be filing an issue with Oracle soon, but I was hoping to hear of possible workarounds in the interim.
>>> 
>>> One alternative approach I was pursuing was incorporating com.apple.eawt.FullScreenUtilities.  This option has been included in my sample code, but I have found limited kiosking capabilities.  In particular, I'm hoping to eliminate access to Command-Tab app switching, Mission Control, and Launch Pad, effectively locking the user into my application (it's an education setting).   Unfortunately, the prevailing suggestions regarding disabling the Dock (which is responsible for those listed capabilities) revealed that the Dock also handles fullscreen apps, rendering the FullScreenUtilities calls inoperable.
>>> 
>>> All input is greatly appreciated.
>>> 
>>> Thank you,
>>> Eric Bailey
>>> Director, Content Engineering
>>> Acuitus
>> 
> 


From leonid.romanov at oracle.com  Fri Nov  2 14:26:24 2012
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Sat, 3 Nov 2012 01:26:24 +0400
Subject: FullScreen (Exclusive) Swing Components Fail to Receive Keyboard
	Input on Java 7 on Mac OS X (Mountain) Lion
In-Reply-To: <FA632D9E722BDD40A4A6775C710C9A6C68E35A67@HQ-EX02.corp.acuitus.com>
References: <FA632D9E722BDD40A4A6775C710C9A6C68E33F37@HQ-EX02.corp.acuitus.com>
	<13134252-EB17-4265-801B-E912E39E285B@oracle.com>
	<9A7961C1-F4D6-4690-A5A2-940DC9F869AE@oracle.com>
	<FA632D9E722BDD40A4A6775C710C9A6C68E35A67@HQ-EX02.corp.acuitus.com>
Message-ID: <30F8933B-FD74-4141-B737-1249B3641881@oracle.com>

Yep, please fill a bug with your latest findings. 

On Nov 3, 2012, at 1:14 AM, Eric Bailey <ebailey at acuitus.com> wrote:

> Wow, thanks for the response!  At least in my test example, this indeed restores keyboard input.  I initially though I might have to resort to invokeLaters on the visibility calls, but immediately after works fine:
> 
> dev.setFullScreenWindow(f);
> f.setVisible(false);
> f.setVisible(true); 
> 
> I have yet to file a bug.  Would you like one based on this latest information?
> 
> Also, I'll be checking my larger app for functionality in a few minutes and will report back.
> 
> Thank you,
> - Eric
> 
> 
> On Nov 2, 2012, at 1:36 PM, Leonid Romanov wrote:
> 
>> Well, although I'm not 100% sure yet, but it looks like when we enter full screen some other window becomes the first responder, hence the beep. Could you please try the following workaround: after calling setFullScreenWindow() on a frame, call setVisible(false) followed by setVisible(true). This, in theory, should restore the correct first responder. 
>> 
>> On Nov 2, 2012, at 10:37 PM, Leonid Romanov <leonid.romanov at oracle.com> wrote:
>> 
>>> Hi,
>>> Confirming that this issue is reproducible on my Mac as well. Have you filled the bug yet?
>>> 
>>> Regards,
>>> Leonid.  
>>> 
>>> On Nov 1, 2012, at 11:26 PM, Eric Bailey <ebailey at acuitus.com> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> My company has a Swing application that needs to run in both a windowed context and in a fullscreen, kiosk-like mode.
>>>> 
>>>> This application has worked fine for years on OS X, most recently targeting Java 6.  We've been looking to move to Java 7 and to incorporate JavaFX elements, driving us to do compatibility testing with the latest Mountain Lion release (10.8.2 Supplemental) and Oracle's JDK 7u9.  
>>>> 
>>>> Unfortunately, we noticed a glaring issue while in fullscreen mode: mouse movement and clicks work fine, but keyboard input is not delivered to the components.  Tab also does not work for focus traversal, though the focus subsystem appears to work properly according to FocusListeners and the KeyboardFocusManager.  Most key presses produce a system alert beep in response, though registered KeyListeners and key bindings receive no events.
>>>> 
>>>> I have a detailed issue and focused sample code on StackOverflow (I didn't want to burden the message with the 240 line sample):
>>>> http://stackoverflow.com/questions/13064607/fullscreen-swing-components-fail-to-receive-keyboard-input-on-java-7-on-mac-os-x
>>>> 
>>>> Digging deeper, we identified that the issue was introduced with 7u6, when JavaFX began its inclusion in the mainline distribution.  It remains in 7u7 and 7u9, and it affects both Lion 10.7 and Mountain Lion 10.8.  A coworker attributes this to a switch from an AWTView to a NSWindow in 7u6 as the backing for the fullscreen window.
>>>> 
>>>> I'll be filing an issue with Oracle soon, but I was hoping to hear of possible workarounds in the interim.
>>>> 
>>>> One alternative approach I was pursuing was incorporating com.apple.eawt.FullScreenUtilities.  This option has been included in my sample code, but I have found limited kiosking capabilities.  In particular, I'm hoping to eliminate access to Command-Tab app switching, Mission Control, and Launch Pad, effectively locking the user into my application (it's an education setting).   Unfortunately, the prevailing suggestions regarding disabling the Dock (which is responsible for those listed capabilities) revealed that the Dock also handles fullscreen apps, rendering the FullScreenUtilities calls inoperable.
>>>> 
>>>> All input is greatly appreciated.
>>>> 
>>>> Thank you,
>>>> Eric Bailey
>>>> Director, Content Engineering
>>>> Acuitus
>>> 
>> 
> 


From rick.hillegas at oracle.com  Mon Nov  5 08:51:33 2012
From: rick.hillegas at oracle.com (Rick Hillegas)
Date: Mon, 05 Nov 2012 08:51:33 -0800
Subject: how to set Java 7u9 to be the default JVM on mac osx 10.7.5
Message-ID: <5097EE95.1050804@oracle.com>

I am trying to use Java 7u9 as the default JVM on my macbook pro 
(running osx 10.7.5). I haven't figured out how to configure my machine 
so that a Java 7 app will come up when I click on its icon. I would 
appreciate your advice about what I need to do to configure my machine.

When I click on the app, I get a popup window telling me that the system 
couldn't find a 1.7 version of Java. The popup window has a button 
labelled "Open Java Preferences", but when I click on that button, 
xyzzy, nothing happens. However, the app does come up if I click on its 
jar file after navigating to it via Finder's "Show Package Contents" option.

This is how I attempted to configure my machine to use 7u9 as the 
default JVM:

A) I installed Java 7u9 using the dmg obtained from 
http://www.oracle.com/technetwork/java/javase/downloads/jre7u9-downloads-1859586.html. 
This put the 7u9 JDK in /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk.

Now I wanted to make Java 7 the default VM on my mac. I googled around 
and came across the suggestion that I should drag Java 7 to the top of 
the list managed by the Java Preferences app. However, this app does not 
exist on my version of mac osx (10.7.5). So I did the following:

B) I created a softlink from 
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to 
/Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents

According to the following webpage, versions of osx like mine are 
supposed to default to the highest version of Java which the os can 
find: 
http://reviews.cnet.com/8301-13727_7-57533880-263/java-preferences-missing-after-latest-os-x-java-update/. 
But I clearly haven't figured out how to let the os know what that 
version is.

Thanks in advance for your advice,
-Rick

Here are some more details on the experiments I ran:

----------- GOOD BEHAVIOR UNDER JAVA 6 ---------------

I built my app with these settings:

i) Used the Java 7 javac
ii) Set javac source and target level to "1.6".
iii) Set the JVMVersion in the app's Info.plist to "1.6+".

When I compiled, I got the following warning but the app built:

"warning: [options] bootstrap class path not set in conjunction with 
-source 1.6"

In this situation:

I) The app comes up if I click on it in a Finder window or on its icon 
in the dock.

II) The app also comes up if I double click on the app's jar file after 
navigating to it via Finder's "Show Package Contents" option.


----------- PUZZLING BEHAVIOR UNDER JAVA 7 ---------------

I then re-built my app with these settings:

i') Used the Java 7 javac
ii') Set javac source and target level to "1.7".
iii') Set the JVMVersion in the app's Info.plist to "1.7+".

This compiled cleanly without warnings.

In this situation:

I') The app does NOT come up if I click on it in a Finder window or on 
its icon in the dock. Instead, I get the popup window described above.

II') However, the app DOES come up if I double click on the app's jar 
file after navigating to it via Finder's "Show Package Contents" option.


From scott.kovatch at oracle.com  Mon Nov  5 10:31:10 2012
From: scott.kovatch at oracle.com (Scott Kovatch)
Date: Mon, 5 Nov 2012 10:31:10 -0800
Subject: how to set Java 7u9 to be the default JVM on mac osx 10.7.5
In-Reply-To: <5097EE95.1050804@oracle.com>
References: <5097EE95.1050804@oracle.com>
Message-ID: <DF7C221D-FA92-4D66-8326-204FBE908634@oracle.com>


On Nov 5, 2012, at 8:51 AM, Rick Hillegas <rick.hillegas at oracle.com> wrote:

> I am trying to use Java 7u9 as the default JVM on my macbook pro (running osx 10.7.5). I haven't figured out how to configure my machine so that a Java 7 app will come up when I click on its icon. I would appreciate your advice about what I need to do to configure my machine.

The short answer is, if you want to use Java 7 in a double-clickable application you have to bundle a JRE with your app with AppBundler (http://java.net/projects/appbundler) or javafxpackager, which is part of the JDK. Apple's bundled application support is private API, and not available to Oracle's JRE.

You can bundle your app so it uses the shared Java 7 runtime.

> When I click on the app, I get a popup window telling me that the system couldn't find a 1.7 version of Java. The popup window has a button labelled "Open Java Preferences", but when I click on that button, xyzzy, nothing happens. However, the app does come up if I click on its jar file after navigating to it via Finder's "Show Package Contents" option.

Right -- double-clicking a JAR launches a helper application which does the equivalent of 'java -jar <jar file>'. And since /usr/bin/java finds either the Java 7 JRE or the newest JDK if the 7 JRE isn't available, your app runs in Java 7.

> According to the following webpage, versions of osx like mine are supposed to default to the highest version of Java which the os can find: http://reviews.cnet.com/8301-13727_7-57533880-263/java-preferences-missing-after-latest-os-x-java-update/. But I clearly haven't figured out how to let the os know what that version is.

I re-read that page, and I think this sentence is a bit confusing: 

"In addition, the various Java tools Apple includes (such as command-line tools) are configured with reference to the Java runtime with the highest version number, ensuring that Java 7 or later will be used once it is installed, regardless of any other runtimes that may be present."

Here, 'Java runtime' means 'JDK'. The Java 7 JDK (7u9), which you installed, is usable from a command line, but the JRE, which it also installed, is not.

-- Scott K.

----------------------------------------
Scott Kovatch
scott.kovatch at oracle.com
Santa Clara/Pleasanton, CA



From private at claudio.ch  Mon Nov  5 11:05:17 2012
From: private at claudio.ch (Claudio Nieder)
Date: Mon, 5 Nov 2012 20:05:17 +0100
Subject: how to set Java 7u9 to be the default JVM on mac osx 10.7.5
Message-ID: <F3AD44B8-4F85-4B4F-A166-A2D23013CFCE@claudio.ch>

Hi,

> According to the following webpage, versions of osx like mine are supposed to default to the highest version of Java which the os can find: http://reviews.cnet.com/8301-13727_7-57533880-263/java-preferences-missing-after-latest-os-x-java-update/. But I clearly haven't figured out how to let the os know what that version is.

Ah, and I wondered, why I didn't find Java Preferences anymore. The article ends with "In short, if you have OS X 10.7 or later and wish to configure Java after applying this update, then you'll be using Oracle's Java system preferences pane." But that one also does "not work" for me. To be precise: I have both the released JDK 7u9 as well as JDK snapshot realease 8 build b63 (from http://jdk8.java.net/download.html) installed on my Mac besides Apples's Java 6. If I open the Java control Panel from the OSX System Preferences go to the Java tab and press the View... button a "Java Runtime Environment Settings" dialog appears with only one line:

Platform Product  ...
1.7      1.8.0-ea ...

It does not offer me a choice between 7u9 or 8.

The only thing which still works as I expect is the command line java_home, which shows me all three installed Java version and allows me to run commands with the -exec option using the desired version.

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





From mik3hall at gmail.com  Mon Nov  5 14:59:39 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 5 Nov 2012 16:59:39 -0600
Subject: All Menus disappear
Message-ID: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>

I'm not remembering if this has been discussed. I'm not finding it in my back mail. I have an application I've been working with mostly using Apple's Java 6 but just set up an openjdk version.
Using apple.laf.useScreenMenuBar in the openjdk after I put up a window and dismiss it going back to the main window all of my menus disappear.
It doesn't seem to reproduce with the Apple jvm.

Is this a known issue or should I bug report?

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 leonid.romanov at oracle.com  Mon Nov  5 16:57:45 2012
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Tue, 6 Nov 2012 04:57:45 +0400
Subject: All Menus disappear
In-Reply-To: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
Message-ID: <8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>

We've recently fixed a number of menu related bugs in JDK 8, so could you please test whether your issue is reproducible with the latest JDK 8 preview build.

Leonid.

On Nov 6, 2012, at 2:59 AM, Michael Hall <mik3hall at gmail.com> wrote:

> I'm not remembering if this has been discussed. I'm not finding it in my back mail. I have an application I've been working with mostly using Apple's Java 6 but just set up an openjdk version.
> Using apple.laf.useScreenMenuBar in the openjdk after I put up a window and dismiss it going back to the main window all of my menus disappear.
> It doesn't seem to reproduce with the Apple jvm.
> 
> Is this a known issue or should I bug report?
> 
> 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  Mon Nov  5 17:26:49 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 5 Nov 2012 19:26:49 -0600
Subject: All Menus disappear
In-Reply-To: <8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
Message-ID: <FD96A8AD-2173-41F3-9112-65134D31BCFF@gmail.com>

On Nov 5, 2012, at 6:57 PM, Leonid Romanov wrote:

> We've recently fixed a number of menu related bugs in JDK 8, so could you please test whether your issue is reproducible with the latest JDK 8 preview build.

I'll give it a try.

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  Mon Nov  5 17:42:10 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 5 Nov 2012 19:42:10 -0600
Subject: All Menus disappear
In-Reply-To: <8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
Message-ID: <1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>

On Nov 5, 2012, at 6:57 PM, Leonid Romanov wrote:

> We've recently fixed a number of menu related bugs in JDK 8, so could you please test whether your issue is reproducible with the latest JDK 8 preview build.


ystem.in:8:java.specification.version=1.8
System.in:13:java.version=1.8.0-ea
System.in:25:java.vm.specification.version=1.8
System.in:26:java.runtime.version=1.8.0-ea-b63

The problem is still there.

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 ray at ganymede.org  Mon Nov  5 22:02:36 2012
From: ray at ganymede.org (Ray Kiddy)
Date: Mon, 5 Nov 2012 22:02:36 -0800
Subject: tricks to running awt tests on Mac OS X?
Message-ID: <9D7F8392-9E71-484C-8497-40745AAF163E@ganymede.org>


Hello -

I downloaded jtreg binaries and am running some of the tests on this machine. It is running 10.7.4. I am having no problems updating the source and building jdk7u-dev. And I can run a lot of the tests with no problems. But AWT tests seem not so cooperative. Is there some trick to running these?

It may be a problem that I downloaded the binaries for jtreg. Looking at the build dependencies was giving me a headache. And, at least with java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh, the test seems to not know what "Darwin" is? This made me suspect I need a newer jtreg. But this one seemed to be from the official source (i.e. http://download.java.net/openjdk/jtreg/).

The full results from this one are below.

I am trying to run with, for example:

	% cd jdk7u-dev
	% ../jtreg/linux/bin/jtreg \
	   -jdk:build/macosx-x86_64/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home \
	   -w build/jtreg/test/java/awt/work -r build/jtreg/test/java/awt/report \
	   -othervm -verbose:summary -ignore:quiet -automatic test/java/awt

I was running with -samevm. Now I am not. I added -ignore:quiet and -automatic. These did not do much.

If I let the tests run, they take a long time. I cannot see how long the set of tests should take, so I am not sure if they are hung. After a while, there are lots of colored windows hanging around and not much seems to be happening. Sort of like a lava lamp in a cubic universe.

Any info about how these test behave when things are passing would be appreciated.

cheers - ray



#Test Results (version 2)
#Mon Nov 05 14:39:05 PST 2012
#checksum:5402429ff12b0171
#-----testdescription-----
$file=/Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
$root=/Users/ray/Projects/openjdk/jdk7u-dev/jdk/test
author=Dmitry Cherepanov\: area\=appletviewer
keywords=bug6193279 bug6619458 shell
run=USER_SPECIFIED compile IOExceptionIfEncodedURLTest.java\nUSER_SPECIFIED main IOExceptionIfEncodedURLTest\nUSER_SPECIFIED shell IOExceptionIfEncodedURLTest.sh\n
source=IOExceptionIfEncodedURLTest.sh
title=REGRESSION\: AppletViewer throws IOException when path is encoded URL

#-----environment-----

#-----testresult-----
description=file\:/Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
elapsed=2295 0\:00\:02.295
end=Mon Nov 05 14\:39\:05 PST 2012
environment=regtest
execStatus=Failed. Execution failed\: exit code 1
hostname=10.1.10.15
javatestOS=Mac OS X 10.7.4 (x86_64)
javatestVersion=4.4
jtregVersion=jtreg 4.1 fcs b04
script=com.sun.javatest.regtest.RegressionScript 
sections=script_messages compile build main shell
start=Mon Nov 05 14\:39\:03 PST 2012
test=java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
user.name=ray
work=/Users/ray/Projects/openjdk/jdk7u-dev/build/jtreg/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/work/java/awt/appletviewer/IOExceptionIfEncodedURLTest

#section:script_messages
----------messages:(4/241)----------
JDK under test: (build/macosx-x86_64/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home)
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-ray_2012_09_21_10_55-b00)
OpenJDK 64-Bit Server VM (build 23.6-b03, mixed mode)

#section:compile
----------messages:(3/254)----------
command: compile /Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.java
reason: User specified action: run compile IOExceptionIfEncodedURLTest.java 
elapsed time (seconds): 1.489
----------System.out:(0/0)----------
----------System.err:(7/627)----------
/Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.java:35: warning: ParseUtil is internal proprietary API and may be removed in a future release
import sun.net.www.ParseUtil;
                  ^
/Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.java:55: warning: ParseUtil is internal proprietary API and may be removed in a future release
        String path = ParseUtil.fileToEncodedURL(new File(System.getProperty("user.dir"))).getPath();
                      ^
2 warnings
result: Passed. Compilation successful

#section:build
----------messages:(3/112)----------
command: build IOExceptionIfEncodedURLTest
reason: Named class compiled on demand
elapsed time (seconds): 0.001
result: Passed. All files up to date

#section:main
----------messages:(3/141)----------
command: main IOExceptionIfEncodedURLTest
reason: User specified action: run main IOExceptionIfEncodedURLTest 
elapsed time (seconds): 0.416
----------System.out:(0/0)----------
----------System.err:(3/248)----------
prior checking...
url=file:IOExceptionIfEncodedURLTest.java -> path=/Users/ray/Projects/openjdk/jdk7u-dev/build/jtreg/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/work/scratch/,filename=IOExceptionIfEncodedURLTest.java
STATUS:Passed.
result: Passed. Execution successful

#section:shell
----------messages:(3/152)----------
command: shell IOExceptionIfEncodedURLTest.sh []
reason: User specified action: run shell IOExceptionIfEncodedURLTest.sh 
elapsed time (seconds): 0.026
----------System.out:(3/67)----------
Unrecognized system!  Darwin
The test failed :-(
exit status was 1
----------System.err:(1/29)----------
Unrecognized system!  Darwin
result: Failed. Execution failed: exit code 1


test result: Failed. Execution failed: exit code 1


From Alan.Bateman at oracle.com  Tue Nov  6 01:04:49 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 06 Nov 2012 09:04:49 +0000
Subject: tricks to running awt tests on Mac OS X?
In-Reply-To: <9D7F8392-9E71-484C-8497-40745AAF163E@ganymede.org>
References: <9D7F8392-9E71-484C-8497-40745AAF163E@ganymede.org>
Message-ID: <5098D2B1.1070108@oracle.com>

On 06/11/2012 06:02, Ray Kiddy wrote:
> Hello -
>
> I downloaded jtreg binaries and am running some of the tests on this machine. It is running 10.7.4. I am having no problems updating the source and building jdk7u-dev. And I can run a lot of the tests with no problems. But AWT tests seem not so cooperative. Is there some trick to running these?
>
> It may be a problem that I downloaded the binaries for jtreg. Looking at the build dependencies was giving me a headache. And, at least with java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh, the test seems to not know what "Darwin" is? This made me suspect I need a newer jtreg. But this one seemed to be from the official source (i.e. http://download.java.net/openjdk/jtreg/).
>
> The full results from this one are below.
>
> I am trying to run with, for example:
>
> 	% cd jdk7u-dev
> 	% ../jtreg/linux/bin/jtreg \
> 	   -jdk:build/macosx-x86_64/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home \
> 	   -w build/jtreg/test/java/awt/work -r build/jtreg/test/java/awt/report \
> 	   -othervm -verbose:summary -ignore:quiet -automatic test/java/awt
>
> I was running with -samevm. Now I am not. I added -ignore:quiet and -automatic. These did not do much.
>
> If I let the tests run, they take a long time. I cannot see how long the set of tests should take, so I am not sure if they are hung. After a while, there are lots of colored windows hanging around and not much seems to be happening. Sort of like a lava lamp in a cubic universe.
>
> Any info about how these test behave when things are passing would be appreciated.
>
> cheers - ray
>
I don't know anything about the AWT tests but they don't run in samevm 
or agentvm mode. In jdk8 then we've added java/awt to othervm.dirs (a 
property in TEST.ROOT) so that they run in othervm mode even if other 
options are specified to jtreg. It's possible that they can't run 
concurrently either, but this is something that the folks on awt-dev 
will know.

As regards IOExceptionIfEncodedURLTest.sh then it looks to be that this 
hasn't been updated to work on Mac, I least I assume that is what 
"Unrecognized system! Darwin" is. That seems surprising as there was a 
big effort to update the tests to work on Mac. Maybe someone on awt-dev 
can say if the tests will be updated.

-Alan

From anthony.petrov at oracle.com  Tue Nov  6 02:26:13 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 06 Nov 2012 14:26:13 +0400
Subject: tricks to running awt tests on Mac OS X?
In-Reply-To: <9D7F8392-9E71-484C-8497-40745AAF163E@ganymede.org>
References: <9D7F8392-9E71-484C-8497-40745AAF163E@ganymede.org>
Message-ID: <5098E5C5.1040804@oracle.com>

This particular test was known to not support macosx. The following bug 
fix covers this issue:

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

If you encounter any other regression tests in JDK that do not run on 
Mac, please file bugs at http://bugs.sun.com/.

--
best regards,
Anthony

On 11/6/2012 10:02 AM, Ray Kiddy wrote:
> Hello -
> 
> I downloaded jtreg binaries and am running some of the tests on this machine. It is running 10.7.4. I am having no problems updating the source and building jdk7u-dev. And I can run a lot of the tests with no problems. But AWT tests seem not so cooperative. Is there some trick to running these?
> 
> It may be a problem that I downloaded the binaries for jtreg. Looking at the build dependencies was giving me a headache. And, at least with java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh, the test seems to not know what "Darwin" is? This made me suspect I need a newer jtreg. But this one seemed to be from the official source (i.e. http://download.java.net/openjdk/jtreg/).
> 
> The full results from this one are below.
> 
> I am trying to run with, for example:
> 
> 	% cd jdk7u-dev
> 	% ../jtreg/linux/bin/jtreg \
> 	   -jdk:build/macosx-x86_64/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home \
> 	   -w build/jtreg/test/java/awt/work -r build/jtreg/test/java/awt/report \
> 	   -othervm -verbose:summary -ignore:quiet -automatic test/java/awt
> 
> I was running with -samevm. Now I am not. I added -ignore:quiet and -automatic. These did not do much.
> 
> If I let the tests run, they take a long time. I cannot see how long the set of tests should take, so I am not sure if they are hung. After a while, there are lots of colored windows hanging around and not much seems to be happening. Sort of like a lava lamp in a cubic universe.
> 
> Any info about how these test behave when things are passing would be appreciated.
> 
> cheers - ray
> 
> 
> 
> #Test Results (version 2)
> #Mon Nov 05 14:39:05 PST 2012
> #checksum:5402429ff12b0171
> #-----testdescription-----
> $file=/Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
> $root=/Users/ray/Projects/openjdk/jdk7u-dev/jdk/test
> author=Dmitry Cherepanov\: area\=appletviewer
> keywords=bug6193279 bug6619458 shell
> run=USER_SPECIFIED compile IOExceptionIfEncodedURLTest.java\nUSER_SPECIFIED main IOExceptionIfEncodedURLTest\nUSER_SPECIFIED shell IOExceptionIfEncodedURLTest.sh\n
> source=IOExceptionIfEncodedURLTest.sh
> title=REGRESSION\: AppletViewer throws IOException when path is encoded URL
> 
> #-----environment-----
> 
> #-----testresult-----
> description=file\:/Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
> elapsed=2295 0\:00\:02.295
> end=Mon Nov 05 14\:39\:05 PST 2012
> environment=regtest
> execStatus=Failed. Execution failed\: exit code 1
> hostname=10.1.10.15
> javatestOS=Mac OS X 10.7.4 (x86_64)
> javatestVersion=4.4
> jtregVersion=jtreg 4.1 fcs b04
> script=com.sun.javatest.regtest.RegressionScript 
> sections=script_messages compile build main shell
> start=Mon Nov 05 14\:39\:03 PST 2012
> test=java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
> user.name=ray
> work=/Users/ray/Projects/openjdk/jdk7u-dev/build/jtreg/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/work/java/awt/appletviewer/IOExceptionIfEncodedURLTest
> 
> #section:script_messages
> ----------messages:(4/241)----------
> JDK under test: (build/macosx-x86_64/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home)
> openjdk version "1.7.0-internal"
> OpenJDK Runtime Environment (build 1.7.0-internal-ray_2012_09_21_10_55-b00)
> OpenJDK 64-Bit Server VM (build 23.6-b03, mixed mode)
> 
> #section:compile
> ----------messages:(3/254)----------
> command: compile /Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.java
> reason: User specified action: run compile IOExceptionIfEncodedURLTest.java 
> elapsed time (seconds): 1.489
> ----------System.out:(0/0)----------
> ----------System.err:(7/627)----------
> /Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.java:35: warning: ParseUtil is internal proprietary API and may be removed in a future release
> import sun.net.www.ParseUtil;
>                   ^
> /Users/ray/Projects/openjdk/jdk7u-dev/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.java:55: warning: ParseUtil is internal proprietary API and may be removed in a future release
>         String path = ParseUtil.fileToEncodedURL(new File(System.getProperty("user.dir"))).getPath();
>                       ^
> 2 warnings
> result: Passed. Compilation successful
> 
> #section:build
> ----------messages:(3/112)----------
> command: build IOExceptionIfEncodedURLTest
> reason: Named class compiled on demand
> elapsed time (seconds): 0.001
> result: Passed. All files up to date
> 
> #section:main
> ----------messages:(3/141)----------
> command: main IOExceptionIfEncodedURLTest
> reason: User specified action: run main IOExceptionIfEncodedURLTest 
> elapsed time (seconds): 0.416
> ----------System.out:(0/0)----------
> ----------System.err:(3/248)----------
> prior checking...
> url=file:IOExceptionIfEncodedURLTest.java -> path=/Users/ray/Projects/openjdk/jdk7u-dev/build/jtreg/jdk/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/work/scratch/,filename=IOExceptionIfEncodedURLTest.java
> STATUS:Passed.
> result: Passed. Execution successful
> 
> #section:shell
> ----------messages:(3/152)----------
> command: shell IOExceptionIfEncodedURLTest.sh []
> reason: User specified action: run shell IOExceptionIfEncodedURLTest.sh 
> elapsed time (seconds): 0.026
> ----------System.out:(3/67)----------
> Unrecognized system!  Darwin
> The test failed :-(
> exit status was 1
> ----------System.err:(1/29)----------
> Unrecognized system!  Darwin
> result: Failed. Execution failed: exit code 1
> 
> 
> test result: Failed. Execution failed: exit code 1
> 

From Sergey.Bylokhov at oracle.com  Tue Nov  6 02:47:00 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 06 Nov 2012 14:47:00 +0400
Subject: All Menus disappear
In-Reply-To: <1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
	<1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>
Message-ID: <5098EAA4.1020100@oracle.com>

06.11.2012 5:42, Michael Hall wrote:
> On Nov 5, 2012, at 6:57 PM, Leonid Romanov wrote:
>
>> We've recently fixed a number of menu related bugs in JDK 8, so could you please test whether your issue is reproducible with the latest JDK 8 preview build.
>
> ystem.in:8:java.specification.version=1.8
> System.in:13:java.version=1.8.0-ea
> System.in:25:java.vm.specification.version=1.8
> System.in:26:java.runtime.version=1.8.0-ea-b63
>
> The problem is still there.
In this case I suggest to file new CR on bugs.sun.com with appropriate 
steps  to reproduce. (Automatic testcase will be useful)
Thanks.
>
> 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
>
>
>


-- 
Best regards, Sergey.


From mik3hall at gmail.com  Tue Nov  6 11:38:46 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 6 Nov 2012 13:38:46 -0600
Subject: All Menus disappear
In-Reply-To: <5098EAA4.1020100@oracle.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
	<1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>
	<5098EAA4.1020100@oracle.com>
Message-ID: <936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com>

On Nov 6, 2012, at 4:47 AM, Sergey Bylokhov wrote:

> 06.11.2012 5:42, Michael Hall wrote:
>> On Nov 5, 2012, at 6:57 PM, Leonid Romanov wrote:
>> 
>>> We've recently fixed a number of menu related bugs in JDK 8, so could you please test whether your issue is reproducible with the latest JDK 8 preview build.
>> 
>> ystem.in:8:java.specification.version=1.8
>> System.in:13:java.version=1.8.0-ea
>> System.in:25:java.vm.specification.version=1.8
>> System.in:26:java.runtime.version=1.8.0-ea-b63
>> 
>> The problem is still there.
> In this case I suggest to file new CR on bugs.sun.com with appropriate steps  to reproduce. (Automatic testcase will be useful)
> Thanks.
> 

I'll see if I can come up with a testcase smaller than my app. 
It is intended to continue supporting the property?

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 leonid.romanov at oracle.com  Thu Nov  8 06:09:54 2012
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Thu, 8 Nov 2012 18:09:54 +0400
Subject: All Menus disappear
In-Reply-To: <936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
	<1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>
	<5098EAA4.1020100@oracle.com>
	<936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com>
Message-ID: <3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com>

Yes, the behavior  you're experiencing is a bug. 

On 06.11.2012, at 23:38, Michael Hall <mik3hall at gmail.com> wrote:

> On Nov 6, 2012, at 4:47 AM, Sergey Bylokhov wrote:
> 
>> 06.11.2012 5:42, Michael Hall wrote:
>>> On Nov 5, 2012, at 6:57 PM, Leonid Romanov wrote:
>>> 
>>>> We've recently fixed a number of menu related bugs in JDK 8, so could you please test whether your issue is reproducible with the latest JDK 8 preview build.
>>> 
>>> ystem.in:8:java.specification.version=1.8
>>> System.in:13:java.version=1.8.0-ea
>>> System.in:25:java.vm.specification.version=1.8
>>> System.in:26:java.runtime.version=1.8.0-ea-b63
>>> 
>>> The problem is still there.
>> In this case I suggest to file new CR on bugs.sun.com with appropriate steps  to reproduce. (Automatic testcase will be useful)
>> Thanks.
>> 
> 
> I'll see if I can come up with a testcase smaller than my app. 
> It is intended to continue supporting the property?
> 
> 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 scott.kovatch at oracle.com  Thu Nov  8 11:25:35 2012
From: scott.kovatch at oracle.com (Scott Kovatch)
Date: Thu, 8 Nov 2012 11:25:35 -0800
Subject: file.encoding vs. sun.jnu.encoding(?) on OS X
Message-ID: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>

Hello,

I want to bring up something that is causing a lot of confusion, and is generating a lot of bugs on OS X.

What is the relationship between path names and file.encoding? Or, maybe more correctly, _why_ is there some relationship between path names and file.encoding? On OS X filenames are ALWAYS in UTF-8, so the current locale should never come into play.

I was about to launch into a discussion (rant) about our use of nl_langinfo(CODESET) for file.encoding, but the more I look into it, I don't think that's the problem, though you can also make a case that all text files on OS X are UTF-8 by default as well. I'm wondering if this has something to do with sun.jnu.encoding being set to the same value as file.encoding.

-- Scott K.

----------------------------------------
Scott Kovatch
scott.kovatch at oracle.com
Santa Clara/Pleasanton, CA



From mik3hall at gmail.com  Thu Nov  8 14:07:05 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 8 Nov 2012 16:07:05 -0600
Subject: All Menus disappear
In-Reply-To: <3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
	<1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>
	<5098EAA4.1020100@oracle.com>
	<936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com>
	<3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com>
Message-ID: <4643C281-1131-4259-BC8B-2DAF514B04BE@gmail.com>

On Nov 8, 2012, at 8:09 AM, Leonid Romanov wrote:

> Yes, the behavior  you're experiencing is a bug. 

Stil haven't come up with a better test case but will try to yet.

Thanks

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 xueming.shen at oracle.com  Thu Nov  8 18:36:14 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 08 Nov 2012 18:36:14 -0800
Subject: file.encoding vs. sun.jnu.encoding(?) on OS X
In-Reply-To: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
Message-ID: <509C6C1E.9010304@oracle.com>

Scott,

There should be no direct relationship between path name and 
file.encoding after we introduced in
the property sun.jnu.encoding (implementation detail, not a public 
interface) couple release ago. The
charset specified by sun.jnu.encoding should be used for 
decoding/encoding the "java" file path and
native file path, not the one from Charset.defaultCharset(), which is 
from file.encoding.
Alan has a webrev for this one at

http://cr.openjdk.java.net/~alanb/7050570/webrev/

I just realized that this one is not in yet. Alan, any reason this one 
is still not pushed in? I think I have
reviewed it already.

-Sherman

On 11/8/2012 11:25 AM, Scott Kovatch wrote:
> Hello,
>
> I want to bring up something that is causing a lot of confusion, and is generating a lot of bugs on OS X.
>
> What is the relationship between path names and file.encoding? Or, maybe more correctly, _why_ is there some relationship between path names and file.encoding? On OS X filenames are ALWAYS in UTF-8, so the current locale should never come into play.
>
> I was about to launch into a discussion (rant) about our use of nl_langinfo(CODESET) for file.encoding, but the more I look into it, I don't think that's the problem, though you can also make a case that all text files on OS X are UTF-8 by default as well. I'm wondering if this has something to do with sun.jnu.encoding being set to the same value as file.encoding.
>
> -- Scott K.
>
> ----------------------------------------
> Scott Kovatch
> scott.kovatch at oracle.com
> Santa Clara/Pleasanton, CA
>
>

From mik3hall at gmail.com  Thu Nov  8 18:55:09 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 8 Nov 2012 20:55:09 -0600
Subject: All Menus disappear
In-Reply-To: <3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
	<1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>
	<5098EAA4.1020100@oracle.com>
	<936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com>
	<3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com>
Message-ID: <F6D8B4DC-FFD2-42E3-942D-A94F9617698A@gmail.com>

On Nov 8, 2012, at 8:09 AM, Leonid Romanov wrote:

> Yes, the behavior  you're experiencing is a bug. 

OK, I have a test case I'll try to come up with a bug report tomorrow.

I think it's if the sub window does this?

   		menuBar = new JMenuBar();
 		setJMenuBar(menuBar);

with the -Dapple.laf.useScreenMenuBar=true

The main window also did the same as the above I think if that matters. Not sure why. Hopefully it made sense sometime.

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 Alan.Bateman at oracle.com  Fri Nov  9 05:12:21 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 09 Nov 2012 13:12:21 +0000
Subject: file.encoding vs. sun.jnu.encoding(?) on OS X
In-Reply-To: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
Message-ID: <509D0135.8000406@oracle.com>

On 08/11/2012 19:25, Scott Kovatch wrote:
> Hello,
>
> I want to bring up something that is causing a lot of confusion, and is generating a lot of bugs on OS X.
>
> What is the relationship between path names and file.encoding? Or, maybe more correctly, _why_ is there some relationship between path names and file.encoding? On OS X filenames are ALWAYS in UTF-8, so the current locale should never come into play.
>
> I was about to launch into a discussion (rant) about our use of nl_langinfo(CODESET) for file.encoding, but the more I look into it, I don't think that's the problem, though you can also make a case that all text files on OS X are UTF-8 by default as well. I'm wondering if this has something to do with sun.jnu.encoding being set to the same value as file.encoding.
>
> -- Scott K.
>
I've seen several mails on macosx-port-dev about this, although I think 
several issues have been conflated which makes for confusing reading.

One of the issues is that HFS normalizes to a variant of NFD and the 
changes that came via the Mac port weren't right. Sherman has 
re-implemented this via 7130915 in jdk8 and it has been back-ported to 
7u for 7u12. We've had confirmation from several people that this 
resolves the issues that they were seeing.

The other issue, and I think the issue that you are trying to get at, is 
that sun.jnu.encoding is being set based on the locale whereas you are 
saying that it should always be UTF-8 on Mac. I think we need to create 
a bug on that and it would be great if you can get technical references 
so that we know this is the right thing to do. There are at least two 
places in the property initialization that would need to be updated to 
do this. I don't think we should change file.encoding as that would 
change the default encoding for the file contents whereas the issues all 
seem to related to the encoding/decoding of file names.

The final issue is just consistent use of sun.jnu.encoding. This 
property was originally only used for Windows but now we have cases 
where it may different to file.encoding on other platforms. Sherman 
brought up 7050570, which is addressing something different again but 
part of it does fix up the new file system API to use sun.jnu.encoding. 
I haven't seen any mails on macosx-port-dev that look like this issue 
but we should get it in anyway (Sherman - you ask why I hadn't pushed 
that several months ago, sorry, it's been on my list as a low priority 
item and low priority items have been starved of cycles).

-Alan.

From mik3hall at gmail.com  Fri Nov  9 14:53:52 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 9 Nov 2012 16:53:52 -0600
Subject: All Menus disappear
In-Reply-To: <F6D8B4DC-FFD2-42E3-942D-A94F9617698A@gmail.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
	<1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>
	<5098EAA4.1020100@oracle.com>
	<936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com>
	<3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com>
	<F6D8B4DC-FFD2-42E3-942D-A94F9617698A@gmail.com>
Message-ID: <AE09D0FC-6ECF-43B6-A917-77AC1564F49B@gmail.com>

On Nov 8, 2012, at 8:55 PM, Michael Hall wrote:

> On Nov 8, 2012, at 8:09 AM, Leonid Romanov wrote:
> 
>> Yes, the behavior  you're experiencing is a bug. 
> 
> OK, I have a test case I'll try to come up with a bug report tomorrow.


Your report has been assigned an internal review ID of 2376841.

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 ray at ganymede.org  Sat Nov 10 13:29:33 2012
From: ray at ganymede.org (Ray Kiddy)
Date: Sat, 10 Nov 2012 13:29:33 -0800
Subject: updated on 10.7.4 and failed to build
Message-ID: <DCAD7F6A-5C52-4DDE-94BE-505A993F4C2A@ganymede.org>


Previous update of this source built. That was fetched on 2012/11/02 19:58 PDT.

Just updated and now I get:

llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I/Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/share/vm/prims -I/Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/share/vm -I/Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/share/vm/precompiled -I/Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/cpu/x86/vm -I/Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/os_cpu/bsd_x86/vm -I/Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/os/bsd/vm -I/Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"24.0-b24\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"ray\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 -pipe -Os -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -DINCLUDE_TRACE -Werror -Wpointer-arith -Wconversion -Wsign-compare    -DDTRACE_ENABLED  -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -fpch-deps -MMD -MP -MF ../generated/dependencies/bcEscapeAnalyzer.o.d -o bcEscapeAnalyzer.o /Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/share/vm/ci/bcEscapeAnalyzer.cpp 
make[8]: *** No rule to make target `/Users/ray/Projects/openjdk/jdk7u-dev/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp', needed by `binaryTreeDictionary.o'.  Stop.
make[8]: *** Waiting for unfinished jobs....

I have been getting updates and building in this directory since 9/21. Let me know if there is anything else I should add to my update/build script.

cheers - ray


From niagarasoft20-macosxportdev at yahoo.com  Sat Nov 10 13:47:04 2012
From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com)
Date: Sat, 10 Nov 2012 13:47:04 -0800 (PST)
Subject: AppBundler launcher, directory structure & info.plist
In-Reply-To: <AE09D0FC-6ECF-43B6-A917-77AC1564F49B@gmail.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>
	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>
	<1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>
	<5098EAA4.1020100@oracle.com>
	<936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com>
	<3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com>
	<F6D8B4DC-FFD2-42E3-942D-A94F9617698A@gmail.com>
	<AE09D0FC-6ECF-43B6-A917-77AC1564F49B@gmail.com>
Message-ID: <1352584024.45912.YahooMailNeo@web121804.mail.ne1.yahoo.com>

I currently do not use ant to build my app, instead using simple shell scripts.

I have downloaded the launcher stub executable (JavaAppLauncher) from the AppBundler project files. Can someone describe or post samples of the .app directory structure expected by the launcher within the app and the relevent info.plist entries?

I'm having trouble getting the launcher to find my bundled jre with Java 7u9.

Thanks,
Mike

From rick.hillegas at oracle.com  Mon Nov 12 06:28:18 2012
From: rick.hillegas at oracle.com (Rick Hillegas)
Date: Mon, 12 Nov 2012 06:28:18 -0800
Subject: AppBundler launcher, directory structure & info.plist
In-Reply-To: <1352584024.45912.YahooMailNeo@web121804.mail.ne1.yahoo.com>
References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com>	<8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com>	<1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com>	<5098EAA4.1020100@oracle.com>	<936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com>	<3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com>	<F6D8B4DC-FFD2-42E3-942D-A94F9617698A@gmail.com>	<AE09D0FC-6ECF-43B6-A917-77AC1564F49B@gmail.com>
	<1352584024.45912.YahooMailNeo@web121804.mail.ne1.yahoo.com>
Message-ID: <50A10782.1090207@oracle.com>

On 11/10/12 1:47 PM, niagarasoft20-macosxportdev at yahoo.com wrote:
> I currently do not use ant to build my app, instead using simple shell scripts.
>
> I have downloaded the launcher stub executable (JavaAppLauncher) from the AppBundler project files. Can someone describe or post samples of the .app directory structure expected by the launcher within the app and the relevent info.plist entries?
>
> I'm having trouble getting the launcher to find my bundled jre with Java 7u9.
>
> Thanks,
> Mike
>
Hi Mike,

I just started using AppBundler to build a java app on Java 7. 
Previously on Java 6, I built the directory structure and Info.plist by 
hand.

Here is the structure of my app as built by AppBundler.

Hopefully you will get better advice from people who are experts in 
using AppBundler, but this may help...

-Rick

-----------------------------------------------

PhotoDB.app
PhotoDB.app/Contents
PhotoDB.app/Contents/Info.plist
PhotoDB.app/Contents/Java
PhotoDB.app/Contents/Java/derby.jar
PhotoDB.app/Contents/Java/fogfallpc.jar

(Here you will see html and license directories which AppBundler did NOT 
build. My ant script adds these AFTER AppBundler finishes.)

PhotoDB.app/Contents/Java/html
PhotoDB.app/Contents/Java/html/advanced.html
PhotoDB.app/Contents/Java/html/help.html
PhotoDB.app/Contents/Java/license
PhotoDB.app/Contents/Java/license/fogfall.license
PhotoDB.app/Contents/Java/license/NOTICE

(Here we resume listing what AppBundler DID build)

PhotoDB.app/Contents/Java/PhotoDB.jar
PhotoDB.app/Contents/MacOS
PhotoDB.app/Contents/MacOS/JavaAppLauncher
PhotoDB.app/Contents/PkgInfo
PhotoDB.app/Contents/PlugIns
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/COPYRIGHT
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib    // 
lots of stuff in this directory
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/images
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/images/cursors    
// plenty of stuff in this directory
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/lwawt
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/lwawt/liblwawt.dylib
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/management    
// plenty of stuff in this directory
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/security    
// plenty of stuff in this directory
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/security/blacklist
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/security/cacerts
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/server    
// plenty of stuff in this directory
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/servicetag
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/servicetag/jdk_header.png
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/xawt
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/xawt/libmawt.dylib
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/lib/zi    
// lots of locale stuff under here
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/LICENSE
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/README
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/THIRDPARTYLICENSEREADME-JAVAFX.txt
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/THIRDPARTYLICENSEREADME.txt
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Home/jre/Welcome.html
PhotoDB.app/Contents/PlugIns/jdk1.7.0_09.jdk/Contents/Info.plist
PhotoDB.app/Contents/Resources
PhotoDB.app/Contents/Resources/en.lproj
PhotoDB.app/Contents/Resources/en.lproj/Localizable.strings
PhotoDB.app/Contents/Resources/macIcon.icns


Here is the Info.plist which AppBundler generated:

<?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">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>libjli.dylib</string>
<key>CFBundleGetInfoString</key>
<string>Java SE 1.7.0_09</string>
<key>CFBundleIdentifier</key>
<string>com.oracle.java.7u09.jdk</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>7.0</string>
<key>CFBundleName</key>
<string>Java SE 7</string>
<key>CFBundlePackageType</key>
<string>BNDL</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.7.0_09</string>
<key>JavaVM</key>
<dict>
<key>JVMCapabilities</key>
<array>
<string>CommandLine</string>
</array>
<key>JVMMinimumFrameworkVersion</key>
<string>13.2.9</string>
<key>JVMMinimumSystemVersion</key>
<string>10.6.0</string>
<key>JVMPlatformVersion</key>
<string>1.7</string>
<key>JVMVendor</key>
<string>Oracle Corporation</string>
<key>JVMVersion</key>
<string>1.7.0_09</string>
</dict>
</dict>
</plist>


From rick.hillegas at oracle.com  Mon Nov 12 06:54:11 2012
From: rick.hillegas at oracle.com (Rick Hillegas)
Date: Mon, 12 Nov 2012 06:54:11 -0800
Subject: issues after porting a mac app from Java 6 to 7u9
Message-ID: <50A10D93.5000707@oracle.com>

I have ported an app from Java 6 to 7u9. I am seeing the following 
behaviors. One behavior is specific. The other is vague and I will need 
to run the app for a while longer before I come up with a theory about 
where the problem may be:

1) Drag-and-drop on a JTable behaves differently. On Java 6, when I drag 
a cell between locations on a JTable, the following happens:

   - A ghost rectangle appears as the drag starts.
   - I drag the ghost rectangle onto the target cell, positioning it so 
that it lines up with the target border, and then release the mouse.
   - My drag-and-drop handler then processes events correctly.

Now on Java 7 the following happens:

   - The ghost rectangle appears as before.
   - But I have to position it differently. Now I have to just barely 
overlap the bottom boundary of the ghost rectangle with the top boundary 
of the target cell in order to generate events for my drag-and-drop handler.

Is this a known difference in behavior?

2) The other problem is probably too vague, but here goes: I seem to 
have memory management issues. After running the app for a while, it 
starts freezing up and I watch the beachball spin. Eventually the app 
becomes unusable and I have to re-start it. Is it expected that I will 
need to give an app more memory in order to run it on Java 7?

Thanks,
-Rick

From philip.race at oracle.com  Mon Nov 12 07:08:03 2012
From: philip.race at oracle.com (Phil Race)
Date: Mon, 12 Nov 2012 07:08:03 -0800
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <50A10D93.5000707@oracle.com>
References: <50A10D93.5000707@oracle.com>
Message-ID: <50A110D3.60100@oracle.com>

On 11/12/12 6:54 AM, Rick Hillegas wrote:
>
>
> 2) The other problem is probably too vague, but here goes: I seem to 
> have memory management issues. After running the app for a while, it 
> starts freezing up and I watch the beachball spin. Eventually the app 
> becomes unusable and I have to re-start it. Is it expected that I will 
> need to give an app more memory in order to run it on Java 7? 

This could be VM differences. 64 bit vs 32 bit maybe.
JDK 7 is 64 bit only. If you are explicitly constraining memory that 
could well be an issue.
If  you are using defaults you might want to see which VM you were using 
with JDK6.
If it was 32 bit, toggle it to 64 bit and see if the issues occur there 
as well.

-phil.

From jesmith at kaon.com  Mon Nov 12 07:29:18 2012
From: jesmith at kaon.com (Joshua Smith)
Date: Mon, 12 Nov 2012 10:29:18 -0500
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <50A110D3.60100@oracle.com>
References: <50A10D93.5000707@oracle.com> <50A110D3.60100@oracle.com>
Message-ID: <0BA9EB4F-FD6D-4595-984D-353D2F6EDC45@kaon.com>

If this is the problem, we've found that -XX:+UseCompressedOops makes a huge difference in our apps.

On Nov 12, 2012, at 10:08 AM, Phil Race <philip.race at oracle.com> wrote:

> On 11/12/12 6:54 AM, Rick Hillegas wrote:
>> 
>> 
>> 2) The other problem is probably too vague, but here goes: I seem to have memory management issues. After running the app for a while, it starts freezing up and I watch the beachball spin. Eventually the app becomes unusable and I have to re-start it. Is it expected that I will need to give an app more memory in order to run it on Java 7? 
> 
> This could be VM differences. 64 bit vs 32 bit maybe.
> JDK 7 is 64 bit only. If you are explicitly constraining memory that could well be an issue.
> If  you are using defaults you might want to see which VM you were using with JDK6.
> If it was 32 bit, toggle it to 64 bit and see if the issues occur there as well.
> 
> -phil.


From rick.hillegas at oracle.com  Mon Nov 12 08:22:42 2012
From: rick.hillegas at oracle.com (Rick Hillegas)
Date: Mon, 12 Nov 2012 08:22:42 -0800
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <0BA9EB4F-FD6D-4595-984D-353D2F6EDC45@kaon.com>
References: <50A10D93.5000707@oracle.com> <50A110D3.60100@oracle.com>
	<0BA9EB4F-FD6D-4595-984D-353D2F6EDC45@kaon.com>
Message-ID: <50A12252.9010409@oracle.com>

On 11/12/12 7:29 AM, Joshua Smith wrote:
> If this is the problem, we've found that -XX:+UseCompressedOops makes a huge difference in our apps.
>
> On Nov 12, 2012, at 10:08 AM, Phil Race<philip.race at oracle.com>  wrote:
>
>> On 11/12/12 6:54 AM, Rick Hillegas wrote:
>>>
>>> 2) The other problem is probably too vague, but here goes: I seem to have memory management issues. After running the app for a while, it starts freezing up and I watch the beachball spin. Eventually the app becomes unusable and I have to re-start it. Is it expected that I will need to give an app more memory in order to run it on Java 7?
>> This could be VM differences. 64 bit vs 32 bit maybe.
>> JDK 7 is 64 bit only. If you are explicitly constraining memory that could well be an issue.
>> If  you are using defaults you might want to see which VM you were using with JDK6.
>> If it was 32 bit, toggle it to 64 bit and see if the issues occur there as well.
>>
>> -phil.
>
Thanks for the quick responses, Phil and Joshua. This is the Java 6 
version I was using:

java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07-395-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-395, mixed mode)

Thanks,
-Rick

From philip.race at oracle.com  Mon Nov 12 08:48:45 2012
From: philip.race at oracle.com (Phil Race)
Date: Mon, 12 Nov 2012 08:48:45 -0800
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <50A12252.9010409@oracle.com>
References: <50A10D93.5000707@oracle.com>
	<50A110D3.60100@oracle.com>	<0BA9EB4F-FD6D-4595-984D-353D2F6EDC45@kaon.com>
	<50A12252.9010409@oracle.com>
Message-ID: <50A1286D.8060702@oracle.com>

So next probable step is do some profiling to see what's happening with 
memory.
Are we allocating something in the implementation that didn't happen 
before ??

-phil.

On 11/12/2012 8:22 AM, Rick Hillegas wrote:
>>
> Thanks for the quick responses, Phil and Joshua. This is the Java 6 
> version I was using:
>
> java version "1.6.0_27"
> Java(TM) SE Runtime Environment (build 1.6.0_27-b07-395-11M3909)
> Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-395, mixed mode)
>
> Thanks, 


From rick.hillegas at oracle.com  Mon Nov 12 09:08:02 2012
From: rick.hillegas at oracle.com (Rick Hillegas)
Date: Mon, 12 Nov 2012 09:08:02 -0800
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <50A1286D.8060702@oracle.com>
References: <50A10D93.5000707@oracle.com>
	<50A110D3.60100@oracle.com>	<0BA9EB4F-FD6D-4595-984D-353D2F6EDC45@kaon.com>
	<50A12252.9010409@oracle.com> <50A1286D.8060702@oracle.com>
Message-ID: <50A12CF2.4020904@oracle.com>

On 11/12/12 8:48 AM, Phil Race wrote:
> So next probable step is do some profiling to see what's happening 
> with memory.
> Are we allocating something in the implementation that didn't happen 
> before ??
Thanks, Phil. The application has not changed. The big change is that 
the Java 7 VM is bundled inside the Mac app now. Previously, OSX was 
able to find an Apple-supplied VM under /Library.

Thanks,
-Rick
>
> -phil.
>
> On 11/12/2012 8:22 AM, Rick Hillegas wrote:
>>>
>> Thanks for the quick responses, Phil and Joshua. This is the Java 6 
>> version I was using:
>>
>> java version "1.6.0_27"
>> Java(TM) SE Runtime Environment (build 1.6.0_27-b07-395-11M3909)
>> Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-395, mixed mode)
>>
>> Thanks, 
>
>


From philip.race at oracle.com  Mon Nov 12 13:16:33 2012
From: philip.race at oracle.com (Phil Race)
Date: Mon, 12 Nov 2012 13:16:33 -0800
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <50A12CF2.4020904@oracle.com>
References: <50A10D93.5000707@oracle.com>	<50A110D3.60100@oracle.com>	<0BA9EB4F-FD6D-4595-984D-353D2F6EDC45@kaon.com>	<50A12252.9010409@oracle.com>
	<50A1286D.8060702@oracle.com> <50A12CF2.4020904@oracle.com>
Message-ID: <50A16731.10900@oracle.com>

On 11/12/2012 9:08 AM, Rick Hillegas wrote:
> On 11/12/12 8:48 AM, Phil Race wrote:
>> So next probable step is do some profiling to see what's happening 
>> with memory.
>> Are we allocating something in the implementation that didn't happen 
>> before ??
> Thanks, Phil. The application has not changed. The big change is that 
> the Java 7 VM is bundled inside the Mac app now. Previously, OSX was 
> able to find an Apple-supplied VM under /Library.

I meant, maybe since the JDK7 rendering pipelines are so different than 
Apple had in 6, that
we are creating and disposing lots of <something> in a way that never 
happened in 6.
If these are visible in the java heap, your profiling should show them.

-phil.

>
> Thanks,
> -Rick
>>
>> -phil.
>>
>> On 11/12/2012 8:22 AM, Rick Hillegas wrote:
>>>>
>>> Thanks for the quick responses, Phil and Joshua. This is the Java 6 
>>> version I was using:
>>>
>>> java version "1.6.0_27"
>>> Java(TM) SE Runtime Environment (build 1.6.0_27-b07-395-11M3909)
>>> Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-395, mixed mode)
>>>
>>> Thanks, 
>>
>>
>


From heinz at javaspecialists.eu  Mon Nov 12 14:57:48 2012
From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz)
Date: Tue, 13 Nov 2012 00:57:48 +0200
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <50A12CF2.4020904@oracle.com>
References: <50A10D93.5000707@oracle.com> <50A110D3.60100@oracle.com>
	<0BA9EB4F-FD6D-4595-984D-353D2F6EDC45@kaon.com>
	<50A12252.9010409@oracle.com> <50A1286D.8060702@oracle.com>
	<50A12CF2.4020904@oracle.com>
Message-ID: <CACLL95ooC4Y0y=uLE-=ZwZc033+zWJ7zAtjrTV50_SP_J85a1Q@mail.gmail.com>

Could you please get GC logs with both versions and send them to us?
Please use
-Xloggc:filename.vgc and -XX:+PrintGCDetails.

On 12/11/2012, Rick Hillegas <rick.hillegas at oracle.com> wrote:
> On 11/12/12 8:48 AM, Phil Race wrote:
>> So next probable step is do some profiling to see what's happening
>> with memory.
>> Are we allocating something in the implementation that didn't happen
>> before ??
> Thanks, Phil. The application has not changed. The big change is that
> the Java 7 VM is bundled inside the Mac app now. Previously, OSX was
> able to find an Apple-supplied VM under /Library.
>
> Thanks,
> -Rick
>>
>> -phil.
>>
>> On 11/12/2012 8:22 AM, Rick Hillegas wrote:
>>>>
>>> Thanks for the quick responses, Phil and Joshua. This is the Java 6
>>> version I was using:
>>>
>>> java version "1.6.0_27"
>>> Java(TM) SE Runtime Environment (build 1.6.0_27-b07-395-11M3909)
>>> Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-395, mixed mode)
>>>
>>> Thanks,
>>
>>
>
>


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

From kirk at kodewerk.com  Mon Nov 12 16:23:02 2012
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Tue, 13 Nov 2012 01:23:02 +0100
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <CACLL95ooC4Y0y=uLE-=ZwZc033+zWJ7zAtjrTV50_SP_J85a1Q@mail.gmail.com>
References: <50A10D93.5000707@oracle.com> <50A110D3.60100@oracle.com>
	<0BA9EB4F-FD6D-4595-984D-353D2F6EDC45@kaon.com>
	<50A12252.9010409@oracle.com> <50A1286D.8060702@oracle.com>
	<50A12CF2.4020904@oracle.com>
	<CACLL95ooC4Y0y=uLE-=ZwZc033+zWJ7zAtjrTV50_SP_J85a1Q@mail.gmail.com>
Message-ID: <341BEB84-D88E-4647-AA2E-371FB86A510B@kodewerk.com>

and add -XX:+PrintTenuringDistribution

On 2012-11-12, at 11:57 PM, Dr Heinz M. Kabutz <heinz at javaspecialists.eu> wrote:

> Could you please get GC logs with both versions and send them to us?
> Please use
> -Xloggc:filename.vgc and -XX:+PrintGCDetails.
> 
> On 12/11/2012, Rick Hillegas <rick.hillegas at oracle.com> wrote:
>> On 11/12/12 8:48 AM, Phil Race wrote:
>>> So next probable step is do some profiling to see what's happening
>>> with memory.
>>> Are we allocating something in the implementation that didn't happen
>>> before ??
>> Thanks, Phil. The application has not changed. The big change is that
>> the Java 7 VM is bundled inside the Mac app now. Previously, OSX was
>> able to find an Apple-supplied VM under /Library.
>> 
>> Thanks,
>> -Rick
>>> 
>>> -phil.
>>> 
>>> On 11/12/2012 8:22 AM, Rick Hillegas wrote:
>>>>> 
>>>> Thanks for the quick responses, Phil and Joshua. This is the Java 6
>>>> version I was using:
>>>> 
>>>> java version "1.6.0_27"
>>>> Java(TM) SE Runtime Environment (build 1.6.0_27-b07-395-11M3909)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06-395, mixed mode)
>>>> 
>>>> Thanks,
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 75 595 262
> Skype: kabutz


From ysr1729 at gmail.com  Tue Nov 13 01:23:17 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Tue, 13 Nov 2012 01:23:17 -0800
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <50A10D93.5000707@oracle.com>
References: <50A10D93.5000707@oracle.com>
Message-ID: <CABzyjyn0Qef8w-90oxnFQm1RRaLytBdUBsfD_GqEd6OHHqxa5g@mail.gmail.com>

On Mon, Nov 12, 2012 at 6:54 AM, Rick Hillegas <rick.hillegas at oracle.com>wrote:

> ...
> 2) The other problem is probably too vague, but here goes: I seem to have
> memory management issues. After running the app for a while, it starts
> freezing up and I watch the beachball spin. Eventually the app becomes
> unusable and I have to re-start it. Is it expected that I will need to give
> an app more memory in order to run it on Java 7?
>
>
The default GC with JDK 6 on the Mac was -XX:+UseConcMarkSweepGC. With JDK
7 it is -XX:+UseParallelGC.
I suspect the JDK 6 version that was the default on your mac, also used a
different default heap size.
The combination of a different heap size and a different collector (but
especially a different heap size)
could make  a big difference in performance (especially if you were running
lots of other stuff on your
mac, so that the Java heap was paging during full gc).

As others have indicated, verbose gc logs are your friend.
-- ramki

From ysr1729 at gmail.com  Tue Nov 13 01:24:44 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Tue, 13 Nov 2012 01:24:44 -0800
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <CABzyjyn0Qef8w-90oxnFQm1RRaLytBdUBsfD_GqEd6OHHqxa5g@mail.gmail.com>
References: <50A10D93.5000707@oracle.com>
	<CABzyjyn0Qef8w-90oxnFQm1RRaLytBdUBsfD_GqEd6OHHqxa5g@mail.gmail.com>
Message-ID: <CABzyjynPDxj4nAaHtSsJzUtWZ1xr8A0APZMy6vofSyuYOOpnFA@mail.gmail.com>

Correction inline below:

On Tue, Nov 13, 2012 at 1:23 AM, Srinivas Ramakrishna <ysr1729 at gmail.com>wrote:

>
>
> On Mon, Nov 12, 2012 at 6:54 AM, Rick Hillegas <rick.hillegas at oracle.com>wrote:
>
>> ...
>>
>> 2) The other problem is probably too vague, but here goes: I seem to have
>> memory management issues. After running the app for a while, it starts
>> freezing up and I watch the beachball spin. Eventually the app becomes
>> unusable and I have to re-start it. Is it expected that I will need to give
>> an app more memory in order to run it on Java 7?
>>
>>
> The default GC with JDK 6 on the Mac was -XX:+UseConcMarkSweepGC. With JDK
> 7 it is -XX:+UseParallelGC.
>

Actually -XX:+UseParallelOldGC (not just -XX:+UseParallelGC).

-- ramki


> I suspect the JDK 6 version that was the default on your mac, also used a
> different default heap size.
> The combination of a different heap size and a different collector (but
> especially a different heap size)
> could make  a big difference in performance (especially if you were
> running lots of other stuff on your
> mac, so that the Java heap was paging during full gc).
>
> As others have indicated, verbose gc logs are your friend.
> -- ramki
>

From anthony.petrov at oracle.com  Tue Nov 13 04:33:57 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 13 Nov 2012 16:33:57 +0400
Subject: issues after porting a mac app from Java 6 to 7u9
In-Reply-To: <50A10D93.5000707@oracle.com>
References: <50A10D93.5000707@oracle.com>
Message-ID: <50A23E35.7040906@oracle.com>

On 11/12/2012 6:54 PM, Rick Hillegas wrote:
> 1) Drag-and-drop on a JTable behaves differently. On Java 6, when I drag 
> a cell between locations on a JTable, the following happens:
> 
>   - A ghost rectangle appears as the drag starts.
>   - I drag the ghost rectangle onto the target cell, positioning it so 
> that it lines up with the target border, and then release the mouse.
>   - My drag-and-drop handler then processes events correctly.
> 
> Now on Java 7 the following happens:
> 
>   - The ghost rectangle appears as before.
>   - But I have to position it differently. Now I have to just barely 
> overlap the bottom boundary of the ghost rectangle with the top boundary 
> of the target cell in order to generate events for my drag-and-drop 
> handler.
> 
> Is this a known difference in behavior?

Not that I know of. Please file a bug at http://bugs.sun.com/. Swing 
engineers will evaluate it.

--
best regards,
Anthony

From swpalmer at gmail.com  Tue Nov 13 08:21:32 2012
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 13 Nov 2012 11:21:32 -0500
Subject: Something is wrong with JNI's jlong in JDK7
Message-ID: <2BFCD800-D49D-41F9-A066-8DCDB6401AF1@gmail.com>

I just noticed that the criteria for defining jlong has changed from that given in Apple's JDK 6 vs. Oracle's JDK 7.  This caused some code of mine to break because it seems to be wrong under some circumstances.

JDK 7u10 has this.  Note that sometimes a jlong is a C "long" and sometimes it is a C "long long": 

#ifndef _JAVASOFT_JNI_MD_H_
#define _JAVASOFT_JNI_MD_H_

#define JNIEXPORT
#define JNIIMPORT
#define JNICALL

typedef int jint;
#ifdef _LP64 /* 64-bit Solaris */
typedef long jlong;
#else
typedef long long jlong;
#endif

typedef signed char jbyte;

#endif /* !_JAVASOFT_JNI_MD_H_ */



Whereas Apple's JDK 6 always uses "long long":



#ifndef _JAVASOFT_JNI_MD_H_
#define _JAVASOFT_JNI_MD_H_

#define JNIEXPORT __attribute__((visibility("default")))
#define JNIIMPORT
#define JNICALL

#if defined(__LP64__) && __LP64__ /* for -Wundef */
typedef int jint;
#else
typedef long jint;
#endif
typedef long long jlong;
typedef signed char jbyte;

#endif /* !_JAVASOFT_JNI_MD_H_ */


From swingler at apple.com  Tue Nov 13 13:36:33 2012
From: swingler at apple.com (Mike Swingler)
Date: Tue, 13 Nov 2012 13:36:33 -0800
Subject: Something is wrong with JNI's jlong in JDK7
In-Reply-To: <2BFCD800-D49D-41F9-A066-8DCDB6401AF1@gmail.com>
References: <2BFCD800-D49D-41F9-A066-8DCDB6401AF1@gmail.com>
Message-ID: <76E78E92-9EF9-4016-9F4A-AC0AA5AC1F16@apple.com>

On Nov 13, 2012, at 8:21 AM, Scott Palmer <swpalmer at gmail.com> wrote:

> I just noticed that the criteria for defining jlong has changed from that given in Apple's JDK 6 vs. Oracle's JDK 7.  This caused some code of mine to break because it seems to be wrong under some circumstances.
> 
> JDK 7u10 has this.  Note that sometimes a jlong is a C "long" and sometimes it is a C "long long": 
> 
> #ifndef _JAVASOFT_JNI_MD_H_
> #define _JAVASOFT_JNI_MD_H_
> 
> #define JNIEXPORT
> #define JNIIMPORT
> #define JNICALL
> 
> typedef int jint;
> #ifdef _LP64 /* 64-bit Solaris */
> typedef long jlong;
> #else
> typedef long long jlong;
> #endif
> 
> typedef signed char jbyte;
> 
> #endif /* !_JAVASOFT_JNI_MD_H_ */
> 
> 
> 
> Whereas Apple's JDK 6 always uses "long long":
> 
> 
> 
> #ifndef _JAVASOFT_JNI_MD_H_
> #define _JAVASOFT_JNI_MD_H_
> 
> #define JNIEXPORT __attribute__((visibility("default")))
> #define JNIIMPORT
> #define JNICALL
> 
> #if defined(__LP64__) && __LP64__ /* for -Wundef */
> typedef int jint;
> #else
> typedef long jint;
> #endif
> typedef long long jlong;
> typedef signed char jbyte;
> 
> #endif /* !_JAVASOFT_JNI_MD_H_ */

Have you filed a bug at <http://bugs.sun.com>?

Regards,
Mike Swingler
Apple Inc.


From swpalmer at gmail.com  Tue Nov 13 14:00:02 2012
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 13 Nov 2012 17:00:02 -0500
Subject: Something is wrong with JNI's jlong in JDK7
In-Reply-To: <76E78E92-9EF9-4016-9F4A-AC0AA5AC1F16@apple.com>
References: <2BFCD800-D49D-41F9-A066-8DCDB6401AF1@gmail.com>
	<76E78E92-9EF9-4016-9F4A-AC0AA5AC1F16@apple.com>
Message-ID: <AF409584-029B-44BB-AB32-D76234A29B7B@gmail.com>

On 2012-11-13, at 4:36 PM, Mike Swingler <swingler at apple.com> wrote:

> On Nov 13, 2012, at 8:21 AM, Scott Palmer <swpalmer at gmail.com> wrote:
> 
>> I just noticed that the criteria for defining jlong has changed from that given in Apple's JDK 6 vs. Oracle's JDK 7.  This caused some code of mine to break because it seems to be wrong under some circumstances.
>> 
>> JDK 7u10 has this.  Note that sometimes a jlong is a C "long" and sometimes it is a C "long long": 
>> 
>> #ifndef _JAVASOFT_JNI_MD_H_
>> #define _JAVASOFT_JNI_MD_H_
>> 
>> #define JNIEXPORT
>> #define JNIIMPORT
>> #define JNICALL
>> 
>> typedef int jint;
>> #ifdef _LP64 /* 64-bit Solaris */
>> typedef long jlong;
>> #else
>> typedef long long jlong;
>> #endif
>> 
>> typedef signed char jbyte;
>> 
>> #endif /* !_JAVASOFT_JNI_MD_H_ */
>> 
>> 
>> 
>> Whereas Apple's JDK 6 always uses "long long":
>> 
>> 
>> 
>> #ifndef _JAVASOFT_JNI_MD_H_
>> #define _JAVASOFT_JNI_MD_H_
>> 
>> #define JNIEXPORT __attribute__((visibility("default")))
>> #define JNIIMPORT
>> #define JNICALL
>> 
>> #if defined(__LP64__) && __LP64__ /* for -Wundef */
>> typedef int jint;
>> #else
>> typedef long jint;
>> #endif
>> typedef long long jlong;
>> typedef signed char jbyte;
>> 
>> #endif /* !_JAVASOFT_JNI_MD_H_ */
> 
> Have you filed a bug at <http://bugs.sun.com>?

Just?  I filed it against "javah" since there was no more appropriate category available.


Scott


From brent.christian at oracle.com  Tue Nov 13 14:50:59 2012
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 13 Nov 2012 14:50:59 -0800
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
Message-ID: <50A2CED3.3080701@oracle.com>

At present, the JDK port for OS X gets its value for os.name from a JRS 
function exported by the Apple Java Runtime Support framework.

Historically this has either been "Mac OS X", or "Mac OS X Server", but 
there have been reports that this could change at any time, e.g.
to just "OS X".  This would break any app that relies on this property
to detect the Mac platform using something like:

System.getProperty("os.name").startsWith("Mac").

To ensure compatibility going forward, the os.name System property on 
Mac should be hard-coded to the value that is expected, "Mac OS X". 
(FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of the 
OS).

Webrev is here:
http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/

Note: the setUnknownOSAndVersion() function is unused following my 
change, so I went ahead and removed it.

Thanks,
-Brent

From Sergey.Bylokhov at oracle.com  Tue Nov 13 17:05:22 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Nov 2012 05:05:22 +0400
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <50A2CED3.3080701@oracle.com>
References: <50A2CED3.3080701@oracle.com>
Message-ID: <50A2EE52.1020604@oracle.com>

So many efforts was done to unify this style across the jdk
http://monaco.sfbay.sun.com/detail.jsf?cr=7147461
http://monaco.sfbay.sun.com/detail.jsf?cr=7130404
changesets
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/77b35c5c4b95
http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/970cbbba54b0
http://closedjdk.us.oracle.com/hsx/hotspot-rt/hotspot/test/closed/rev/40505e5a55e8

Note that official documentation from apple suggest: contains("OS X")
https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html

14.11.2012 2:50, Brent Christian wrote:
> At present, the JDK port for OS X gets its value for os.name from a 
> JRS function exported by the Apple Java Runtime Support framework.
>
> Historically this has either been "Mac OS X", or "Mac OS X Server", 
> but there have been reports that this could change at any time, e.g.
> to just "OS X".  This would break any app that relies on this property
> to detect the Mac platform using something like:
>
> System.getProperty("os.name").startsWith("Mac").
>
> To ensure compatibility going forward, the os.name System property on 
> Mac should be hard-coded to the value that is expected, "Mac OS X". 
> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of 
> the OS).
>
> Webrev is here:
> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>
> Note: the setUnknownOSAndVersion() function is unused following my 
> change, so I went ahead and removed it.
>
> Thanks,
> -Brent


-- 
Best regards, Sergey.


From Alan.Bateman at oracle.com  Wed Nov 14 01:59:34 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Nov 2012 09:59:34 +0000
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <50A2CED3.3080701@oracle.com>
References: <50A2CED3.3080701@oracle.com>
Message-ID: <50A36B86.3010709@oracle.com>

On 13/11/2012 22:50, Brent Christian wrote:
> At present, the JDK port for OS X gets its value for os.name from a 
> JRS function exported by the Apple Java Runtime Support framework.
>
> Historically this has either been "Mac OS X", or "Mac OS X Server", 
> but there have been reports that this could change at any time, e.g.
> to just "OS X".  This would break any app that relies on this property
> to detect the Mac platform using something like:
>
> System.getProperty("os.name").startsWith("Mac").
>
> To ensure compatibility going forward, the os.name System property on 
> Mac should be hard-coded to the value that is expected, "Mac OS X". 
> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of 
> the OS).
>
> Webrev is here:
> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>
> Note: the setUnknownOSAndVersion() function is unused following my 
> change, so I went ahead and removed it.
>
> Thanks,
> -Brent
This might be a question for the MacOSX folks but is it safe to continue 
to depend on JavaRuntimeSupport period? I'm just wondering if we really 
need to use it to determine the OS version and locale?

-Alan.

From Sergey.Bylokhov at oracle.com  Wed Nov 14 07:14:25 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Nov 2012 19:14:25 +0400
Subject: [8] Request for review: 7154516 [macosx] Popup menus have no visible
	borders
Message-ID: <50A3B551.7040707@oracle.com>

Hi.
Please review the fix for 7154516 [macosx] Popup menus have no visible 
borders
This is direct forward port from jdk7.

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

-- 
Best regards, Sergey.


From anthony.petrov at oracle.com  Wed Nov 14 08:15:00 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 14 Nov 2012 20:15:00 +0400
Subject: [8] Request for review: 7154516 [macosx] Popup menus have no
	visible borders
In-Reply-To: <50A3B551.7040707@oracle.com>
References: <50A3B551.7040707@oracle.com>
Message-ID: <50A3C384.6030503@oracle.com>

Looks good.

--
best regards,
Anthony

On 11/14/2012 7:14 PM, Sergey Bylokhov wrote:
> Hi.
> Please review the fix for 7154516 [macosx] Popup menus have no visible 
> borders
> This is direct forward port from jdk7.
> 
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154516
> Webrev can be found at: 
> http://cr.openjdk.java.net/~dcherepanov/7154516/webrev.0/
> 

From tobi at ultramixer.com  Wed Nov 14 09:57:38 2012
From: tobi at ultramixer.com (Tobi)
Date: Wed, 14 Nov 2012 18:57:38 +0100
Subject: JavaFX: Stage and Unified Toolbars on Mac (apple.awt.brushMetalLook
	for JavaFX)
In-Reply-To: <50A3C384.6030503@oracle.com>
References: <50A3B551.7040707@oracle.com> <50A3C384.6030503@oracle.com>
Message-ID: <FC0C16A8-F5F3-40DA-A2AF-FF90936F08D1@ultramixer.com>

Hi,

how can I make an JavaFX app with an unified toolbar like on Swing with "apple.awt.brushMetalLook"

There was a discussion a few month ago here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-February/000776.html

Any news about this feature?

Best regards,
Tobi


From naoto.sato at oracle.com  Wed Nov 14 10:08:33 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 14 Nov 2012 10:08:33 -0800
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <50A36B86.3010709@oracle.com>
References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com>
Message-ID: <50A3DE21.8050406@oracle.com>

As to the default locale detection, we need to call JavaRuntimeSupport. 
MacOSX's POSIX calls do not return user's preferred language/format 
settings.

Naoto

On 11/14/12 1:59 AM, Alan Bateman wrote:
> On 13/11/2012 22:50, Brent Christian wrote:
>> At present, the JDK port for OS X gets its value for os.name from a
>> JRS function exported by the Apple Java Runtime Support framework.
>>
>> Historically this has either been "Mac OS X", or "Mac OS X Server",
>> but there have been reports that this could change at any time, e.g.
>> to just "OS X". This would break any app that relies on this property
>> to detect the Mac platform using something like:
>>
>> System.getProperty("os.name").startsWith("Mac").
>>
>> To ensure compatibility going forward, the os.name System property on
>> Mac should be hard-coded to the value that is expected, "Mac OS X".
>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of
>> the OS).
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>>
>> Note: the setUnknownOSAndVersion() function is unused following my
>> change, so I went ahead and removed it.
>>
>> Thanks,
>> -Brent
> This might be a question for the MacOSX folks but is it safe to continue
> to depend on JavaRuntimeSupport period? I'm just wondering if we really
> need to use it to determine the OS version and locale?
>
> -Alan.


From david.dehaven at oracle.com  Wed Nov 14 10:21:01 2012
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 14 Nov 2012 10:21:01 -0800
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <50A3DE21.8050406@oracle.com>
References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com>
	<50A3DE21.8050406@oracle.com>
Message-ID: <4AB803E2-DEA0-420A-A321-78F2B90332EF@oracle.com>


Why not just use CFLocale and call CFLocaleCopyCurrent?

https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFLocaleRef/Reference/reference.html#//apple_ref/c/func/CFLocaleCopyCurrent

-DrD-

> As to the default locale detection, we need to call JavaRuntimeSupport. MacOSX's POSIX calls do not return user's preferred language/format settings.
> 
> Naoto
> 
> On 11/14/12 1:59 AM, Alan Bateman wrote:
>> On 13/11/2012 22:50, Brent Christian wrote:
>>> At present, the JDK port for OS X gets its value for os.name from a
>>> JRS function exported by the Apple Java Runtime Support framework.
>>> 
>>> Historically this has either been "Mac OS X", or "Mac OS X Server",
>>> but there have been reports that this could change at any time, e.g.
>>> to just "OS X". This would break any app that relies on this property
>>> to detect the Mac platform using something like:
>>> 
>>> System.getProperty("os.name").startsWith("Mac").
>>> 
>>> To ensure compatibility going forward, the os.name System property on
>>> Mac should be hard-coded to the value that is expected, "Mac OS X".
>>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of
>>> the OS).
>>> 
>>> Webrev is here:
>>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>>> 
>>> Note: the setUnknownOSAndVersion() function is unused following my
>>> change, so I went ahead and removed it.
>>> 
>>> Thanks,
>>> -Brent
>> This might be a question for the MacOSX folks but is it safe to continue
>> to depend on JavaRuntimeSupport period? I'm just wondering if we really
>> need to use it to determine the OS version and locale?
>> 
>> -Alan.
> 


From swingler at apple.com  Wed Nov 14 10:26:17 2012
From: swingler at apple.com (Mike Swingler)
Date: Wed, 14 Nov 2012 10:26:17 -0800
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <50A36B86.3010709@oracle.com>
References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com>
Message-ID: <E9AC129D-70F9-4584-ACCB-D557C210200B@apple.com>

On Nov 14, 2012, at 1:59 AM, Alan Bateman <Alan.Bateman at ORACLE.COM> wrote:

> On 13/11/2012 22:50, Brent Christian wrote:
>> At present, the JDK port for OS X gets its value for os.name from a JRS function exported by the Apple Java Runtime Support framework.
>> 
>> Historically this has either been "Mac OS X", or "Mac OS X Server", but there have been reports that this could change at any time, e.g.
>> to just "OS X".  This would break any app that relies on this property
>> to detect the Mac platform using something like:
>> 
>> System.getProperty("os.name").startsWith("Mac").
>> 
>> To ensure compatibility going forward, the os.name System property on Mac should be hard-coded to the value that is expected, "Mac OS X". (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of the OS).
>> 
>> Webrev is here:
>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>> 
>> Note: the setUnknownOSAndVersion() function is unused following my change, so I went ahead and removed it.
>> 
>> Thanks,
>> -Brent
> This might be a question for the MacOSX folks but is it safe to continue to depend on JavaRuntimeSupport period? I'm just wondering if we really need to use it to determine the OS version and locale?

JavaRuntimeSupport.framework was explicitly created to make API for OpenJDK and 3rd party JVMs to do everything that the Apple Java SE 6 did using private SPI. To prove that it worked, we re-implemented Java SE 6 on top of it. It's purpose is to expose a stable API for functionality that is generally inappropriate for Cocoa applications, but is necessary for the Java to cooperate with the OS X graphical environment.

We currently have no plans to expand JavaRuntimeSupport, and no plans to deprecate it.

Regards,
Mike Swingler
Apple Inc.


From naoto.sato at oracle.com  Wed Nov 14 10:30:09 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 14 Nov 2012 10:30:09 -0800
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <4AB803E2-DEA0-420A-A321-78F2B90332EF@oracle.com>
References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com>
	<50A3DE21.8050406@oracle.com>
	<4AB803E2-DEA0-420A-A321-78F2B90332EF@oracle.com>
Message-ID: <50A3E331.40209@oracle.com>

We do use CFLocale for the default format locale detection, which is 
used for formatting Date/Time/Number etc. Users can specify different 
language from it for the UI language, such as menu/button/etc, which can 
(I think) only be retrieved with that JRS function.

Naoto

On 11/14/12 10:21 AM, David DeHaven wrote:
>
> Why not just use CFLocale and call CFLocaleCopyCurrent?
>
> https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFLocaleRef/Reference/reference.html#//apple_ref/c/func/CFLocaleCopyCurrent
>
> -DrD-
>
>> As to the default locale detection, we need to call JavaRuntimeSupport. MacOSX's POSIX calls do not return user's preferred language/format settings.
>>
>> Naoto
>>
>> On 11/14/12 1:59 AM, Alan Bateman wrote:
>>> On 13/11/2012 22:50, Brent Christian wrote:
>>>> At present, the JDK port for OS X gets its value for os.name from a
>>>> JRS function exported by the Apple Java Runtime Support framework.
>>>>
>>>> Historically this has either been "Mac OS X", or "Mac OS X Server",
>>>> but there have been reports that this could change at any time, e.g.
>>>> to just "OS X". This would break any app that relies on this property
>>>> to detect the Mac platform using something like:
>>>>
>>>> System.getProperty("os.name").startsWith("Mac").
>>>>
>>>> To ensure compatibility going forward, the os.name System property on
>>>> Mac should be hard-coded to the value that is expected, "Mac OS X".
>>>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of
>>>> the OS).
>>>>
>>>> Webrev is here:
>>>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>>>>
>>>> Note: the setUnknownOSAndVersion() function is unused following my
>>>> change, so I went ahead and removed it.
>>>>
>>>> Thanks,
>>>> -Brent
>>> This might be a question for the MacOSX folks but is it safe to continue
>>> to depend on JavaRuntimeSupport period? I'm just wondering if we really
>>> need to use it to determine the OS version and locale?
>>>
>>> -Alan.
>>
>


From brent.christian at oracle.com  Wed Nov 14 13:23:58 2012
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 14 Nov 2012 13:23:58 -0800
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <50A2EE52.1020604@oracle.com>
References: <50A2CED3.3080701@oracle.com> <50A2EE52.1020604@oracle.com>
Message-ID: <50A40BEE.2030205@oracle.com>

Thanks, Sergey.

It's good that we standardized on the recommended usage within the JDK 
in order to stay ahead of a possible change to the value of ProductName 
in /System/Library/CoreServices/SystemVersion.plist

But we can expect that Java application developers use the same variety 
of OS platform checks.  Which is why we should maintain the current 
value (versus risking apps breaking in the event of a change in 
ProductName used by OS X), especially considering that it works fine 
with the recommended osName.contains("OS X").

As is suggested in the bug report, if the Mac's OS changes so radically 
that we should be reporting a new os.name ("Mac OS XI", or who knows 
what), we will almost certainly need to update the JDK to run on it, at 
which time we can also change the value of os.name.

Thanks,
-Brent

On 11/13/12 5:05 PM, Sergey Bylokhov wrote:
> So many efforts was done to unify this style across the jdk
> http://monaco.sfbay.sun.com/detail.jsf?cr=7147461
> http://monaco.sfbay.sun.com/detail.jsf?cr=7130404
> changesets
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/77b35c5c4b95
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/970cbbba54b0
> http://closedjdk.us.oracle.com/hsx/hotspot-rt/hotspot/test/closed/rev/40505e5a55e8
>
>
> Note that official documentation from apple suggest: contains("OS X")
> https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html
>
> 14.11.2012 2:50, Brent Christian wrote:
>> At present, the JDK port for OS X gets its value for os.name from a
>> JRS function exported by the Apple Java Runtime Support framework.
>>
>> Historically this has either been "Mac OS X", or "Mac OS X Server",
>> but there have been reports that this could change at any time, e.g.
>> to just "OS X".  This would break any app that relies on this property
>> to detect the Mac platform using something like:
>>
>> System.getProperty("os.name").startsWith("Mac").
>>
>> To ensure compatibility going forward, the os.name System property on
>> Mac should be hard-coded to the value that is expected, "Mac OS X".
>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of
>> the OS).
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>>
>> Note: the setUnknownOSAndVersion() function is unused following my
>> change, so I went ahead and removed it.
>>
>> Thanks,
>> -Brent
>
>

From Alan.Bateman at oracle.com  Wed Nov 14 14:06:17 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Nov 2012 22:06:17 +0000
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <E9AC129D-70F9-4584-ACCB-D557C210200B@apple.com>
References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com>
	<E9AC129D-70F9-4584-ACCB-D557C210200B@apple.com>
Message-ID: <50A415D9.9070903@oracle.com>

On 14/11/2012 18:26, Mike Swingler wrote:
> :
> JavaRuntimeSupport.framework was explicitly created to make API for OpenJDK and 3rd party JVMs to do everything that the Apple Java SE 6 did using private SPI. To prove that it worked, we re-implemented Java SE 6 on top of it. It's purpose is to expose a stable API for functionality that is generally inappropriate for Cocoa applications, but is necessary for the Java to cooperate with the OS X graphical environment.
>
> We currently have no plans to expand JavaRuntimeSupport, and no plans to deprecate it.
>
> Regards,
> Mike Swingler
> Apple Inc.
Thank you for the clear statement, this is exactly what we needed as the 
status of JavaRuntimeSupport.framework was not clear (at least not to me).

-Alan

From artem.ananiev at oracle.com  Thu Nov 15 01:09:38 2012
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 15 Nov 2012 13:09:38 +0400
Subject: JavaFX: Stage and Unified Toolbars on Mac
	(apple.awt.brushMetalLook for JavaFX)
In-Reply-To: <FC0C16A8-F5F3-40DA-A2AF-FF90936F08D1@ultramixer.com>
References: <50A3B551.7040707@oracle.com> <50A3C384.6030503@oracle.com>
	<FC0C16A8-F5F3-40DA-A2AF-FF90936F08D1@ultramixer.com>
Message-ID: <50A4B152.2040601@oracle.com>

Hi, Tobi,

On 11/14/2012 9:57 PM, Tobi wrote:
> Hi,
>
> how can I make an JavaFX app with an unified toolbar like on Swing
> with "apple.awt.brushMetalLook"

this functionality is currently not supported in JavaFX. Corresponding 
JIRA issue is

http://javafx-jira.kenai.com/browse/RT-19834

It depends on another one, RT-19988, which you are already subscribed to.

> There was a discussion a few month ago here:
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-February/000776.html
>
>  Any news about this feature?

It's still targeted to 8, this is what I can say right now :)

Thanks,

Artem

> Best regards,
> Tobi

From swpalmer at gmail.com  Fri Nov 16 06:21:46 2012
From: swpalmer at gmail.com (Scott Palmer)
Date: Fri, 16 Nov 2012 09:21:46 -0500
Subject: Something is wrong with JNI's jlong in JDK7
In-Reply-To: <AF409584-029B-44BB-AB32-D76234A29B7B@gmail.com>
References: <2BFCD800-D49D-41F9-A066-8DCDB6401AF1@gmail.com>
	<76E78E92-9EF9-4016-9F4A-AC0AA5AC1F16@apple.com>
	<AF409584-029B-44BB-AB32-D76234A29B7B@gmail.com>
Message-ID: <6344C77F-E6E6-4975-BD29-858AB2EDEE16@gmail.com>

On 2012-11-13, at 5:00 PM, Scott Palmer <swpalmer at gmail.com> wrote:

> On 2012-11-13, at 4:36 PM, Mike Swingler <swingler at apple.com> wrote:
> 
>> On Nov 13, 2012, at 8:21 AM, Scott Palmer <swpalmer at gmail.com> wrote:
>> 
>>> I just noticed that the criteria for defining jlong has changed from that given in Apple's JDK 6 vs. Oracle's JDK 7.  This caused some code of mine to break because it seems to be wrong under some circumstances.
>>> 
>>> JDK 7u10 has this.  Note that sometimes a jlong is a C "long" and sometimes it is a C "long long": 
>>> 
>>> #ifndef _JAVASOFT_JNI_MD_H_
>>> #define _JAVASOFT_JNI_MD_H_
>>> 
>>> #define JNIEXPORT
>>> #define JNIIMPORT
>>> #define JNICALL
>>> 
>>> typedef int jint;
>>> #ifdef _LP64 /* 64-bit Solaris */
>>> typedef long jlong;
>>> #else
>>> typedef long long jlong;
>>> #endif
>>> 
>>> typedef signed char jbyte;
>>> 
>>> #endif /* !_JAVASOFT_JNI_MD_H_ */
>>> 
>>> 
>>> 
>>> Whereas Apple's JDK 6 always uses "long long":
>>> 
>>> 
>>> 
>>> #ifndef _JAVASOFT_JNI_MD_H_
>>> #define _JAVASOFT_JNI_MD_H_
>>> 
>>> #define JNIEXPORT __attribute__((visibility("default")))
>>> #define JNIIMPORT
>>> #define JNICALL
>>> 
>>> #if defined(__LP64__) && __LP64__ /* for -Wundef */
>>> typedef int jint;
>>> #else
>>> typedef long jint;
>>> #endif
>>> typedef long long jlong;
>>> typedef signed char jbyte;
>>> 
>>> #endif /* !_JAVASOFT_JNI_MD_H_ */
>> 
>> Have you filed a bug at <http://bugs.sun.com>?
> 
> Just?  I filed it against "javah" since there was no more appropriate category available.
> 

Just in case anyone is wondering why this matters.  The C++ linkage breaks because func(long) - a method taking the Java 7 version of jlong, and func(long long) a method taking the Java 6 version of jlong, are considered different, even though both types are 8 bytes.  C++ name mangling comes out different.

We have a Java project that uses a lot of native code and depends a lot on a plugin mechanism where the plugins need to link with a native library we provide as well.  When our library is compiled with Java 6 headers, plugins compiled against Java 7 headers can't link with it.

I neglected to point that out in my bug report (Review ID: 2381559), and I have not yet got any confirmation that it was accepted.

Scott


From Sergey.Bylokhov at oracle.com  Fri Nov 16 08:45:21 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Nov 2012 20:45:21 +0400
Subject: [8] Request for review: 7124219 [macosx] Unable to draw images to
	fullscreen
Message-ID: <50A66DA1.1060107@oracle.com>

Hi Everyone,
Please review the fix.
This is not a direct forward port from jdk 7.

Changes description:
1 All stuff related to the backbuffer now located in CGLGraphicsConfig. 
Implementation was synchronized with the version on windows and linux.
2 LWCanvasPeer, LWWindowPeer , CPlatform.... : all code related to the 
backbuffer was removed.
3 One general interface was added: LWGraphicsConfig. It is used in LWAWT.
4 Outdated documentation was removed/moved to LWGraphicsConfig.

Tested: jck, awt/2d regression, guimark2. No new issues found.

Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124219
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124552
Webrev can be found at: http://cr.openjdk.java.net/~serb/7124219/webrev.00
JDK7 changesets:
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/0dac7f8b4282
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/ecbd4c9fc9c1

-- 
Best regards, Sergey.

From brent.christian at oracle.com  Fri Nov 16 09:32:52 2012
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 16 Nov 2012 09:32:52 -0800
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <50A40BEE.2030205@oracle.com>
References: <50A2CED3.3080701@oracle.com> <50A2EE52.1020604@oracle.com>
	<50A40BEE.2030205@oracle.com>
Message-ID: <50A678C4.6070207@oracle.com>

Any more comments on this?

-Brent

On 11/14/12 1:23 PM, Brent Christian wrote:
> Thanks, Sergey.
>
> It's good that we standardized on the recommended usage within the JDK
> in order to stay ahead of a possible change to the value of ProductName
> in /System/Library/CoreServices/SystemVersion.plist
>
> But we can expect that Java application developers use the same variety
> of OS platform checks.  Which is why we should maintain the current
> value (versus risking apps breaking in the event of a change in
> ProductName used by OS X), especially considering that it works fine
> with the recommended osName.contains("OS X").
>
> As is suggested in the bug report, if the Mac's OS changes so radically
> that we should be reporting a new os.name ("Mac OS XI", or who knows
> what), we will almost certainly need to update the JDK to run on it, at
> which time we can also change the value of os.name.
>
> Thanks,
> -Brent
>
> On 11/13/12 5:05 PM, Sergey Bylokhov wrote:
>> So many efforts was done to unify this style across the jdk
>> http://monaco.sfbay.sun.com/detail.jsf?cr=7147461
>> http://monaco.sfbay.sun.com/detail.jsf?cr=7130404
>> changesets
>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/77b35c5c4b95
>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/970cbbba54b0
>> http://closedjdk.us.oracle.com/hsx/hotspot-rt/hotspot/test/closed/rev/40505e5a55e8
>>
>>
>>
>> Note that official documentation from apple suggest: contains("OS X")
>> https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html
>>
>> 14.11.2012 2:50, Brent Christian wrote:
>>> At present, the JDK port for OS X gets its value for os.name from a
>>> JRS function exported by the Apple Java Runtime Support framework.
>>>
>>> Historically this has either been "Mac OS X", or "Mac OS X Server",
>>> but there have been reports that this could change at any time, e.g.
>>> to just "OS X".  This would break any app that relies on this property
>>> to detect the Mac platform using something like:
>>>
>>> System.getProperty("os.name").startsWith("Mac").
>>>
>>> To ensure compatibility going forward, the os.name System property on
>>> Mac should be hard-coded to the value that is expected, "Mac OS X".
>>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of
>>> the OS).
>>>
>>> Webrev is here:
>>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>>>
>>> Note: the setUnknownOSAndVersion() function is unused following my
>>> change, so I went ahead and removed it.
>>>
>>> Thanks,
>>> -Brent
>>
>>

From mandy.chung at oracle.com  Fri Nov 16 12:46:54 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 16 Nov 2012 12:46:54 -0800
Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac
In-Reply-To: <50A678C4.6070207@oracle.com>
References: <50A2CED3.3080701@oracle.com> <50A2EE52.1020604@oracle.com>
	<50A40BEE.2030205@oracle.com> <50A678C4.6070207@oracle.com>
Message-ID: <50A6A63E.80708@oracle.com>

Looks good to me.  I can push it for you.   Who are the reviewers 
besides me (it wasn't clear to me from the thread)?

Mandy

On 11/16/12 9:32 AM, Brent Christian wrote:
> Any more comments on this?
>
> -Brent
>
> On 11/14/12 1:23 PM, Brent Christian wrote:
>> Thanks, Sergey.
>>
>> It's good that we standardized on the recommended usage within the JDK
>> in order to stay ahead of a possible change to the value of ProductName
>> in /System/Library/CoreServices/SystemVersion.plist
>>
>> But we can expect that Java application developers use the same variety
>> of OS platform checks.  Which is why we should maintain the current
>> value (versus risking apps breaking in the event of a change in
>> ProductName used by OS X), especially considering that it works fine
>> with the recommended osName.contains("OS X").
>>
>> As is suggested in the bug report, if the Mac's OS changes so radically
>> that we should be reporting a new os.name ("Mac OS XI", or who knows
>> what), we will almost certainly need to update the JDK to run on it, at
>> which time we can also change the value of os.name.
>>
>> Thanks,
>> -Brent
>>
>> On 11/13/12 5:05 PM, Sergey Bylokhov wrote:
>>> So many efforts was done to unify this style across the jdk
>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7147461
>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7130404
>>> changesets
>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/77b35c5c4b95
>>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/970cbbba54b0
>>> http://closedjdk.us.oracle.com/hsx/hotspot-rt/hotspot/test/closed/rev/40505e5a55e8 
>>>
>>>
>>>
>>>
>>> Note that official documentation from apple suggest: contains("OS X")
>>> https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html
>>>
>>> 14.11.2012 2:50, Brent Christian wrote:
>>>> At present, the JDK port for OS X gets its value for os.name from a
>>>> JRS function exported by the Apple Java Runtime Support framework.
>>>>
>>>> Historically this has either been "Mac OS X", or "Mac OS X Server",
>>>> but there have been reports that this could change at any time, e.g.
>>>> to just "OS X".  This would break any app that relies on this property
>>>> to detect the Mac platform using something like:
>>>>
>>>> System.getProperty("os.name").startsWith("Mac").
>>>>
>>>> To ensure compatibility going forward, the os.name System property on
>>>> Mac should be hard-coded to the value that is expected, "Mac OS X".
>>>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of
>>>> the OS).
>>>>
>>>> Webrev is here:
>>>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/
>>>>
>>>> Note: the setUnknownOSAndVersion() function is unused following my
>>>> change, so I went ahead and removed it.
>>>>
>>>> Thanks,
>>>> -Brent
>>>
>>>


From anthony.petrov at oracle.com  Tue Nov 20 02:39:31 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 20 Nov 2012 14:39:31 +0400
Subject: [8] Request for review: 7124219 [macosx] Unable to draw images
	to fullscreen
In-Reply-To: <50A66DA1.1060107@oracle.com>
References: <50A66DA1.1060107@oracle.com>
Message-ID: <50AB5DE3.7040009@oracle.com>

Nice refactoring. The fix looks good to me.

--
best regards,
Anthony

On 11/16/2012 8:45 PM, Sergey Bylokhov wrote:
> Hi Everyone,
> Please review the fix.
> This is not a direct forward port from jdk 7.
> 
> Changes description:
> 1 All stuff related to the backbuffer now located in CGLGraphicsConfig. 
> Implementation was synchronized with the version on windows and linux.
> 2 LWCanvasPeer, LWWindowPeer , CPlatform.... : all code related to the 
> backbuffer was removed.
> 3 One general interface was added: LWGraphicsConfig. It is used in LWAWT.
> 4 Outdated documentation was removed/moved to LWGraphicsConfig.
> 
> Tested: jck, awt/2d regression, guimark2. No new issues found.
> 
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124219
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124552
> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124219/webrev.00
> JDK7 changesets:
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/0dac7f8b4282
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/ecbd4c9fc9c1
> 

From andrew.brygin at oracle.com  Tue Nov 20 07:58:40 2012
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Tue, 20 Nov 2012 19:58:40 +0400
Subject: [OpenJDK 2D-Dev] [8] Request for review: 7124219 [macosx] Unable
	to draw images to fullscreen
In-Reply-To: <50A66DA1.1060107@oracle.com>
References: <50A66DA1.1060107@oracle.com>
Message-ID: <50ABA8B0.6060009@oracle.com>

Hi Sergey,

  the change looks fine to me.

Thanks,
Andrew

On 16.11.2012 20:45, Sergey Bylokhov wrote:
> Hi Everyone,
> Please review the fix.
> This is not a direct forward port from jdk 7.
>
> Changes description:
> 1 All stuff related to the backbuffer now located in 
> CGLGraphicsConfig. Implementation was synchronized with the version on 
> windows and linux.
> 2 LWCanvasPeer, LWWindowPeer , CPlatform.... : all code related to the 
> backbuffer was removed.
> 3 One general interface was added: LWGraphicsConfig. It is used in LWAWT.
> 4 Outdated documentation was removed/moved to LWGraphicsConfig.
>
> Tested: jck, awt/2d regression, guimark2. No new issues found.
>
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124219
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124552
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/7124219/webrev.00
> JDK7 changesets:
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/0dac7f8b4282
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/ecbd4c9fc9c1
>


From paul_t100 at fastmail.fm  Thu Nov 22 12:10:15 2012
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Thu, 22 Nov 2012 20:10:15 +0000
Subject: file.encoding vs. sun.jnu.encoding(?) on OS X
In-Reply-To: <509D0135.8000406@oracle.com>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
	<509D0135.8000406@oracle.com>
Message-ID: <50AE86A7.5040907@fastmail.fm>

On 09/11/2012 13:12, Alan Bateman wrote:
> On 08/11/2012 19:25, Scott Kovatch wrote:
>> Hello,
>>
>> I want to bring up something that is causing a lot of confusion, and 
>> is generating a lot of bugs on OS X.
>>
>> What is the relationship between path names and file.encoding? Or, 
>> maybe more correctly, _why_ is there some relationship between path 
>> names and file.encoding? On OS X filenames are ALWAYS in UTF-8, so 
>> the current locale should never come into play.
>>
>> I was about to launch into a discussion (rant) about our use of 
>> nl_langinfo(CODESET) for file.encoding, but the more I look into it, 
>> I don't think that's the problem, though you can also make a case 
>> that all text files on OS X are UTF-8 by default as well. I'm 
>> wondering if this has something to do with sun.jnu.encoding being set 
>> to the same value as file.encoding.
>>
>> -- Scott K.
>>
> I've seen several mails on macosx-port-dev about this, although I 
> think several issues have been conflated which makes for confusing 
> reading.
>
> One of the issues is that HFS normalizes to a variant of NFD and the 
> changes that came via the Mac port weren't right. Sherman has 
> re-implemented this via 7130915 in jdk8 and it has been back-ported to 
> 7u for 7u12. We've had confirmation from several people that this 
> resolves the issues that they were seeing.
>
> The other issue, and I think the issue that you are trying to get at, 
> is that sun.jnu.encoding is being set based on the locale whereas you 
> are saying that it should always be UTF-8 on Mac. I think we need to 
> create a bug on that and it would be great if you can get technical 
> references so that we know this is the right thing to do. There are at 
> least two places in the property initialization that would need to be 
> updated to do this. I don't think we should change file.encoding as 
> that would change the default encoding for the file contents whereas 
> the issues all seem to related to the encoding/decoding of file names.
>
> The final issue is just consistent use of sun.jnu.encoding. This 
> property was originally only used for Windows but now we have cases 
> where it may different to file.encoding on other platforms. Sherman 
> brought up 7050570, which is addressing something different again but 
> part of it does fix up the new file system API to use 
> sun.jnu.encoding. I haven't seen any mails on macosx-port-dev that 
> look like this issue but we should get it in anyway (Sherman - you ask 
> why I hadn't pushed that several months ago, sorry, it's been on my 
> list as a low priority item and low priority items have been starved 
> of cycles).
>
> -Alan.
>
Just tried the latest ea release

macbook:songkong paul$ java -version
java version "1.7.0_12-ea"
Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b02)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b25, mixed mode)


and Im still getting a problem that files containing certain chars are 
not failing file.exists();

Is this the issue discussed that is meant to be fixed in 7u12 ?

This is the one bug in the Java 7 port that I need to resolve one way or 
the other before I can release my software so Id appreciate a definitive 
reply to this.

Also do you have an eta for when 7u10 final , and 7u12 final will be 
available ?


Paul

From Alan.Bateman at oracle.com  Thu Nov 22 13:45:00 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 22 Nov 2012 21:45:00 +0000
Subject: file.encoding vs. sun.jnu.encoding(?) on OS X
In-Reply-To: <50AE86A7.5040907@fastmail.fm>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
	<509D0135.8000406@oracle.com> <50AE86A7.5040907@fastmail.fm>
Message-ID: <50AE9CDC.2090503@oracle.com>

On 22/11/2012 20:10, Paul Taylor wrote:
> :
>
> Just tried the latest ea release
>
> macbook:songkong paul$ java -version
> java version "1.7.0_12-ea"
> Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b25, mixed mode)
>
>
> and Im still getting a problem that files containing certain chars are 
> not failing file.exists();
>
> Is this the issue discussed that is meant to be fixed in 7u12 ?
7130915 is fixed in 7u12, 8003228 is not. As I said in the previous 
mail, I think these issues have been mixed up (for understandable reasons).

For 8003228 then we need to get an authoritative reference before fixing 
the value of sun.jnu.encoding to UTF-8. Scott may be able to provide 
this. In the mean-time then setting your locale appropriately is the 
workaround.

> :
>
> Also do you have an eta for when 7u10 final , and 7u12 final will be 
> available ?

I just checked the 7u12 page [1] and it doesn't look like a GA date has 
been published yet.

-Alan

[1] http://openjdk.java.net/projects/jdk7u/releases/7u12.html


From paul_t100 at fastmail.fm  Thu Nov 22 14:28:56 2012
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Thu, 22 Nov 2012 22:28:56 +0000
Subject: file.encoding vs. sun.jnu.encoding(?) on OS X
In-Reply-To: <50AE9CDC.2090503@oracle.com>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
	<509D0135.8000406@oracle.com> <50AE86A7.5040907@fastmail.fm>
	<50AE9CDC.2090503@oracle.com>
Message-ID: <50AEA728.9060903@fastmail.fm>

On 22/11/2012 21:45, Alan Bateman wrote:
> On 22/11/2012 20:10, Paul Taylor wrote:
>> :
>>
>> Just tried the latest ea release
>>
>> macbook:songkong paul$ java -version
>> java version "1.7.0_12-ea"
>> Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b02)
>> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b25, mixed mode)
>>
>>
>> and Im still getting a problem that files containing certain chars 
>> are not failing file.exists();
>>
>> Is this the issue discussed that is meant to be fixed in 7u12 ?
> 7130915 is fixed in 7u12, 8003228 is not. As I said in the previous 
> mail, I think these issues have been mixed up (for understandable 
> reasons).
>
> For 8003228 then we need to get an authoritative reference before 
> fixing the value of sun.jnu.encoding to UTF-8. Scott may be able to 
> provide this. In the mean-time then setting your locale appropriately 
> is the workaround.

Thanks Alan

But confused, I think 7130915 is the problem I'm having however it isn't 
fixed in the latest version of 7u12 (build 2) according to my testing.
Maybe it is fixed in a as yet unreleased build of 7u12, unfortunately I 
was looking to do a release within a couple of weeks assuming so may 
have to ship with 7u10 (looks like should be released about then) is 
there a workaround
I can use in the meantime, does this  sun.jnu.encoding workaround fix 
this issue, I'm using appbundler rather than webstart so I assume I can 
use this if it works.

I cannot even find 8003228 in the bug tracker.

Paul


From Alan.Bateman at oracle.com  Fri Nov 23 01:45:34 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 23 Nov 2012 09:45:34 +0000
Subject: file.encoding vs. sun.jnu.encoding(?) on OS X
In-Reply-To: <50AEA728.9060903@fastmail.fm>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
	<509D0135.8000406@oracle.com> <50AE86A7.5040907@fastmail.fm>
	<50AE9CDC.2090503@oracle.com> <50AEA728.9060903@fastmail.fm>
Message-ID: <50AF45BE.1020707@oracle.com>

On 22/11/2012 22:28, Paul Taylor wrote:
> :
>
> But confused, I think 7130915 is the problem I'm having however it 
> isn't fixed in the latest version of 7u12 (build 2) according to my 
> testing.
> Maybe it is fixed in a as yet unreleased build of 7u12, unfortunately 
> I was looking to do a release within a couple of weeks assuming so may 
> have to ship with 7u10 (looks like should be released about then) is 
> there a workaround
Yes, it's there:

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/03b9d0ba2488

and so in 7u12-b01 (and b02 of course).

There are hundreds of fixes in b01, I'm not sure why they aren't listed 
here:

http://download.java.net/jdk7u12/changes/jdk7u12-b01.html


> I can use in the meantime, does this  sun.jnu.encoding workaround fix 
> this issue, I'm using appbundler rather than webstart so I assume I 
> can use this if it works.
I'll have to defer this one to Scott as I don't know whether there is a 
work around for appbundler or webstart. For standalone apps then you can 
set the appropriate locale.
>
> I cannot even find 8003228 in the bug tracker.
I just checked and it turns out to be just bad timing (some maintenance 
going on at bugs.sun.com at the moment, should be up to date later today).

-Alan.

From paul_t100 at fastmail.fm  Fri Nov 23 02:29:38 2012
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Fri, 23 Nov 2012 10:29:38 +0000
Subject: file.encoding vs. sun.jnu.encoding(?) on OS X
In-Reply-To: <50AF45BE.1020707@oracle.com>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
	<509D0135.8000406@oracle.com> <50AE86A7.5040907@fastmail.fm>
	<50AE9CDC.2090503@oracle.com> <50AEA728.9060903@fastmail.fm>
	<50AF45BE.1020707@oracle.com>
Message-ID: <50AF5012.4000807@fastmail.fm>

On 23/11/2012 09:45, Alan Bateman wrote:
> On 22/11/2012 22:28, Paul Taylor wrote:
>> :
>>
>> But confused, I think 7130915 is the problem I'm having however it 
>> isn't fixed in the latest version of 7u12 (build 2) according to my 
>> testing.
>> Maybe it is fixed in a as yet unreleased build of 7u12, unfortunately 
>> I was looking to do a release within a couple of weeks assuming so 
>> may have to ship with 7u10 (looks like should be released about then) 
>> is there a workaround
> Yes, it's there:
>
> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/03b9d0ba2488
>
> and so in 7u12-b01 (and b02 of course).
>
> There are hundreds of fixes in b01, I'm not sure why they aren't 
> listed here:
>
> http://download.java.net/jdk7u12/changes/jdk7u12-b01.html
>
>
>> I can use in the meantime, does this sun.jnu.encoding workaround fix 
>> this issue, I'm using appbundler rather than webstart so I assume I 
>> can use this if it works.
> I'll have to defer this one to Scott as I don't know whether there is 
> a work around for appbundler or webstart. For standalone apps then you 
> can set the appropriate locale.
>>
>> I cannot even find 8003228 in the bug tracker.
> I just checked and it turns out to be just bad timing (some 
> maintenance going on at bugs.sun.com at the moment, should be up to 
> date later today).
>
> -Alan.
>
Alan

Thanks for taking the time, as I'm using appbundler I can configure it 
so gets added to Info.plist, and Info.plist ends up with

<key>JVMOptions</key>
<array>
<string>-Dsun.jnu.encoding=UTF8</string></array>

but I wasnt clear if the encoding thing fixed the problem.

Testing has been confusing as b12-b02 didn't appear to be working but 
then I realized I was checking a file over the network from a nas , if I 
loaded same file from local drive then it did work.
But then I tried rebuilding my app using b10 and rerunning and had same 
results, working localy but not on network.

So Im unclear whether the b12 fix should have fixed issues for file on 
nas, or if that is another issue (that may exist for Java 6)  or only 
local filesystem, and if it is just for local fs why it was still 
working with b10 whihc doesnt have the fix.

Sorry this is so garbled.

Paul





From niagarasoft20-macosxportdev at yahoo.com  Sat Nov 24 09:35:50 2012
From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com)
Date: Sat, 24 Nov 2012 09:35:50 -0800 (PST)
Subject: Bundled .app Splash Splash Screen invocation?
In-Reply-To: <50AF5012.4000807@fastmail.fm>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
	<509D0135.8000406@oracle.com> <50AE86A7.5040907@fastmail.fm>
	<50AE9CDC.2090503@oracle.com> <50AEA728.9060903@fastmail.fm>
	<50AF45BE.1020707@oracle.com> <50AF5012.4000807@fastmail.fm>
Message-ID: <1353778550.57423.YahooMailNeo@web121806.mail.ne1.yahoo.com>

Previously Java Mac developers were able to launch a Java 1.6 splash screen from within the app bundle using the info.plist key:

<key>SplashFile</key>
<string>$JAVAROOT/splash.gif</string>

... storing the splash.gif in the /XXX.app/Contents/Resources/Java/ directory.

How is this now being handled with the latest Java 1.7 OpenJDK mac-port implementation? 

What am I missing?

Mike


From niagarasoft20-macosxportdev at yahoo.com  Sat Nov 24 12:44:58 2012
From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com)
Date: Sat, 24 Nov 2012 12:44:58 -0800 (PST)
Subject: Bundled .app Splash Splash Screen invocation?
In-Reply-To: <1353778550.57423.YahooMailNeo@web121806.mail.ne1.yahoo.com>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
	<509D0135.8000406@oracle.com> <50AE86A7.5040907@fastmail.fm>
	<50AE9CDC.2090503@oracle.com> <50AEA728.9060903@fastmail.fm>
	<50AF45BE.1020707@oracle.com> <50AF5012.4000807@fastmail.fm>
	<1353778550.57423.YahooMailNeo@web121806.mail.ne1.yahoo.com>
Message-ID: <1353789898.52242.YahooMailNeo@web121801.mail.ne1.yahoo.com>

Ok, after some trial and error testing I found that if I included the ...

<key>JVMOptions</key>
<array>
<string>-splash:splash.gif</string>
</array>

... option and added the splash.gif file to my 'user.home' directory, then the splash.gif would present itself at program launch. This seems strangely arbitrary (bug?).

Is there any way to specify the path of the image to be located in relation to the .app bundle root instead?

Mike




----- Original Message -----
> From: "niagarasoft20-macosxportdev at yahoo.com" <niagarasoft20-macosxportdev at yahoo.com>
> To: "macosx-port-dev at openjdk.java.net X" <macosx-port-dev at openjdk.java.net>
> Cc: 
> Sent: Saturday, November 24, 2012 12:35 PM
> Subject: Bundled .app Splash Splash Screen invocation?
> 
> Previously Java Mac developers were able to launch a Java 1.6 splash screen from 
> within the app bundle using the info.plist key:
> 
> <key>SplashFile</key>
> <string>$JAVAROOT/splash.gif</string>
> 
> ... storing the splash.gif in the /XXX.app/Contents/Resources/Java/ directory.
> 
> How is this now being handled with the latest Java 1.7 OpenJDK mac-port 
> implementation? 
> 
> What am I missing?
> 
> Mike
> 

From niagarasoft20-macosxportdev at yahoo.com  Sat Nov 24 13:10:44 2012
From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com)
Date: Sat, 24 Nov 2012 13:10:44 -0800 (PST)
Subject: Bundled .app Splash Splash Screen invocation?
In-Reply-To: <1353789898.52242.YahooMailNeo@web121801.mail.ne1.yahoo.com>
References: <BFF08E5C-9945-4B8E-843A-7CCA3E399565@oracle.com>
	<509D0135.8000406@oracle.com> <50AE86A7.5040907@fastmail.fm>
	<50AE9CDC.2090503@oracle.com> <50AEA728.9060903@fastmail.fm>
	<50AF45BE.1020707@oracle.com> <50AF5012.4000807@fastmail.fm>
	<1353778550.57423.YahooMailNeo@web121806.mail.ne1.yahoo.com>
	<1353789898.52242.YahooMailNeo@web121801.mail.ne1.yahoo.com>
Message-ID: <1353791444.2367.YahooMailNeo@web121805.mail.ne1.yahoo.com>

Ok, I found that ...

<string>-splash:$APP_ROOT/Contents/Java/splash.gif</string>

...works .

Mike


----- Original Message -----
> From: "niagarasoft20-macosxportdev at yahoo.com" <niagarasoft20-macosxportdev at yahoo.com>
> To: "macosx-port-dev at openjdk.java.net X" <macosx-port-dev at openjdk.java.net>
> Cc: 
> Sent: Saturday, November 24, 2012 3:44 PM
> Subject: Re: Bundled .app Splash Splash Screen invocation?
> 
> Ok, after some trial and error testing I found that if I included the ...
> 
> <key>JVMOptions</key>
> <array>
> <string>-splash:splash.gif</string>
> </array>
> 
> ... option and added the splash.gif file to my 'user.home' directory, 
> then the splash.gif would present itself at program launch. This seems strangely 
> arbitrary (bug?).
> 
> Is there any way to specify the path of the image to be located in relation to 
> the .app bundle root instead?
> 
> Mike
> 
> 
> 
> 
> ----- Original Message -----
>>  From: "niagarasoft20-macosxportdev at yahoo.com" 
> <niagarasoft20-macosxportdev at yahoo.com>
>>  To: "macosx-port-dev at openjdk.java.net X" 
> <macosx-port-dev at openjdk.java.net>
>>  Cc: 
>>  Sent: Saturday, November 24, 2012 12:35 PM
>>  Subject: Bundled .app Splash Splash Screen invocation?
>> 
>>  Previously Java Mac developers were able to launch a Java 1.6 splash screen 
> from 
>>  within the app bundle using the info.plist key:
>> 
>>  <key>SplashFile</key>
>>  <string>$JAVAROOT/splash.gif</string>
>> 
>>  ... storing the splash.gif in the /XXX.app/Contents/Resources/Java/ 
> directory.
>> 
>>  How is this now being handled with the latest Java 1.7 OpenJDK mac-port 
>>  implementation? 
>> 
>>  What am I missing?
>> 
>>  Mike
>> 
> 

From Sergey.Bylokhov at oracle.com  Mon Nov 26 10:51:40 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Nov 2012 22:51:40 +0400
Subject: [8] Request for review: 7154516 [macosx] Popup menus have no visible
	borders
Message-ID: <50B3BA3C.9010502@oracle.com>

Hi.
Please review the fix for 8002308 : [macosx] 7198229 should be applied 
to the user action only
setBounds/setSize can cause StackOverflow in case of the considerable 
loading. It occurs when the system doesn't change the size of a window 
quickly and a large number of loops collects, because our setBounds 
method is asynchronous. Note that when the user changes the size of a 
window, system doesn't send a new event while previous event isn't 
processed.

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

-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Nov 26 10:54:10 2012
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Nov 2012 22:54:10 +0400
Subject: [8] Request for review: 8002308 : [macosx] 7198229 should be applied
	to the user action only
In-Reply-To: <50B3BA3C.9010502@oracle.com>
References: <50B3BA3C.9010502@oracle.com>
Message-ID: <50B3BAD2.6030702@oracle.com>

Subject was fixed.

Hi.
Please review the fix for 8002308 : [macosx] 7198229 should be applied 
to the user action only
setBounds/setSize can cause StackOverflow in case of the considerable 
loading. It occurs when the system doesn't change the size of a window 
quickly and a large number of loops collects, because our setBounds 
method is asynchronous. Note that when the user changes the size of a 
window, system doesn't send a new event while previous event isn't 
processed.

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

-- 
Best regards, Sergey.


From scott.kovatch at oracle.com  Mon Nov 26 11:33:56 2012
From: scott.kovatch at oracle.com (Scott Kovatch)
Date: Mon, 26 Nov 2012 11:33:56 -0800
Subject: [8] Request for review: 8002308 : [macosx] 7198229 should be
	applied to the user action only
In-Reply-To: <50B3BAD2.6030702@oracle.com>
References: <50B3BA3C.9010502@oracle.com> <50B3BAD2.6030702@oracle.com>
Message-ID: <3E719799-F0AC-48C7-8933-CEFC5E9A0541@oracle.com>

Makes sense to me. It's a pretty simple fix.

-- Scott K.

On Nov 26, 2012, at 10:54 AM, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:

> Subject was fixed.
> 
> Hi.
> Please review the fix for 8002308 : [macosx] 7198229 should be applied to the user action only
> setBounds/setSize can cause StackOverflow in case of the considerable loading. It occurs when the system doesn't change the size of a window quickly and a large number of loops collects, because our setBounds method is asynchronous. Note that when the user changes the size of a window, system doesn't send a new event while previous event isn't processed.
> 
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002308
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8002308/webrev.00/
> 
> -- 
> Best regards, Sergey.
> 


From anthony.petrov at oracle.com  Tue Nov 27 03:11:23 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 27 Nov 2012 15:11:23 +0400
Subject: [8] Request for review:  8002308 : [macosx] 7198229 should be
	applied to the user action only
In-Reply-To: <50B3BAD2.6030702@oracle.com>
References: <50B3BA3C.9010502@oracle.com> <50B3BAD2.6030702@oracle.com>
Message-ID: <50B49FDB.2000801@oracle.com>

Hi Sergey,

I suggest to call frame.dispose() at the end of the test (no need to 
resend the webrev for this). Otherwise the fix looks good to me.

--
best regards,
Anthony

On 11/26/2012 10:54 PM, Sergey Bylokhov wrote:
> Subject was fixed.
> 
> Hi.
> Please review the fix for 8002308 : [macosx] 7198229 should be applied 
> to the user action only
> setBounds/setSize can cause StackOverflow in case of the considerable 
> loading. It occurs when the system doesn't change the size of a window 
> quickly and a large number of loops collects, because our setBounds 
> method is asynchronous. Note that when the user changes the size of a 
> window, system doesn't send a new event while previous event isn't 
> processed.
> 
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002308
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8002308/webrev.00/
> 

From tobi at ultramixer.com  Tue Nov 27 23:36:06 2012
From: tobi at ultramixer.com (Tobias Bley)
Date: Wed, 28 Nov 2012 08:36:06 +0100
Subject: JDK 7 & Retina: How to prevent HiDPI scaling?
In-Reply-To: <3C4B9260-2FF4-457F-ADAE-35E5C5471030@cinderella.de>
References: <CAEnqZEUcDe3NaJ==9hwYwgC5VBZZiRXz-hDmKmcgOAFTE=qBEg@mail.gmail.com>
	<C39A8372-555D-46E6-8B00-63320C80DB44@apple.com>
	<97D0B63A-FDDF-4A06-B615-B21CF06DFA5B@oracle.com>
	<90FF3327-69D5-4BF6-9B35-734109250E7F@gmail.com>
	<877CD9EB-5E4A-4F2E-9005-D871901677D8@oracle.com>
	<81356080-7264-476D-8EF8-6601235F38FD@cinderella.de>
	<op.wmfyeimc2ilaq7@mistral-macosx.local>
	<CF6ADD60-3A83-4A0B-A2D3-6DBD23CF498C@apple.com>
	<op.wmf1uvxb2ilaq7@mistral-macosx.local>
	<5C570BC7-8373-4F4D-A848-9A0AC6093B9D@apple.com>
	<449E0513-653F-4503-9EFB-BB7EF9979FB3@cinderella.de>
	<A9F219E3-4E5C-4F69-870C-E4D4ACD91588@apple.com>
	<3C4B9260-2FF4-457F-ADAE-35E5C5471030@cinderella.de>
Message-ID: <B798609C-7CA7-4051-872F-F632CD0284D7@ultramixer.com>

Hi (Mike),

is it possible to tell Cocoa(?) not to scale up everthing on a Retina display? I would like to try to scale the text in JavaFX2 to factor 2.0 but currently the text size doubles ;) So how can I prevent the automatic upscaling?

Best regards,
Tobi


From anthony.petrov at oracle.com  Wed Nov 28 02:05:33 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 28 Nov 2012 14:05:33 +0400
Subject: JDK 7 & Retina: How to prevent HiDPI scaling?
In-Reply-To: <B798609C-7CA7-4051-872F-F632CD0284D7@ultramixer.com>
References: <CAEnqZEUcDe3NaJ==9hwYwgC5VBZZiRXz-hDmKmcgOAFTE=qBEg@mail.gmail.com>	<C39A8372-555D-46E6-8B00-63320C80DB44@apple.com>	<97D0B63A-FDDF-4A06-B615-B21CF06DFA5B@oracle.com>	<90FF3327-69D5-4BF6-9B35-734109250E7F@gmail.com>	<877CD9EB-5E4A-4F2E-9005-D871901677D8@oracle.com>	<81356080-7264-476D-8EF8-6601235F38FD@cinderella.de>	<op.wmfyeimc2ilaq7@mistral-macosx.local>	<CF6ADD60-3A83-4A0B-A2D3-6DBD23CF498C@apple.com>	<op.wmf1uvxb2ilaq7@mistral-macosx.local>	<5C570BC7-8373-4F4D-A848-9A0AC6093B9D@apple.com>	<449E0513-653F-4503-9EFB-BB7EF9979FB3@cinderella.de>	<A9F219E3-4E5C-4F69-870C-E4D4ACD91588@apple.com>	<3C4B9260-2FF4-457F-ADAE-35E5C5471030@cinderella.de>
	<B798609C-7CA7-4051-872F-F632CD0284D7@ultramixer.com>
Message-ID: <50B5E1ED.7050707@oracle.com>

(I'm CC'ing openjfx-dev@ since this is a JavaFX topic)

I think you might want to check out the following issue:

http://javafx-jira.kenai.com/browse/RT-24009

Currently JavaFX isn't HiDPI-aware, and as such this is impossible to 
turn automatic scaling off (unless there's a hack in OS X for this.)


PS. If you're interested in support for this feature in JDK as well, 
here's a bug to watch: http://bugs.sun.com/view_bug.do?bug_id=8000629

--
best regards,
Anthony

On 11/28/2012 11:36 AM, Tobias Bley wrote:
> Hi (Mike),
> 
> is it possible to tell Cocoa(?) not to scale up everthing on a Retina display? I would like to try to scale the text in JavaFX2 to factor 2.0 but currently the text size doubles ;) So how can I prevent the automatic upscaling?
> 
> Best regards,
> Tobi
> 

From mik3hall at gmail.com  Wed Nov 28 02:48:32 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 28 Nov 2012 04:48:32 -0600
Subject: Populating applet text components
Message-ID: <4838A732-229C-4AB1-95A3-2010A43F3E0F@gmail.com>

I have just been coding an applet where I intended some slightly involved text to be pasted into a text component.
I found out as per [1] that a 1.6 update eliminated applet paste access to the clipboard.
In appletviewer testing I tried drag and drop and that seemed to work, so this seemed a reasonable other option.
This morning I uploaded the applet and tried to test there. Drag and drop did not work from either Safari or Firefox.
Does the browser provide a blocking layer that keeps the drag and drop from getting to the applet? If not is something wrong in the implementation that keeps it from working in the browsers.
Given that paste doesn't work this would be a nice substitute option to have working. 

[1] https://blogs.oracle.com/kyle/entry/copy_and_paste_in_java

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 jesmith at kaon.com  Wed Nov 28 06:22:40 2012
From: jesmith at kaon.com (Joshua Smith)
Date: Wed, 28 Nov 2012 09:22:40 -0500
Subject: Populating applet text components
In-Reply-To: <4838A732-229C-4AB1-95A3-2010A43F3E0F@gmail.com>
References: <4838A732-229C-4AB1-95A3-2010A43F3E0F@gmail.com>
Message-ID: <AE735706-2D67-4FEF-8E2A-3E515028D3DE@kaon.com>

I found that a lot of my copy/paste bugs only happen in unsigned applets. Is signing the applet an option?

On Nov 28, 2012, at 5:48 AM, Michael Hall <mik3hall at gmail.com> wrote:

> I have just been coding an applet where I intended some slightly involved text to be pasted into a text component.
> I found out as per [1] that a 1.6 update eliminated applet paste access to the clipboard.
> In appletviewer testing I tried drag and drop and that seemed to work, so this seemed a reasonable other option.
> This morning I uploaded the applet and tried to test there. Drag and drop did not work from either Safari or Firefox.
> Does the browser provide a blocking layer that keeps the drag and drop from getting to the applet? If not is something wrong in the implementation that keeps it from working in the browsers.
> Given that paste doesn't work this would be a nice substitute option to have working. 
> 
> [1] https://blogs.oracle.com/kyle/entry/copy_and_paste_in_java
> 
> 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 scott.kovatch at oracle.com  Wed Nov 28 08:13:51 2012
From: scott.kovatch at oracle.com (Scott Kovatch)
Date: Wed, 28 Nov 2012 08:13:51 -0800
Subject: Populating applet text components
In-Reply-To: <4838A732-229C-4AB1-95A3-2010A43F3E0F@gmail.com>
References: <4838A732-229C-4AB1-95A3-2010A43F3E0F@gmail.com>
Message-ID: <E27CFCAB-5E39-41D2-A65B-D01267265B1C@oracle.com>


On Nov 28, 2012, at 2:48 AM, Michael Hall <mik3hall at gmail.com> wrote:

> I have just been coding an applet where I intended some slightly involved text to be pasted into a text component.
> I found out as per [1] that a 1.6 update eliminated applet paste access to the clipboard.
> In appletviewer testing I tried drag and drop and that seemed to work, so this seemed a reasonable other option.
> This morning I uploaded the applet and tried to test there. Drag and drop did not work from either Safari or Firefox.
> Does the browser provide a blocking layer that keeps the drag and drop from getting to the applet? If not is something wrong in the implementation that keeps it from working in the browsers.
> Given that paste doesn't work this would be a nice substitute option to have working. 

Drag and drop unfortunately won't work due to limitations in the NPAPI. All plugins run in their own process. What you are seeing in the applet area is actually an image of what the applet process has rendered. This also means that any event that is intended for the applet has to be serialized and sent to the plugin process. This works well for mouse, key and window activation events but no provision was made for drag-type events, so there's no way to know what was dragged onto the applet.

This will require changes from all of the browsers, so I'm not optimistic it will ever happen.

-- Scott K.

----------------------------------------
Scott Kovatch
scott.kovatch at oracle.com
Santa Clara/Pleasanton, CA


From leonid.romanov at oracle.com  Wed Nov 28 13:19:43 2012
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Thu, 29 Nov 2012 01:19:43 +0400
Subject: [7u12] Review request for 2223196 : [macosx] Situation when
	KeyEventDispatcher doesn't work on AWT but does on Swing
Message-ID: <7AB66D3D-E82D-45CC-98FE-7017A548D2F4@oracle.com>

Hi,
Please review a fix for 2223196 : [macosx] Situation when KeyEventDispatcher doesn't work on AWT but does on Swing. In JDK 8 this bug was fixed by the Anton Tarasov fix for 6981400 (*). This fix is a OS X specific subset of the Anton's fix.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2223196
Wbrev: http://cr.openjdk.java.net/~leonidr/2223196/webrev.00/


* http://cr.openjdk.java.net/~ant/6981400/webrev.7/

Thanks,
Leonid.



From mik3hall at gmail.com  Thu Nov 29 03:39:56 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 29 Nov 2012 05:39:56 -0600
Subject: Populating applet text components
In-Reply-To: <AE735706-2D67-4FEF-8E2A-3E515028D3DE@kaon.com>
References: <4838A732-229C-4AB1-95A3-2010A43F3E0F@gmail.com>
	<AE735706-2D67-4FEF-8E2A-3E515028D3DE@kaon.com>
Message-ID: <E50CBA65-831B-49FB-9E9B-03EF7933643D@gmail.com>

On Nov 28, 2012, at 8:22 AM, Joshua Smith wrote:

> I found that a lot of my copy/paste bugs only happen in unsigned applets. Is signing the applet an option?

I saw signing helped sometimes but it didn't seem to do me any good. Maybe I'll double check I did it correctly when I get a chance.

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  Thu Nov 29 14:08:02 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 29 Nov 2012 16:08:02 -0600
Subject: Populating applet text components
In-Reply-To: <AE735706-2D67-4FEF-8E2A-3E515028D3DE@kaon.com>
References: <4838A732-229C-4AB1-95A3-2010A43F3E0F@gmail.com>
	<AE735706-2D67-4FEF-8E2A-3E515028D3DE@kaon.com>
Message-ID: <6ACAAB7A-53E9-4070-AB14-D81AF5D61CE3@gmail.com>

On Nov 28, 2012, at 8:22 AM, Joshua Smith wrote:

> I found that a lot of my copy/paste bugs only happen in unsigned applets. Is signing the applet an option?

Have you checked this recently on OS X? I didn't get it to work (Key sequence paste), with appletviewer 1.6 or 1.7. or the uploaded applet with Safari. 
I did get it to work on a Windows box that appears to be running 1.6.0_37

Bug?

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  Thu Nov 29 15:40:06 2012
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 29 Nov 2012 17:40:06 -0600
Subject: Populating applet text components
In-Reply-To: <6ACAAB7A-53E9-4070-AB14-D81AF5D61CE3@gmail.com>
References: <4838A732-229C-4AB1-95A3-2010A43F3E0F@gmail.com>
	<AE735706-2D67-4FEF-8E2A-3E515028D3DE@kaon.com>
	<6ACAAB7A-53E9-4070-AB14-D81AF5D61CE3@gmail.com>
Message-ID: <8DC7507F-00D3-4A43-8075-D66EDA1B4AD5@gmail.com>

On Nov 29, 2012, at 4:08 PM, Michael Hall wrote:

> On Nov 28, 2012, at 8:22 AM, Joshua Smith wrote:
> 
>> I found that a lot of my copy/paste bugs only happen in unsigned applets. Is signing the applet an option?
> 
> Have you checked this recently on OS X? I didn't get it to work (Key sequence paste), with appletviewer 1.6 or 1.7. or the uploaded applet with Safari. 
> I did get it to work on a Windows box that appears to be running 1.6.0_37
> 
> Bug?

I re-uploaded unsigned jar and it failed on Windows. This seemed to confirm signed works on Windows but not on OS X. So, in turn this seemed bug confirmation.
So...
Your report has been assigned an internal review ID of 2391708. 


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





> 
> 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 jcpalmer at rochester.rr.com  Fri Nov 30 20:52:55 2012
From: jcpalmer at rochester.rr.com (Jeff Palmer)
Date: Fri, 30 Nov 2012 23:52:55 -0500
Subject: macosx-port-dev Digest, Vol 23, Issue 27
In-Reply-To: <mailman.0.1354305600.21806.macosx-port-dev@openjdk.java.net>
References: <mailman.0.1354305600.21806.macosx-port-dev@openjdk.java.net>
Message-ID: <895A131A-012C-46F4-86BF-7B72E6E1BEB9@rochester.rr.com>

FYI,  My O'Reilly book, Java Foundation Classes, is really old.  I did see for the java.awt.datatransfer.Clipboard class that "Untrusted applet code is not allowed to access the system clipboard, so untrusted applets cannot participate in inter application cut-and-paste".

I am not sure if this is the issue, but if so it is not a bug.  No sign, just intra application cut-and-paste.

On Nov 30, 2012, at 3:00 PM, macosx-port-dev-request at openjdk.java.net wrote:

> From: Michael Hall <mik3hall at gmail.com>
> Subject: Re: Populating applet text components
> Date: November 29, 2012 5:08:02 PM EST
> To: Mac OS X Port <macosx-port-dev at openjdk.java.net>
> 
> 
> On Nov 28, 2012, at 8:22 AM, Joshua Smith wrote:
> 
>> I found that a lot of my copy/paste bugs only happen in unsigned applets. Is signing the applet an option?
> 
> Have you checked this recently on OS X? I didn't get it to work (Key sequence paste), with appletviewer 1.6 or 1.7. or the uploaded applet with Safari. 
> I did get it to work on a Windows box that appears to be running 1.6.0_37
> 
> Bug?
> 
> 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