From Alan.Bateman at oracle.com Sun Apr 1 06:16:14 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 01 Apr 2012 14:16:14 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F72DF79.5080907@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> <4F720AEB.7080106@oracle.com> <12715007-AA8C-4C31-81E5-F7716C829E87@oracle.com> <4F72C08A.7000106@oracle.com> <4F72DF79.5080907@oracle.com> Message-ID: <4F78551E.2050701@oracle.com> On 28/03/2012 10:52, Michael McMahon wrote: > > Maybe, we should be doing what Dan Daugherty suggested yesterday and > re-mapping the native > filename in the case where a full absolute path is passed in (which is > the code-path > when System.load() is called above) > > My reasoning (for rejecting that) was that an absolute path is a > request for an explicit name > eg. System.load("/abs/path/libfoo.dylib") and it seems odd to go > modifying the path that > the user provided (as opposed to the System.loadLibrary("foo") case, > where we have to > construct the path internally). But, I hadn't considered the case > above where the path > is constructed by calling System.mapLibraryName(). > > So, I think a better approach might be to just to check for the old > ".jnilib" suffix in all > the cases, rather than changing System.mapLibraryName(). Otherwise, > we'll have an inconsistency > forever more between the output of that method and the library suffix > that we want people > to use. > > I've attached the jdk8 diffs for doing this. > > - Michael I checked Apple's JDK6 and it looks to me that they always favor .jnilib over .dylib. If I compile some native code to two shared libraries, one with the .dylib suffix and the other with .jnilib then with Apple's JDK6 it always seems to load the .jnilib version. If only the .dylib library exists then it loads that. Also, as per a previous post, the System.mapLibraryName method with Apple's JDK6 seems to favor .jnilib too. This makes wonder about the original patches in the bsd-port and macosx forest as the comments there suggest that ".jnilib" is legacy when it seems to have been the favored suffix in JDK6 at least. Anyway, for jdk7 & jdk8 it looks like we are making a break from the past and supporting .jnilib is just to give developers a chance to migrate. In that context Dan's suggestion and your latest patch seems reasonable but does lead a few anomalies - for example System.loadLibrary with an absolute path might succeed even though the library will appear to not exist if tested separately. Also I wonder about System.mapLibraryName where someone tests to see if the library exists before then invoke System.loadLibrary. My guess is that there isn't a perfect solution to this as there will always been anomalies in a migration like this. On the latest webrev then the use of final at L1867 is a bit odd and can be removed. For the jdk8 version then the fromClass needs to be Class. -Alan From david.holmes at oracle.com Sun Apr 1 06:28:24 2012 From: david.holmes at oracle.com (David Holmes) Date: Sun, 01 Apr 2012 23:28:24 +1000 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F78551E.2050701@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> <4F720AEB.7080106@oracle.com> <12715007-AA8C-4C31-81E5-F7716C829E87@oracle.com> <4F72C08A.7000106@oracle.com> <4F72DF79.5080907@oracle.com> <4F78551E.2050701@oracle.com> Message-ID: <4F7857F8.2010308@oracle.com> Alan, Michael, This sounds like a case where a property to control what the preferred library suffix is might be useful as a migration aid. Though the fundamental flaw in the API is assuming there is only a single suffix. David On 1/04/2012 11:16 PM, Alan Bateman wrote: > On 28/03/2012 10:52, Michael McMahon wrote: >> >> Maybe, we should be doing what Dan Daugherty suggested yesterday and >> re-mapping the native >> filename in the case where a full absolute path is passed in (which is >> the code-path >> when System.load() is called above) >> >> My reasoning (for rejecting that) was that an absolute path is a >> request for an explicit name >> eg. System.load("/abs/path/libfoo.dylib") and it seems odd to go >> modifying the path that >> the user provided (as opposed to the System.loadLibrary("foo") case, >> where we have to >> construct the path internally). But, I hadn't considered the case >> above where the path >> is constructed by calling System.mapLibraryName(). >> >> So, I think a better approach might be to just to check for the old >> ".jnilib" suffix in all >> the cases, rather than changing System.mapLibraryName(). Otherwise, >> we'll have an inconsistency >> forever more between the output of that method and the library suffix >> that we want people >> to use. >> >> I've attached the jdk8 diffs for doing this. >> >> - Michael > I checked Apple's JDK6 and it looks to me that they always favor .jnilib > over .dylib. If I compile some native code to two shared libraries, one > with the .dylib suffix and the other with .jnilib then with Apple's JDK6 > it always seems to load the .jnilib version. If only the .dylib library > exists then it loads that. Also, as per a previous post, the > System.mapLibraryName method with Apple's JDK6 seems to favor .jnilib > too. This makes wonder about the original patches in the bsd-port and > macosx forest as the comments there suggest that ".jnilib" is legacy > when it seems to have been the favored suffix in JDK6 at least. > > Anyway, for jdk7 & jdk8 it looks like we are making a break from the > past and supporting .jnilib is just to give developers a chance to > migrate. In that context Dan's suggestion and your latest patch seems > reasonable but does lead a few anomalies - for example > System.loadLibrary with an absolute path might succeed even though the > library will appear to not exist if tested separately. Also I wonder > about System.mapLibraryName where someone tests to see if the library > exists before then invoke System.loadLibrary. My guess is that there > isn't a perfect solution to this as there will always been anomalies in > a migration like this. > > On the latest webrev then the use of final at L1867 is a bit odd and can > be removed. For the jdk8 version then the fromClass needs to be Class. > > -Alan > > > > > From jcpalmer at rochester.rr.com Sun Apr 1 09:03:34 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Sun, 01 Apr 2012 12:03:34 -0400 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: Message-ID: On 3/30/12 4:15 PM, "Scott Palmer" wrote: > > On 2012-03-30, at 3:58 PM, Jeff Palmer wrote: > >> Thanks for replying. I actually thought I was closer giving a legal "heads >> up" (advice seem too strong), not asking for it. This was directed to those >> thinking about using the bundling process under development here. >> >> This is an actual quote from the preamble of GNU Lesser General Public >> License, version 2.1, http://www.gnu.org/licenses/lgpl-2.1.html >> >> "Although the Lesser General Public License is Less protective of the users' >> freedom, it does ensure that the user of a program that is linked with the >> Library has the freedom and the wherewithal to run that program using a >> modified version of the Library." >> >> People who would run one of these bundled programs would seem to have the >> the right to switch out the JRE, but how can they? If you have customers >> that want to cause a developer problems, this is a wide open way for them to >> do it. > > > It says they have the right to switch it out.. But does it say you have to > tell them how to do that or help them in any way? > > Has LGPL ever been successfully defended anyway? Even the Linux kernel folks > happily let nVidia ignore it? nobody but Richard Stallman actually cares. > > Scott Good point on the it doesn't have to be pretty front. It just has to be possible. If the OS files that constitute a JRE from bundling, can be cp'ed over by ones the user got from somewhere else, then they are replaceable. As far as LPGL defense success: -First, I do not know what GPL libraries nVidia is using as building blocks of their video drivers, but presumably they could also be cp'ed with replacements per above. - There has been one success I know of: http://www.macnn.com/articles/11/01/07/move.said.to.be.related.to.licensing. dispute . It is really the addition of some physical barrier, usually created by some other party that causes the potential problem. Being required to jail break your phone to change out the library seems a bit much. Bundling itself should pose no problem. Hopefully, an app from the Mac store would still run after the copy operation. I think people raising these problems are just mad at iOS. Unfortunately, the only ones that have the potential to get hurt is the application maker. Cannot say I'm thrilled myself, but I do not like the mechanism of retaliation. If there is some code signing like defense mechanism of the mac store which means it won't run post copy, then put in another exemption, like the class path one, & force people using this tactic to find other, less prepared victims. From leonid.romanov at oracle.com Mon Apr 2 02:23:06 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 2 Apr 2012 02:23:06 -0700 (PDT) Subject: Q: how to display menu accelerators Message-ID: <73d1bce2-dcf4-4953-a994-53337a9284a8@default> Thanks! ----- ???????? ????????? ----- ??: swingler at apple.com ????: leonid.romanov at oracle.com ?????: macosx-port-dev at openjdk.java.net ????????????: ???????, 29 ???? 2012 ? 19:05:43 GMT +04:00 ???-????, ?????? ????: Re: Q: how to display menu accelerators On Mar 29, 2012, at 6:50 AM, Leonid Romanov wrote: > Hi, > Currently we display menu accelerators (that is, keyboard modifiers one needs to press in order to invoke menu command via keystroke) as "Control", "Alt" and "Meta" text strings. This is obviously not right. However, I'm not sure what is the correct solution here: Apple has these funky symbols that stand for Control, Option and Command, yet they seem to be absent on the most modern Apple keyboards. For example, on my MBP keyboard only Command key has a corresponding symbol above "Command" string. So, what should JDK display: symbols, or just plain "Control", "Option" and "Command"? My suggestion would be to remain coherent with the Java SE 6 and the rest of OS X by using the symbols. This is an excerpt from an awt.properties file which contains the OS X-specific menu glyphs: # Modifier names AWT.shift=\u21e7 AWT.control=\u2303 AWT.alt=\u2325 AWT.meta=\u2318 AWT.altGraph=\u2325 # Key names AWT.enter=\u23ce AWT.backSpace=\u232b AWT.tab=\u21e5 AWT.cancel=\u238b AWT.clear=\u2327 AWT.pause=Pause AWT.capsLock=\u21ea AWT.escape=\u238b AWT.space=\u2423 AWT.pgup=\u21de AWT.pgdn=\u21df AWT.end=\u2198 AWT.home=\u2196 AWT.left=\u2190 AWT.up=\u2191 AWT.right=\u2192 AWT.down=\u2193 AWT.begin=Begin AWT.comma=, AWT.period=. AWT.slash=/ AWT.semicolon=; AWT.equals=\u003d AWT.openBracket=[ AWT.backSlash=\\ AWT.closeBracket=] AWT.multiply=\u2328 * AWT.add=\u2328 + AWT.separator=\u2328 , AWT.separater=\u2328 , AWT.subtract=\u2328 - AWT.decimal=\u2328 . AWT.divide=\u2328 / AWT.delete=\u2326 AWT.numLock=Num Lock AWT.scrollLock=Scroll Lock AWT.f1=F1 AWT.f2=F2 AWT.f3=F3 AWT.f4=F4 AWT.f5=F5 AWT.f6=F6 AWT.f7=F7 AWT.f8=F8 AWT.f9=F9 AWT.f10=F10 AWT.f11=F11 AWT.f12=F12 AWT.f13=F13 AWT.f14=F14 AWT.f15=F15 AWT.f16=F16 AWT.f17=F17 AWT.f18=F18 AWT.f19=F19 AWT.f20=F20 AWT.f21=F21 AWT.f22=F22 AWT.f23=F23 AWT.f24=F24 AWT.printScreen=\u2399 AWT.insert=Insert AWT.help=Help AWT.windows=Windows AWT.context=Context Menu AWT.backQuote=` AWT.quote=' AWT.deadGrave=Dead Grave AWT.deadAcute=Dead Acute AWT.deadCircumflex=Dead Circumflex AWT.deadTilde=Dead Tilde AWT.deadMacron=Dead Macron AWT.deadBreve=Dead Breve AWT.deadAboveDot=Dead Above Dot AWT.deadDiaeresis=Dead Diaeresis AWT.deadAboveRing=Dead Above Ring AWT.deadDoubleAcute=Dead Double Acute AWT.deadCaron=Dead Caron AWT.deadCedilla=Dead Cedilla AWT.deadOgonek=Dead Ogonek AWT.deadIota=Dead Iota AWT.deadVoicedSound=Dead Voiced Sound AWT.deadSemivoicedSound=Dead Semivoiced Sound AWT.ampersand=& AWT.asterisk=* AWT.quoteDbl=" AWT.Less=< AWT.greater=> AWT.braceLeft=[ AWT.braceRight=] AWT.at=@ AWT.colon=: AWT.circumflex=^ AWT.dollar=$ AWT.euro=\u20ac AWT.exclamationMark=! AWT.invertedExclamationMark=\u00a1 AWT.leftParenthesis=( AWT.numberSign=# AWT.plus=+ AWT.minus=- AWT.rightParenthesis=) AWT.underscore=_ AWT.final=Final AWT.convert=Convert AWT.noconvert=No Convert AWT.accept=Accept AWT.modechange=Mode Change AWT.kana=Kana AWT.kanji=Kanji AWT.alphanumeric=Alphanumeric AWT.katakana=Katakana AWT.hiragana=Hiragana AWT.fullWidth=Full-Width AWT.halfWidth=Half-Width AWT.romanCharacters=Roman Characters AWT.allCandidates=All Candidates AWT.previousCandidate=Previous Candidate AWT.codeInput=Code Input AWT.japaneseKatakana=Japanese Katakana AWT.japaneseHiragana=Japanese Hiragana AWT.japaneseRoman=Japanese Roman AWT.kanaLock=Kana Lock AWT.inputMethodOnOff=Input Method On/Off AWT.again=Again AWT.undo=Undo AWT.copy=Copy AWT.paste=Paste AWT.cut=Cut AWT.find=Find AWT.props=Props AWT.stop=Stop AWT.compose=Compose # Numeric Keypad AWT.numpad=\u2328 AWT.unknown=Unknown AWT.undefined=Undefined Regards, Mike Swingler Apple Inc. From artem.ananiev at oracle.com Mon Apr 2 05:45:20 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Apr 2012 16:45:20 +0400 Subject: [8] Review request for 7124411: [macosx] There's no KEY_TYPED for VK_ESCAPE In-Reply-To: References: Message-ID: <4F799F60.5060804@oracle.com> Looks fine. Thanks, Artem On 3/29/2012 4:25 PM, Leonid Romanov wrote: > Hi, > Please review a fix for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124411 > > webrev: http://cr.openjdk.java.net/~leonidr/7124411/webrev.00/ > > Thanks, > Leonid. From anthony.petrov at oracle.com Tue Apr 3 03:50:36 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 03 Apr 2012 14:50:36 +0400 Subject: [8] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. In-Reply-To: <4F77634D.1020707@oracle.com> References: <4F77634D.1020707@oracle.com> Message-ID: <4F7AD5FC.10503@oracle.com> Hi Sergey, The fix looks good to me. -- best regards, Anthony On 4/1/2012 12:04 AM, Sergey Bylokhov wrote: > Hi Everyone, > A subcomponents may want to override the cursor over some of their > parts(LWTextAreaPeer changes the cursor over scrollbars). > > Changes description: > 1. LWComponentPeer.java: > - Just one method added getCursor(); > > 2. LWCursorManager.java: > - updateCursorImpl now use LWComponentPeer.getCursor() if applicable. > - cleanup + TODO implemented "// TODO: it's possible to get the > component under cursor directly as" > > 3. LWTextAreaPeer.java: > - Changes the cursor over scrollbars. > > 4. LWWindowPeer.java: > - We should update cursor even on MOUSE_EXIT event. > > 5. CCursorManager.java: > - currentCursor was always null. Unused method getNativeWindow() > removed. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150105 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7150105/webrev.00/ > From staffan.larsen at oracle.com Tue Apr 3 06:39:02 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 3 Apr 2012 15:39:02 +0200 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values Message-ID: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> Please review the following fix: webrev: http://cr.openjdk.java.net/~sla/7147848/webrev.00/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 This fix implements the missing functionality in UnixOperatingSystem for Mac OS X. Any feedback on the implementation is welcome as I am not very familiar with the APIs in Mac OS X. I have verified that the changes build on all platforms through JPRT. The correctness has been verified manually by looking in JConsole and running the tests in test/java/lang/management/OperatingSystemMXBean test/com/sun/management/OperatingSystemMXBean. Thanks, /Staffan From alexander.zuev at oracle.com Tue Apr 3 08:26:49 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 03 Apr 2012 19:26:49 +0400 Subject: [8] Request for review for 7153735: [macosx] Text with diacritics is pasted with broken encoding Message-ID: <4F7B16B9.2050702@oracle.com> Hello, please review my fix for CR 7153735: [macosx] Text with diacritics is pasted with broken encoding This is just a forward-port of the bug 7153735 into the JDK8 The bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153735 Webrev with proposed fix: http://cr.openjdk.java.net/~kizune/7153735/8/webrev.00/ With best regards, Alex From anthony.petrov at oracle.com Wed Apr 4 03:18:33 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Apr 2012 14:18:33 +0400 Subject: [8] Request for review for 7153735: [macosx] Text with diacritics is pasted with broken encoding In-Reply-To: <4F7B16B9.2050702@oracle.com> References: <4F7B16B9.2050702@oracle.com> Message-ID: <4F7C1FF9.6000509@oracle.com> Looks fine. -- best regards, Anthony On 4/3/2012 7:26 PM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7153735: [macosx] Text with diacritics is > pasted with broken encoding > This is just a forward-port of the bug 7153735 into the JDK8 > > The bug description: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153735 > Webrev with proposed fix: > http://cr.openjdk.java.net/~kizune/7153735/8/webrev.00/ > > With best regards, > Alex From anthony.petrov at oracle.com Wed Apr 4 07:00:46 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Apr 2012 18:00:46 +0400 Subject: [8] Review request for 7124553: [macosx] Need minimum size for titled Frames and JFrames In-Reply-To: <4F7C1979.4040302@oracle.com> References: <4F6CB1FB.1010700@oracle.com> <4F706C0E.4030908@oracle.com> <4F71B34D.3070801@oracle.com> <4F7AEB84.2030304@oracle.com> <4F7C1979.4040302@oracle.com> Message-ID: <4F7C540E.1060500@oracle.com> Here's a fix that wipes out all traces of the grow box: http://cr.openjdk.java.net/~anthony/8-19-frameMinSize-7124553.1/ -- best regards, Anthony On 4/4/2012 1:50 PM, Artem Ananiev wrote: > > On 4/3/2012 4:22 PM, Anthony Petrov wrote: >> Hi Artem, >> >> May I consider the fix reviewed, or do you (and anyone else interested) >> have any further questions/suggestions? > > I still think that the code to support 10.6, which will a legacy OS at > the moment when JDK8 is released, should not be fw-ported from 7u to 8. > > Thanks, > > Artem > >> -- >> best regards, >> Anthony >> >> On 3/27/2012 4:32 PM, Anthony Petrov wrote: >>> Hi Artem, >>> >>> Thanks for the review. >>> >>> Reading through macosx-port-dev@ mailing list I observe a lot of users >>> who (try to) use Oracle JDK for Mac on Snow Leopard systems, and I see >>> nothing wrong with that as long as it is runnable on those systems. At >>> least at this exact moment we don't have a strong reason to drop >>> support for (this is a wrong word here, rather "ability to run on") >>> Mac OS X 10.6. When there's some code that ultimately won't run on >>> Snow Leopard and we drop the support completely, then we may remove >>> this grow box stuff as well. But currently it doesn't hurt anyone. >>> >>> So for now I would like to leave GROW_BOX_SIZE and friends as they >>> are. Is this OK? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 3/26/2012 5:15 PM, Artem Ananiev wrote: >>>> >>>> Looks fine, but... Is the new constant GROW_BOX_SIZE about pre-Lion >>>> window resize box at the bottom-right corner of the window? I doubt >>>> [Snow] Leopard will be in the list of supported platforms for JDK8, >>>> so it doesn't make any sense to have code specific to this resize box >>>> in the workspace. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 3/23/2012 9:25 PM, Anthony Petrov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124553 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/8-19-frameMinSize-7124553.0/ >>>>> >>>>> This is a direct forward-port of the same fix from 7u4. >>>>> >>>>> More details: >>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003101.html >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony From swingler at apple.com Wed Apr 4 08:20:20 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 04 Apr 2012 08:20:20 -0700 Subject: [8] Review request for 7124553: [macosx] Need minimum size for titled Frames and JFrames In-Reply-To: <4F7C540E.1060500@oracle.com> References: <4F6CB1FB.1010700@oracle.com> <4F706C0E.4030908@oracle.com> <4F71B34D.3070801@oracle.com> <4F7AEB84.2030304@oracle.com> <4F7C1979.4040302@oracle.com> <4F7C540E.1060500@oracle.com> Message-ID: <1C6C6BFA-3F96-4BE2-980C-463782B72215@apple.com> Looks good to me. Cheers, Mike Swingler Apple Inc. On Apr 4, 2012, at 7:00 AM, Anthony Petrov wrote: > Here's a fix that wipes out all traces of the grow box: > > http://cr.openjdk.java.net/~anthony/8-19-frameMinSize-7124553.1/ > > -- > best regards, > Anthony > > On 4/4/2012 1:50 PM, Artem Ananiev wrote: >> On 4/3/2012 4:22 PM, Anthony Petrov wrote: >>> Hi Artem, >>> >>> May I consider the fix reviewed, or do you (and anyone else interested) >>> have any further questions/suggestions? >> I still think that the code to support 10.6, which will a legacy OS at the moment when JDK8 is released, should not be fw-ported from 7u to 8. >> Thanks, >> Artem >>> -- >>> best regards, >>> Anthony >>> >>> On 3/27/2012 4:32 PM, Anthony Petrov wrote: >>>> Hi Artem, >>>> >>>> Thanks for the review. >>>> >>>> Reading through macosx-port-dev@ mailing list I observe a lot of users >>>> who (try to) use Oracle JDK for Mac on Snow Leopard systems, and I see >>>> nothing wrong with that as long as it is runnable on those systems. At >>>> least at this exact moment we don't have a strong reason to drop >>>> support for (this is a wrong word here, rather "ability to run on") >>>> Mac OS X 10.6. When there's some code that ultimately won't run on >>>> Snow Leopard and we drop the support completely, then we may remove >>>> this grow box stuff as well. But currently it doesn't hurt anyone. >>>> >>>> So for now I would like to leave GROW_BOX_SIZE and friends as they >>>> are. Is this OK? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/26/2012 5:15 PM, Artem Ananiev wrote: >>>>> >>>>> Looks fine, but... Is the new constant GROW_BOX_SIZE about pre-Lion >>>>> window resize box at the bottom-right corner of the window? I doubt >>>>> [Snow] Leopard will be in the list of supported platforms for JDK8, >>>>> so it doesn't make any sense to have code specific to this resize box >>>>> in the workspace. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 3/23/2012 9:25 PM, Anthony Petrov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124553 at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/8-19-frameMinSize-7124553.0/ >>>>>> >>>>>> This is a direct forward-port of the same fix from 7u4. >>>>>> >>>>>> More details: >>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003101.html >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony From artem.ananiev at oracle.com Thu Apr 5 03:41:24 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Apr 2012 14:41:24 +0400 Subject: [8] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. In-Reply-To: <4F77634D.1020707@oracle.com> References: <4F77634D.1020707@oracle.com> Message-ID: <4F7D76D4.4090601@oracle.com> Looks fine. Thanks, Artem On 4/1/2012 12:04 AM, Sergey Bylokhov wrote: > Hi Everyone, > A subcomponents may want to override the cursor over some of their > parts(LWTextAreaPeer changes the cursor over scrollbars). > > Changes description: > 1. LWComponentPeer.java: > - Just one method added getCursor(); > > 2. LWCursorManager.java: > - updateCursorImpl now use LWComponentPeer.getCursor() if applicable. > - cleanup + TODO implemented "// TODO: it's possible to get the > component under cursor directly as" > > 3. LWTextAreaPeer.java: > - Changes the cursor over scrollbars. > > 4. LWWindowPeer.java: > - We should update cursor even on MOUSE_EXIT event. > > 5. CCursorManager.java: > - currentCursor was always null. Unused method getNativeWindow() removed. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150105 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7150105/webrev.00/ > From artem.ananiev at oracle.com Thu Apr 5 03:48:00 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Apr 2012 14:48:00 +0400 Subject: [8] Request for review: 7124401 [macosx] After call Frame dispose() application continues to work In-Reply-To: <4F7485E0.3070102@oracle.com> References: <4F7485E0.3070102@oracle.com> Message-ID: <4F7D7860.9050305@oracle.com> Looks fine. Thanks, Artem On 3/29/2012 7:55 PM, Sergey Bylokhov wrote: > Hi Everyone, > On the latest version the dispose works as expected, but the test > expects that the window will be fully red. But it is not true on the mac > because of resizegrowboxwindow. Testcase updated. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124401 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124401/webrev.00/ > From artem.ananiev at oracle.com Thu Apr 5 03:53:09 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Apr 2012 14:53:09 +0400 Subject: [8] Request for review: 7150100 [macosx] "0123456789" is selected in the TextField. In-Reply-To: <4F7336C3.80907@oracle.com> References: <4F7336C3.80907@oracle.com> Message-ID: <4F7D7995.70800@oracle.com> Hi, Sergey, On 3/28/2012 8:05 PM, Sergey Bylokhov wrote: > Hi Everyone, > Two issues resolved: > 1) We should set caret position before the text selection. it's not clear why this particular change fixes the selection. Could you add more comments to the bug evaluation, please? Thanks, Artem > 2) On macosx we clear selection when the test component lost its focus, > so test was simplified and instructions dialog was removed (because > sometimes it steal the focus from the text component) > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150100 ** > Webrev can be found at: http://cr.openjdk.java.net/~serb/7150100/webrev.00/ > > -- > Best regards, Sergey. > From artem.ananiev at oracle.com Thu Apr 5 03:55:59 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Apr 2012 14:55:59 +0400 Subject: [8] Request for review: 7125657 [macosx] SpreadSheet demo has the broken display when clicking outside of the table In-Reply-To: <4F71B42B.9070606@oracle.com> References: <4F71B42B.9070606@oracle.com> Message-ID: <4F7D7A3F.2020501@oracle.com> Looks fine. Thanks, Artem On 3/27/2012 4:35 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a forward port from jdk 7u4: > http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/fab57f1dc2aa > > The general bug is that we repaint native part of the LWPanelPeer after > UPDATE event. This is not mac specific bug, because we do the same > things on XToolkit too. But this demo works there because > XPanel.paintPeer is noop. > > Fox XToolkit new bug will be created. Note that testworks in MToolkit > and WToolkit. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125657 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7125657/webrev.00/ > From artem.ananiev at oracle.com Thu Apr 5 03:59:57 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Apr 2012 14:59:57 +0400 Subject: [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer In-Reply-To: <4F70987B.3040404@oracle.com> References: <4F6B3195.2070909@oracle.com> <4F707106.3030700@oracle.com> <4F707133.90808@oracle.com> <4F708A97.40706@oracle.com> <4F70987B.3040404@oracle.com> Message-ID: <4F7D7B2D.4010606@oracle.com> Approved. Thanks, Artem On 3/26/2012 8:25 PM, Sergey Bylokhov wrote: > Hi Artem. > Done. > > 26.03.2012 19:26, Artem Ananiev ???????: >> >> On 3/26/2012 5:37 PM, Sergey Bylokhov wrote: >>> Hi, Artem. >>> AWT tree lock used for locking delegate. >> >> Ah, right, I was confused by the method name, getDelegateLock()... OK, >> could you add some information to the bug, please? Right now >> Evaluation contains a statement about the deadlock, but not about what >> it is caused by and how it can be resolved. >> >> Thanks, >> >> Artem >> >>> 26.03.2012 17:37, Artem Ananiev wrote: >>>> Hi, Sergey, >>>> >>>> On 3/22/2012 6:05 PM, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> This is a forward port from jdk 7u4: >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c >>>>> >>>>> Deadlock happens when 2 threads lock delegateLock and DefaultCaret >>>>> object in different order. Removed code initially was added to stop >>>>> recursion between paintPeer and addDirtyRegion( >>>>> repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> >>>>> etc), but it is impossible now because repaintPeer() asynchronous. >>>> >>>> according to the stack trace in bug description, the evaluation above >>>> doesn't look right. Initially reported deadlock involved AWT tree >>>> lock, not delegate lock. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7149913/webrev.00/ >>>>> >>> >>> > > From artem.ananiev at oracle.com Thu Apr 5 04:06:05 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Apr 2012 15:06:05 +0400 Subject: [8] Request for approval: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: <4F6B33A5.7080309@oracle.com> References: <4F6B33A5.7080309@oracle.com> Message-ID: <4F7D7C9D.7060507@oracle.com> Looks fine. Thanks, Artem On 3/22/2012 6:13 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a forward port from jdk 7u4: > hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/7816a64158c4 > > Now we reset selection in text components on focuslost event. > Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124528/webrev.01 > From artem.ananiev at oracle.com Thu Apr 5 04:07:28 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Apr 2012 15:07:28 +0400 Subject: [7u6] Request for review: 7124551 [macosx] Once added, Menu shortcut cannot be removed In-Reply-To: <4F747218.8020207@oracle.com> References: <4F747218.8020207@oracle.com> Message-ID: <4F7D7CF0.4050909@oracle.com> After backporting from 8 the fix still looks fine :) Thanks, Artem On 3/29/2012 6:30 PM, Sergey Bylokhov wrote: > Hi Everyone, > We should accept empty KeyEquivalent in case of shortcut removing. > This is a back port from jdk 8: > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74a1284ca75a > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00/ > From Alexander.Potochkin at oracle.com Thu Apr 5 06:32:28 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 05 Apr 2012 17:32:28 +0400 Subject: [8] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. In-Reply-To: <4F77634D.1020707@oracle.com> References: <4F77634D.1020707@oracle.com> Message-ID: <4F7D9EEC.9010200@oracle.com> Hello Sergey looks good alexp > Hi Everyone, > A subcomponents may want to override the cursor over some of their > parts(LWTextAreaPeer changes the cursor over scrollbars). > > Changes description: > 1. LWComponentPeer.java: > - Just one method added getCursor(); > > 2. LWCursorManager.java: > - updateCursorImpl now use LWComponentPeer.getCursor() if applicable. > - cleanup + TODO implemented "// TODO: it's possible to get the > component under cursor directly as" > > 3. LWTextAreaPeer.java: > - Changes the cursor over scrollbars. > > 4. LWWindowPeer.java: > - We should update cursor even on MOUSE_EXIT event. > > 5. CCursorManager.java: > - currentCursor was always null. Unused method getNativeWindow() > removed. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150105 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7150105/webrev.00/ > From Alexander.Potochkin at oracle.com Thu Apr 5 06:37:24 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 05 Apr 2012 17:37:24 +0400 Subject: [8] Request for review: 7150100 [macosx] "0123456789" is selected in the TextField. In-Reply-To: <4F7336C3.80907@oracle.com> References: <4F7336C3.80907@oracle.com> Message-ID: <4F7DA014.50100@oracle.com> Hello Sergey looks good alexp > Hi Everyone, > Two issues resolved: > 1) We should set caret position before the text selection. > 2) On macosx we clear selection when the test component lost its > focus, so test was simplified and instructions dialog was removed > (because sometimes it steal the focus from the text component) > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150100 ** > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7150100/webrev.00/ > From Alexander.Potochkin at oracle.com Thu Apr 5 06:39:53 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 05 Apr 2012 17:39:53 +0400 Subject: [8] Request for review: 7125657 [macosx] SpreadSheet demo has the broken display when clicking outside of the table In-Reply-To: <4F71B42B.9070606@oracle.com> References: <4F71B42B.9070606@oracle.com> Message-ID: <4F7DA0A9.5080806@oracle.com> Hello Sergey looks good alexp > Hi Everyone, > This is a forward port from jdk 7u4: > http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/fab57f1dc2aa > > The general bug is that we repaint native part of the LWPanelPeer > after UPDATE event. This is not mac specific bug, because we do the > same things on XToolkit too. But this demo works there because > XPanel.paintPeer is noop. > > Fox XToolkit new bug will be created. Note that testworks in MToolkit > and WToolkit. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125657 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7125657/webrev.00/ > From anthony.petrov at oracle.com Thu Apr 5 08:01:35 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 05 Apr 2012 19:01:35 +0400 Subject: [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode Message-ID: <4F7DB3CF.4030802@oracle.com> Hello, Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ With this fix we avoid setting an application delegate when AWT is started in the headless mode. This prevents a hang when another GUI toolkit (e.g. JavaFX) is already running in the same Java process. -- best regards, Anthony From swingler at apple.com Thu Apr 5 08:07:27 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 05 Apr 2012 08:07:27 -0700 Subject: [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode In-Reply-To: <4F7DB3CF.4030802@oracle.com> References: <4F7DB3CF.4030802@oracle.com> Message-ID: <1892A20F-DFBA-4788-9F8D-DC0616133B11@apple.com> On Apr 5, 2012, at 8:01 AM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: > > http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ > > With this fix we avoid setting an application delegate when AWT is started in the headless mode. This prevents a hang when another GUI toolkit (e.g. JavaFX) is already running in the same Java process. This would logically mean that you won't get eAWT events (file open, quit, etc) while started in this mode. Does this impact SWT as well? Regards, Mike Swingler Apple Inc. From anthony.petrov at oracle.com Thu Apr 5 08:23:00 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 05 Apr 2012 19:23:00 +0400 Subject: [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode In-Reply-To: <1892A20F-DFBA-4788-9F8D-DC0616133B11@apple.com> References: <4F7DB3CF.4030802@oracle.com> <1892A20F-DFBA-4788-9F8D-DC0616133B11@apple.com> Message-ID: <4F7DB8D4.2020404@oracle.com> On 04/05/12 19:07, Mike Swingler wrote: >> Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: >> >> http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ >> >> With this fix we avoid setting an application delegate when AWT is started in the headless mode. This prevents a hang when another GUI toolkit (e.g. JavaFX) is already running in the same Java process. > > This would logically mean that you won't get eAWT events (file open, quit, etc) while started in this mode. Does this impact SWT as well? In the headless mode an application doesn't have any UI, and as such there's no way to generate e.g. a Quit action. Hence the application delegate isn't necessary in this mode. SWT uses a special "SWT mode" (== -XstartOnFirstThread) which is different from the headless mode. In the SWT mode the delegate will still be installed. I think this may not work in case of running an SWT application together with the AWT in headless mode. However, I can't imagine who might want to run SWT/AWT in such configuration because the headless mode is supposed to be primarily used in server environments where a display is physically unavailable, in which case SWT wouldn't be able to run there either. -- best regards, Anthony From steve.x.northover at oracle.com Thu Apr 5 13:11:13 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 05 Apr 2012 16:11:13 -0400 Subject: [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode In-Reply-To: <4F7DB8D4.2020404@oracle.com> References: <4F7DB3CF.4030802@oracle.com> <1892A20F-DFBA-4788-9F8D-DC0616133B11@apple.com> <4F7DB8D4.2020404@oracle.com> Message-ID: <4F7DFC61.9020904@oracle.com> Hi all, Headless mode works fine for SWT. SWT doesn't use eAWT to do Quit etc. Instead, it uses the appropriate native cocoa calls. Steve On 05/04/2012 11:23 AM, Anthony Petrov wrote: > On 04/05/12 19:07, Mike Swingler wrote: >>> Please review a fix for >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: >>> >>> http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ >>> >>> With this fix we avoid setting an application delegate when AWT is >>> started in the headless mode. This prevents a hang when another GUI >>> toolkit (e.g. JavaFX) is already running in the same Java process. >> >> This would logically mean that you won't get eAWT events (file open, >> quit, etc) while started in this mode. Does this impact SWT as well? > > In the headless mode an application doesn't have any UI, and as such > there's no way to generate e.g. a Quit action. Hence the application > delegate isn't necessary in this mode. > > SWT uses a special "SWT mode" (== -XstartOnFirstThread) which is > different from the headless mode. In the SWT mode the delegate will > still be installed. > > I think this may not work in case of running an SWT application > together with the AWT in headless mode. However, I can't imagine who > might want to run SWT/AWT in such configuration because the headless > mode is supposed to be primarily used in server environments where a > display is physically unavailable, in which case SWT wouldn't be able > to run there either. > > -- > best regards, > Anthony From swingler at apple.com Thu Apr 5 13:31:13 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 05 Apr 2012 13:31:13 -0700 Subject: [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode In-Reply-To: <4F7DFC61.9020904@oracle.com> References: <4F7DB3CF.4030802@oracle.com> <1892A20F-DFBA-4788-9F8D-DC0616133B11@apple.com> <4F7DB8D4.2020404@oracle.com> <4F7DFC61.9020904@oracle.com> Message-ID: <3B6D46BF-6CC0-44F0-BC55-F5324BB30037@apple.com> How would an SWT developer accept new "open document" file double-clicks, or listen for sleep/wake events? AFAIK, eAWT is the only aperture that handles that right now. Regards, Mike Swingler Apple Inc. On Apr 5, 2012, at 1:11 PM, steve.x.northover at oracle.com wrote: > Hi all, > > Headless mode works fine for SWT. SWT doesn't use eAWT to do Quit etc. Instead, it uses the appropriate native cocoa calls. > > Steve > > On 05/04/2012 11:23 AM, Anthony Petrov wrote: >> On 04/05/12 19:07, Mike Swingler wrote: >>>> Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ >>>> >>>> With this fix we avoid setting an application delegate when AWT is started in the headless mode. This prevents a hang when another GUI toolkit (e.g. JavaFX) is already running in the same Java process. >>> >>> This would logically mean that you won't get eAWT events (file open, quit, etc) while started in this mode. Does this impact SWT as well? >> >> In the headless mode an application doesn't have any UI, and as such there's no way to generate e.g. a Quit action. Hence the application delegate isn't necessary in this mode. >> >> SWT uses a special "SWT mode" (== -XstartOnFirstThread) which is different from the headless mode. In the SWT mode the delegate will still be installed. >> >> I think this may not work in case of running an SWT application together with the AWT in headless mode. However, I can't imagine who might want to run SWT/AWT in such configuration because the headless mode is supposed to be primarily used in server environments where a display is physically unavailable, in which case SWT wouldn't be able to run there either. >> >> -- >> best regards, >> Anthony From scott.kovatch at oracle.com Thu Apr 5 13:58:15 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 5 Apr 2012 13:58:15 -0700 Subject: [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode In-Reply-To: <3B6D46BF-6CC0-44F0-BC55-F5324BB30037@apple.com> References: <4F7DB3CF.4030802@oracle.com> <1892A20F-DFBA-4788-9F8D-DC0616133B11@apple.com> <4F7DB8D4.2020404@oracle.com> <4F7DFC61.9020904@oracle.com> <3B6D46BF-6CC0-44F0-BC55-F5324BB30037@apple.com> Message-ID: <08B04D13-B9A1-47FD-9E93-C593A88844C2@oracle.com> Support for open-document events was added into the SWT about 4 years ago. I remember Kevin Barnes implemented it across all SWT platforms. I think it shows up as an event you can listen for on the Display. I'm not aware of any SWT apps that cared about sleep/wake events, though I do know there were apps that wanted to add handlers on the application menu items. I added the ability to listen for app menu events entirely in SWT in 3.7. Prior to that you had to use eAWT. -- Scott --------------------------------------- scott.kovatch at oracle.com Santa Clara/Pleasanton, CA On Apr 5, 2012, at 1:31 PM, Mike Swingler wrote: > How would an SWT developer accept new "open document" file double-clicks, or listen for sleep/wake events? AFAIK, eAWT is the only aperture that handles that right now. > > Regards, > Mike Swingler > Apple Inc. > > On Apr 5, 2012, at 1:11 PM, steve.x.northover at oracle.com wrote: > >> Hi all, >> >> Headless mode works fine for SWT. SWT doesn't use eAWT to do Quit etc. Instead, it uses the appropriate native cocoa calls. >> >> Steve >> >> On 05/04/2012 11:23 AM, Anthony Petrov wrote: >>> On 04/05/12 19:07, Mike Swingler wrote: >>>>> Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ >>>>> >>>>> With this fix we avoid setting an application delegate when AWT is started in the headless mode. This prevents a hang when another GUI toolkit (e.g. JavaFX) is already running in the same Java process. >>>> >>>> This would logically mean that you won't get eAWT events (file open, quit, etc) while started in this mode. Does this impact SWT as well? >>> >>> In the headless mode an application doesn't have any UI, and as such there's no way to generate e.g. a Quit action. Hence the application delegate isn't necessary in this mode. >>> >>> SWT uses a special "SWT mode" (== -XstartOnFirstThread) which is different from the headless mode. In the SWT mode the delegate will still be installed. >>> >>> I think this may not work in case of running an SWT application together with the AWT in headless mode. However, I can't imagine who might want to run SWT/AWT in such configuration because the headless mode is supposed to be primarily used in server environments where a display is physically unavailable, in which case SWT wouldn't be able to run there either. >>> >>> -- >>> best regards, >>> Anthony > From steve.x.northover at oracle.com Thu Apr 5 14:10:37 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 05 Apr 2012 17:10:37 -0400 Subject: [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode In-Reply-To: <3B6D46BF-6CC0-44F0-BC55-F5324BB30037@apple.com> References: <4F7DB3CF.4030802@oracle.com> <1892A20F-DFBA-4788-9F8D-DC0616133B11@apple.com> <4F7DB8D4.2020404@oracle.com> <4F7DFC61.9020904@oracle.com> <3B6D46BF-6CC0-44F0-BC55-F5324BB30037@apple.com> Message-ID: <4F7E0A4D.1000503@oracle.com> Hi Mike, It's been a while since I looked at the implementation. Are you telling me that there is no public Apple API to do the things that you describe? Note that we are way off topic ... Steve On 05/04/2012 4:31 PM, Mike Swingler wrote: > How would an SWT developer accept new "open document" file double-clicks, or listen for sleep/wake events? AFAIK, eAWT is the only aperture that handles that right now. > > Regards, > Mike Swingler > Apple Inc. > > On Apr 5, 2012, at 1:11 PM, steve.x.northover at oracle.com wrote: > >> Hi all, >> >> Headless mode works fine for SWT. SWT doesn't use eAWT to do Quit etc. Instead, it uses the appropriate native cocoa calls. >> >> Steve >> >> On 05/04/2012 11:23 AM, Anthony Petrov wrote: >>> On 04/05/12 19:07, Mike Swingler wrote: >>>>> Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ >>>>> >>>>> With this fix we avoid setting an application delegate when AWT is started in the headless mode. This prevents a hang when another GUI toolkit (e.g. JavaFX) is already running in the same Java process. >>>> This would logically mean that you won't get eAWT events (file open, quit, etc) while started in this mode. Does this impact SWT as well? >>> In the headless mode an application doesn't have any UI, and as such there's no way to generate e.g. a Quit action. Hence the application delegate isn't necessary in this mode. >>> >>> SWT uses a special "SWT mode" (== -XstartOnFirstThread) which is different from the headless mode. In the SWT mode the delegate will still be installed. >>> >>> I think this may not work in case of running an SWT application together with the AWT in headless mode. However, I can't imagine who might want to run SWT/AWT in such configuration because the headless mode is supposed to be primarily used in server environments where a display is physically unavailable, in which case SWT wouldn't be able to run there either. >>> >>> -- >>> best regards, >>> Anthony From andrew.brygin at oracle.com Fri Apr 6 01:59:38 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Fri, 06 Apr 2012 12:59:38 +0400 Subject: [7u4] request for review: 7154505: [macosx] NetBeans sometimes starts with no text rendered Message-ID: <4F7EB07A.4010908@oracle.com> Hello, could you please review a fix for CR 7154505? The problem with text rendering happens on mac books with two video boards, and on multi-monitor systems with macosx 10.7. Although a root cause of the problem is still unclear, after a set of experiments we found that suggested change makes the problem gone. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154505 Webrev: http://cr.openjdk.java.net/~bae/7154505/webrev/index.html Thanks, Andrew From alexander.zuev at oracle.com Fri Apr 6 03:15:34 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 06 Apr 2012 14:15:34 +0400 Subject: [7u4] request for review: 7154505: [macosx] NetBeans sometimes starts with no text rendered In-Reply-To: <4F7EB07A.4010908@oracle.com> References: <4F7EB07A.4010908@oracle.com> Message-ID: <4F7EC246.7060504@oracle.com> Andrew, as we indeed setting scratch surface later in flusher i don't see any harm avoiding setting it in the initialization so fix looks Ok. WBR, Alex On 4/6/12 12:59, Andrew Brygin wrote: > Hello, > > could you please review a fix for CR 7154505? > > The problem with text rendering happens on mac books with two > video boards, and on multi-monitor systems with macosx 10.7. > Although a root cause of the problem is still unclear, > after a set of experiments we found that suggested change > makes the problem gone. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154505 > Webrev: http://cr.openjdk.java.net/~bae/7154505/webrev/index.html > > Thanks, > Andrew From anthony.petrov at oracle.com Fri Apr 6 03:37:52 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 06 Apr 2012 14:37:52 +0400 Subject: [7u4] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode In-Reply-To: <4F7DB8D4.2020404@oracle.com> References: <4F7DB3CF.4030802@oracle.com> <1892A20F-DFBA-4788-9F8D-DC0616133B11@apple.com> <4F7DB8D4.2020404@oracle.com> Message-ID: <4F7EC780.8040206@oracle.com> Mike, Steve, Scott, Thanks a lot for your comments! I conclude that SWT is OK to go with this fix. All, Please note the change in the subject line: we're now targeting this fix for 7u4. We really want to push it as is into 7u4. Please review at: http://cr.openjdk.java.net/~anthony/7u4-11-fxHang-7159266.0/ We can re-work this fix for 7u6 if: a) there's real use cases for headless AWT + eAWT API usage. Personally, I doubt there's any, but let's see, AND b) we find a better solution for this problem. However, right now we really need this fix pushed because otherwise the FX software rendering pipline is unusable on the Mac with 7u4. Thanks in advance for your reviews! -- best regards, Anthony On 4/5/2012 7:23 PM, Anthony Petrov wrote: > On 04/05/12 19:07, Mike Swingler wrote: >>> Please review a fix for >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: >>> >>> http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ >>> >>> With this fix we avoid setting an application delegate when AWT is >>> started in the headless mode. This prevents a hang when another GUI >>> toolkit (e.g. JavaFX) is already running in the same Java process. >> >> This would logically mean that you won't get eAWT events (file open, >> quit, etc) while started in this mode. Does this impact SWT as well? > > In the headless mode an application doesn't have any UI, and as such > there's no way to generate e.g. a Quit action. Hence the application > delegate isn't necessary in this mode. > > SWT uses a special "SWT mode" (== -XstartOnFirstThread) which is > different from the headless mode. In the SWT mode the delegate will > still be installed. > > I think this may not work in case of running an SWT application together > with the AWT in headless mode. However, I can't imagine who might want > to run SWT/AWT in such configuration because the headless mode is > supposed to be primarily used in server environments where a display is > physically unavailable, in which case SWT wouldn't be able to run there > either. > > -- > best regards, > Anthony From artem.ananiev at oracle.com Fri Apr 6 03:44:58 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 06 Apr 2012 14:44:58 +0400 Subject: [8] Review request for 7124553: [macosx] Need minimum size for titled Frames and JFrames In-Reply-To: <4F7C540E.1060500@oracle.com> References: <4F6CB1FB.1010700@oracle.com> <4F706C0E.4030908@oracle.com> <4F71B34D.3070801@oracle.com> <4F7AEB84.2030304@oracle.com> <4F7C1979.4040302@oracle.com> <4F7C540E.1060500@oracle.com> Message-ID: <4F7EC92A.5080203@oracle.com> On 4/4/2012 6:00 PM, Anthony Petrov wrote: > Here's a fix that wipes out all traces of the grow box: > > http://cr.openjdk.java.net/~anthony/8-19-frameMinSize-7124553.1/ Looks fine, thank you! Artem > -- > best regards, > Anthony > > On 4/4/2012 1:50 PM, Artem Ananiev wrote: >> >> On 4/3/2012 4:22 PM, Anthony Petrov wrote: >>> Hi Artem, >>> >>> May I consider the fix reviewed, or do you (and anyone else interested) >>> have any further questions/suggestions? >> >> I still think that the code to support 10.6, which will a legacy OS at >> the moment when JDK8 is released, should not be fw-ported from 7u to 8. >> >> Thanks, >> >> Artem >> >>> -- >>> best regards, >>> Anthony >>> >>> On 3/27/2012 4:32 PM, Anthony Petrov wrote: >>>> Hi Artem, >>>> >>>> Thanks for the review. >>>> >>>> Reading through macosx-port-dev@ mailing list I observe a lot of users >>>> who (try to) use Oracle JDK for Mac on Snow Leopard systems, and I see >>>> nothing wrong with that as long as it is runnable on those systems. At >>>> least at this exact moment we don't have a strong reason to drop >>>> support for (this is a wrong word here, rather "ability to run on") >>>> Mac OS X 10.6. When there's some code that ultimately won't run on >>>> Snow Leopard and we drop the support completely, then we may remove >>>> this grow box stuff as well. But currently it doesn't hurt anyone. >>>> >>>> So for now I would like to leave GROW_BOX_SIZE and friends as they >>>> are. Is this OK? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/26/2012 5:15 PM, Artem Ananiev wrote: >>>>> >>>>> Looks fine, but... Is the new constant GROW_BOX_SIZE about pre-Lion >>>>> window resize box at the bottom-right corner of the window? I doubt >>>>> [Snow] Leopard will be in the list of supported platforms for JDK8, >>>>> so it doesn't make any sense to have code specific to this resize box >>>>> in the workspace. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 3/23/2012 9:25 PM, Anthony Petrov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124553 at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/8-19-frameMinSize-7124553.0/ >>>>>> >>>>>> This is a direct forward-port of the same fix from 7u4. >>>>>> >>>>>> More details: >>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003101.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony From philip.race at oracle.com Fri Apr 6 09:09:42 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 06 Apr 2012 09:09:42 -0700 Subject: [7u4] request for review: 7154505: [macosx] NetBeans sometimes starts with no text rendered In-Reply-To: <4F7EC246.7060504@oracle.com> References: <4F7EB07A.4010908@oracle.com> <4F7EC246.7060504@oracle.com> Message-ID: <4F7F1546.1030608@oracle.com> Yep. I don't see anywhere we use it without setting it first. That would seem to be the only possible issue. Could you please correct the spelling of "scrach" -> "scratch" in the comment. Otherwise OK. -phil. On 4/6/12 3:15 AM, Alexander Zuev wrote: > Andrew, > > as we indeed setting scratch surface later in flusher i don't see > any harm avoiding setting it in the initialization > so fix looks Ok. > > WBR, > Alex > > On 4/6/12 12:59, Andrew Brygin wrote: >> Hello, >> >> could you please review a fix for CR 7154505? >> >> The problem with text rendering happens on mac books with two >> video boards, and on multi-monitor systems with macosx 10.7. >> Although a root cause of the problem is still unclear, >> after a set of experiments we found that suggested change >> makes the problem gone. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154505 >> Webrev: http://cr.openjdk.java.net/~bae/7154505/webrev/index.html >> >> Thanks, >> Andrew > From sergey.bylokhov at oracle.com Fri Apr 6 09:25:22 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 06 Apr 2012 20:25:22 +0400 Subject: [8] Request for review: 7150100 [macosx] "0123456789" is selected in the TextField. In-Reply-To: <4F7D7995.70800@oracle.com> References: <4F7336C3.80907@oracle.com> <4F7D7995.70800@oracle.com> Message-ID: <4F7F18F2.8090308@oracle.com> 05.04.2012 14:53, Artem Ananiev ???????: > Hi, Sergey, > > On 3/28/2012 8:05 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Two issues resolved: >> 1) We should set caret position before the text selection. > > it's not clear why this particular change fixes the selection. Could > you add more comments to the bug evaluation, please? comment added: This happens because at the beginning of LWTextComponentPeer initialization we select text and then we call JTextComponent.setCaretPosition() which clears selection. > > Thanks, > > Artem > >> 2) On macosx we clear selection when the test component lost its focus, >> so test was simplified and instructions dialog was removed (because >> sometimes it steal the focus from the text component) >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150100 ** >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7150100/webrev.00/ >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From sergey.bylokhov at oracle.com Fri Apr 6 10:03:39 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 06 Apr 2012 21:03:39 +0400 Subject: [7u6] Request for approval: 7124551 [macosx] Once added, Menu shortcut cannot be removed Message-ID: <4F7F21EB.4090106@oracle.com> Hello, This is a request to push the following changes to jdk7u-dev. This is a back port from jdk 8: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74a1284ca75a The fix has been reviewed on macosx-port-dev mailing list by Artem Ananiev, Anthony Petrov. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00 Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003782.html -- Best regards, Sergey. From edvard.wendelin at oracle.com Fri Apr 6 16:54:50 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 6 Apr 2012 16:54:50 -0700 Subject: [7u6] Request for approval: 7124551 [macosx] Once added, Menu shortcut cannot be removed In-Reply-To: <4F7F21EB.4090106@oracle.com> References: <4F7F21EB.4090106@oracle.com> Message-ID: <23B0CF58-7000-4B29-A660-E3B066876582@oracle.com> Approved. On Apr 6, 2012, at 10:03 AM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u-dev. > This is a back port from jdk 8: > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74a1284ca75a > The fix has been reviewed on macosx-port-dev mailing list by Artem Ananiev, Anthony Petrov. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00 > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003782.html > > -- > Best regards, Sergey. > From artem.ananiev at oracle.com Mon Apr 9 04:03:47 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 09 Apr 2012 15:03:47 +0400 Subject: [8] Request for review: 7150100 [macosx] "0123456789" is selected in the TextField. In-Reply-To: <4F7F18F2.8090308@oracle.com> References: <4F7336C3.80907@oracle.com> <4F7D7995.70800@oracle.com> <4F7F18F2.8090308@oracle.com> Message-ID: <4F82C213.8020609@oracle.com> On 4/6/2012 8:25 PM, Sergey Bylokhov wrote: > 05.04.2012 14:53, Artem Ananiev ???????: >> Hi, Sergey, >> >> On 3/28/2012 8:05 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Two issues resolved: >>> 1) We should set caret position before the text selection. >> >> it's not clear why this particular change fixes the selection. Could >> you add more comments to the bug evaluation, please? > comment added: > This happens because at the beginning of LWTextComponentPeer > initialization we select text and then we call > JTextComponent.setCaretPosition() which clears selection. Thanks. Approved. Artem >> Thanks, >> >> Artem >> >>> 2) On macosx we clear selection when the test component lost its focus, >>> so test was simplified and instructions dialog was removed (because >>> sometimes it steal the focus from the text component) >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150100 ** >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7150100/webrev.00/ >>> >>> -- >>> Best regards, Sergey. >>> > > From Alexander.Potochkin at oracle.com Mon Apr 9 08:06:11 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 09 Apr 2012 19:06:11 +0400 Subject: [7u6] Request for review: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent In-Reply-To: <4F77351B.4000608@oracle.com> References: <4F748EA7.8000305@oracle.com> <4F77351B.4000608@oracle.com> Message-ID: <4F82FAE3.8020503@oracle.com> Hello Sergey > Hi Alexander, > I assume we have the same behavior in xawt too? Should we create > additional CR for xawt? I've no idea if we have the same behavior in xawt Thanks alexp > > 29.03.2012 20:32, Alexander Potochkin wrote: >> Hello >> >> Please review this fix: >> http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ >> >> Thanks >> alexp > > From sergey.bylokhov at oracle.com Mon Apr 9 08:53:04 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 09 Apr 2012 19:53:04 +0400 Subject: [7u6] Request for review: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent In-Reply-To: <4F82FAE3.8020503@oracle.com> References: <4F748EA7.8000305@oracle.com> <4F77351B.4000608@oracle.com> <4F82FAE3.8020503@oracle.com> Message-ID: <4F8305E0.4050005@oracle.com> 09.04.2012 19:06, Alexander Potochkin ???????: > Hello Sergey >> Hi Alexander, >> I assume we have the same behavior in xawt too? Should we create >> additional CR for xawt? > > I've no idea if we have the same behavior in xawt yes, the same. > > Thanks > alexp > >> >> 29.03.2012 20:32, Alexander Potochkin wrote: >>> Hello >>> >>> Please review this fix: >>> http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ >>> >>> Thanks >>> alexp >> >> > -- Best regards, Sergey. From sergey.bylokhov at oracle.com Mon Apr 9 08:57:17 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 09 Apr 2012 19:57:17 +0400 Subject: [8] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking Message-ID: <4F8306DD.1050300@oracle.com> Hi Everyone, Cursor for blocked window was fixed. Now we use default cursor in this case. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147055 Webrev can be found at: http://cr.openjdk.java.net/~serb/7147055/webrev.00 -- Best regards, Sergey. From staffan.larsen at oracle.com Tue Apr 10 02:30:09 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Apr 2012 11:30:09 +0200 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> Message-ID: <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> Any takers for this review? (added core-libs-dev as well) Thanks, /Staffan On 3 apr 2012, at 15:39, Staffan Larsen wrote: > Please review the following fix: > > webrev: http://cr.openjdk.java.net/~sla/7147848/webrev.00/ > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 > > This fix implements the missing functionality in UnixOperatingSystem for Mac OS X. Any feedback on the implementation is welcome as I am not very familiar with the APIs in Mac OS X. > > I have verified that the changes build on all platforms through JPRT. The correctness has been verified manually by looking in JConsole and running the tests in test/java/lang/management/OperatingSystemMXBean test/com/sun/management/OperatingSystemMXBean. > > Thanks, > /Staffan From artem.ananiev at oracle.com Tue Apr 10 03:53:12 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 10 Apr 2012 14:53:12 +0400 Subject: [8] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking In-Reply-To: <4F8306DD.1050300@oracle.com> References: <4F8306DD.1050300@oracle.com> Message-ID: <4F841118.8080203@oracle.com> Hi, Sergey, the changes look fine. Thanks, Artem On 4/9/2012 7:57 PM, Sergey Bylokhov wrote: > Hi Everyone, > Cursor for blocked window was fixed. Now we use default cursor in this case. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147055 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7147055/webrev.00 > > -- > Best regards, Sergey. > From leonid.romanov at oracle.com Tue Apr 10 06:59:40 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 10 Apr 2012 17:59:40 +0400 Subject: [8] Request for review: 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField In-Reply-To: <4F7472A6.4020403@oracle.com> References: <4F74562B.5040702@oracle.com> <6F7AD1B3-C3CF-4A61-8AA4-779AAFD43635@oracle.com> <4F7472A6.4020403@oracle.com> Message-ID: Hi, Here is an updated web rev, with the dead code removed. http://cr.openjdk.java.net/~leonidr/7124272/webrev.03/ On 29.03.2012, at 18:33, Artem Ananiev wrote: > > On 3/29/2012 4:51 PM, Leonid Romanov wrote: >> Yes, you are right in your guess: OS X doesn't generate any kind of "key typed" events, this is why we have to do it manually. As for the dead code in AWTEvent.m, the answer is again yes, it could use some cleaning. Perhaps a separate low priority bug could be filled. > > As this is a request for JDK8 fix, which is of no urgency (yet), it makes sense to perform this refactoring as a part of 7124272. We all know all those low-priority bugs will never be fixed/implemented. > > Thanks, > > Artem > >> On 29.03.2012, at 16:31, Artem Ananiev wrote: >> >>> Hi, Leonid, >>> >>> a general question, not tightly related to the fix. Why do we want to generate KEY_TYPED events from Java? Do we receive such events from the native platform? Probably, not, because I see the following method in AWTEvent.m: >>> >>> static void >>> DeliverKeyTypedEvents(JNIEnv *env, NSEvent *nsEvent, jobject peer) >>> >>> but it is not called from anywhere. Should it be deleted, or reused, or what? >>> >>> Thanks, >>> >>> Artem >>> >>> On 3/27/2012 6:49 PM, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField. This fix has already been pushed into 7u4. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124272 >>>> Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.02/ >>>> >>>> Thanks, >>>> Leonid. >>>> >>>> >> From daniel.daugherty at oracle.com Tue Apr 10 08:58:06 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 10 Apr 2012 09:58:06 -0600 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> Message-ID: <4F84588E.8010702@oracle.com> Staffan, I reviewed it and I think it looks OK. I tried looking at the code in MacosxOperatingSystem.c relative to the Linux version, but I think it is easily possible to miss something subtle here. You might try a direct ping to Mandy Chung since M&M was her area. You might also try a direct ping to Mike Swingler to get an Apple reviewer. Dan On 4/10/12 3:30 AM, Staffan Larsen wrote: > Any takers for this review? (added core-libs-dev as well) > > Thanks, > /Staffan > > On 3 apr 2012, at 15:39, Staffan Larsen wrote: > >> Please review the following fix: >> >> webrev: http://cr.openjdk.java.net/~sla/7147848/webrev.00/ >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 >> >> This fix implements the missing functionality in UnixOperatingSystem >> for Mac OS X. Any feedback on the implementation is welcome as I am >> not very familiar with the APIs in Mac OS X. >> >> I have verified that the changes build on all platforms through JPRT. >> The correctness has been verified manually by looking in JConsole and >> running the tests in test/java/lang/management/OperatingSystemMXBean >> test/com/sun/management/OperatingSystemMXBean. >> >> Thanks, >> /Staffan > From scott.kovatch at oracle.com Tue Apr 10 09:21:18 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 10 Apr 2012 09:21:18 -0700 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <4F84588E.8010702@oracle.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> <4F84588E.8010702@oracle.com> Message-ID: Regarding Apple, Roger Hoover would be a good person to look at this, as he's spent more time in the Darwin levels of the VM. I think he's still partially attached to the OpenJDK work. -- Scott On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote: > Staffan, > > I reviewed it and I think it looks OK. I tried looking at the code > in MacosxOperatingSystem.c relative to the Linux version, but I think > it is easily possible to miss something subtle here. > > You might try a direct ping to Mandy Chung since M&M was her area. > You might also try a direct ping to Mike Swingler to get an Apple > reviewer. > > Dan > > > > On 4/10/12 3:30 AM, Staffan Larsen wrote: >> Any takers for this review? (added core-libs-dev as well) >> >> Thanks, >> /Staffan >> >> On 3 apr 2012, at 15:39, Staffan Larsen wrote: >> >>> Please review the following fix: >>> >>> webrev: http://cr.openjdk.java.net/~sla/7147848/webrev.00/ >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 >>> >>> This fix implements the missing functionality in UnixOperatingSystem for Mac OS X. Any feedback on the implementation is welcome as I am not very familiar with the APIs in Mac OS X. >>> >>> I have verified that the changes build on all platforms through JPRT. The correctness has been verified manually by looking in JConsole and running the tests in test/java/lang/management/OperatingSystemMXBean test/com/sun/management/OperatingSystemMXBean. >>> >>> Thanks, >>> /Staffan >> From anthony.petrov at oracle.com Tue Apr 10 10:23:12 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Apr 2012 21:23:12 +0400 Subject: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen Message-ID: <4F846C80.204@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7131021 at: http://cr.openjdk.java.net/~anthony/7u6-2-keepEnvVars-7131021.0/ The comments added to java_md_macosx.c have been approved by CCC already. This is mainly a review for the newly added test that checks for the environment variables that can be set by the launcher on the Mac. A short background to avoid any confusion regarding the synopsis of the bug. We've discussed the issue thoroughly and come to a conclusion that we want to preserve the existing behavior, i.e. use the environment variables to pass some information from the launcher to AWT. With this fix we add comments to the source code to make sure maintainers of the code are aware of compatibility issues related to the variables, should they need to modify this code. Also, we're adding an automatic regression test that verifies that the launcher correctly sets these variables. -- best regards, Anthony From Alexander.Potochkin at oracle.com Tue Apr 10 10:25:54 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 10 Apr 2012 21:25:54 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value Message-ID: <4F846D22.4030706@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ for this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 the spec for the method javax.swing.JDesktopPane.getAllFrames() says * Returns all JInternalFrames currently displayed in the * desktop. Returns iconified frames as well as expanded frames. but the AquaLookAndFeel on MacOS uses a special container for the minimized internal frames and that's why the current implementation doesn't see them the proposed fix recursively looks for the internal frames among the JDesktopPane's children the test can be found here: http://java.net/jira/browse/MACOSX_PORT-557 Thanks alexp From rhoover at apple.com Tue Apr 10 10:51:33 2012 From: rhoover at apple.com (rhoover) Date: Tue, 10 Apr 2012 11:51:33 -0600 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> <4F84588E.8010702@oracle.com> Message-ID: <07FE6789-E7DA-45F7-999F-6D2E0A62FAEF@apple.com> Scott, Steffan (I am he one who put in the original lines of: return -1.0; // not available being replaced by this patch) I was reluctant to implement these functions because the linux code was quite involved and it appeared to me that there might be some additional semantics to what was implemented than what was indicated by the function names alone. I have not compared the code with the 'top' source, but it looks plausible. As a sanity test, the function values being returned could be printed by a java program and visually compared with the output of 'top' as a system is loaded up. It might also be wise to run the same java program on other platforms to make sure that the magnitude of the numbers is in the same ballpark. On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote: > > Regarding Apple, Roger Hoover would be a good person to look at this, as he's spent more time in the Darwin levels of the VM. I think he's still partially attached to the OpenJDK work. > > -- Scott > > On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote: > >> Staffan, >> >> I reviewed it and I think it looks OK. I tried looking at the code >> in MacosxOperatingSystem.c relative to the Linux version, but I think >> it is easily possible to miss something subtle here. >> >> You might try a direct ping to Mandy Chung since M&M was her area. >> You might also try a direct ping to Mike Swingler to get an Apple >> reviewer. >> >> Dan >> >> >> >> On 4/10/12 3:30 AM, Staffan Larsen wrote: >>> Any takers for this review? (added core-libs-dev as well) >>> >>> Thanks, >>> /Staffan >>> >>> On 3 apr 2012, at 15:39, Staffan Larsen wrote: >>> >>>> Please review the following fix: >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/7147848/webrev.00/ >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 >>>> >>>> This fix implements the missing functionality in UnixOperatingSystem for Mac OS X. Any feedback on the implementation is welcome as I am not very familiar with the APIs in Mac OS X. >>>> >>>> I have verified that the changes build on all platforms through JPRT. The correctness has been verified manually by looking in JConsole and running the tests in test/java/lang/management/OperatingSystemMXBean test/com/sun/management/OperatingSystemMXBean. >>>> >>>> Thanks, >>>> /Staffan >>> > From swingler at apple.com Tue Apr 10 12:54:38 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 10 Apr 2012 12:54:38 -0700 Subject: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen In-Reply-To: <4F846C80.204@oracle.com> References: <4F846C80.204@oracle.com> Message-ID: <115F89A1-385C-4FB2-8B73-1E3B03BAB9F0@apple.com> On Apr 10, 2012, at 10:23 AM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7131021 at: > > http://cr.openjdk.java.net/~anthony/7u6-2-keepEnvVars-7131021.0/ > > The comments added to java_md_macosx.c have been approved by CCC already. This is mainly a review for the newly added test that checks for the environment variables that can be set by the launcher on the Mac. > > A short background to avoid any confusion regarding the synopsis of the bug. We've discussed the issue thoroughly and come to a conclusion that we want to preserve the existing behavior, i.e. use the environment variables to pass some information from the launcher to AWT. With this fix we add comments to the source code to make sure maintainers of the code are aware of compatibility issues related to the variables, should they need to modify this code. Also, we're adding an automatic regression test that verifies that the launcher correctly sets these variables. This looks good. The only comment I would add is that the _ part is attached so that sub-invocations of Java tools won't stomp on each other's environment variables, which inherit from parent to child. Cheers, Mike Swingler Apple Inc. From mandy.chung at oracle.com Tue Apr 10 12:57:30 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Apr 2012 12:57:30 -0700 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <07FE6789-E7DA-45F7-999F-6D2E0A62FAEF@apple.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> <4F84588E.8010702@oracle.com> <07FE6789-E7DA-45F7-999F-6D2E0A62FAEF@apple.com> Message-ID: <4F8490AA.8000208@oracle.com> Staffan, Roger, There isn't any undocumented semantics other than what the specification for com.sun.management.OperatingSystemMXBean specifies (that is indicated by its method name): http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html As Roger suggests, you can do some sanity tests and compare the result with native commands (top or other CLI). There are a few regression tests in jdk/test/com/sun/management. In particular, you might want to update test/com/sun/management/TestTotalSwap.sh to check the swap space with a suitable macosx command, if there is one. FYI. I'm not familiar with Mac OS X API and didn't review the code. Mandy On 4/10/2012 10:51 AM, rhoover wrote: > Scott, Steffan > > (I am he one who put in the original lines of: return -1.0; // not available being replaced by this patch) > > I was reluctant to implement these functions because the linux code was quite involved and it appeared to me that there might be some additional semantics to what was implemented than what was indicated by the function names alone. > > I have not compared the code with the 'top' source, but it looks plausible. As a sanity test, the function values being returned could be printed by a java program and visually compared with the output of 'top' as a system is loaded up. It might also be wise to run the same java program on other platforms to make sure that the magnitude of the numbers is in the same ballpark. > > On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote: > >> Regarding Apple, Roger Hoover would be a good person to look at this, as he's spent more time in the Darwin levels of the VM. I think he's still partially attached to the OpenJDK work. >> >> -- Scott >> >> On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote: >> >>> Staffan, >>> >>> I reviewed it and I think it looks OK. I tried looking at the code >>> in MacosxOperatingSystem.c relative to the Linux version, but I think >>> it is easily possible to miss something subtle here. >>> >>> You might try a direct ping to Mandy Chung since M&M was her area. >>> You might also try a direct ping to Mike Swingler to get an Apple >>> reviewer. >>> >>> Dan >>> >>> >>> >>> On 4/10/12 3:30 AM, Staffan Larsen wrote: >>>> Any takers for this review? (added core-libs-dev as well) >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 3 apr 2012, at 15:39, Staffan Larsen wrote: >>>> >>>>> Please review the following fix: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/7147848/webrev.00/ >>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 >>>>> >>>>> This fix implements the missing functionality in UnixOperatingSystem for Mac OS X. Any feedback on the implementation is welcome as I am not very familiar with the APIs in Mac OS X. >>>>> >>>>> I have verified that the changes build on all platforms through JPRT. The correctness has been verified manually by looking in JConsole and running the tests in test/java/lang/management/OperatingSystemMXBean test/com/sun/management/OperatingSystemMXBean. >>>>> >>>>> Thanks, >>>>> /Staffan From Dmitry.Samersoff at oracle.com Tue Apr 10 15:04:41 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 11 Apr 2012 02:04:41 +0400 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> Message-ID: <4F84AE79.3020305@oracle.com> Staffan, 1. MacosxOperatingSystem.c 49 return 0; Probably it should be -1 here. NIT: 133 if (gettimeofday(&now, NULL)) { if (gettimeofday(&now, NULL) < 0) { - IMHO is more readable. -Dmitry On 2012-04-03 17:39, Staffan Larsen wrote: > Please review the following fix: > > webrev: http://cr.openjdk.java.net/~sla/7147848/webrev.00/ > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 > > This fix implements the missing functionality in UnixOperatingSystem for > Mac OS X. Any feedback on the implementation is welcome as I am not very > familiar with the APIs in Mac OS X. > > I have verified that the changes build on all platforms through JPRT. > The correctness has been verified manually by looking in JConsole and > running the tests in test/java/lang/management/OperatingSystemMXBean > test/com/sun/management/OperatingSystemMXBean. > > Thanks, > /Staffan -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From kumar.x.srinivasan at oracle.com Tue Apr 10 20:16:19 2012 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 10 Apr 2012 20:16:19 -0700 (PDT) Subject: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen Message-ID: Hi Anthony, I personally don't want to see shell based test, I spent several hours cleaning up the shell tests in the launcher area for jdk8, there are few left, I will get to them sooner or later. I am assuming this will be forward ported to jdk8. Having said that, I have done the following, which simplifies a great deal. 1. Removed the shell script 2. Piggy back the test control onto TestSpecialArgs.java which was introduced for MacOSX, anyway. 3. Java invoking java exposed an unique problem where we have multiple env variables ex: JAVA_MAIN_CLASS_ABC=com.sun.javatest.regtest.Main JAVA_MAIN_CLASS_XYZ=EnvironmentVariables To fix the above, TestHelper needed some adjustments. It was simpler to show you the changes in a webrev. :) Full webrev is here: http://cr.openjdk.java.net/~ksrini/7131021/webrev/ The incremental changes wrt. your changes are here: http://cr.openjdk.java.net/~ksrini/7131021/webrev/webrev.delta/index.html I have tested the above changes on Mac and Solaris. Thanks Kumar ----- anthony.petrov at oracle.com wrote: > From: anthony.petrov at oracle.com > To: macosx-port-dev at openjdk.java.net, kumar.x.srinivasan at oracle.COM > Sent: Tuesday, April 10, 2012 10:23:19 AM GMT -08:00 US/Canada Pacific > Subject: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the > launcher to AWT/SplashScreen > > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7131021 > at: > > http://cr.openjdk.java.net/~anthony/7u6-2-keepEnvVars-7131021.0/ > > The comments added to java_md_macosx.c have been approved by CCC > already. This is mainly a review for the newly added test that checks > > for the environment variables that can be set by the launcher on the > Mac. > > A short background to avoid any confusion regarding the synopsis of > the > bug. We've discussed the issue thoroughly and come to a conclusion > that > we want to preserve the existing behavior, i.e. use the environment > variables to pass some information from the launcher to AWT. With this > > fix we add comments to the source code to make sure maintainers of the > > code are aware of compatibility issues related to the variables, > should > they need to modify this code. Also, we're adding an automatic > regression test that verifies that the launcher correctly sets these > variables. > > -- > best regards, > Anthony From staffan.larsen at oracle.com Wed Apr 11 00:52:58 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Apr 2012 09:52:58 +0200 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <4F8490AA.8000208@oracle.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> <4F84588E.8010702@oracle.com> <07FE6789-E7DA-45F7-999F-6D2E0A62FAEF@apple.com> <4F8490AA.8000208@oracle.com> Message-ID: <3567B062-5700-48BA-B691-1A0A2AC3E412@oracle.com> Thank you all for your comments! New webrev here: http://cr.openjdk.java.net/~sla/7147848/webrev.01/ Changes: - Fixed Dmitry's comments - Updated TestTotalSwap.sh for Darwin (thanks Mandy) I have verified the values manually by running a Java program (see attachment) and comparing to top and other system utilities. I've also compared output with a Linux system to compare magnitude of numbers. I have run the various regression tests. Thanks, /Staffan On 10 apr 2012, at 21:57, Mandy Chung wrote: > Staffan, Roger, > > There isn't any undocumented semantics other than what the specification for com.sun.management.OperatingSystemMXBean specifies (that is indicated by its method name): > http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html > > As Roger suggests, you can do some sanity tests and compare the result with native commands (top or other CLI). There are a few regression tests in jdk/test/com/sun/management. In particular, you might want to update test/com/sun/management/TestTotalSwap.sh to check the swap space with a suitable macosx command, if there is one. > > FYI. I'm not familiar with Mac OS X API and didn't review the code. > > Mandy > > On 4/10/2012 10:51 AM, rhoover wrote: >> Scott, Steffan >> >> (I am he one who put in the original lines of: return -1.0; // not available being replaced by this patch) >> >> I was reluctant to implement these functions because the linux code was quite involved and it appeared to me that there might be some additional semantics to what was implemented than what was indicated by the function names alone. >> >> I have not compared the code with the 'top' source, but it looks plausible. As a sanity test, the function values being returned could be printed by a java program and visually compared with the output of 'top' as a system is loaded up. It might also be wise to run the same java program on other platforms to make sure that the magnitude of the numbers is in the same ballpark. >> >> On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote: >> >>> Regarding Apple, Roger Hoover would be a good person to look at this, as he's spent more time in the Darwin levels of the VM. I think he's still partially attached to the OpenJDK work. >>> >>> -- Scott >>> >>> On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote: >>> >>>> Staffan, >>>> >>>> I reviewed it and I think it looks OK. I tried looking at the code >>>> in MacosxOperatingSystem.c relative to the Linux version, but I think >>>> it is easily possible to miss something subtle here. >>>> >>>> You might try a direct ping to Mandy Chung since M&M was her area. >>>> You might also try a direct ping to Mike Swingler to get an Apple >>>> reviewer. >>>> >>>> Dan >>>> >>>> >>>> >>>> On 4/10/12 3:30 AM, Staffan Larsen wrote: >>>>> Any takers for this review? (added core-libs-dev as well) >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 3 apr 2012, at 15:39, Staffan Larsen wrote: >>>>> >>>>>> Please review the following fix: >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~sla/7147848/webrev.00/ >>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 >>>>>> >>>>>> This fix implements the missing functionality in UnixOperatingSystem for Mac OS X. Any feedback on the implementation is welcome as I am not very familiar with the APIs in Mac OS X. >>>>>> >>>>>> I have verified that the changes build on all platforms through JPRT. The correctness has been verified manually by looking in JConsole and running the tests in test/java/lang/management/OperatingSystemMXBean test/com/sun/management/OperatingSystemMXBean. >>>>>> >>>>>> Thanks, >>>>>> /Staffan From artem.ananiev at oracle.com Wed Apr 11 03:02:56 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Apr 2012 14:02:56 +0400 Subject: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen In-Reply-To: <4F846C80.204@oracle.com> References: <4F846C80.204@oracle.com> Message-ID: <4F8556D0.1020000@oracle.com> Hi, Anthony, the test and comments look fine. Thanks, Artem On 4/10/2012 9:23 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7131021 at: > > http://cr.openjdk.java.net/~anthony/7u6-2-keepEnvVars-7131021.0/ > > The comments added to java_md_macosx.c have been approved by CCC > already. This is mainly a review for the newly added test that checks > for the environment variables that can be set by the launcher on the Mac. > > A short background to avoid any confusion regarding the synopsis of the > bug. We've discussed the issue thoroughly and come to a conclusion that > we want to preserve the existing behavior, i.e. use the environment > variables to pass some information from the launcher to AWT. With this > fix we add comments to the source code to make sure maintainers of the > code are aware of compatibility issues related to the variables, should > they need to modify this code. Also, we're adding an automatic > regression test that verifies that the launcher correctly sets these > variables. > > -- > best regards, > Anthony From Dmitry.Samersoff at oracle.com Wed Apr 11 03:33:52 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 11 Apr 2012 14:33:52 +0400 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <3567B062-5700-48BA-B691-1A0A2AC3E412@oracle.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> <4F84588E.8010702@oracle.com> <07FE6789-E7DA-45F7-999F-6D2E0A62FAEF@apple.com> <4F8490AA.8000208@oracle.com> <3567B062-5700-48BA-B691-1A0A2AC3E412@oracle.com> Message-ID: <4F855E10.90805@oracle.com> Staffan, MacosxOperatingSystem.c Probably something went wrong with webrev: 48 if (kr != KERN_SUCCESS) { 49 return 0; 50 } 133 if (gettimeofday(&now, NULL)) { 134 return -1; 135 } -Dmitry On 2012-04-11 11:52, Staffan Larsen wrote: > Thank you all for your comments! > > New webrev here: http://cr.openjdk.java.net/~sla/7147848/webrev.01/ > > Changes: > - Fixed Dmitry's comments > - Updated TestTotalSwap.sh for Darwin (thanks Mandy) > > I have verified the values manually by running a Java program (see > attachment) and comparing to top and other system utilities. I've also > compared output with a Linux system to compare magnitude of numbers. I > have run the various regression tests. > > Thanks, > /Staffan > > > > > On 10 apr 2012, at 21:57, Mandy Chung wrote: > >> Staffan, Roger, >> >> There isn't any undocumented semantics other than what the >> specification for com.sun.management.OperatingSystemMXBean specifies >> (that is indicated by its method name): >> http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html >> >> As Roger suggests, you can do some sanity tests and compare the result >> with native commands (top or other CLI). There are a few regression >> tests in jdk/test/com/sun/management. In particular, you might want to >> update test/com/sun/management/TestTotalSwap.sh to check the swap >> space with a suitable macosx command, if there is one. >> >> FYI. I'm not familiar with Mac OS X API and didn't review the code. >> >> Mandy >> >> On 4/10/2012 10:51 AM, rhoover wrote: >>> Scott, Steffan >>> >>> (I am he one who put in the original lines of: return -1.0; // not >>> available being replaced by this patch) >>> >>> I was reluctant to implement these functions because the linux code >>> was quite involved and it appeared to me that there might be some >>> additional semantics to what was implemented than what was indicated >>> by the function names alone. >>> >>> I have not compared the code with the 'top' source, but it looks >>> plausible. As a sanity test, the function values being returned could >>> be printed by a java program and visually compared with the output of >>> 'top' as a system is loaded up. It might also be wise to run the same >>> java program on other platforms to make sure that the magnitude of >>> the numbers is in the same ballpark. >>> >>> On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote: >>> >>>> Regarding Apple, Roger Hoover would be a good person to look at >>>> this, as he's spent more time in the Darwin levels of the VM. I >>>> think he's still partially attached to the OpenJDK work. >>>> >>>> -- Scott >>>> >>>> On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote: >>>> >>>>> Staffan, >>>>> >>>>> I reviewed it and I think it looks OK. I tried looking at the code >>>>> in MacosxOperatingSystem.c relative to the Linux version, but I think >>>>> it is easily possible to miss something subtle here. >>>>> >>>>> You might try a direct ping to Mandy Chung since M&M was her area. >>>>> You might also try a direct ping to Mike Swingler to get an Apple >>>>> reviewer. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> On 4/10/12 3:30 AM, Staffan Larsen wrote: >>>>>> Any takers for this review? (added core-libs-dev as well) >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 3 apr 2012, at 15:39, Staffan Larsen wrote: >>>>>> >>>>>>> Please review the following fix: >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~sla/7147848/webrev.00/ >>>>>>> > >>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 >>>>>>> >>>>>>> This fix implements the missing functionality in >>>>>>> UnixOperatingSystem for Mac OS X. Any feedback on the >>>>>>> implementation is welcome as I am not very familiar with the APIs >>>>>>> in Mac OS X. >>>>>>> >>>>>>> I have verified that the changes build on all platforms through >>>>>>> JPRT. The correctness has been verified manually by looking in >>>>>>> JConsole and running the tests in >>>>>>> test/java/lang/management/OperatingSystemMXBean >>>>>>> test/com/sun/management/OperatingSystemMXBean. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From anthony.petrov at oracle.com Wed Apr 11 04:54:33 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Apr 2012 15:54:33 +0400 Subject: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen In-Reply-To: References: Message-ID: <4F8570F9.6040209@oracle.com> Hi Kumar and Mike, Thanks for the review! Initially I wanted to invoke the sub-tests from Java, too, but the Runtime functionality won't let me redirect input/output/error streams from a child process, so I ended up with a shell test. Given that launcher tests already employ the ProcessBuilder, and thus deal with IO streams redirection, I like the idea of using it for this test as well. The changes suggested by Kumar look great. Thanks! I've also incorporated feedback from Mike and added a line to the comments that explains the necessity for the _ part. Here's the updated webrev: http://cr.openjdk.java.net/~anthony/7u6-2-keepEnvVars-7131021.1/ -- best regards, Anthony On 4/11/2012 7:16 AM, Kumar Srinivasan wrote: > Hi Anthony, > > I personally don't want to see shell based test, I spent > several hours cleaning up the shell tests in the launcher area > for jdk8, there are few left, I will get to them sooner > or later. I am assuming this will be forward ported to jdk8. > > Having said that, I have done the following, which simplifies > a great deal. > > 1. Removed the shell script > 2. Piggy back the test control onto TestSpecialArgs.java > which was introduced for MacOSX, anyway. > 3. Java invoking java exposed an unique problem where > we have multiple env variables > ex: > JAVA_MAIN_CLASS_ABC=com.sun.javatest.regtest.Main > JAVA_MAIN_CLASS_XYZ=EnvironmentVariables > > To fix the above, TestHelper needed some adjustments. > > > It was simpler to show you the changes in a webrev. :) > Full webrev is here: > http://cr.openjdk.java.net/~ksrini/7131021/webrev/ > > The incremental changes wrt. your changes are here: > http://cr.openjdk.java.net/~ksrini/7131021/webrev/webrev.delta/index.html > > I have tested the above changes on Mac and Solaris. > > Thanks > Kumar > > ----- anthony.petrov at oracle.com wrote: > >> From: anthony.petrov at oracle.com >> To: macosx-port-dev at openjdk.java.net, kumar.x.srinivasan at oracle.COM >> Sent: Tuesday, April 10, 2012 10:23:19 AM GMT -08:00 US/Canada Pacific >> Subject: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the >> launcher to AWT/SplashScreen >> >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7131021 >> at: >> >> http://cr.openjdk.java.net/~anthony/7u6-2-keepEnvVars-7131021.0/ >> >> The comments added to java_md_macosx.c have been approved by CCC >> already. This is mainly a review for the newly added test that checks >> >> for the environment variables that can be set by the launcher on the >> Mac. >> >> A short background to avoid any confusion regarding the synopsis of >> the >> bug. We've discussed the issue thoroughly and come to a conclusion >> that >> we want to preserve the existing behavior, i.e. use the environment >> variables to pass some information from the launcher to AWT. With this >> >> fix we add comments to the source code to make sure maintainers of the >> >> code are aware of compatibility issues related to the variables, >> should >> they need to modify this code. Also, we're adding an automatic >> regression test that verifies that the launcher correctly sets these >> variables. >> >> -- >> best regards, >> Anthony From anthony.petrov at oracle.com Wed Apr 11 05:26:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Apr 2012 16:26:18 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F846D22.4030706@oracle.com> References: <4F846D22.4030706@oracle.com> Message-ID: <4F85786A.3060407@oracle.com> Hi Alex, It seems like the new private getAllFrames(Contianer) method may be declared as static. Also I suggest to insert spaces between "if"s and "("s at lines 275, 277, and 282. Otherwise the changes look good. BTW, do we have any regression tests for this method? Do they pass? What about the performance regression caused by iterating over the inner containers? -- best regards, Anthony On 4/10/2012 9:25 PM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ > > for this bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 > > the spec for the method > javax.swing.JDesktopPane.getAllFrames() > > says > > * Returns all JInternalFrames currently displayed in the > * desktop. Returns iconified frames as well as expanded frames. > > but the AquaLookAndFeel on MacOS uses a special container for the > minimized internal frames > and that's why the current implementation doesn't see them > > the proposed fix recursively looks for the internal frames > among the JDesktopPane's children > > the test can be found here: > http://java.net/jira/browse/MACOSX_PORT-557 > > Thanks > alexp From kumar.x.srinivasan at oracle.com Wed Apr 11 05:54:53 2012 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 11 Apr 2012 05:54:53 -0700 (PDT) Subject: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen Message-ID: <2b2f5654-7558-442a-be90-bce7ea0cb12a@default> Hi Anthony, Looks good!, and a big thanks for doing this. Kumar ----- anthony.petrov at oracle.com wrote: > From: anthony.petrov at oracle.com > To: kumar.x.srinivasan at oracle.com, swingler at apple.com > Cc: macosx-port-dev at openjdk.java.net > Sent: Wednesday, April 11, 2012 4:54:38 AM GMT -08:00 US/Canada Pacific > Subject: Re: [7u6] Review request for 7131021: [macosx] Consider using system properties to pass arguments from the > launcher to AWT/SplashScreen > > Hi Kumar and Mike, > > Thanks for the review! > > Initially I wanted to invoke the sub-tests from Java, too, but the > Runtime functionality won't let me redirect input/output/error streams > > from a child process, so I ended up with a shell test. > > Given that launcher tests already employ the ProcessBuilder, and thus > > deal with IO streams redirection, I like the idea of using it for this > > test as well. The changes suggested by Kumar look great. Thanks! > > I've also incorporated feedback from Mike and added a line to the > comments that explains the necessity for the _ part. > > Here's the updated webrev: > > http://cr.openjdk.java.net/~anthony/7u6-2-keepEnvVars-7131021.1/ > > -- > best regards, > Anthony > > On 4/11/2012 7:16 AM, Kumar Srinivasan wrote: > > Hi Anthony, > > > > I personally don't want to see shell based test, I spent > > several hours cleaning up the shell tests in the launcher area > > for jdk8, there are few left, I will get to them sooner > > or later. I am assuming this will be forward ported to jdk8. > > > > Having said that, I have done the following, which simplifies > > a great deal. > > > > 1. Removed the shell script > > 2. Piggy back the test control onto TestSpecialArgs.java > > which was introduced for MacOSX, anyway. > > 3. Java invoking java exposed an unique problem where > > we have multiple env variables > > ex: > > JAVA_MAIN_CLASS_ABC=com.sun.javatest.regtest.Main > > JAVA_MAIN_CLASS_XYZ=EnvironmentVariables > > > > To fix the above, TestHelper needed some adjustments. > > > > > > It was simpler to show you the changes in a webrev. :) > > Full webrev is here: > > http://cr.openjdk.java.net/~ksrini/7131021/webrev/ > > > > The incremental changes wrt. your changes are here: > > > http://cr.openjdk.java.net/~ksrini/7131021/webrev/webrev.delta/index.html > > > > I have tested the above changes on Mac and Solaris. > > > > Thanks > > Kumar > > > > ----- anthony.petrov at oracle.com wrote: > > > >> From: anthony.petrov at oracle.com > >> To: macosx-port-dev at openjdk.java.net, > kumar.x.srinivasan at oracle.COM > >> Sent: Tuesday, April 10, 2012 10:23:19 AM GMT -08:00 US/Canada > Pacific > >> Subject: [7u6] Review request for 7131021: [macosx] Consider using > system properties to pass arguments from the > >> launcher to AWT/SplashScreen > >> > >> Hello, > >> > >> Please review a fix for > http://bugs.sun.com/view_bug.do?bug_id=7131021 > >> at: > >> > >> http://cr.openjdk.java.net/~anthony/7u6-2-keepEnvVars-7131021.0/ > >> > >> The comments added to java_md_macosx.c have been approved by CCC > >> already. This is mainly a review for the newly added test that > checks > >> > >> for the environment variables that can be set by the launcher on > the > >> Mac. > >> > >> A short background to avoid any confusion regarding the synopsis > of > >> the > >> bug. We've discussed the issue thoroughly and come to a conclusion > >> that > >> we want to preserve the existing behavior, i.e. use the environment > > >> variables to pass some information from the launcher to AWT. With > this > >> > >> fix we add comments to the source code to make sure maintainers of > the > >> > >> code are aware of compatibility issues related to the variables, > >> should > >> they need to modify this code. Also, we're adding an automatic > >> regression test that verifies that the launcher correctly sets > these > >> variables. > >> > >> -- > >> best regards, > >> Anthony From staffan.larsen at oracle.com Wed Apr 11 09:24:14 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Apr 2012 18:24:14 +0200 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <4F855E10.90805@oracle.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> <4F84588E.8010702@oracle.com> <07FE6789-E7DA-45F7-999F-6D2E0A62FAEF@apple.com> <4F8490AA.8000208@oracle.com> <3567B062-5700-48BA-B691-1A0A2AC3E412@oracle.com> <4F855E10.90805@oracle.com> Message-ID: <53FB22EA-AAD6-4CC3-B212-CC5D592DC088@oracle.com> Apparently something went wrong with the webrev. Here is new one: http://cr.openjdk.java.net/~sla/7147848/webrev.02/ Thanks Dmitry, /Staffan On 11 apr 2012, at 12:33, Dmitry Samersoff wrote: > Staffan, > > MacosxOperatingSystem.c > > Probably something went wrong with webrev: > > 48 if (kr != KERN_SUCCESS) { > 49 return 0; > 50 } > > > 133 if (gettimeofday(&now, NULL)) { > 134 return -1; > 135 } > > -Dmitry > > > On 2012-04-11 11:52, Staffan Larsen wrote: >> Thank you all for your comments! >> >> New webrev here: http://cr.openjdk.java.net/~sla/7147848/webrev.01/ >> >> Changes: >> - Fixed Dmitry's comments >> - Updated TestTotalSwap.sh for Darwin (thanks Mandy) >> >> I have verified the values manually by running a Java program (see >> attachment) and comparing to top and other system utilities. I've also >> compared output with a Linux system to compare magnitude of numbers. I >> have run the various regression tests. >> >> Thanks, >> /Staffan >> >> >> >> >> On 10 apr 2012, at 21:57, Mandy Chung wrote: >> >>> Staffan, Roger, >>> >>> There isn't any undocumented semantics other than what the >>> specification for com.sun.management.OperatingSystemMXBean specifies >>> (that is indicated by its method name): >>> http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html >>> >>> As Roger suggests, you can do some sanity tests and compare the result >>> with native commands (top or other CLI). There are a few regression >>> tests in jdk/test/com/sun/management. In particular, you might want to >>> update test/com/sun/management/TestTotalSwap.sh to check the swap >>> space with a suitable macosx command, if there is one. >>> >>> FYI. I'm not familiar with Mac OS X API and didn't review the code. >>> >>> Mandy >>> >>> On 4/10/2012 10:51 AM, rhoover wrote: >>>> Scott, Steffan >>>> >>>> (I am he one who put in the original lines of: return -1.0; // not >>>> available being replaced by this patch) >>>> >>>> I was reluctant to implement these functions because the linux code >>>> was quite involved and it appeared to me that there might be some >>>> additional semantics to what was implemented than what was indicated >>>> by the function names alone. >>>> >>>> I have not compared the code with the 'top' source, but it looks >>>> plausible. As a sanity test, the function values being returned could >>>> be printed by a java program and visually compared with the output of >>>> 'top' as a system is loaded up. It might also be wise to run the same >>>> java program on other platforms to make sure that the magnitude of >>>> the numbers is in the same ballpark. >>>> >>>> On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote: >>>> >>>>> Regarding Apple, Roger Hoover would be a good person to look at >>>>> this, as he's spent more time in the Darwin levels of the VM. I >>>>> think he's still partially attached to the OpenJDK work. >>>>> >>>>> -- Scott >>>>> >>>>> On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> I reviewed it and I think it looks OK. I tried looking at the code >>>>>> in MacosxOperatingSystem.c relative to the Linux version, but I think >>>>>> it is easily possible to miss something subtle here. >>>>>> >>>>>> You might try a direct ping to Mandy Chung since M&M was her area. >>>>>> You might also try a direct ping to Mike Swingler to get an Apple >>>>>> reviewer. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>>> On 4/10/12 3:30 AM, Staffan Larsen wrote: >>>>>>> Any takers for this review? (added core-libs-dev as well) >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 3 apr 2012, at 15:39, Staffan Larsen wrote: >>>>>>> >>>>>>>> Please review the following fix: >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~sla/7147848/webrev.00/ >>>>>>>> > >>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 >>>>>>>> >>>>>>>> This fix implements the missing functionality in >>>>>>>> UnixOperatingSystem for Mac OS X. Any feedback on the >>>>>>>> implementation is welcome as I am not very familiar with the APIs >>>>>>>> in Mac OS X. >>>>>>>> >>>>>>>> I have verified that the changes build on all platforms through >>>>>>>> JPRT. The correctness has been verified manually by looking in >>>>>>>> JConsole and running the tests in >>>>>>>> test/java/lang/management/OperatingSystemMXBean >>>>>>>> test/com/sun/management/OperatingSystemMXBean. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From Dmitry.Samersoff at oracle.com Wed Apr 11 11:01:38 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 11 Apr 2012 22:01:38 +0400 Subject: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values In-Reply-To: <53FB22EA-AAD6-4CC3-B212-CC5D592DC088@oracle.com> References: <694BFB79-DE09-492C-860E-F82DD5D3E5AF@oracle.com> <8C8B239C-4A32-4B15-AB07-A18320E105BF@oracle.com> <4F84588E.8010702@oracle.com> <07FE6789-E7DA-45F7-999F-6D2E0A62FAEF@apple.com> <4F8490AA.8000208@oracle.com> <3567B062-5700-48BA-B691-1A0A2AC3E412@oracle.com> <4F855E10.90805@oracle.com> <53FB22EA-AAD6-4CC3-B212-CC5D592DC088@oracle.com> Message-ID: <4F85C702.1040303@oracle.com> Looks good for me. -Dmitry On 2012-04-11 20:24, Staffan Larsen wrote: > Apparently something went wrong with the webrev. Here is new one: > > http://cr.openjdk.java.net/~sla/7147848/webrev.02/ > > Thanks Dmitry, > /Staffan > > On 11 apr 2012, at 12:33, Dmitry Samersoff wrote: > >> Staffan, >> >> MacosxOperatingSystem.c >> >> Probably something went wrong with webrev: >> >> 48 if (kr != KERN_SUCCESS) { >> 49 return 0; >> 50 } >> >> >> 133 if (gettimeofday(&now, NULL)) { >> 134 return -1; >> 135 } >> >> -Dmitry >> >> >> On 2012-04-11 11:52, Staffan Larsen wrote: >>> Thank you all for your comments! >>> >>> New webrev here: http://cr.openjdk.java.net/~sla/7147848/webrev.01/ >>> >>> Changes: >>> - Fixed Dmitry's comments >>> - Updated TestTotalSwap.sh for Darwin (thanks Mandy) >>> >>> I have verified the values manually by running a Java program (see >>> attachment) and comparing to top and other system utilities. I've also >>> compared output with a Linux system to compare magnitude of numbers. I >>> have run the various regression tests. >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> >>> On 10 apr 2012, at 21:57, Mandy Chung wrote: >>> >>>> Staffan, Roger, >>>> >>>> There isn't any undocumented semantics other than what the >>>> specification for com.sun.management.OperatingSystemMXBean specifies >>>> (that is indicated by its method name): >>>> http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html >>>> >>>> As Roger suggests, you can do some sanity tests and compare the result >>>> with native commands (top or other CLI). There are a few regression >>>> tests in jdk/test/com/sun/management. In particular, you might want to >>>> update test/com/sun/management/TestTotalSwap.sh to check the swap >>>> space with a suitable macosx command, if there is one. >>>> >>>> FYI. I'm not familiar with Mac OS X API and didn't review the code. >>>> >>>> Mandy >>>> >>>> On 4/10/2012 10:51 AM, rhoover wrote: >>>>> Scott, Steffan >>>>> >>>>> (I am he one who put in the original lines of: return -1.0; // not >>>>> available being replaced by this patch) >>>>> >>>>> I was reluctant to implement these functions because the linux code >>>>> was quite involved and it appeared to me that there might be some >>>>> additional semantics to what was implemented than what was indicated >>>>> by the function names alone. >>>>> >>>>> I have not compared the code with the 'top' source, but it looks >>>>> plausible. As a sanity test, the function values being returned could >>>>> be printed by a java program and visually compared with the output of >>>>> 'top' as a system is loaded up. It might also be wise to run the same >>>>> java program on other platforms to make sure that the magnitude of >>>>> the numbers is in the same ballpark. >>>>> >>>>> On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote: >>>>> >>>>>> Regarding Apple, Roger Hoover would be a good person to look at >>>>>> this, as he's spent more time in the Darwin levels of the VM. I >>>>>> think he's still partially attached to the OpenJDK work. >>>>>> >>>>>> -- Scott >>>>>> >>>>>> On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote: >>>>>> >>>>>>> Staffan, >>>>>>> >>>>>>> I reviewed it and I think it looks OK. I tried looking at the code >>>>>>> in MacosxOperatingSystem.c relative to the Linux version, but I think >>>>>>> it is easily possible to miss something subtle here. >>>>>>> >>>>>>> You might try a direct ping to Mandy Chung since M&M was her area. >>>>>>> You might also try a direct ping to Mike Swingler to get an Apple >>>>>>> reviewer. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/10/12 3:30 AM, Staffan Larsen wrote: >>>>>>>> Any takers for this review? (added core-libs-dev as well) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 3 apr 2012, at 15:39, Staffan Larsen wrote: >>>>>>>> >>>>>>>>> Please review the following fix: >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~sla/7147848/webrev.00/ >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >> >>>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848 >>>>>>>>> >>>>>>>>> This fix implements the missing functionality in >>>>>>>>> UnixOperatingSystem for Mac OS X. Any feedback on the >>>>>>>>> implementation is welcome as I am not very familiar with the APIs >>>>>>>>> in Mac OS X. >>>>>>>>> >>>>>>>>> I have verified that the changes build on all platforms through >>>>>>>>> JPRT. The correctness has been verified manually by looking in >>>>>>>>> JConsole and running the tests in >>>>>>>>> test/java/lang/management/OperatingSystemMXBean >>>>>>>>> test/com/sun/management/OperatingSystemMXBean. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Alan.Bateman at oracle.com Thu Apr 12 04:08:43 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Apr 2012 12:08:43 +0100 Subject: 7143744: (se) Stabilize KQueue SelectorProvider and make default on MacOSX Message-ID: <4F86B7BB.1000405@oracle.com> I need a reviewer for a patch that fixes several issues with the kqueue SelectorProvider. It also restores it to be the default SelectorProvider on MacOSX. Note that these changes are for jdk8. Once they have baked for a while in 8 then we should consider them for jdk7u too. As background, Apple contributed their kqueue SelectorProvider to the macosx-port project [1] as it's more scalable than the poll based SelectorProvider that the bsd-port project was using. Unfortunately the kqueue SelectorProvider had a few issues and there were several test failures. In the end the default was switched back to the poll SelectorProvider [2], pending resolution of these issues. I've finally got a chance to look at the issues and have a webrev with the changes here: http://cr.openjdk.java.net/~alanb/7143744/webrev The main issue is the SelectorProvider didn't work correctly with channels that are registered for more than one op at a time (OP_READ | OP_WRITE for example). If more than one event was retrieved for the same file descriptor then the ready ops were replaced rather than updated. This stems from having the same file descriptor associated with more than one filter. The return from the select or selectNow methods was incorrect for these cases too (double accounting). There were also intermittent CancelledKeyException issues when keys were canceled or channels closed at around the same time as a select. There was also an intermittent NullPointerException during wakeup. With these changes then all tests are passing. There is further clean-up that is required but it's not critical. In particular, the AsynchronousChannelProvider implementation [2] is also based on kqueue (in ONESHOT rather than level triggered mode) so there is an opportunity to remove some code, native code and wrapper in particular. I've deliberately not included this refactoring in this patch as it's more appropriate for jdk8. As I mentioned above, we will likely want to push this patch to jdk7u in the future so the changes have been kept to a minimum. Thank you, Alan. [1] http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/cb5ebc902d33 [2] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/98564f184614 [3] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/5599aa5a4a51 From alexander.zuev at oracle.com Thu Apr 12 10:10:12 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 12 Apr 2012 21:10:12 +0400 Subject: [8] Request for review: 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField In-Reply-To: References: <4F74562B.5040702@oracle.com> <6F7AD1B3-C3CF-4A61-8AA4-779AAFD43635@oracle.com> <4F7472A6.4020403@oracle.com> Message-ID: <4F870C74.6040503@oracle.com> The new webrev looks Ok to me. On 4/10/12 17:59, Leonid Romanov wrote: > Hi, > Here is an updated web rev, with the dead code removed. > > http://cr.openjdk.java.net/~leonidr/7124272/webrev.03/ > > On 29.03.2012, at 18:33, Artem Ananiev wrote: > >> On 3/29/2012 4:51 PM, Leonid Romanov wrote: >>> Yes, you are right in your guess: OS X doesn't generate any kind of "key typed" events, this is why we have to do it manually. As for the dead code in AWTEvent.m, the answer is again yes, it could use some cleaning. Perhaps a separate low priority bug could be filled. >> As this is a request for JDK8 fix, which is of no urgency (yet), it makes sense to perform this refactoring as a part of 7124272. We all know all those low-priority bugs will never be fixed/implemented. >> >> Thanks, >> >> Artem >> >>> On 29.03.2012, at 16:31, Artem Ananiev wrote: >>> >>>> Hi, Leonid, >>>> >>>> a general question, not tightly related to the fix. Why do we want to generate KEY_TYPED events from Java? Do we receive such events from the native platform? Probably, not, because I see the following method in AWTEvent.m: >>>> >>>> static void >>>> DeliverKeyTypedEvents(JNIEnv *env, NSEvent *nsEvent, jobject peer) >>>> >>>> but it is not called from anywhere. Should it be deleted, or reused, or what? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 3/27/2012 6:49 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField. This fix has already been pushed into 7u4. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124272 >>>>> Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.02/ >>>>> >>>>> Thanks, >>>>> Leonid. >>>>> >>>>> From niagarasoft20-macosxportdev at yahoo.com Thu Apr 12 11:02:35 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Thu, 12 Apr 2012 11:02:35 -0700 (PDT) Subject: FileDialog system property "apple.awt.fileDialogForDirectories" still valid? In-Reply-To: <4F870C74.6040503@oracle.com> References: <4F74562B.5040702@oracle.com> <6F7AD1B3-C3CF-4A61-8AA4-779AAFD43635@oracle.com> <4F7472A6.4020403@oracle.com> <4F870C74.6040503@oracle.com> Message-ID: <1334253755.13289.YahooMailNeo@web126006.mail.ne1.yahoo.com> Is the apple FileDialog system property "apple.awt.fileDialogForDirectories" still valid for selecting directories with a awt.FileDialog? It does not seem to work anymore. Mike From artem.ananiev at oracle.com Thu Apr 12 11:57:32 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 12 Apr 2012 22:57:32 +0400 Subject: [8] Request for review: 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField In-Reply-To: References: <4F74562B.5040702@oracle.com> <6F7AD1B3-C3CF-4A61-8AA4-779AAFD43635@oracle.com> <4F7472A6.4020403@oracle.com> Message-ID: <4F87259C.3080609@oracle.com> Hi, Leonid, this new version looks much better! 398 removed lines! Approved. Thanks, Artem On 4/10/2012 5:59 PM, Leonid Romanov wrote: > Hi, > Here is an updated web rev, with the dead code removed. > > http://cr.openjdk.java.net/~leonidr/7124272/webrev.03/ > > On 29.03.2012, at 18:33, Artem Ananiev wrote: > >> >> On 3/29/2012 4:51 PM, Leonid Romanov wrote: >>> Yes, you are right in your guess: OS X doesn't generate any kind of "key typed" events, this is why we have to do it manually. As for the dead code in AWTEvent.m, the answer is again yes, it could use some cleaning. Perhaps a separate low priority bug could be filled. >> >> As this is a request for JDK8 fix, which is of no urgency (yet), it makes sense to perform this refactoring as a part of 7124272. We all know all those low-priority bugs will never be fixed/implemented. >> >> Thanks, >> >> Artem >> >>> On 29.03.2012, at 16:31, Artem Ananiev wrote: >>> >>>> Hi, Leonid, >>>> >>>> a general question, not tightly related to the fix. Why do we want to generate KEY_TYPED events from Java? Do we receive such events from the native platform? Probably, not, because I see the following method in AWTEvent.m: >>>> >>>> static void >>>> DeliverKeyTypedEvents(JNIEnv *env, NSEvent *nsEvent, jobject peer) >>>> >>>> but it is not called from anywhere. Should it be deleted, or reused, or what? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 3/27/2012 6:49 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField. This fix has already been pushed into 7u4. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124272 >>>>> Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.02/ >>>>> >>>>> Thanks, >>>>> Leonid. >>>>> >>>>> >>> > From sergey.bylokhov at oracle.com Fri Apr 13 10:11:33 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Apr 2012 21:11:33 +0400 Subject: [8] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit Message-ID: <4F885E45.6020104@oracle.com> Hi Everyone, This is a port of 7155298 to macosx. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160623 Webrev can be found at: http://cr.openjdk.java.net/~serb/7160623/webrev.00 Discussion about xawt fix: http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html -- Best regards, Sergey. From niagarasoft20-macosxportdev at yahoo.com Sun Apr 15 08:14:20 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Sun, 15 Apr 2012 08:14:20 -0700 (PDT) Subject: FileDialog system property "apple.awt.fileDialogForDirectories" still valid? In-Reply-To: <1334253755.13289.YahooMailNeo@web126006.mail.ne1.yahoo.com> References: <4F74562B.5040702@oracle.com> <6F7AD1B3-C3CF-4A61-8AA4-779AAFD43635@oracle.com> <4F7472A6.4020403@oracle.com> <4F870C74.6040503@oracle.com> <1334253755.13289.YahooMailNeo@web126006.mail.ne1.yahoo.com> Message-ID: <1334502860.78052.YahooMailNeo@web126004.mail.ne1.yahoo.com> I went ahead and filed bug for this. See here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 Mike >________________________________ > From: "niagarasoft20-macosxportdev at yahoo.com" >To: "macosx-port-dev at openjdk.java.net" >Sent: Thursday, April 12, 2012 2:02 PM >Subject: FileDialog system property "apple.awt.fileDialogForDirectories" still valid? > >Is the apple FileDialog system property "apple.awt.fileDialogForDirectories" still valid for selecting directories with a awt.FileDialog? It does not seem to work anymore. > >Mike > > > From steve at weblite.ca Sun Apr 15 10:45:53 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 15 Apr 2012 10:45:53 -0700 Subject: Java and Mac App Sandboxing Message-ID: Hi all, I'm having trouble finding information on how the upcoming App sandboxing requirement will affect Java applications. Is there an API that we need to start using for interacting with the file system in order to comply with sandboxing? Any pointers on this matter are very much appreciated. Best regards Steve From scott.kovatch at oracle.com Sun Apr 15 16:46:16 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Sun, 15 Apr 2012 16:46:16 -0700 Subject: Java and Mac App Sandboxing In-Reply-To: References: Message-ID: <64FFCF8F-5C21-4FC2-8C3B-C6E6F7A8214D@oracle.com> On Apr 15, 2012, at 10:45 AM, Steve Hannah wrote: > Hi all, > > I'm having trouble finding information on how the upcoming App sandboxing > requirement will affect Java applications. Is there an API that we need to > start using for interacting with the file system in order to comply with > sandboxing? > > Any pointers on this matter are very much appreciated. If you follow the standard Apple documentation on sandboxing you should be fine. You will need to bundle your application with the JRE, but there's no special API to invoke to trigger sandboxing. -- Scott ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From steve at weblite.ca Sun Apr 15 17:01:26 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 15 Apr 2012 17:01:26 -0700 Subject: Java and Mac App Sandboxing In-Reply-To: <64FFCF8F-5C21-4FC2-8C3B-C6E6F7A8214D@oracle.com> References: <64FFCF8F-5C21-4FC2-8C3B-C6E6F7A8214D@oracle.com> Message-ID: Thanks for the reply, Scott. Just to follow up, if I use a file dialog to allow the user to open a file the os will know that the user has granted me access to open that file? And temporary files will also comply automatically? (ie File.createTempFile())? Steve On Sunday, April 15, 2012, Scott Kovatch wrote: > On Apr 15, 2012, at 10:45 AM, Steve Hannah wrote: > > > Hi all, > > > > I'm having trouble finding information on how the upcoming App sandboxing > > requirement will affect Java applications. Is there an API that we need > to > > start using for interacting with the file system in order to comply with > > sandboxing? > > > > Any pointers on this matter are very much appreciated. > > If you follow the standard Apple documentation on sandboxing you should be > fine. You will need to bundle your application with the JRE, but there's no > special API to invoke to trigger sandboxing. > > -- Scott > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > -- Steve Hannah Web Lite Solutions Corp. From michael.x.mcmahon at oracle.com Mon Apr 16 07:47:30 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 16 Apr 2012 15:47:30 +0100 Subject: 7143744: (se) Stabilize KQueue SelectorProvider and make default on MacOSX In-Reply-To: <4F86B7BB.1000405@oracle.com> References: <4F86B7BB.1000405@oracle.com> Message-ID: <4F8C3102.10108@oracle.com> The change looks good to me. - Michael. On 12/04/12 12:08, Alan Bateman wrote: > > I need a reviewer for a patch that fixes several issues with the > kqueue SelectorProvider. It also restores it to be the default > SelectorProvider on MacOSX. Note that these changes are for jdk8. Once > they have baked for a while in 8 then we should consider them for > jdk7u too. > > As background, Apple contributed their kqueue SelectorProvider to the > macosx-port project [1] as it's more scalable than the poll based > SelectorProvider that the bsd-port project was using. Unfortunately > the kqueue SelectorProvider had a few issues and there were several > test failures. In the end the default was switched back to the poll > SelectorProvider [2], pending resolution of these issues. > > I've finally got a chance to look at the issues and have a webrev with > the changes here: > http://cr.openjdk.java.net/~alanb/7143744/webrev > > The main issue is the SelectorProvider didn't work correctly with > channels that are registered for more than one op at a time (OP_READ | > OP_WRITE for example). If more than one event was retrieved for the > same file descriptor then the ready ops were replaced rather than > updated. This stems from having the same file descriptor associated > with more than one filter. The return from the select or selectNow > methods was incorrect for these cases too (double accounting). There > were also intermittent CancelledKeyException issues when keys were > canceled or channels closed at around the same time as a select. There > was also an intermittent NullPointerException during wakeup. > > With these changes then all tests are passing. There is further > clean-up that is required but it's not critical. In particular, the > AsynchronousChannelProvider implementation [2] is also based on kqueue > (in ONESHOT rather than level triggered mode) so there is an > opportunity to remove some code, native code and wrapper in > particular. I've deliberately not included this refactoring in this > patch as it's more appropriate for jdk8. As I mentioned above, we will > likely want to push this patch to jdk7u in the future so the changes > have been kept to a minimum. > > Thank you, > Alan. > > [1] > http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/cb5ebc902d33 > [2] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/98564f184614 > [3] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/5599aa5a4a51 From sergey.bylokhov at oracle.com Mon Apr 16 07:50:18 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Apr 2012 18:50:18 +0400 Subject: [8] Request for review: 7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms. Message-ID: <4F8C31AA.5060900@oracle.com> Hi Everyone, LWScrollPanePeer.getMinimumSize() on macosx should work in the same way, as on other platforms. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124213/webrev.00/ -- Best regards, Sergey. From david.dehaven at oracle.com Mon Apr 16 09:55:19 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 16 Apr 2012 09:55:19 -0700 Subject: Java and Mac App Sandboxing In-Reply-To: References: <64FFCF8F-5C21-4FC2-8C3B-C6E6F7A8214D@oracle.com> Message-ID: <32AA02F8-39A6-48FD-8188-F2DEE82602AE@oracle.com> The sandbox daemon restricts file access at a low level and it works on top of normal file permissions. It is always equal or more restrictive, never less. If you don't have execute permission (either via file permissions or by sandboxd) you cannot browse to that directory in the file chooser. Each sandboxed app has it's own temp file space in it's sandbox, you have unrestricted access to it and IIRC the temp file commands will always use the correct location (the java.io.File methods use standard file calls internally). I just re-verified to make sure and even with full filesystem restrictions the temp file methods work as expected. -DrD- > Thanks for the reply, Scott. Just to follow up, if I use a file dialog to > allow the user to open a file the os will know that the user has granted me > access to open that file? And temporary files will also comply > automatically? (ie File.createTempFile())? > > Steve > > On Sunday, April 15, 2012, Scott Kovatch wrote: > >> On Apr 15, 2012, at 10:45 AM, Steve Hannah wrote: >> >>> Hi all, >>> >>> I'm having trouble finding information on how the upcoming App sandboxing >>> requirement will affect Java applications. Is there an API that we need >> to >>> start using for interacting with the file system in order to comply with >>> sandboxing? >>> >>> Any pointers on this matter are very much appreciated. From david.dehaven at oracle.com Mon Apr 16 10:00:59 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 16 Apr 2012 10:00:59 -0700 Subject: Java and Mac App Sandboxing In-Reply-To: <32AA02F8-39A6-48FD-8188-F2DEE82602AE@oracle.com> References: <64FFCF8F-5C21-4FC2-8C3B-C6E6F7A8214D@oracle.com> <32AA02F8-39A6-48FD-8188-F2DEE82602AE@oracle.com> Message-ID: <7CBB84A0-51D0-4652-BE5C-622D7FFA7C67@oracle.com> > Each sandboxed app has it's own temp file space in it's sandbox Argh.. typing too fast? NOT in the sandbox, in the per-user temp directory hierarchy as it's been for a while now. -DrD- From alexander.zuev at oracle.com Mon Apr 16 11:12:31 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 16 Apr 2012 22:12:31 +0400 Subject: [8] Request for review for 7161109: [macosx] JCK AWT interactive test DnDTextDropTest fails on MacOS Message-ID: <4F8C610F.4090203@oracle.com> Hello, please review my fix for CR 7161109: [macosx] JCK AWT interactive test DnDTextDropTest fails on MacOS The fix is just a forward-port of fix for CR 7124262 which was not synced up into jdk8 workspace. Bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161109 Webrev: http://cr.openjdk.java.net/~kizune/7161109/webrev.00 Withe best regards, Alexander Zuev From sergey.bylokhov at oracle.com Mon Apr 16 11:21:30 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Apr 2012 22:21:30 +0400 Subject: [8] Request for review for 7161109: [macosx] JCK AWT interactive test DnDTextDropTest fails on MacOS In-Reply-To: <4F8C610F.4090203@oracle.com> References: <4F8C610F.4090203@oracle.com> Message-ID: <4F8C632A.8000300@oracle.com> Hi, Alexander. Fix looks good. 16.04.2012 22:12, Alexander Zuev wrote > Hello, > > please review my fix for CR 7161109: [macosx] JCK AWT interactive > test DnDTextDropTest fails on MacOS > > The fix is just a forward-port of fix for CR 7124262 which was not > synced up into jdk8 workspace. > > Bug description: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161109 > Webrev: http://cr.openjdk.java.net/~kizune/7161109/webrev.00 > > Withe best regards, > Alexander Zuev -- Best regards, Sergey. From Alexander.Potochkin at oracle.com Mon Apr 16 11:30:29 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 16 Apr 2012 22:30:29 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F85786A.3060407@oracle.com> References: <4F846D22.4030706@oracle.com> <4F85786A.3060407@oracle.com> Message-ID: <4F8C6545.7010304@oracle.com> Hello Anthony Thanks for reviewing it, here is the new version: http://cr.openjdk.java.net/~alexp/7124328/webrev.01/ > Hi Alex, > > It seems like the new private getAllFrames(Contianer) method may be > declared as static. Also I suggest to insert spaces between "if"s and > "("s at lines 275, 277, and 282. Otherwise the changes look good. fixed > > BTW, do we have any regression tests for this method? Do they pass? It's a pretty good question :-) There is no regression tests for JDesktopPane.getAllFrames() but I've found a regression test for the old bug 4132993 which fixes the problem with JDesktopPane.getAllFramesInLayer(). This method also should return iconified frames in a specified layer, it didn't work for Aqua so I fixed it as well > What about the performance regression caused by iterating over the > inner containers? No observable performance regression. Thanks alexp > > -- > best regards, > Anthony > > On 4/10/2012 9:25 PM, Alexander Potochkin wrote: >> Hello >> >> Please review the following fix: >> http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ >> >> for this bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 >> >> the spec for the method >> javax.swing.JDesktopPane.getAllFrames() >> >> says >> >> * Returns all JInternalFrames currently displayed in the >> * desktop. Returns iconified frames as well as expanded frames. >> >> but the AquaLookAndFeel on MacOS uses a special container for the >> minimized internal frames >> and that's why the current implementation doesn't see them >> >> the proposed fix recursively looks for the internal frames >> among the JDesktopPane's children >> >> the test can be found here: >> http://java.net/jira/browse/MACOSX_PORT-557 >> >> Thanks >> alexp From tobi at ultramixer.com Tue Apr 17 04:03:40 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 17 Apr 2012 13:03:40 +0200 Subject: Native look and feel documentation? Message-ID: <90E50C32-642B-45EA-84DB-24C89D97F96A@ultramixer.com> Hi Mike, I started a new project to create native looking skins for JavaFX 2...http://blog.software4java.com/?p=15 So I have to create a complex css file to style all common controls like buttons, checkboxes, tables etc. Because of the many gradient fills of the beautiful Mac OS X theme it's not simple to port it to pure CSS without an documentation of the mac os x theme. It know the style guide but my question is: Is there any official documentation or photoshop file available about every user interface element in Mac OS X 10.7? the best would for me something like this: Button - border: 2px black - gradient: color1 0%, color2 10%, color3 100% - font: Helvetica - font-size: 12px - font-color: #222222 .... Best regards, Tobi From anthony.petrov at oracle.com Tue Apr 17 06:08:08 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Apr 2012 17:08:08 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F8C6545.7010304@oracle.com> References: <4F846D22.4030706@oracle.com> <4F85786A.3060407@oracle.com> <4F8C6545.7010304@oracle.com> Message-ID: <4F8D6B38.8010403@oracle.com> Hi Alex, The fix looks good to me. Though if I were you, I would add an argument to the new static method to allow for inclusion of internal frame from a specified layer only, or all layers if the argument is equal to e.g. MAX_INT. This way we could avoid adding and then removing some of the found frames to/from the collection. -- best regards, Anthony On 4/16/2012 10:30 PM, Alexander Potochkin wrote: > Hello Anthony > > Thanks for reviewing it, here is the new version: > > http://cr.openjdk.java.net/~alexp/7124328/webrev.01/ > >> Hi Alex, >> >> It seems like the new private getAllFrames(Contianer) method may be >> declared as static. Also I suggest to insert spaces between "if"s and >> "("s at lines 275, 277, and 282. Otherwise the changes look good. > > fixed > >> >> BTW, do we have any regression tests for this method? Do they pass? > > It's a pretty good question > :-) > > There is no regression tests for JDesktopPane.getAllFrames() > but I've found a regression test for the old bug 4132993 which fixes the > problem with > JDesktopPane.getAllFramesInLayer(). > > This method also should return iconified frames in a specified layer, > it didn't work for Aqua so I fixed it as well >> What about the performance regression caused by iterating over the >> inner containers? > > No observable performance regression. > > Thanks > alexp >> >> -- >> best regards, >> Anthony >> >> On 4/10/2012 9:25 PM, Alexander Potochkin wrote: >>> Hello >>> >>> Please review the following fix: >>> http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ >>> >>> for this bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 >>> >>> the spec for the method >>> javax.swing.JDesktopPane.getAllFrames() >>> >>> says >>> >>> * Returns all JInternalFrames currently displayed in the >>> * desktop. Returns iconified frames as well as expanded frames. >>> >>> but the AquaLookAndFeel on MacOS uses a special container for the >>> minimized internal frames >>> and that's why the current implementation doesn't see them >>> >>> the proposed fix recursively looks for the internal frames >>> among the JDesktopPane's children >>> >>> the test can be found here: >>> http://java.net/jira/browse/MACOSX_PORT-557 >>> >>> Thanks >>> alexp > From Alexander.Potochkin at oracle.com Tue Apr 17 06:30:17 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 17 Apr 2012 17:30:17 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F8D6B38.8010403@oracle.com> References: <4F846D22.4030706@oracle.com> <4F85786A.3060407@oracle.com> <4F8C6545.7010304@oracle.com> <4F8D6B38.8010403@oracle.com> Message-ID: <4F8D7069.8070805@oracle.com> Hello Anthony > Hi Alex, > > The fix looks good to me. thanks > > Though if I were you, I would add an argument to the new static method > to allow for inclusion of internal frame from a specified layer only, > or all layers if the argument is equal to e.g. MAX_INT. This way we > could avoid adding and then removing some of the found frames to/from > the collection. MAX_INT is a valid parameter for JLayeredPane.putLayer(JComponent, int), negative values are also ok, for example JLayeredPane.FRAME_CONTENT_LAYER is defined as -30000 so there is no "reserved" integer to serve as a special flag for frames in all layers alexp > > -- > best regards, > Anthony > > On 4/16/2012 10:30 PM, Alexander Potochkin wrote: >> Hello Anthony >> >> Thanks for reviewing it, here is the new version: >> >> http://cr.openjdk.java.net/~alexp/7124328/webrev.01/ >> >>> Hi Alex, >>> >>> It seems like the new private getAllFrames(Contianer) method may be >>> declared as static. Also I suggest to insert spaces between "if"s >>> and "("s at lines 275, 277, and 282. Otherwise the changes look good. >> >> fixed >> >>> >>> BTW, do we have any regression tests for this method? Do they pass? >> >> It's a pretty good question >> :-) >> >> There is no regression tests for JDesktopPane.getAllFrames() >> but I've found a regression test for the old bug 4132993 which fixes >> the problem with >> JDesktopPane.getAllFramesInLayer(). >> >> This method also should return iconified frames in a specified layer, >> it didn't work for Aqua so I fixed it as well >>> What about the performance regression caused by iterating over the >>> inner containers? >> >> No observable performance regression. >> >> Thanks >> alexp >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/10/2012 9:25 PM, Alexander Potochkin wrote: >>>> Hello >>>> >>>> Please review the following fix: >>>> http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ >>>> >>>> for this bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 >>>> >>>> the spec for the method >>>> javax.swing.JDesktopPane.getAllFrames() >>>> >>>> says >>>> >>>> * Returns all JInternalFrames currently displayed in the >>>> * desktop. Returns iconified frames as well as expanded frames. >>>> >>>> but the AquaLookAndFeel on MacOS uses a special container for the >>>> minimized internal frames >>>> and that's why the current implementation doesn't see them >>>> >>>> the proposed fix recursively looks for the internal frames >>>> among the JDesktopPane's children >>>> >>>> the test can be found here: >>>> http://java.net/jira/browse/MACOSX_PORT-557 >>>> >>>> Thanks >>>> alexp >> From anthony.petrov at oracle.com Tue Apr 17 06:34:21 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Apr 2012 17:34:21 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F8D7069.8070805@oracle.com> References: <4F846D22.4030706@oracle.com> <4F85786A.3060407@oracle.com> <4F8C6545.7010304@oracle.com> <4F8D6B38.8010403@oracle.com> <4F8D7069.8070805@oracle.com> Message-ID: <4F8D715D.3050303@oracle.com> OK then. The fix is fine anyway. -- best regards, Anthony On 4/17/2012 5:30 PM, Alexander Potochkin wrote: > Hello Anthony >> Hi Alex, >> >> The fix looks good to me. > thanks >> >> Though if I were you, I would add an argument to the new static method >> to allow for inclusion of internal frame from a specified layer only, >> or all layers if the argument is equal to e.g. MAX_INT. This way we >> could avoid adding and then removing some of the found frames to/from >> the collection. > > MAX_INT is a valid parameter for JLayeredPane.putLayer(JComponent, int), > negative values are also ok, for example > JLayeredPane.FRAME_CONTENT_LAYER is defined as -30000 > > so there is no "reserved" integer to serve as a special flag for frames > in all layers > > alexp > >> >> -- >> best regards, >> Anthony >> >> On 4/16/2012 10:30 PM, Alexander Potochkin wrote: >>> Hello Anthony >>> >>> Thanks for reviewing it, here is the new version: >>> >>> http://cr.openjdk.java.net/~alexp/7124328/webrev.01/ >>> >>>> Hi Alex, >>>> >>>> It seems like the new private getAllFrames(Contianer) method may be >>>> declared as static. Also I suggest to insert spaces between "if"s >>>> and "("s at lines 275, 277, and 282. Otherwise the changes look good. >>> >>> fixed >>> >>>> >>>> BTW, do we have any regression tests for this method? Do they pass? >>> >>> It's a pretty good question >>> :-) >>> >>> There is no regression tests for JDesktopPane.getAllFrames() >>> but I've found a regression test for the old bug 4132993 which fixes >>> the problem with >>> JDesktopPane.getAllFramesInLayer(). >>> >>> This method also should return iconified frames in a specified layer, >>> it didn't work for Aqua so I fixed it as well >>>> What about the performance regression caused by iterating over the >>>> inner containers? >>> >>> No observable performance regression. >>> >>> Thanks >>> alexp >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/10/2012 9:25 PM, Alexander Potochkin wrote: >>>>> Hello >>>>> >>>>> Please review the following fix: >>>>> http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ >>>>> >>>>> for this bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 >>>>> >>>>> the spec for the method >>>>> javax.swing.JDesktopPane.getAllFrames() >>>>> >>>>> says >>>>> >>>>> * Returns all JInternalFrames currently displayed in the >>>>> * desktop. Returns iconified frames as well as expanded frames. >>>>> >>>>> but the AquaLookAndFeel on MacOS uses a special container for the >>>>> minimized internal frames >>>>> and that's why the current implementation doesn't see them >>>>> >>>>> the proposed fix recursively looks for the internal frames >>>>> among the JDesktopPane's children >>>>> >>>>> the test can be found here: >>>>> http://java.net/jira/browse/MACOSX_PORT-557 >>>>> >>>>> Thanks >>>>> alexp >>> > From anthony.petrov at oracle.com Wed Apr 18 05:37:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 18 Apr 2012 16:37:53 +0400 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames Message-ID: <4F8EB5A1.6060104@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7149062 at: http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.0/ The AWTWindow class now inherits from NSObject and implements the NSWindowDelegate protocol. The real NSWindow object is held in the nsWindow property of the AWTWindow class, and is represented by either an AWTWindow_Normal or AWTWindow_Panel instance. These two classes inherit from NSWindow and NSPanel correspondingly. Note, however, that we still return a reference to the NSWindow/NSPanel instance to Java so that the pointer could be used with CWrapper methods directly. A reference to an associated AWTWindow instance is always available as (AWTWindow*)[nsWindow delegate]. All windows that inherit from NSWindow are added to the windows list in the dock icon menu by default. We use NSPanel-based windows for UTILITY, HUD, NONACTIVATING, and HIDES_ON_DEACTIVATE windows only, because these kinds of windows typically don't represent main application windows, and thus aren't expected to be added to the windows list. Besides, UTILITY (and HUD?) windows just have to be NSPanels. This fix is going to be back-ported to 7u6 later on. -- best regards, Anthony From anthony.petrov at oracle.com Wed Apr 18 06:11:55 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 18 Apr 2012 17:11:55 +0400 Subject: [8] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit In-Reply-To: <4F885E45.6020104@oracle.com> References: <4F885E45.6020104@oracle.com> Message-ID: <4F8EBD9B.9020703@oracle.com> Looks fine to me. -- best regards, Anthony On 4/13/2012 9:11 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a port of 7155298 to macosx. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160623 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7160623/webrev.00 > > Discussion about xawt fix: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html > From anthony.petrov at oracle.com Wed Apr 18 06:18:03 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 18 Apr 2012 17:18:03 +0400 Subject: [8] Request for review: 7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms. In-Reply-To: <4F8C31AA.5060900@oracle.com> References: <4F8C31AA.5060900@oracle.com> Message-ID: <4F8EBF0B.3000100@oracle.com> Looks good. -- best regards, Anthony On 4/16/2012 6:50 PM, Sergey Bylokhov wrote: > Hi Everyone, > LWScrollPanePeer.getMinimumSize() on macosx should work in the same way, > as on other platforms. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124213/webrev.00/ > From alexandr.scherbatiy at oracle.com Wed Apr 18 08:40:54 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 18 Apr 2012 19:40:54 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. Message-ID: <4F8EE086.2090809@oracle.com> Please review a fix for CR 7154048. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ Let's see the following test case: - Frame contains two components JLabel and JButton - The JLabel component has a mouse listener mousePressed: create a Window under the mouse click mouseDragged: drag the created window mouseReleased: close the Window - A user clicks on the JLabel component, drags the mouse to the JButton component and releases the mouse button The current JDK 8 implementation shows the following events on Mac OS X: -------------------------------------------------------- mouse pressed: javax.swing.JLabel mouse exited: javax.swing.JLabel mouse entered: javax.swing.JLabel mouse dragged: javax.swing.JLabel mouse exited: javax.swing.JLabel mouse entered: javax.swing.JButton mouse dragged: javax.swing.JLabel mouse exited: javax.swing.JButton mouse entered: Drag Window mouse exited: Drag Window mouse entered: javax.swing.JButton mouse released: javax.swing.JButton -------------------------------------------------------- There are several issues: 1) The window does not receive the mouse entered event when it is created under the mouse 2) There are JLabel exited/JButton entered events during the window dragging 3) JLabel does not receive the mouse released event The fix synthesizes the mouse entered/exited events manually if they are not received. The entered/exited events synthesizing is added to setFrame, toFront, toBack, and zoom methods of the AWTWindow and CWrapper classes. There is an option to add the events synthesizing to the windowDidResize notification. However this notification is sent when a window size is changed in both cases, programmatically and when user is resized the window. So in a lot of case there is no need for the our use case events generation. The LWWindowPeer class is updated to not generate extra mouse enter/exit events during the mouse dragging. Tho automated tests are added. Thanks, Alexandr. From leonid.romanov at oracle.com Wed Apr 18 09:22:58 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 18 Apr 2012 20:22:58 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F8EE086.2090809@oracle.com> References: <4F8EE086.2090809@oracle.com> Message-ID: Hi, A quick question to help me better understand what is going on in your webrev. The common way to track mouse enter/exit events in OS X is to use NSView's tracking rectangle or (newer than tracking rectangle) NSTrackingArea class. In our port, we set a tracking rectangle in -viewDidMoveToWindow method of AWTView class. So, my question is: have you investigated what is wrong with our current approach? That is, why it doesn't work and for what cases? Thanks, Leonid. On 18.04.2012, at 19:40, Alexander Scherbatiy wrote: > > Please review a fix for CR 7154048. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 > > webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ > > Let's see the following test case: > - Frame contains two components JLabel and JButton > - The JLabel component has a mouse listener > mousePressed: create a Window under the mouse click > mouseDragged: drag the created window > mouseReleased: close the Window > - A user clicks on the JLabel component, drags the mouse to the JButton component and releases the mouse button > > The current JDK 8 implementation shows the following events on Mac OS X: > -------------------------------------------------------- > mouse pressed: javax.swing.JLabel > mouse exited: javax.swing.JLabel > mouse entered: javax.swing.JLabel > mouse dragged: javax.swing.JLabel > mouse exited: javax.swing.JLabel > mouse entered: javax.swing.JButton > mouse dragged: javax.swing.JLabel > mouse exited: javax.swing.JButton > mouse entered: Drag Window > mouse exited: Drag Window > mouse entered: javax.swing.JButton > mouse released: javax.swing.JButton > -------------------------------------------------------- > > There are several issues: > 1) The window does not receive the mouse entered event when it is created under the mouse > 2) There are JLabel exited/JButton entered events during the window dragging > 3) JLabel does not receive the mouse released event > > The fix synthesizes the mouse entered/exited events manually if they are not received. > > The entered/exited events synthesizing is added to setFrame, toFront, toBack, and zoom methods of the AWTWindow and CWrapper classes. > > There is an option to add the events synthesizing to the windowDidResize notification. However this notification is sent when a window size is changed in both cases, programmatically and when user is resized the window. So in a lot of case there is no need for the our use case events generation. > > The LWWindowPeer class is updated to not generate extra mouse enter/exit events during the mouse dragging. > > Tho automated tests are added. > > Thanks, > Alexandr. From mik3hall at gmail.com Wed Apr 18 15:34:46 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 18 Apr 2012 17:34:46 -0500 Subject: styled JTextPane Message-ID: <630D88F6-B8C0-4DB2-9A11-85AFF785F546@gmail.com> Is font support supposed to be complete? I have a JTextPane subclass that includes a menu that is supposed to list available fonts. It shows nothing but the standard defaults like Serif. It is supposed to optionally allow styled output like monospaced. It doesn't appear to work for monospaced. Changing text color does work. The project status shows nothing outstanding for fonts that I'm seeing. I haven't checked for bugs. From anthony.petrov at oracle.com Thu Apr 19 06:14:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 19 Apr 2012 17:14:23 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F8EE086.2090809@oracle.com> References: <4F8EE086.2090809@oracle.com> Message-ID: <4F900FAF.6070104@oracle.com> Hi Alexander, 1. I don't think that it's a good idea to add synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These methods are supposed to perform direct calls to Cocoa API w/o any side-effects. They may be used for windows that even aren't AWT windows, and as such sending them the synthesizeMouseEnteredExitedEvents message is useless, and just doesn't seem right from CWrapper's purpose perspective. You may want to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() native method that would call this native method, and then add a call to it where needed in Java code. 2. Please follow formatting guidelines and reformat lines like this: > if(id != MouseEvent.MOUSE_DRAGGED){ to read as if (id != MouseEvent.MOUSE_DRAGGED) { instead. I see lots of such mis-formatted if() statements all over your code. 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer after sending the MOUSE_ENTERED event. Before your fix it's been set earlier. Can this change affect some logic in the peer code while processing ENTERED events at a user event handler? -- best regards, Anthony On 04/18/12 19:40, Alexander Scherbatiy wrote: > > Please review a fix for CR 7154048. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 > > webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ > > Let's see the following test case: > - Frame contains two components JLabel and JButton > - The JLabel component has a mouse listener > mousePressed: create a Window under the mouse click > mouseDragged: drag the created window > mouseReleased: close the Window > - A user clicks on the JLabel component, drags the mouse to the JButton > component and releases the mouse button > > The current JDK 8 implementation shows the following events on Mac OS X: > -------------------------------------------------------- > mouse pressed: javax.swing.JLabel > mouse exited: javax.swing.JLabel > mouse entered: javax.swing.JLabel > mouse dragged: javax.swing.JLabel > mouse exited: javax.swing.JLabel > mouse entered: javax.swing.JButton > mouse dragged: javax.swing.JLabel > mouse exited: javax.swing.JButton > mouse entered: Drag Window > mouse exited: Drag Window > mouse entered: javax.swing.JButton > mouse released: javax.swing.JButton > -------------------------------------------------------- > > There are several issues: > 1) The window does not receive the mouse entered event when it is > created under the mouse > 2) There are JLabel exited/JButton entered events during the window > dragging > 3) JLabel does not receive the mouse released event > > The fix synthesizes the mouse entered/exited events manually if they are > not received. > > The entered/exited events synthesizing is added to setFrame, toFront, > toBack, and zoom methods of the AWTWindow and CWrapper classes. > > There is an option to add the events synthesizing to the windowDidResize > notification. However this notification is sent when a window size is > changed in both cases, programmatically and when user is resized the > window. So in a lot of case there is no need for the our use case events > generation. > > The LWWindowPeer class is updated to not generate extra mouse enter/exit > events during the mouse dragging. > > Tho automated tests are added. > > Thanks, > Alexandr. From alexandr.scherbatiy at oracle.com Thu Apr 19 06:55:43 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 19 Apr 2012 17:55:43 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: References: <4F8EE086.2090809@oracle.com> Message-ID: <4F90195F.1010404@oracle.com> The first attached file contains the cocoa code snippets that reproduce the problem. - At first we create the Main window - Clicking on the Main window creates the Second window - The tracking rectangle is set for the Second window during the window creation (I also tried to set it in the -viewDidMoveToWindow method) - When the second window appears under the mouse, the mouse enter event is not received. However the Second window tracks the mouse exited/entered events if we manually move the mouse over the window The second attached file is a test that shows the problem on the Java side. It does the same and passes on the Windows and Ubuntu but fails on the Mac OS X. Thanks, Alexandr. On 4/18/2012 8:22 PM, Leonid Romanov wrote: > Hi, > A quick question to help me better understand what is going on in your webrev. The common way to track mouse enter/exit events in OS X is to use NSView's tracking rectangle or (newer than tracking rectangle) NSTrackingArea class. In our port, we set a tracking rectangle in -viewDidMoveToWindow method of AWTView class. So, my question is: have you investigated what is wrong with our current approach? That is, why it doesn't work and for what cases? > > Thanks, > Leonid. > > On 18.04.2012, at 19:40, Alexander Scherbatiy wrote: > >> Please review a fix for CR 7154048. >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >> >> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >> >> Let's see the following test case: >> - Frame contains two components JLabel and JButton >> - The JLabel component has a mouse listener >> mousePressed: create a Window under the mouse click >> mouseDragged: drag the created window >> mouseReleased: close the Window >> - A user clicks on the JLabel component, drags the mouse to the JButton component and releases the mouse button >> >> The current JDK 8 implementation shows the following events on Mac OS X: >> -------------------------------------------------------- >> mouse pressed: javax.swing.JLabel >> mouse exited: javax.swing.JLabel >> mouse entered: javax.swing.JLabel >> mouse dragged: javax.swing.JLabel >> mouse exited: javax.swing.JLabel >> mouse entered: javax.swing.JButton >> mouse dragged: javax.swing.JLabel >> mouse exited: javax.swing.JButton >> mouse entered: Drag Window >> mouse exited: Drag Window >> mouse entered: javax.swing.JButton >> mouse released: javax.swing.JButton >> -------------------------------------------------------- >> >> There are several issues: >> 1) The window does not receive the mouse entered event when it is created under the mouse >> 2) There are JLabel exited/JButton entered events during the window dragging >> 3) JLabel does not receive the mouse released event >> >> The fix synthesizes the mouse entered/exited events manually if they are not received. >> >> The entered/exited events synthesizing is added to setFrame, toFront, toBack, and zoom methods of the AWTWindow and CWrapper classes. >> >> There is an option to add the events synthesizing to the windowDidResize notification. However this notification is sent when a window size is changed in both cases, programmatically and when user is resized the window. So in a lot of case there is no need for the our use case events generation. >> >> The LWWindowPeer class is updated to not generate extra mouse enter/exit events during the mouse dragging. >> >> Tho automated tests are added. >> >> Thanks, >> Alexandr. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sources.txt Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120419/e325d592/sources.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MouseEnterTest.java Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120419/e325d592/MouseEnterTest.java From Alan.Bateman at oracle.com Thu Apr 19 09:56:35 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Apr 2012 17:56:35 +0100 Subject: 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <20120419150806.05A9C47179@hg.openjdk.java.net> References: <20120419150806.05A9C47179@hg.openjdk.java.net> Message-ID: <4F9043C3.6010905@oracle.com> Jim - I see this changes lots of places to look for "OS X" in the value of the os.name property, up until now the check was to see if the os.name value starts with "Mac OS". Was this change necessary? I was following the discussion on the os.arch change but missed the discussion on os.name. I'm mostly curious to know if something was actually broken. -Alan On 19/04/2012 16:07, coleen.phillimore at oracle.com wrote: > Changeset: 77b35c5c4b95 > Author: jmelvin > Date: 2012-04-16 18:09 -0400 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77b35c5c4b95 > > 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 > Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs. Also, improve os.name string matching by using .contains() method instead of .startsWith(). This fix spans multiple repositories. > Reviewed-by: dcubed, phh, ohair, katleman > > From swingler at apple.com Thu Apr 19 10:04:56 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 19 Apr 2012 10:04:56 -0700 Subject: 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F9043C3.6010905@oracle.com> References: <20120419150806.05A9C47179@hg.openjdk.java.net> <4F9043C3.6010905@oracle.com> Message-ID: I recommended that this change be implemented for robustness against potential fluctuations in the value reported by the OS that are likely to occur. Regards, Mike Swingler Apple Inc. On Apr 19, 2012, at 9:56 AM, Alan Bateman wrote: > > Jim - I see this changes lots of places to look for "OS X" in the value of the os.name property, up until now the check was to see if the os.name value starts with "Mac OS". Was this change necessary? I was following the discussion on the os.arch change but missed the discussion on os.name. I'm mostly curious to know if something was actually broken. > > -Alan > > > On 19/04/2012 16:07, coleen.phillimore at oracle.com wrote: >> Changeset: 77b35c5c4b95 >> Author: jmelvin >> Date: 2012-04-16 18:09 -0400 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77b35c5c4b95 >> >> 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 >> Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs. Also, improve os.name string matching by using .contains() method instead of .startsWith(). This fix spans multiple repositories. >> Reviewed-by: dcubed, phh, ohair, katleman >> >> > > From jonathan.gibbons at oracle.com Thu Apr 19 10:07:02 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 19 Apr 2012 10:07:02 -0700 Subject: 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F9043C3.6010905@oracle.com> References: <20120419150806.05A9C47179@hg.openjdk.java.net> <4F9043C3.6010905@oracle.com> Message-ID: <4F904636.80603@oracle.com> Alan, In a previous message relating to jtreg, Mike Swingler wrote: > The appropriate checks are: > > In Java: osName.contains("OS X") > In shell: uname -s == Darwin > -- Jon On 04/19/2012 09:56 AM, Alan Bateman wrote: > > Jim - I see this changes lots of places to look for "OS X" in the > value of the os.name property, up until now the check was to see if > the os.name value starts with "Mac OS". Was this change necessary? I > was following the discussion on the os.arch change but missed the > discussion on os.name. I'm mostly curious to know if something was > actually broken. > > -Alan > > > On 19/04/2012 16:07, coleen.phillimore at oracle.com wrote: >> Changeset: 77b35c5c4b95 >> Author: jmelvin >> Date: 2012-04-16 18:09 -0400 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77b35c5c4b95 >> >> 7130404: [macosx] "os.arch" value should be "x86_64" for >> compatibility with Apple JDK6 >> Summary: On Mac OS X, align system property "os.arch" with Apple >> legacy JDKs. Also, improve os.name string matching by using >> .contains() method instead of .startsWith(). This fix spans multiple >> repositories. >> Reviewed-by: dcubed, phh, ohair, katleman >> >> > > From james.melvin at oracle.com Thu Apr 19 10:17:34 2012 From: james.melvin at oracle.com (James Melvin) Date: Thu, 19 Apr 2012 13:17:34 -0400 Subject: 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F9043C3.6010905@oracle.com> References: <20120419150806.05A9C47179@hg.openjdk.java.net> <4F9043C3.6010905@oracle.com> Message-ID: <4F9048AE.6030205@oracle.com> Hi Alan, Nothing is broken... yet. The change to os.name string compares was on the advice of Mike Swingler from Apple. They may be changing the name to just "OS X" at some point and this change was in preparation for that potential change. This was also pushed to 7uX earlier. The JDK 8 change is a forward port of the same. The change also affected RE build and promote scripts so the integration order and process was somewhat out of the ordinary. - Jim On 4/19/12 12:56 PM, Alan Bateman wrote: > > Jim - I see this changes lots of places to look for "OS X" in the value > of the os.name property, up until now the check was to see if the > os.name value starts with "Mac OS". Was this change necessary? I was > following the discussion on the os.arch change but missed the discussion > on os.name. I'm mostly curious to know if something was actually broken. > > -Alan > > > On 19/04/2012 16:07, coleen.phillimore at oracle.com wrote: >> Changeset: 77b35c5c4b95 >> Author: jmelvin >> Date: 2012-04-16 18:09 -0400 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77b35c5c4b95 >> >> 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility >> with Apple JDK6 >> Summary: On Mac OS X, align system property "os.arch" with Apple >> legacy JDKs. Also, improve os.name string matching by using >> .contains() method instead of .startsWith(). This fix spans multiple >> repositories. >> Reviewed-by: dcubed, phh, ohair, katleman >> >> > > From Alan.Bateman at oracle.com Thu Apr 19 10:25:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Apr 2012 18:25:54 +0100 Subject: 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F9048AE.6030205@oracle.com> References: <20120419150806.05A9C47179@hg.openjdk.java.net> <4F9043C3.6010905@oracle.com> <4F9048AE.6030205@oracle.com> Message-ID: <4F904AA2.5060602@oracle.com> On 19/04/2012 18:17, James Melvin wrote: > Hi Alan, > > Nothing is broken... yet. The change to os.name string compares was on > the advice of Mike Swingler from Apple. They may be changing the name to > just "OS X" at some point and this change was in preparation for that > potential change. This was also pushed to 7uX earlier. The JDK 8 change > is a forward port of the same. The change also affected RE build and > promote scripts so the integration order and process was somewhat out of > the ordinary. > > - Jim Thanks Jim, and I see the reply from Mike Swingler too. On 7u then I just checked jdk7u/jdk7u-dev and several tests are using startsWith("Mac OS") like we had in 8 so maybe it's not all pushed to 7u yet. -Alan. From swingler at apple.com Thu Apr 19 10:34:26 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 19 Apr 2012 10:34:26 -0700 Subject: Native look and feel documentation? In-Reply-To: <90E50C32-642B-45EA-84DB-24C89D97F96A@ultramixer.com> References: <90E50C32-642B-45EA-84DB-24C89D97F96A@ultramixer.com> Message-ID: <83CA7262-EE96-406A-9B11-0D3E33B3FCC7@apple.com> Hi, We do not publish a spec for people to replicate the Aqua UI, which changes with every OS release (sometimes in big ways, sometimes in small ways). Many UI elements are not expressible with simple gradient fills because they are filled with textures, curved highlights, subtle noise. The Swing Aqua Look and Feel asks the native system to render components into a BufferedImage using the JavaRuntimeSupport.framework, so it is always current with the OS, with a minimum of version checks in Java code. Oh, and the system default font is Lucida Grande, not Helvetica. Regards, ~Mike On Apr 17, 2012, at 4:03 AM, Tobias Bley wrote: > Hi Mike, > > I started a new project to create native looking skins for JavaFX 2...http://blog.software4java.com/?p=15 > > So I have to create a complex css file to style all common controls like buttons, checkboxes, tables etc. > > Because of the many gradient fills of the beautiful Mac OS X theme it's not simple to port it to pure CSS without an documentation of the mac os x theme. It know the style guide but my question is: Is there any official documentation or photoshop file available about every user interface element in Mac OS X 10.7? > > the best would for me something like this: > > Button > - border: 2px black > - gradient: color1 0%, color2 10%, color3 100% > - font: Helvetica > - font-size: 12px > - font-color: #222222 > .... > > Best regards, > Tobi > > > From james.melvin at oracle.com Thu Apr 19 10:55:33 2012 From: james.melvin at oracle.com (James Melvin) Date: Thu, 19 Apr 2012 13:55:33 -0400 Subject: 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F904AA2.5060602@oracle.com> References: <20120419150806.05A9C47179@hg.openjdk.java.net> <4F9043C3.6010905@oracle.com> <4F9048AE.6030205@oracle.com> <4F904AA2.5060602@oracle.com> Message-ID: <4F905195.9060506@oracle.com> Exactly right. The fix was pushed to 7u4-b20. I plan to confirm the sync plan for 7u6 includes this work. If not, I can push the same fix to 7u6 independently. - Jim On 4/19/12 1:25 PM, Alan Bateman wrote: > On 19/04/2012 18:17, James Melvin wrote: >> Hi Alan, >> >> Nothing is broken... yet. The change to os.name string compares was on >> the advice of Mike Swingler from Apple. They may be changing the name to >> just "OS X" at some point and this change was in preparation for that >> potential change. This was also pushed to 7uX earlier. The JDK 8 change >> is a forward port of the same. The change also affected RE build and >> promote scripts so the integration order and process was somewhat out of >> the ordinary. >> >> - Jim > Thanks Jim, and I see the reply from Mike Swingler too. > > On 7u then I just checked jdk7u/jdk7u-dev and several tests are using > startsWith("Mac OS") like we had in 8 so maybe it's not all pushed to 7u > yet. > > -Alan. From mik3hall at gmail.com Thu Apr 19 14:37:22 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 16:37:22 -0500 Subject: Font support Message-ID: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> Still wondering known or is this a bug report? public class FontTest { public static void main(String[] args) { String [] fonts = java.awt.Toolkit.getDefaultToolkit().getFontList(); if (args.length > 0 && args[0].equals("c")) { System.out.println("Font count " + fonts.length); return; } System.out.println("Font count " + fonts.length); for (int i=0;i References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> Message-ID: <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> Hi, > OpenJDK Runtime Environment (build 1.7.0-u4-b228-20120203) I can reproduce the same with the latest Oracle download: $ echo $J7 java_home -v 1.7 --exec $ $J7 java -version java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b20) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode) $ $J7 java FontTest Font count 5 Dialog SansSerif Serif Monospaced DialogInput claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch From mik3hall at gmail.com Thu Apr 19 14:51:04 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 16:51:04 -0500 Subject: Font support In-Reply-To: <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> Message-ID: <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> On Apr 19, 2012, at 4:46 PM, Claudio Nieder wrote: > Hi, > >> OpenJDK Runtime Environment (build 1.7.0-u4-b228-20120203) > > I can reproduce the same with the latest Oracle download: > Thank you. I guess I was starting to wonder if it was only my opinion this wasn't right. 'reproduce' suggests bug. I suppose I should try to figure out what to search on to see if it's an already filed bug report? From private at claudio.ch Thu Apr 19 14:54:47 2012 From: private at claudio.ch (Claudio Nieder) Date: Thu, 19 Apr 2012 23:54:47 +0200 Subject: Font support In-Reply-To: <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> Message-ID: <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> Hi, > Thank you. I guess I was starting to wonder if it was only my opinion this wasn't right. > 'reproduce' suggests bug. I suppose I should try to figure out what to search on to see if it's an already filed bug report? one addition though. The method you use is declared as deprecated. Using this: public class FontTest { public static void main(String[] args) { // String [] fonts = java.awt.Toolkit.getDefaultToolkit().getFontList(); String [] fonts = java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames(); if (args.length > 0 && args[0].equals("c")) { System.out.println("Font count " + fonts.length); return; } System.out.println("Font count " + fonts.length); for (int i=0;i References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> Message-ID: <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> On Apr 19, 2012, at 4:54 PM, Claudio Nieder wrote: > Hi, > >> Thank you. I guess I was starting to wonder if it was only my opinion this wasn't right. >> 'reproduce' suggests bug. I suppose I should try to figure out what to search on to see if it's an already filed bug report? > > one addition though. The method you use is declared as deprecated. Using this: > Faster than me. I just noticed that as well and was going to try the GraphicsEnvironment method. Old code, deprecated should not mean broken though? Now I would wonder if the issue I originally mentioned, monospaced styled output for a JTextPane not working is the same issue or a separate one. If font support is ok, just the deprecated Toolkit method is bad, then JTextPane not right may not be related and a separate bug report or at least a separate issue. From private at claudio.ch Thu Apr 19 15:10:31 2012 From: private at claudio.ch (Claudio Nieder) Date: Fri, 20 Apr 2012 00:10:31 +0200 Subject: Font support In-Reply-To: <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> Message-ID: <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> Hi, > Old code, deprecated should not mean broken though? Though given it is deprecated since and including Java 1.2 the easiest fix would be to remove the method :-) claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch From mik3hall at gmail.com Thu Apr 19 15:18:02 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 17:18:02 -0500 Subject: Font support In-Reply-To: <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> Message-ID: <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> On Apr 19, 2012, at 5:10 PM, Claudio Nieder wrote: > Hi, > >> Old code, deprecated should not mean broken though? > > Though given it is deprecated since and including Java 1.2 the easiest fix would be to remove the method :-) > True enough. I will take your advice there. But I suppose I should still do the bug report. From philip.race at oracle.com Thu Apr 19 15:48:08 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 19 Apr 2012 15:48:08 -0700 Subject: Font support In-Reply-To: <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> Message-ID: <4F909628.4070304@oracle.com> The program is behaving correctly and consistently with the Windows implementation AWT components (java.awt.Button etc) and the AWT toolkit only support the logical fonts and that's all this method will enumerate. We have deprecated methods to indicate there are better alternatives and that may have been over done some times. We have never removed deprecated methods so I don't think we'll remove this one either. -phil. On 4/19/2012 3:18 PM, Michael Hall wrote: > On Apr 19, 2012, at 5:10 PM, Claudio Nieder wrote: > >> Hi, >> >>> Old code, deprecated should not mean broken though? >> Though given it is deprecated since and including Java 1.2 the easiest fix would be to remove the method :-) >> > True enough. I will take your advice there. But I suppose I should still do the bug report. > From mik3hall at gmail.com Thu Apr 19 15:53:18 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 17:53:18 -0500 Subject: Font support In-Reply-To: <4F909628.4070304@oracle.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> Message-ID: On Apr 19, 2012, at 5:48 PM, Phil Race wrote: > The program is behaving correctly and consistently with the Windows implementation > AWT components (java.awt.Button etc) and the AWT toolkit only support the logical fonts > and that's all this method will enumerate. > > We have deprecated methods to indicate there are better alternatives > and that may have been over done some times. > > We have never removed deprecated methods so I don't think we'll > remove this one either. I actually have been putting some time into this code trying to clean up some of the deprecated but it still has quite a ways to go. Most developers have over time probably been better about that than I have. I would have to say it is unfortunate this behavior differs from the Windows implementation. It might be old Mac code you need to worry about here. From mik3hall at gmail.com Thu Apr 19 16:05:23 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 18:05:23 -0500 Subject: Font support In-Reply-To: References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> Message-ID: On Apr 19, 2012, at 5:53 PM, Michael Hall wrote: > > On Apr 19, 2012, at 5:48 PM, Phil Race wrote: > >> The program is behaving correctly and consistently with the Windows implementation >> AWT components (java.awt.Button etc) and the AWT toolkit only support the logical fonts >> and that's all this method will enumerate. >> >> We have deprecated methods to indicate there are better alternatives >> and that may have been over done some times. >> >> We have never removed deprecated methods so I don't think we'll >> remove this one either. > > I actually have been putting some time into this code trying to clean up some of the deprecated but it still has quite a ways to go. > Most developers have over time probably been better about that than I have. > I would have to say it is unfortunate this behavior differs from the Windows implementation. It might be old Mac code you need to worry about here. > Should probably have said that I will probably still file the bug report as a behavior change from prior OS X jvm's. If it's decided to close it since it is deprecated anyhow and the Windows implementation is the correct handling that's OK with me. I plan on changing mine as Claudio mentioned. From philip.race at oracle.com Thu Apr 19 16:14:01 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 19 Apr 2012 16:14:01 -0700 Subject: Font support In-Reply-To: References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> Message-ID: <4F909C39.2080706@oracle.com> I didn't say it was different from Windows. I said it was the *same*. > I actually have been putting some time into this code trying > to clean up some of the deprecated but it still has quite a ways to go. What do you mean here ? What are you doing ? Deprecated methods should be left alone. -phil. On 4/19/2012 3:53 PM, Michael Hall wrote: > On Apr 19, 2012, at 5:48 PM, Phil Race wrote: > >> The program is behaving correctly and consistently with the Windows implementation >> AWT components (java.awt.Button etc) and the AWT toolkit only support the logical fonts >> and that's all this method will enumerate. >> >> We have deprecated methods to indicate there are better alternatives >> and that may have been over done some times. >> >> We have never removed deprecated methods so I don't think we'll >> remove this one either. > I actually have been putting some time into this code trying to clean up some of the deprecated but it still has quite a ways to go. > Most developers have over time probably been better about that than I have. > I would have to say it is unfortunate this behavior differs from the Windows implementation. It might be old Mac code you need to worry about here. > From philip.race at oracle.com Thu Apr 19 16:22:08 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 19 Apr 2012 16:22:08 -0700 Subject: Font support In-Reply-To: References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> Message-ID: <4F909E20.6020101@oracle.com> We wouldn't close it for the reason the method is deprecated. We'd close it as something like "not a bug". I've no idea how it came to be made consistent with what it should have been all along but we aren't likely to put it back the way it was on Apple JDK 6. Using the method on GraphicsEnvironment() should always have been the only way to enumerate all these fonts. -phil. > Should probably have said that I will probably still file the bug report as a behavior change from prior OS X jvm's. If it's decided to close it since it is deprecated anyhow and the Windows implementation is the correct handling that's OK with me. I plan on changing mine as Claudio mentioned. From mik3hall at gmail.com Thu Apr 19 16:23:37 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 18:23:37 -0500 Subject: Font support In-Reply-To: <4F909C39.2080706@oracle.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> <4F909C39.2080706@oracle.com> Message-ID: <48136E0C-5FF6-44D8-AB47-F8FA5DE2A52D@gmail.com> On Apr 19, 2012, at 6:14 PM, Phil Race wrote: > I didn't say it was different from Windows. I said it was the *same*. > > > I actually have been putting some time into this code trying > > to clean up some of the deprecated but it still has quite a ways to go. > > What do you mean here ? What are you doing ? Deprecated methods should be left alone. I apparently misunderstood what you were saying in the Windows comparison. If you look at my first post you will see that this method gets different results between the two versions of the jvm. Both can't be right. From mik3hall at gmail.com Thu Apr 19 16:29:44 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 18:29:44 -0500 Subject: Font support In-Reply-To: <4F909E20.6020101@oracle.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> <4F909E20.6020101@oracle.com> Message-ID: <807C0D37-A18B-4D66-A597-E00D64E703D2@gmail.com> On Apr 19, 2012, at 6:22 PM, Phil Race wrote: > We wouldn't close it for the reason the method is deprecated. We'd close it as something like "not a bug". > I've no idea how it came to be made consistent with what it should have been all along but we aren't > likely to put it back the way it was on Apple JDK 6. > > Using the method on GraphicsEnvironment() should always have been the only way > to enumerate all these fonts. Again up to you what you do with the bug. If you are indicating it is simply pointless then I won't do it? getAvailableFontFamilyNames is since 1.2. Believe it or not some of the code in this application is probably 1.1 Classic Mac OS in origin. You probably won't run into too much code that pre-dates 1.2 though so I doubt this will be a big problem for you at this point. From philip.race at oracle.com Thu Apr 19 16:37:05 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 19 Apr 2012 16:37:05 -0700 Subject: Font support In-Reply-To: <48136E0C-5FF6-44D8-AB47-F8FA5DE2A52D@gmail.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> <4F909C39.2080706@oracle.com> <48136E0C-5FF6-44D8-AB47-F8FA5DE2A52D@gmail.com> Message-ID: <4F90A1A1.7000003@oracle.com> The Apple JDK 6 is the odd one out here. -phil. On 4/19/2012 4:23 PM, Michael Hall wrote: > On Apr 19, 2012, at 6:14 PM, Phil Race wrote: > >> I didn't say it was different from Windows. I said it was the *same*. >> >>> I actually have been putting some time into this code trying >>> to clean up some of the deprecated but it still has quite a ways to go. >> What do you mean here ? What are you doing ? Deprecated methods should be left alone. > I apparently misunderstood what you were saying in the Windows comparison. > If you look at my first post you will see that this method gets different results between the two versions of the jvm. > Both can't be right. > From philip.race at oracle.com Thu Apr 19 16:37:10 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 19 Apr 2012 16:37:10 -0700 Subject: Font support In-Reply-To: <807C0D37-A18B-4D66-A597-E00D64E703D2@gmail.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> <4F909E20.6020101@oracle.com> <807C0D37-A18B-4D66-A597-E00D64E703D2@gmail.com> Message-ID: <4F90A1A6.2080509@oracle.com> In 1.1 you would not have had anything except those 5 logical families. Physical font support was added in 1.2 .. so if the code really dates from 1.1 it shouldn't need more than that anyway. -phil. On 4/19/2012 4:29 PM, Michael Hall wrote: > On Apr 19, 2012, at 6:22 PM, Phil Race wrote: > >> We wouldn't close it for the reason the method is deprecated. We'd close it as something like "not a bug". >> I've no idea how it came to be made consistent with what it should have been all along but we aren't >> likely to put it back the way it was on Apple JDK 6. >> >> Using the method on GraphicsEnvironment() should always have been the only way >> to enumerate all these fonts. > Again up to you what you do with the bug. If you are indicating it is simply pointless then I won't do it? > getAvailableFontFamilyNames is since 1.2. Believe it or not some of the code in this application is probably 1.1 Classic Mac OS in origin. > You probably won't run into too much code that pre-dates 1.2 though so I doubt this will be a big problem for you at this point. > > From mik3hall at gmail.com Thu Apr 19 16:36:21 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 18:36:21 -0500 Subject: Font support In-Reply-To: <4F90A1A6.2080509@oracle.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> <4F909E20.6020101@oracle.com> <807C0D37-A18B-4D66-A597-E00D64E703D2@gmail.com> <4F90A1A6.2080509@oracle.com> Message-ID: <68CB6FE7-1D29-450B-A39F-DF70665E91E0@gmail.com> On Apr 19, 2012, at 6:37 PM, Phil Race wrote: > In 1.1 you would not have had anything except those 5 logical families. > Physical font support was added in 1.2 .. so if the code really dates from > 1.1 it shouldn't need more than that anyway. I will trust your memory on this more than mine it definitely sounds more precise. From mik3hall at gmail.com Thu Apr 19 16:41:38 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 18:41:38 -0500 Subject: Font support In-Reply-To: <4F90A1A1.7000003@oracle.com> References: <140F76A7-99A6-4458-9137-73C95D69B200@gmail.com> <6FEEDDBA-1FCF-4A9D-B115-0A85550A934D@claudio.ch> <19317A62-83CC-4B98-A903-C27592FC71A8@gmail.com> <52278E8A-1583-4B47-AA36-899108623685@claudio.ch> <3876CD38-6281-48BB-B4CB-83423ECA16FE@gmail.com> <70F8D42E-E8F9-4B3A-81BD-D3D335691283@claudio.ch> <98C5DCDE-2C20-4987-AF27-237B351EFB73@gmail.com> <4F909628.4070304@oracle.com> <4F909C39.2080706@oracle.com> <48136E0C-5FF6-44D8-AB47-F8FA5DE2A52D@gmail.com> <4F90A1A1.7000003@oracle.com> Message-ID: <0B9B1E26-9808-44EE-88D9-4105A19A0BC4@gmail.com> On Apr 19, 2012, at 6:37 PM, Phil Race wrote: > The Apple JDK 6 is the odd one out here. But it's your existing codebase for this port. Most of it for features such as this would probably have been cross-platform to Windows so would not be using the deprecated. So again this is an instance where you probably won't have too many instances of problems with Mac specific behavior. In this instance. I'd still be a little concerned about choosing Windows behavior over Apple's in less precisely spec'd areas. From mik3hall at gmail.com Thu Apr 19 18:45:30 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 19 Apr 2012 20:45:30 -0500 Subject: styled JTextPane In-Reply-To: <630D88F6-B8C0-4DB2-9A11-85AFF785F546@gmail.com> References: <630D88F6-B8C0-4DB2-9A11-85AFF785F546@gmail.com> Message-ID: <71D8F3E0-A444-4CDE-9011-2EDA7E45525D@gmail.com> As I indicated earlier this does appear to be a separate issue. I'm not 100% sure again though that it is a bug. It is different from 1.6. Test case.... import javax.swing.*; import javax.swing.text.*; public class StyledTest extends JTextPane { private static final StyleContext sc = new StyleContext(); private static final DefaultStyledDocument doc = new DefaultStyledDocument(sc); static final Style mono = sc.addStyle("mono",null); public static void main(String[] args) { JFrame f = new JFrame("StyledTest"); f.setMinimumSize(new java.awt.Dimension(100,100)); StyledTest st = new StyledTest(); f.add(st); f.pack(); f.setVisible(true); SwingUtilities.invokeLater(new Runnable() { public void run() { try { doc.insertString(0,"AaBbCcDd\nEeFfGgHh",mono); } catch (BadLocationException blex) { blex.printStackTrace(); } }}); } public StyledTest() { setStyledDocument(doc); StyleConstants.setFontFamily(mono,"monospaced"); } } Run on 1.6 you get a smaller serifed font that could be monospaced. Run on 1.7 you get a larger non-serified font that, well, still just might be monospaced. Bug or incidental change? Strictly as opinion probably biased to what I'm used to, assuming both are correctly monospaced output, I like the smaller serifed better, it tends to stand out as different a little better in my application. Not a voting situation? From tobi at ultramixer.com Thu Apr 19 23:51:09 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 20 Apr 2012 08:51:09 +0200 Subject: Native look and feel documentation? In-Reply-To: <83CA7262-EE96-406A-9B11-0D3E33B3FCC7@apple.com> References: <90E50C32-642B-45EA-84DB-24C89D97F96A@ultramixer.com> <83CA7262-EE96-406A-9B11-0D3E33B3FCC7@apple.com> Message-ID: Hi, thanks Mike for that important information. I know that the Mac UI is not as simple I explained it ;) But with JavaFX 2 and the extended CSS possibilities you can do many many things like multi gradient backgrounds, highlights, noise, svg, etc. I love the approach to ask the native system to render the UI in an image! I think it would be the best way for JavaFX 2 too. I would like to dry a few things - so is there a documentation about the JavaRuntimeSupport.framework? Or is this part of code in Java OpenSource / in OpenJDK too? btw: You are right, Lucida Grande in Mac OS X, Helvetica in iOS. Best regards, -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- info at ultramixer.com http://www.ultramixer.com Am 19.04.2012 um 19:34 schrieb Mike Swingler : > Hi, > > We do not publish a spec for people to replicate the Aqua UI, which changes with every OS release (sometimes in big ways, sometimes in small ways). Many UI elements are not expressible with simple gradient fills because they are filled with textures, curved highlights, subtle noise. > > The Swing Aqua Look and Feel asks the native system to render components into a BufferedImage using the JavaRuntimeSupport.framework, so it is always current with the OS, with a minimum of version checks in Java code. > > Oh, and the system default font is Lucida Grande, not Helvetica. > > Regards, > ~Mike > > On Apr 17, 2012, at 4:03 AM, Tobias Bley wrote: > >> Hi Mike, >> >> I started a new project to create native looking skins for JavaFX 2...http://blog.software4java.com/?p=15 >> >> So I have to create a complex css file to style all common controls like buttons, checkboxes, tables etc. >> >> Because of the many gradient fills of the beautiful Mac OS X theme it's not simple to port it to pure CSS without an documentation of the mac os x theme. It know the style guide but my question is: Is there any official documentation or photoshop file available about every user interface element in Mac OS X 10.7? >> >> the best would for me something like this: >> >> Button >> - border: 2px black >> - gradient: color1 0%, color2 10%, color3 100% >> - font: Helvetica >> - font-size: 12px >> - font-color: #222222 >> .... >> >> Best regards, >> Tobi >> >> >> > From artem.ananiev at oracle.com Fri Apr 20 03:02:13 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 20 Apr 2012 14:02:13 +0400 Subject: Native look and feel documentation? In-Reply-To: References: <90E50C32-642B-45EA-84DB-24C89D97F96A@ultramixer.com> <83CA7262-EE96-406A-9B11-0D3E33B3FCC7@apple.com> Message-ID: <4F913425.8080606@oracle.com> (Cross-posting to the OpenJFX mailing list) JavaFX 2.0 controls are open-sourced, and the rest of JavaFX is coming, so didn't you think about contributing your work to OpenJFX? Or even starting a new OpenJDK project to implement native look for JavaFX controls? Note that such project is not Aqua (Mac OS X) specific: on Windows, there is also a way to render platform widgets to offscreen, we use this approach in Windows L&F in Swing. Thanks, Artem On 4/20/2012 10:51 AM, Tobias Bley wrote: > Hi, > > thanks Mike for that important information. I know that the Mac UI is not as simple I explained it ;) But with JavaFX 2 and the extended CSS possibilities you can do many many things like multi gradient backgrounds, highlights, noise, svg, etc. > > I love the approach to ask the native system to render the UI in an image! I think it would be the best way for JavaFX 2 too. I would like to dry a few things - so is there a documentation about the JavaRuntimeSupport.framework? Or is this part of code in Java OpenSource / in OpenJDK too? > > btw: You are right, Lucida Grande in Mac OS X, Helvetica in iOS. > > Best regards, > From swingler at apple.com Fri Apr 20 08:34:42 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 20 Apr 2012 08:34:42 -0700 Subject: Native look and feel documentation? In-Reply-To: References: <90E50C32-642B-45EA-84DB-24C89D97F96A@ultramixer.com> <83CA7262-EE96-406A-9B11-0D3E33B3FCC7@apple.com> Message-ID: <53FF87E7-3A9B-42C3-A01E-762F0C46AAEF@apple.com> All the code is here: Native: Native bridging: Swing LaF/Behavior: Cheers, Mike Swingler Apple Inc. On Apr 19, 2012, at 11:51 PM, Tobias Bley wrote: > Hi, > > thanks Mike for that important information. I know that the Mac UI is not as simple I explained it ;) But with JavaFX 2 and the extended CSS possibilities you can do many many things like multi gradient backgrounds, highlights, noise, svg, etc. > > I love the approach to ask the native system to render the UI in an image! I think it would be the best way for JavaFX 2 too. I would like to dry a few things - so is there a documentation about the JavaRuntimeSupport.framework? Or is this part of code in Java OpenSource / in OpenJDK too? > > btw: You are right, Lucida Grande in Mac OS X, Helvetica in iOS. > > Best regards, > > -- > Tobias Bley > Chief Executive Officer > > -------------------------------------------------------- > > UltraMixer Digital Audio Solutions > Schillerstra?e 29 > D-01326 Dresden > Germany > > -------------------------------------------------------- > info at ultramixer.com http://www.ultramixer.com > > > > Am 19.04.2012 um 19:34 schrieb Mike Swingler : > >> Hi, >> >> We do not publish a spec for people to replicate the Aqua UI, which changes with every OS release (sometimes in big ways, sometimes in small ways). Many UI elements are not expressible with simple gradient fills because they are filled with textures, curved highlights, subtle noise. >> >> The Swing Aqua Look and Feel asks the native system to render components into a BufferedImage using the JavaRuntimeSupport.framework, so it is always current with the OS, with a minimum of version checks in Java code. >> >> Oh, and the system default font is Lucida Grande, not Helvetica. >> >> Regards, >> ~Mike >> >> On Apr 17, 2012, at 4:03 AM, Tobias Bley wrote: >> >>> Hi Mike, >>> >>> I started a new project to create native looking skins for JavaFX 2...http://blog.software4java.com/?p=15 >>> >>> So I have to create a complex css file to style all common controls like buttons, checkboxes, tables etc. >>> >>> Because of the many gradient fills of the beautiful Mac OS X theme it's not simple to port it to pure CSS without an documentation of the mac os x theme. It know the style guide but my question is: Is there any official documentation or photoshop file available about every user interface element in Mac OS X 10.7? >>> >>> the best would for me something like this: >>> >>> Button >>> - border: 2px black >>> - gradient: color1 0%, color2 10%, color3 100% >>> - font: Helvetica >>> - font-size: 12px >>> - font-color: #222222 >>> .... >>> >>> Best regards, >>> Tobi >>> >>> >>> >> > From steve.mcleod at gmail.com Fri Apr 20 10:36:31 2012 From: steve.mcleod at gmail.com (Steve McLeod) Date: Fri, 20 Apr 2012 19:36:31 +0200 Subject: apple.awt.brushMetalLook client property not honoured in OpenJDK 1.7.0_04 Message-ID: <89F29BA3CEB748E2BA11F69C182A744B@gmail.com> (Sorry for the cross-post; I accidentally posted originally to the wrong list) I have this self-contained code example: import javax.swing.*; import java.awt.*; public class ScratchSpace { public static void main(String[] args) { System.out.println("javaVersion = " + System.getProperty("java.version")); JToolBar toolBar = new JToolBar(); toolBar.setFloatable(false); toolBar.add(new JButton("Dummy")); JPanel contentPane = new JPanel(new BorderLayout()); contentPane.add(toolBar, BorderLayout.NORTH); contentPane.add(new JTextArea(20, 20), BorderLayout.CENTER); JFrame frame = new JFrame(); frame.getRootPane().putClientProperty("apple.awt.brushMetalLook", Boolean.TRUE); frame.setContentPane(contentPane); frame.pack(); frame.setLocationRelativeTo(null); frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); frame.setVisible(true); } } In Apple's Java 6 on Lion, this gives me a "unified tool bar" appearance. On OpenJDK 1.7.0_04, I don't get the unified tool bar appearance. Instead the toolbar is a distinct different colour from the window title bar. Regards, Steve --------------------------------------------------- Steve McLeod Founder, Poker Copilot http://www.pokercopilot.com From leonid.romanov at oracle.com Fri Apr 20 10:48:47 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 20 Apr 2012 21:48:47 +0400 Subject: apple.awt.brushMetalLook client property not honoured in OpenJDK 1.7.0_04 In-Reply-To: <89F29BA3CEB748E2BA11F69C182A744B@gmail.com> References: <89F29BA3CEB748E2BA11F69C182A744B@gmail.com> Message-ID: Yep, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 On 20.04.2012, at 21:36, Steve McLeod wrote: > (Sorry for the cross-post; I accidentally posted originally to the wrong list) > > I have this self-contained code example: > > import javax.swing.*; > import java.awt.*; > > public class ScratchSpace { > > public static void main(String[] args) { > System.out.println("javaVersion = " + System.getProperty("java.version")); > JToolBar toolBar = new JToolBar(); > toolBar.setFloatable(false); > toolBar.add(new JButton("Dummy")); > > JPanel contentPane = new JPanel(new BorderLayout()); > contentPane.add(toolBar, BorderLayout.NORTH); > contentPane.add(new JTextArea(20, 20), BorderLayout.CENTER); > > JFrame frame = new JFrame(); > frame.getRootPane().putClientProperty("apple.awt.brushMetalLook", Boolean.TRUE); > frame.setContentPane(contentPane); > frame.pack(); > frame.setLocationRelativeTo(null); > frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); > frame.setVisible(true); > } > > } > > In Apple's Java 6 on Lion, this gives me a "unified tool bar" appearance. > > On OpenJDK 1.7.0_04, I don't get the unified tool bar appearance. Instead the toolbar is a distinct different colour from the window title bar. > > > Regards, > > > > > > > Steve > > > --------------------------------------------------- > > > Steve McLeod > > > Founder, Poker Copilot > > > http://www.pokercopilot.com > > > > From mik3hall at gmail.com Sun Apr 22 16:37:24 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 22 Apr 2012 18:37:24 -0500 Subject: Application memory use Message-ID: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> I am noticing what seems to be some memory issues running my application on openjdk versus on Java 6. Currently in Activity monitor it shows 140.2 MB real mem versus 70.6 for a 1.6 version of the application It has fairly consistently seemed to be showing that it's using twice as much memory. I started up jconsole. (With 1.6 , the 1.7 doesn't appear to work? seems to just show a truncated duke image??) The 1.6 appeared to sawtooth memory in a range, 1.7 seems to climb steady with very infrequent drops. The current information that jconsole shows. 1.6 Used: 17,248 KB Committed: 21,968 KB Max: 253,440 KB GC time 1.978 sec on MarkSweepCompact(8 collections) 2.808 sec on Copy (85 collections) 1.7 Used 70,773 KB Committed 120,384 KB Max: 233,024 KB GC time 8.138 sec on PS Scavenge (68 collections) 2.141 sec on PS MarkSweep(6 collections) Are there any concerns or things developers should be aware of in this area? From henri.gomez at gmail.com Sun Apr 22 23:53:01 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 08:53:01 +0200 Subject: Application memory use In-Reply-To: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: OpenJDK 7 is a 64bits JVM whereas Apple JDK 6 is a 32/64 bits VM. So larger memory footprint. I allready pointed this and we should wait OpenJDK 7 for OSX to re-enable a 32/64bits VM mode or at least pointers compression (it's no more the case). 2012/4/23 Michael Hall : > I am noticing what seems to be some memory issues running my application on openjdk versus on Java 6. > Currently in Activity monitor it shows 140.2 MB real mem versus 70.6 for a 1.6 version of the application > It has fairly consistently seemed to be showing that it's using twice as much memory. > > I started up jconsole. (With 1.6 , the 1.7 doesn't appear to work? seems to just show a truncated duke image??) > The 1.6 appeared to sawtooth memory in a range, 1.7 seems to climb steady with very infrequent drops. > The current information that jconsole shows. > > 1.6 > Used: 17,248 KB > Committed: 21,968 KB > Max: 253,440 KB > GC time 1.978 sec on MarkSweepCompact(8 collections) > ? ? ? ? ? ? ? ?2.808 sec on Copy (85 collections) > > 1.7 > Used 70,773 KB > Committed 120,384 KB > Max: 233,024 KB > GC time 8.138 sec on PS Scavenge (68 collections) > ? ? ? ? ? ? ? 2.141 sec on PS MarkSweep(6 collections) > > Are there any concerns or things developers should be aware of in this area? > From mik3hall at gmail.com Mon Apr 23 02:02:19 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 04:02:19 -0500 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: On Apr 23, 2012, at 1:53 AM, Henri Gomez wrote: > OpenJDK 7 is a 64bits JVM whereas Apple JDK 6 is a 32/64 bits VM. > So larger memory footprint. > > I allready pointed this and we should wait OpenJDK 7 for OSX to > re-enable a 32/64bits VM mode or at least pointers compression (it's > no more the case). Both showed as 64 bit in Activity Monitor. This may very well be the largest part of it but the JConsole heap graphs looked considerably different between the two applications and the information seemed to indicate different methods for gc. I guess I was wondering if there is anything we should know about this as well? From tobi at ultramixer.com Mon Apr 23 02:18:00 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 23 Apr 2012 11:18:00 +0200 Subject: apple.awt.brushMetalLook support on OpenJDK7? - JNI solution? Message-ID: <86678C13-C887-417F-B15B-58DEC2225388@ultramixer.com> Hi, it seams in current OpenJDK7 there is no support for Apples JDK6 property "apple.awt.brushMetalLook"? So we can not provide the same quality of GUI like with JDK6 :( Is there any solution for OpenJDK7 to make textured windows? I wrote a little JNI code to make a Java window a "textured window" but it doen't work with OpenJDK7 as well :( Any suggestions? Tobi -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com From henri.gomez at gmail.com Mon Apr 23 02:28:34 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 11:28:34 +0200 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: > Both showed as 64 bit in Activity Monitor. > This may very well be the largest part of it but the JConsole heap graphs > looked considerably different between the two applications and the > information seemed to indicate different methods for gc. I guess I was > wondering if there is anything we should know about this as well? 64bits Hotspot (6u23 and later) JVMs switch automatically to Compressed Pointers (-XX:+UseCompressedOops), saving memory. http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html From hs at tagtraum.com Mon Apr 23 02:30:09 2012 From: hs at tagtraum.com (Hendrik Schreiber) Date: Mon, 23 Apr 2012 11:30:09 +0200 Subject: apple.awt.brushMetalLook support on OpenJDK7? - JNI solution? In-Reply-To: <86678C13-C887-417F-B15B-58DEC2225388@ultramixer.com> References: <86678C13-C887-417F-B15B-58DEC2225388@ultramixer.com> Message-ID: On Apr 23, 2012, at 11:18 AM, Tobias Bley wrote: > it seams in current OpenJDK7 there is no support for Apples JDK6 property "apple.awt.brushMetalLook"? So we can not provide the same quality of GUI like with JDK6 :( > > Is there any solution for OpenJDK7 to make textured windows? > > I wrote a little JNI code to make a Java window a "textured window" but it doen't work with OpenJDK7 as well :( > > Any suggestions? There is a bug for this: http://java.net/jira/browse/MACOSX_PORT-764 Also see: http://lists.apple.com/archives/java-dev/2011/Dec/msg00008.html Cheers, -hendrik From mik3hall at gmail.com Mon Apr 23 02:41:25 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 04:41:25 -0500 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: On Apr 23, 2012, at 4:28 AM, Henri Gomez wrote: >> Both showed as 64 bit in Activity Monitor. >> This may very well be the largest part of it but the JConsole heap graphs >> looked considerably different between the two applications and the >> information seemed to indicate different methods for gc. I guess I was >> wondering if there is anything we should know about this as well? > > 64bits Hotspot (6u23 and later) JVMs switch automatically to > Compressed Pointers (-XX:+UseCompressedOops), saving memory. > > http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html I will read that. Thanks. I'm wondering now if I can determine if this does more or less completely explain the difference. Can I get the Java 6 to show about the same memory use as the Java 7? If there is an option to turn the switch off that you mention I could try that. Otherwise I was wondering if starting the Java 6 jvm -d64, iirc, or whatever it is to indicate it should use 64 bit would also accomplish eliminating the compression? For a while watching JConsole it appeared Java 7 wasn't going to give any memory back at while while 6 showed to briefly climb and drop back down in a narrower range in the sawtooth pattern mentioned earlier. I would think this might mean some difference in the maximum memory footprint. From tobi at ultramixer.com Mon Apr 23 02:58:06 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 23 Apr 2012 11:58:06 +0200 Subject: apple.awt.brushMetalLook support on OpenJDK7? - JNI solution? In-Reply-To: References: <86678C13-C887-417F-B15B-58DEC2225388@ultramixer.com> Message-ID: <6E5C72B4-E0E9-42C9-A496-1FAC705A3E14@ultramixer.com> Thanks Hendrik, I know the report, voted and commented it ;) But there is no acitvity since 5 month :( So I think about my own native solution in writing JNI code. My current problem is that with OpenJDK7 it's not possible to get the NSWindow from JavaWindow in Objective C code: The folling code only works on JDK6: // Given a Java component, return an NSWindow* NSWindow * GetWindowFromComponent(jobject parent, JNIEnv *env) { JAWT awt; JAWT_DrawingSurface* ds; JAWT_DrawingSurfaceInfo* dsi; JAWT_MacOSXDrawingSurfaceInfo* dsi_mac; jboolean result; jint lock; // Get the AWT awt.version = JAWT_VERSION_1_4; result = JAWT_GetAWT(env, &awt); assert(result != JNI_FALSE); // Get the drawing surface ds = awt.GetDrawingSurface(env, parent); assert(ds != NULL); // Lock the drawing surface lock = ds->Lock(ds); assert((lock & JAWT_LOCK_ERROR) == 0); // Get the drawing surface info dsi = ds->GetDrawingSurfaceInfo(ds); // Get the platform-specific drawing info dsi_mac = (JAWT_MacOSXDrawingSurfaceInfo*)dsi->platformInfo; // Get the NSView corresponding to the component that was passed NSView *view = dsi_mac->cocoaViewRef; // Free the drawing surface info ds->FreeDrawingSurfaceInfo(dsi); // Unlock the drawing surface ds->Unlock(ds); // Free the drawing surface awt.FreeDrawingSurface(ds); // Get the view's parent window; this is what we need to show a sheet return [view window]; } -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 23.04.2012 um 11:30 schrieb Hendrik Schreiber : > On Apr 23, 2012, at 11:18 AM, Tobias Bley wrote: > >> it seams in current OpenJDK7 there is no support for Apples JDK6 property "apple.awt.brushMetalLook"? So we can not provide the same quality of GUI like with JDK6 :( >> >> Is there any solution for OpenJDK7 to make textured windows? >> >> I wrote a little JNI code to make a Java window a "textured window" but it doen't work with OpenJDK7 as well :( >> >> Any suggestions? > > There is a bug for this: > > http://java.net/jira/browse/MACOSX_PORT-764 > Also see: http://lists.apple.com/archives/java-dev/2011/Dec/msg00008.html > > Cheers, > > -hendrik From mik3hall at gmail.com Mon Apr 23 03:07:10 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 05:07:10 -0500 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: On Apr 23, 2012, at 4:28 AM, Henri Gomez wrote: > 64bits Hotspot (6u23 and later) JVMs switch automatically to > Compressed Pointers (-XX:+UseCompressedOops), saving memory. > > http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html OK reading this I'm not sure there is much I can do in order to compare both running the same mode to see if this about all of the memory use difference. Since 32 bit isn't available in current builds compression is not possible? Do you currently have any builds that still actually include the 32 bit in a universal build? For the Java 6 I'm assuming I'm also stuck with the default and can't change given... > For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag with the java command to enable the feature. Along with... /usr/libexec/java_home -v 1.6 --exec java -version java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-10M3635) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) I'm assuming the 31 in 1.6.0_31 means > the 23 in 6u23? So forced to use the default there as well? From henri.gomez at gmail.com Mon Apr 23 03:08:57 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 12:08:57 +0200 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: >> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html > > OK reading this I'm not sure there is much I can do in order to compare both running the same mode to see if this about all of the memory use difference. > Since 32 bit isn't available in current builds compression is not possible? > Do you currently have any builds that still actually include the 32 bit in a universal build? > > For the Java 6 I'm assuming I'm also stuck with the default and can't change given... > >> For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag with the java command to enable the feature. > > Along with... > /usr/libexec/java_home -v 1.6 --exec java -version > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-10M3635) > Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) > > I'm assuming the 31 in 1.6.0_31 means > the 23 in 6u23? So forced to use the default there as well? -XX:+UseCompressedOop is activated by default on 23 and post release From henri.gomez at gmail.com Mon Apr 23 03:17:42 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 12:17:42 +0200 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 Message-ID: Hi to all, I tested Oracle Java 7 for OSX today (Developper Preview release b21 based on u4). I could see a 32/64bits aware JVM is available (-d32/-d64 & -XX:+UseCompressedOop) whereas it's no more case for OpenJDK 7 since Mac OSX Port has been merged into u4 branch. Putting back 32/64bits support in OpenJDK 7 for OSX was a point discussed many time on this list and macosx-port list but is still in pending state. Since it appears to be technically possible, could we have feedbacks and informations on how to bring dual mode VM to stock OpenJDK7 for OSX ? Cheers From mik3hall at gmail.com Mon Apr 23 03:22:54 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 05:22:54 -0500 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> On Apr 23, 2012, at 5:08 AM, Henri Gomez wrote: >> > > -XX:+UseCompressedOop is activated by default on 23 and post release Right. So unless I could fallback to an earlier Apple release or you or someone somewhere else has a true universal 32/64 openjdk build still available there is no way to compare a running application for memory differences due to the presence or absence of the compressed option. From mik3hall at gmail.com Mon Apr 23 03:25:03 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 05:25:03 -0500 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: References: Message-ID: On Apr 23, 2012, at 5:17 AM, Henri Gomez wrote: > Hi to all, > > I tested Oracle Java 7 for OSX today (Developper Preview release b21 > based on u4). > > I could see a 32/64bits aware JVM is available (-d32/-d64 & > -XX:+UseCompressedOop) whereas it's no more case for OpenJDK 7 since > Mac OSX Port has been merged into u4 branch. Ah, missed this before sending my last. From mik3hall at gmail.com Mon Apr 23 03:35:01 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 05:35:01 -0500 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: References: Message-ID: <4D7BB565-F6AA-484C-8A83-4FAD74D21440@gmail.com> On Apr 23, 2012, at 5:17 AM, Henri Gomez wrote: > I could see a 32/64bits aware JVM is available (-d32/-d64 & > -XX:+UseCompressedOop) whereas it's no more case for OpenJDK 7 since > Mac OSX Port has been merged into u4 branch. One thing on this. I'd assumed one thing eliminating 32 bit support accomplished was eliminating any 32 bit specific bugs. Does this bring them back? I had one that was a duplicate of someone else's. I assume there are others? From kirk at kodewerk.com Mon Apr 23 03:38:52 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 23 Apr 2012 12:38:52 +0200 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: CMS will leave floating garbage which will be picked up on the next collection. The parallel collectors will be exact and thus the working or live set size after GC will always be larger when using CMS. On 2012-04-23, at 11:41 AM, Michael Hall wrote: > > On Apr 23, 2012, at 4:28 AM, Henri Gomez wrote: > >>> Both showed as 64 bit in Activity Monitor. >>> This may very well be the largest part of it but the JConsole heap graphs >>> looked considerably different between the two applications and the >>> information seemed to indicate different methods for gc. I guess I was >>> wondering if there is anything we should know about this as well? >> >> 64bits Hotspot (6u23 and later) JVMs switch automatically to >> Compressed Pointers (-XX:+UseCompressedOops), saving memory. >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html > > I will read that. Thanks. I'm wondering now if I can determine if this does more or less completely explain the difference. > Can I get the Java 6 to show about the same memory use as the Java 7? > If there is an option to turn the switch off that you mention I could try that. > Otherwise I was wondering if starting the Java 6 jvm -d64, iirc, or whatever it is to indicate it should use 64 bit would also accomplish eliminating the compression? > For a while watching JConsole it appeared Java 7 wasn't going to give any memory back at while while 6 showed to briefly climb and drop back down in a narrower range in the sawtooth pattern mentioned earlier. I would think this might mean some difference in the maximum memory footprint. From alexandr.scherbatiy at oracle.com Mon Apr 23 04:08:21 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Apr 2012 15:08:21 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F900FAF.6070104@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> Message-ID: <4F953825.20508@oracle.com> Thank you for the review. Here is the new version: http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ 1. The synthesizeMouseEnteredExitedEvents method is added as a native method to the CPlatformWindow class. Now it is invoked only in places that programmatically change a window size: - nativeSetNSWindowBounds method from the AWTWindow - setVisible and setWindowState methods from the CPlatformWindow 2. The objective-c code is formatted. 3. I do not think that setting the lastMouseEventPeer after sending the MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in the peer. The postEvent method just post the MOUSE_ENTERED events to the queue. It does not use the lastMouseEventPeer variable and there is no a recursion that invokes the dispatchMouseEvent method again. 4. Dragging a window under a panel should not generate mouse entered/exited events for components. However the events should be generated if the window is moved out of the frame or moved in to the frame. So one more condition that checks is the mouse crosess the frame borders are added to the dispatchMouseEvent method from the LWWindowPeer class. The DragWindowOutOfFrameTest test is added that these events are properly generated. Thanks, Alexandr. On 4/19/2012 5:14 PM, Anthony Petrov wrote: > Hi Alexander, > > 1. I don't think that it's a good idea to add > synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These > methods are supposed to perform direct calls to Cocoa API w/o any > side-effects. They may be used for windows that even aren't AWT > windows, and as such sending them the > synthesizeMouseEnteredExitedEvents message is useless, and just > doesn't seem right from CWrapper's purpose perspective. You may want > to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() > native method that would call this native method, and then add a call > to it where needed in Java code. > > 2. Please follow formatting guidelines and reformat lines like this: > >> if(id != MouseEvent.MOUSE_DRAGGED){ > > to read as > > if (id != MouseEvent.MOUSE_DRAGGED) { > > instead. I see lots of such mis-formatted if() statements all over > your code. > > 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer > after sending the MOUSE_ENTERED event. Before your fix it's been set > earlier. Can this change affect some logic in the peer code while > processing ENTERED events at a user event handler? > > -- > best regards, > Anthony > > On 04/18/12 19:40, Alexander Scherbatiy wrote: >> >> Please review a fix for CR 7154048. >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >> >> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >> >> Let's see the following test case: >> - Frame contains two components JLabel and JButton >> - The JLabel component has a mouse listener >> mousePressed: create a Window under the mouse click >> mouseDragged: drag the created window >> mouseReleased: close the Window >> - A user clicks on the JLabel component, drags the mouse to the JButton >> component and releases the mouse button >> >> The current JDK 8 implementation shows the following events on Mac OS X: >> -------------------------------------------------------- >> mouse pressed: javax.swing.JLabel >> mouse exited: javax.swing.JLabel >> mouse entered: javax.swing.JLabel >> mouse dragged: javax.swing.JLabel >> mouse exited: javax.swing.JLabel >> mouse entered: javax.swing.JButton >> mouse dragged: javax.swing.JLabel >> mouse exited: javax.swing.JButton >> mouse entered: Drag Window >> mouse exited: Drag Window >> mouse entered: javax.swing.JButton >> mouse released: javax.swing.JButton >> -------------------------------------------------------- >> >> There are several issues: >> 1) The window does not receive the mouse entered event when it is >> created under the mouse >> 2) There are JLabel exited/JButton entered events during the window >> dragging >> 3) JLabel does not receive the mouse released event >> >> The fix synthesizes the mouse entered/exited events manually if they are >> not received. >> >> The entered/exited events synthesizing is added to setFrame, toFront, >> toBack, and zoom methods of the AWTWindow and CWrapper classes. >> >> There is an option to add the events synthesizing to the windowDidResize >> notification. However this notification is sent when a window size is >> changed in both cases, programmatically and when user is resized the >> window. So in a lot of case there is no need for the our use case events >> generation. >> >> The LWWindowPeer class is updated to not generate extra mouse enter/exit >> events during the mouse dragging. >> >> Tho automated tests are added. >> >> Thanks, >> Alexandr. From henri.gomez at gmail.com Mon Apr 23 04:54:21 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 13:54:21 +0200 Subject: Application memory use In-Reply-To: <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> Message-ID: 2012/4/23 Michael Hall : > > On Apr 23, 2012, at 5:08 AM, Henri Gomez wrote: >>> >> >> -XX:+UseCompressedOop is activated by default on 23 and post release > > Right. > So unless I could fallback to an earlier Apple release or you or someone somewhere else has a true universal 32/64 openjdk build still available there is no way to compare a running application for memory differences due to the presence or absence of the compressed option. I'm studing on bringing back 32/64 (universal) OpenJDK 7 fo From henri.gomez at gmail.com Mon Apr 23 04:54:54 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 13:54:54 +0200 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> Message-ID: 2012/4/23 Henri Gomez : > 2012/4/23 Michael Hall : >> >> On Apr 23, 2012, at 5:08 AM, Henri Gomez wrote: >>>> >>> >>> -XX:+UseCompressedOop is activated by default on 23 and post release >> >> Right. >> So unless I could fallback to an earlier Apple release or you or someone somewhere else has a true universal 32/64 openjdk build still available there is no way to compare a running application for memory differences due to the presence or absence of the compressed option. I'm studying on how to bring back 32/64 (universal) OpenJDK 7 to OSX From staffan.larsen at oracle.com Mon Apr 23 05:05:04 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Apr 2012 14:05:04 +0200 Subject: RFR (S): 7163524: Add SecTaskAccess attribute to jstack [macosx] Message-ID: Please review the following change to allow jstack to attach to other processes on OS X. Webrev: http://cr.openjdk.java.net/~sla/7163524/webrev.00/ This allows jstack to use the SA framework to attach to the JVM to get information. OS X requires binaries to be linked with the SecTaskAccess attribute in Info.plist to allow them access to other processes. Previously jmap, jinfo and jsadebugd has been compiled this way, but jstack was missing. This fix treats jstack in the same way. Thanks, /Staffan From david.holmes at oracle.com Mon Apr 23 05:17:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Apr 2012 22:17:10 +1000 Subject: RFR (S): 7163524: Add SecTaskAccess attribute to jstack [macosx] In-Reply-To: References: Message-ID: <4F954846.5070504@oracle.com> On 23/04/2012 10:05 PM, Staffan Larsen wrote: > Please review the following change to allow jstack to attach to other > processes on OS X. > > Webrev: http://cr.openjdk.java.net/~sla/7163524/webrev.00/ > > This allows jstack to use the SA framework to attach to the JVM to get > information. OS X requires binaries to be linked with the SecTaskAccess > attribute in Info.plist to allow them access to other processes. > Previously jmap, jinfo and jsadebugd has been compiled this way, but > jstack was missing. This fix treats jstack in the same way. Looks fine in that regard. David > Thanks, > /Staffan From anthony.petrov at oracle.com Mon Apr 23 07:31:54 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 23 Apr 2012 18:31:54 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F953825.20508@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> <4F953825.20508@oracle.com> Message-ID: <4F9567DA.3010306@oracle.com> Hi Alexander, Thanks! The fix looks fine to me. I appreciate the newly added tests, however, I haven't reviewed them thoroughly. One question though, do the tests pass on other platforms (Win & X11) as well? -- best regards, Anthony On 04/23/12 15:08, Alexander Scherbatiy wrote: > > Thank you for the review. > > Here is the new version: > http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ > > 1. The synthesizeMouseEnteredExitedEvents method is added as a native > method to the CPlatformWindow class. > Now it is invoked only in places that programmatically change a window > size: > - nativeSetNSWindowBounds method from the AWTWindow > - setVisible and setWindowState methods from the CPlatformWindow > > 2. The objective-c code is formatted. > > 3. I do not think that setting the lastMouseEventPeer after sending the > MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in > the peer. > The postEvent method just post the MOUSE_ENTERED events to the queue. It > does not use the lastMouseEventPeer variable and there is no a recursion > that invokes the dispatchMouseEvent method again. > > 4. Dragging a window under a panel should not generate mouse > entered/exited events for components. However the events should be > generated if the window is moved out of the frame or moved in to the > frame. So one more condition that checks is the mouse crosess the frame > borders are added to the dispatchMouseEvent method from the LWWindowPeer > class. > The DragWindowOutOfFrameTest test is added that these events are > properly generated. > > Thanks, > Alexandr. > > On 4/19/2012 5:14 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> 1. I don't think that it's a good idea to add >> synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These >> methods are supposed to perform direct calls to Cocoa API w/o any >> side-effects. They may be used for windows that even aren't AWT >> windows, and as such sending them the >> synthesizeMouseEnteredExitedEvents message is useless, and just >> doesn't seem right from CWrapper's purpose perspective. You may want >> to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() >> native method that would call this native method, and then add a call >> to it where needed in Java code. >> >> 2. Please follow formatting guidelines and reformat lines like this: >> >>> if(id != MouseEvent.MOUSE_DRAGGED){ >> >> to read as >> >> if (id != MouseEvent.MOUSE_DRAGGED) { >> >> instead. I see lots of such mis-formatted if() statements all over >> your code. >> >> 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer >> after sending the MOUSE_ENTERED event. Before your fix it's been set >> earlier. Can this change affect some logic in the peer code while >> processing ENTERED events at a user event handler? >> >> -- >> best regards, >> Anthony >> >> On 04/18/12 19:40, Alexander Scherbatiy wrote: >>> >>> Please review a fix for CR 7154048. >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >>> >>> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >>> >>> Let's see the following test case: >>> - Frame contains two components JLabel and JButton >>> - The JLabel component has a mouse listener >>> mousePressed: create a Window under the mouse click >>> mouseDragged: drag the created window >>> mouseReleased: close the Window >>> - A user clicks on the JLabel component, drags the mouse to the JButton >>> component and releases the mouse button >>> >>> The current JDK 8 implementation shows the following events on Mac OS X: >>> -------------------------------------------------------- >>> mouse pressed: javax.swing.JLabel >>> mouse exited: javax.swing.JLabel >>> mouse entered: javax.swing.JLabel >>> mouse dragged: javax.swing.JLabel >>> mouse exited: javax.swing.JLabel >>> mouse entered: javax.swing.JButton >>> mouse dragged: javax.swing.JLabel >>> mouse exited: javax.swing.JButton >>> mouse entered: Drag Window >>> mouse exited: Drag Window >>> mouse entered: javax.swing.JButton >>> mouse released: javax.swing.JButton >>> -------------------------------------------------------- >>> >>> There are several issues: >>> 1) The window does not receive the mouse entered event when it is >>> created under the mouse >>> 2) There are JLabel exited/JButton entered events during the window >>> dragging >>> 3) JLabel does not receive the mouse released event >>> >>> The fix synthesizes the mouse entered/exited events manually if they are >>> not received. >>> >>> The entered/exited events synthesizing is added to setFrame, toFront, >>> toBack, and zoom methods of the AWTWindow and CWrapper classes. >>> >>> There is an option to add the events synthesizing to the windowDidResize >>> notification. However this notification is sent when a window size is >>> changed in both cases, programmatically and when user is resized the >>> window. So in a lot of case there is no need for the our use case events >>> generation. >>> >>> The LWWindowPeer class is updated to not generate extra mouse enter/exit >>> events during the mouse dragging. >>> >>> Tho automated tests are added. >>> >>> Thanks, >>> Alexandr. > From anthony.petrov at oracle.com Mon Apr 23 07:34:34 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 23 Apr 2012 18:34:34 +0400 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: <4F8EB5A1.6060104@oracle.com> References: <4F8EB5A1.6060104@oracle.com> Message-ID: <4F95687A.3000709@oracle.com> Mike et al., Could I get a review for this fix please? -- best regards, Anthony On 04/18/12 16:37, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7149062 at: > > http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.0/ > > The AWTWindow class now inherits from NSObject and implements the > NSWindowDelegate protocol. The real NSWindow object is held in the > nsWindow property of the AWTWindow class, and is represented by either > an AWTWindow_Normal or AWTWindow_Panel instance. These two classes > inherit from NSWindow and NSPanel correspondingly. Note, however, that > we still return a reference to the NSWindow/NSPanel instance to Java so > that the pointer could be used with CWrapper methods directly. A > reference to an associated AWTWindow instance is always available as > (AWTWindow*)[nsWindow delegate]. > > All windows that inherit from NSWindow are added to the windows list in > the dock icon menu by default. We use NSPanel-based windows for UTILITY, > HUD, NONACTIVATING, and HIDES_ON_DEACTIVATE windows only, because these > kinds of windows typically don't represent main application windows, and > thus aren't expected to be added to the windows list. Besides, UTILITY > (and HUD?) windows just have to be NSPanels. > > This fix is going to be back-ported to 7u6 later on. > > -- > best regards, > Anthony From Dmitry.Samersoff at oracle.com Mon Apr 23 08:14:31 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 23 Apr 2012 19:14:31 +0400 Subject: RFR (S): 7163524: Add SecTaskAccess attribute to jstack [macosx] In-Reply-To: References: Message-ID: <4F9571D7.4030306@oracle.com> Looks good for me. On 2012-04-23 16:05, Staffan Larsen wrote: > Please review the following change to allow jstack to attach to other > processes on OS X. > > Webrev: http://cr.openjdk.java.net/~sla/7163524/webrev.00/ > > This allows jstack to use the SA framework to attach to the JVM to get > information. OS X requires binaries to be linked with the SecTaskAccess > attribute in Info.plist to allow them access to other processes. > Previously jmap, jinfo and jsadebugd has been compiled this way, but > jstack was missing. This fix treats jstack in the same way. > > Thanks, > /Staffan -- Dmitry Samersoff Java SE development team, SPB04 * There will come soft rains ... From hs at tagtraum.com Mon Apr 23 08:30:40 2012 From: hs at tagtraum.com (Hendrik Schreiber) Date: Mon, 23 Apr 2012 17:30:40 +0200 Subject: apple.awt.brushMetalLook support on OpenJDK7? - JNI solution? In-Reply-To: <6E5C72B4-E0E9-42C9-A496-1FAC705A3E14@ultramixer.com> References: <86678C13-C887-417F-B15B-58DEC2225388@ultramixer.com> <6E5C72B4-E0E9-42C9-A496-1FAC705A3E14@ultramixer.com> Message-ID: <17DA0DA3-1797-4865-889C-4C7DAB44AE6B@tagtraum.com> On Apr 23, 2012, at 11:58 AM, Tobias Bley wrote: > Thanks Hendrik, I know the report, voted and commented it ;) > > But there is no acitvity since 5 month :( It looks like Dmitry assigned the bug to Sergey - I hope this leads to some progress.. -hendrik From scott.kovatch at oracle.com Mon Apr 23 08:30:27 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 23 Apr 2012 08:30:27 -0700 Subject: apple.awt.brushMetalLook support on OpenJDK7? - JNI solution? In-Reply-To: <6E5C72B4-E0E9-42C9-A496-1FAC705A3E14@ultramixer.com> References: <86678C13-C887-417F-B15B-58DEC2225388@ultramixer.com> <6E5C72B4-E0E9-42C9-A496-1FAC705A3E14@ultramixer.com> Message-ID: <16679ECE-D6EA-4601-B544-875CC183CD95@oracle.com> On Apr 23, 2012, at 2:58 AM, Tobias Bley wrote: > Thanks Hendrik, I know the report, voted and commented it ;) > > But there is no acitvity since 5 month :( > > So I think about my own native solution in writing JNI code. My current problem is that with OpenJDK7 it's not possible to get the NSWindow from JavaWindow in Objective C code: The folling code only works on JDK6: This is correct. You can't assume that you are hosted in an NSWindow anymore. The AWT in JDK 7 does not support the NSView/CG drawing that JDK 6 used; everything is CALayer-based now. The platformInfo field is an NSObject that conforms to the JAWT_SurfaceLayers protocol: @protocol JAWT_SurfaceLayers @property (readwrite, retain) CALayer *layer; @property (readonly) CALayer *windowLayer; @end It does look like we have some work left to do in the JAWT API, based on what I see in jdk/src/macosx/native/sun/awt/awt_DrawingSurface.m. I'm also not completely sure why we removed access to the NSWindow. CALayers or not, you probably are going to be hosted in an NSWindow. Your main applet panel is the only case where you won't be. Patches are always welcome. :-) -- Scott From leonid.romanov at oracle.com Mon Apr 23 08:39:40 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 23 Apr 2012 19:39:40 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F953825.20508@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> <4F953825.20508@oracle.com> Message-ID: <8600BFDB-9091-4F9C-93A9-7F29B42CC5AD@oracle.com> Hi, I can't find where you set initial value of mouseIsOver variable. Does Objective-C guarantee that it gets some defined default value? On 23.04.2012, at 15:08, Alexander Scherbatiy wrote: > > Thank you for the review. > > Here is the new version: > http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ > > 1. The synthesizeMouseEnteredExitedEvents method is added as a native method to the CPlatformWindow class. > Now it is invoked only in places that programmatically change a window size: > - nativeSetNSWindowBounds method from the AWTWindow > - setVisible and setWindowState methods from the CPlatformWindow > > 2. The objective-c code is formatted. > > 3. I do not think that setting the lastMouseEventPeer after sending the MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in the peer. > The postEvent method just post the MOUSE_ENTERED events to the queue. It does not use the lastMouseEventPeer variable and there is no a recursion that invokes the dispatchMouseEvent method again. > > 4. Dragging a window under a panel should not generate mouse entered/exited events for components. However the events should be generated if the window is moved out of the frame or moved in to the frame. So one more condition that checks is the mouse crosess the frame borders are added to the dispatchMouseEvent method from the LWWindowPeer class. > The DragWindowOutOfFrameTest test is added that these events are properly generated. > > Thanks, > Alexandr. > > On 4/19/2012 5:14 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> 1. I don't think that it's a good idea to add synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These methods are supposed to perform direct calls to Cocoa API w/o any side-effects. They may be used for windows that even aren't AWT windows, and as such sending them the synthesizeMouseEnteredExitedEvents message is useless, and just doesn't seem right from CWrapper's purpose perspective. You may want to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() native method that would call this native method, and then add a call to it where needed in Java code. >> >> 2. Please follow formatting guidelines and reformat lines like this: >> >>> if(id != MouseEvent.MOUSE_DRAGGED){ >> >> to read as >> >> if (id != MouseEvent.MOUSE_DRAGGED) { >> >> instead. I see lots of such mis-formatted if() statements all over your code. >> >> 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer after sending the MOUSE_ENTERED event. Before your fix it's been set earlier. Can this change affect some logic in the peer code while processing ENTERED events at a user event handler? >> >> -- >> best regards, >> Anthony >> >> On 04/18/12 19:40, Alexander Scherbatiy wrote: >>> >>> Please review a fix for CR 7154048. >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >>> >>> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >>> >>> Let's see the following test case: >>> - Frame contains two components JLabel and JButton >>> - The JLabel component has a mouse listener >>> mousePressed: create a Window under the mouse click >>> mouseDragged: drag the created window >>> mouseReleased: close the Window >>> - A user clicks on the JLabel component, drags the mouse to the JButton >>> component and releases the mouse button >>> >>> The current JDK 8 implementation shows the following events on Mac OS X: >>> -------------------------------------------------------- >>> mouse pressed: javax.swing.JLabel >>> mouse exited: javax.swing.JLabel >>> mouse entered: javax.swing.JLabel >>> mouse dragged: javax.swing.JLabel >>> mouse exited: javax.swing.JLabel >>> mouse entered: javax.swing.JButton >>> mouse dragged: javax.swing.JLabel >>> mouse exited: javax.swing.JButton >>> mouse entered: Drag Window >>> mouse exited: Drag Window >>> mouse entered: javax.swing.JButton >>> mouse released: javax.swing.JButton >>> -------------------------------------------------------- >>> >>> There are several issues: >>> 1) The window does not receive the mouse entered event when it is >>> created under the mouse >>> 2) There are JLabel exited/JButton entered events during the window >>> dragging >>> 3) JLabel does not receive the mouse released event >>> >>> The fix synthesizes the mouse entered/exited events manually if they are >>> not received. >>> >>> The entered/exited events synthesizing is added to setFrame, toFront, >>> toBack, and zoom methods of the AWTWindow and CWrapper classes. >>> >>> There is an option to add the events synthesizing to the windowDidResize >>> notification. However this notification is sent when a window size is >>> changed in both cases, programmatically and when user is resized the >>> window. So in a lot of case there is no need for the our use case events >>> generation. >>> >>> The LWWindowPeer class is updated to not generate extra mouse enter/exit >>> events during the mouse dragging. >>> >>> Tho automated tests are added. >>> >>> Thanks, >>> Alexandr. > From artem.ananiev at oracle.com Mon Apr 23 08:46:51 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Apr 2012 19:46:51 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F846D22.4030706@oracle.com> References: <4F846D22.4030706@oracle.com> Message-ID: <4F95796B.9080204@oracle.com> Hi, Alex, the fix looks fine. Just a minor comment: I would use LinkedList instead of ArrayList as the type of "results" as this collection is mostly used to add elements: this operation is faster in linked lists than in array ones. Thanks, Artem On 4/10/2012 9:25 PM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ > > for this bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 > > the spec for the method > javax.swing.JDesktopPane.getAllFrames() > > says > > * Returns all JInternalFrames currently displayed in the > * desktop. Returns iconified frames as well as expanded frames. > > but the AquaLookAndFeel on MacOS uses a special container for the > minimized internal frames > and that's why the current implementation doesn't see them > > the proposed fix recursively looks for the internal frames > among the JDesktopPane's children > > the test can be found here: > http://java.net/jira/browse/MACOSX_PORT-557 > > Thanks > alexp From henri.gomez at gmail.com Mon Apr 23 09:04:40 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 18:04:40 +0200 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: <4F952DD9.7010309@javaspecialists.eu> References: <4F952DD9.7010309@javaspecialists.eu> Message-ID: 2012/4/23 Dr Heinz M. Kabutz : > 32-bit support is very useful for research purposes - I would definitely > welcome having it back. ?Otherwise it means having to also have Java 6 > available, just for testing purposes. I patched OSX build process a bit and I've got now a 32/64bits VM working on OpenJDK 7 : java -d32 -version openjdk version "1.7.0-jdk7u4-b21" OpenJDK Runtime Environment (build 1.7.0-jdk7u4-b21-20120423) OpenJDK Server VM (build 23.0-b21, mixed mode) java -d64 -version openjdk version "1.7.0-jdk7u4-b21" OpenJDK Runtime Environment (build 1.7.0-jdk7u4-b21-20120423) OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode) It was mainly uncomments of features already included in OpenJDK 7 trunk. Patch available here : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch Thanks to review and apply if interested, openjdk-osx-build packages will use it. From scott.kovatch at oracle.com Mon Apr 23 09:54:14 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 23 Apr 2012 09:54:14 -0700 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: References: <4F952DD9.7010309@javaspecialists.eu> Message-ID: <0DB24238-2533-4283-B9F1-BD8E9015F669@oracle.com> On Apr 23, 2012, at 9:04 AM, Henri Gomez wrote: > 2012/4/23 Dr Heinz M. Kabutz : >> 32-bit support is very useful for research purposes - I would definitely >> welcome having it back. Otherwise it means having to also have Java 6 >> available, just for testing purposes. > > I patched OSX build process a bit and I've got now a 32/64bits VM > working on OpenJDK 7 : > > java -d32 -version > openjdk version "1.7.0-jdk7u4-b21" > OpenJDK Runtime Environment (build 1.7.0-jdk7u4-b21-20120423) > OpenJDK Server VM (build 23.0-b21, mixed mode) > > java -d64 -version > openjdk version "1.7.0-jdk7u4-b21" > OpenJDK Runtime Environment (build 1.7.0-jdk7u4-b21-20120423) > OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode) > > It was mainly uncomments of features already included in OpenJDK 7 trunk. > > Patch available here : > > http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch I haven't tried this, but I noticed in jdk/src/macosx/bin/universal/jvm.cfg you have -server KNOWN -client IGNORE Should that be '-client KNOWN' ? I thought the 32-bit JVM is a client-tuned hotspot. I could be wrong, based on the output of 'java -d32 version'. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From henri.gomez at gmail.com Mon Apr 23 10:13:00 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 19:13:00 +0200 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: <0DB24238-2533-4283-B9F1-BD8E9015F669@oracle.com> References: <4F952DD9.7010309@javaspecialists.eu> <0DB24238-2533-4283-B9F1-BD8E9015F669@oracle.com> Message-ID: > -server KNOWN > -client IGNORE > > Should that be '-client KNOWN' ? I thought the 32-bit JVM is a client-tuned hotspot. I could be wrong, based on the output of 'java -d32 version'. I just made a copy off x86-64 file into universal, so may be there is miss. I checked with Oracle Java 7 for OSX, same contents : # List of JVMs that can be used as an option to java, javac, etc. # Order is important -- first in this list is the default JVM. # NOTE that this both this file and its format are UNSUPPORTED and # WILL GO AWAY in a future release. # # You may also select a JVM in an arbitrary location with the # "-XXaltjvm=" option, but that too is unsupported # and may not be available in a future release. # -server KNOWN -client IGNORE -hotspot ERROR -classic WARN -native ERROR -green ERROR May be a mistake ? From scott.kovatch at oracle.com Mon Apr 23 10:15:19 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 23 Apr 2012 10:15:19 -0700 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: <4F95687A.3000709@oracle.com> References: <4F8EB5A1.6060104@oracle.com> <4F95687A.3000709@oracle.com> Message-ID: <586FC99C-0C39-49A6-916C-516C568FFB71@oracle.com> This looks fine to me. Only question is in CPlatformWindow: 313 if (Window.Type.UTILITY.equals(target.getType())) { 314 styleBits = SET(styleBits, UTILITY, true); 315 } Is this new? It looks needed but not necessarily part of this fix. It's unfortunate that you have to replicate code in AWTWindow_Normal and AWTWindow_Panel, but I don't see a better way to do it since you want to override methods. Would a category work here? There's not a lot of code here, but it may be harder to maintain over time. -- Scott On Apr 23, 2012, at 7:34 AM, Anthony Petrov wrote: > Mike et al., > > Could I get a review for this fix please? > > -- > best regards, > Anthony > > On 04/18/12 16:37, Anthony Petrov wrote: >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7149062 at: >> >> http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.0/ >> >> The AWTWindow class now inherits from NSObject and implements the >> NSWindowDelegate protocol. The real NSWindow object is held in the >> nsWindow property of the AWTWindow class, and is represented by either >> an AWTWindow_Normal or AWTWindow_Panel instance. These two classes >> inherit from NSWindow and NSPanel correspondingly. Note, however, that >> we still return a reference to the NSWindow/NSPanel instance to Java so >> that the pointer could be used with CWrapper methods directly. A >> reference to an associated AWTWindow instance is always available as >> (AWTWindow*)[nsWindow delegate]. >> >> All windows that inherit from NSWindow are added to the windows list in >> the dock icon menu by default. We use NSPanel-based windows for UTILITY, >> HUD, NONACTIVATING, and HIDES_ON_DEACTIVATE windows only, because these >> kinds of windows typically don't represent main application windows, and >> thus aren't expected to be added to the windows list. Besides, UTILITY >> (and HUD?) windows just have to be NSPanels. >> >> This fix is going to be back-ported to 7u6 later on. >> >> -- >> best regards, >> Anthony From tobi at ultramixer.com Mon Apr 23 11:05:16 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 23 Apr 2012 20:05:16 +0200 Subject: apple.awt.brushMetalLook support on OpenJDK7? - JNI solution? In-Reply-To: <16679ECE-D6EA-4601-B544-875CC183CD95@oracle.com> References: <86678C13-C887-417F-B15B-58DEC2225388@ultramixer.com> <6E5C72B4-E0E9-42C9-A496-1FAC705A3E14@ultramixer.com> <16679ECE-D6EA-4601-B544-875CC183CD95@oracle.com> Message-ID: Thanks Scott for that information. Maybe the CALayer implementation is the reason for the "bad redrawing behavior" when resizing the frame? Currently there is a very big quality gap between Apples AWT and the OpenJDK AWT implementation. flickering when resizing window, redrawing errors, bad perceived graphics performance... Are there any open todos concerning AWT / graphics pipeline? Currently it's not possible to use OpenJDK 7 on Mac for a real commercial java application :( Best regards, Tobi -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 23.04.2012 um 17:30 schrieb Scott Kovatch : > > On Apr 23, 2012, at 2:58 AM, Tobias Bley wrote: > >> Thanks Hendrik, I know the report, voted and commented it ;) >> >> But there is no acitvity since 5 month :( >> >> So I think about my own native solution in writing JNI code. My current problem is that with OpenJDK7 it's not possible to get the NSWindow from JavaWindow in Objective C code: The folling code only works on JDK6: > > This is correct. You can't assume that you are hosted in an NSWindow anymore. The AWT in JDK 7 does not support the NSView/CG drawing that JDK 6 used; everything is CALayer-based now. > > The platformInfo field is an NSObject that conforms to the JAWT_SurfaceLayers protocol: > > @protocol JAWT_SurfaceLayers > @property (readwrite, retain) CALayer *layer; > @property (readonly) CALayer *windowLayer; > @end > > It does look like we have some work left to do in the JAWT API, based on what I see in jdk/src/macosx/native/sun/awt/awt_DrawingSurface.m. > > I'm also not completely sure why we removed access to the NSWindow. CALayers or not, you probably are going to be hosted in an NSWindow. Your main applet panel is the only case where you won't be. > > Patches are always welcome. :-) > > -- Scott > From artem.ananiev at oracle.com Mon Apr 23 11:10:59 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Apr 2012 22:10:59 +0400 Subject: [8] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit In-Reply-To: <4F885E45.6020104@oracle.com> References: <4F885E45.6020104@oracle.com> Message-ID: <4F959B33.8000007@oracle.com> Looks fine. Thanks, Artem On 4/13/2012 9:11 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a port of 7155298 to macosx. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160623 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7160623/webrev.00 > > Discussion about xawt fix: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html > From artem.ananiev at oracle.com Mon Apr 23 11:15:38 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Apr 2012 22:15:38 +0400 Subject: [8] Request for review: 7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms. In-Reply-To: <4F8C31AA.5060900@oracle.com> References: <4F8C31AA.5060900@oracle.com> Message-ID: <4F959C4A.7070602@oracle.com> Hi, Sergey, I'm fine with the fix, just curious about "... should work in the same way as on other platforms". Both on Windows and X11 TextArea peer's minimum size is calculated as the size of TextArea that consists of 10 rows by 60 columns. What did you mean then? Thanks, Artem On 4/16/2012 6:50 PM, Sergey Bylokhov wrote: > Hi Everyone, > LWScrollPanePeer.getMinimumSize() on macosx should work in the same way, > as on other platforms. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124213/webrev.00/ > From Alexander.Potochkin at oracle.com Mon Apr 23 12:09:52 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 23 Apr 2012 23:09:52 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F95796B.9080204@oracle.com> References: <4F846D22.4030706@oracle.com> <4F95796B.9080204@oracle.com> Message-ID: <4F95A900.6050008@oracle.com> Hello Artem > Hi, Alex, > > the fix looks fine. Just a minor comment: > > I would use LinkedList instead of ArrayList as the type of "results" > as this collection is mostly used to add elements: this operation is > faster in linked lists than in array ones. The second version of the fix (approved by Anthony) also uses the list to remove the elements in one case so I guess it is fine to use ArrayList here Thanks alexp > > Thanks, > > Artem > > On 4/10/2012 9:25 PM, Alexander Potochkin wrote: >> Hello >> >> Please review the following fix: >> http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ >> >> for this bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 >> >> the spec for the method >> javax.swing.JDesktopPane.getAllFrames() >> >> says >> >> * Returns all JInternalFrames currently displayed in the >> * desktop. Returns iconified frames as well as expanded frames. >> >> but the AquaLookAndFeel on MacOS uses a special container for the >> minimized internal frames >> and that's why the current implementation doesn't see them >> >> the proposed fix recursively looks for the internal frames >> among the JDesktopPane's children >> >> the test can be found here: >> http://java.net/jira/browse/MACOSX_PORT-557 >> >> Thanks >> alexp From Alexander.Potochkin at oracle.com Mon Apr 23 12:28:32 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 23 Apr 2012 23:28:32 +0400 Subject: [8] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value Message-ID: <4F95AD60.8020600@oracle.com> Hello Please review the forward port to JDK 8 http://cr.openjdk.java.net/~alexp/7124328/webrev.01/ the patch is the same as previously approved for 7u6, I applied it to JDK8 and checked that it works as expected Thanks alexp From Alexander.Potochkin at oracle.com Mon Apr 23 12:34:47 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 23 Apr 2012 23:34:47 +0400 Subject: [8] request for review: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent Message-ID: <4F95AED7.8000902@oracle.com> Hello Please review the forward port to JDK 8 http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ the patch is the same as previously approved for 7u6, I applied it to JDK8 and checked that it works as expected Thanks alexp From mik3hall at gmail.com Mon Apr 23 14:04:04 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 16:04:04 -0500 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> Message-ID: On Apr 23, 2012, at 6:54 AM, Henri Gomez wrote: > 2012/4/23 Michael Hall : >> >> On Apr 23, 2012, at 5:08 AM, Henri Gomez wrote: >>>> >>> >>> -XX:+UseCompressedOop is activated by default on 23 and post release >> >> Right. >> So unless I could fallback to an earlier Apple release or you or someone somewhere else has a true universal 32/64 openjdk build still available there is no way to compare a running application for memory differences due to the presence or absence of the compressed option. > > I'm studing on bringing back 32/64 (universal) OpenJDK 7 fo If I'm understanding correctly this would mean by default compressed would be used for both and you should see more or less the same memory footprint. I'll check when a 32/64 bit openjdk jvm build is available that should match on this option. From henri.gomez at gmail.com Mon Apr 23 14:09:06 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 23:09:06 +0200 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> Message-ID: >> I'm studing on bringing back 32/64 (universal) OpenJDK 7 fo > If I'm understanding correctly this would mean by default compressed would be used for both and you should see more or less the same memory footprint. With Compressed Pointers a 64 bits JVM will consume less memory but it will still be higher than a 32 bits JVM for same usage. >I'll check when a 32/64 bit openjdk jvm build is available that should match on this option. I built a TestDrive OpenJDK 7 universal (32/64) : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-x64-u4-jdk-jdk7u4-b21-20120423.dmg Feedbacks welcomed From mik3hall at gmail.com Mon Apr 23 14:15:23 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 16:15:23 -0500 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> Message-ID: On Apr 23, 2012, at 5:38 AM, Kirk Pepperdine wrote: > CMS will leave floating garbage which will be picked up on the next collection. The parallel collectors will be exact and thus the working or live set size after GC will always be larger when using CMS. > There seemed to be more than a one collection difference between the numbers. Real mem per Activity Monitor was double. JConsole Comparison Used: 1.7 is 4.10 times greater than 1.6 Committed: 1.7 is 5.47 times greater than 1.6 Max: no significant difference GC time:* 1.7 is 2.14 times greater than 1.6 * For GC time I summed the two times for each and divided the 1.7 sum by the 1.6. For all the others I just divided the 1.7 value by the 1.6. I'm not real familiar with the functioning of gc but most of these differences didn't seem minor. I'll see if I can reproduce and get some JConsole screen shots. Very different. From henri.gomez at gmail.com Mon Apr 23 14:28:58 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Apr 2012 23:28:58 +0200 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: References: <4F952DD9.7010309@javaspecialists.eu> Message-ID: > I patched OSX build process a bit and I've got now a 32/64bits VM > working on OpenJDK 7 : > > java -d32 -version > openjdk version "1.7.0-jdk7u4-b21" > OpenJDK Runtime Environment (build 1.7.0-jdk7u4-b21-20120423) > OpenJDK Server VM (build 23.0-b21, mixed mode) > > java -d64 -version > openjdk version "1.7.0-jdk7u4-b21" > OpenJDK Runtime Environment (build 1.7.0-jdk7u4-b21-20120423) > OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode) > > It was mainly uncomments of features already included in OpenJDK 7 trunk. > > Patch available here : > > http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch > > Thanks to review and apply if interested, openjdk-osx-build packages > will use it. Forgot to mention Test Drive package location : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-x64-u4-jdk-jdk7u4-b21-20120423.dmg Feedbacks welcomed From scott.kovatch at oracle.com Mon Apr 23 14:50:38 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 23 Apr 2012 14:50:38 -0700 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: References: <4F952DD9.7010309@javaspecialists.eu> <0DB24238-2533-4283-B9F1-BD8E9015F669@oracle.com> Message-ID: On Apr 23, 2012, at 10:13 AM, Henri Gomez wrote: >> -server KNOWN >> -client IGNORE >> >> Should that be '-client KNOWN' ? I thought the 32-bit JVM is a client-tuned hotspot. I could be wrong, based on the output of 'java -d32 version'. > > I just made a copy off x86-64 file into universal, so may be there is miss. > > I checked with Oracle Java 7 for OSX, same contents I think you did the right thing with the name of the file and directory, but the content of jvm.cfg should be slightly different. For the Oracle Java 7 release this is correct because there's only a 64-bit JDK. For a universal JDK, I think -client and -server should both be valid choices. ============== # List of JVMs that can be used as an option to java, javac, etc. # Order is important -- first in this list is the default JVM. # NOTE that this both this file and its format are UNSUPPORTED and # WILL GO AWAY in a future release. -server KNOWN -client KNOWN -hotspot ERROR -classic WARN -native ERROR -green ERROR ============== I apologize for just making random suggestions, but I'm not in a position to test it out right now. -- Scott ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From henri.gomez at gmail.com Mon Apr 23 15:01:27 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 24 Apr 2012 00:01:27 +0200 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: References: <4F952DD9.7010309@javaspecialists.eu> <0DB24238-2533-4283-B9F1-BD8E9015F669@oracle.com> Message-ID: > I think you did the right thing with the name of the file and directory, but > the content of jvm.cfg should be slightly different. > > For the Oracle Java 7 release this is correct because there's only a 64-bit > JDK.?For a universal JDK, I think -client and -server should both be valid > choices. Oracle Java 7 release support both -d32 and -d64 in command line but still report a 64bits VM java -d32 -version java version "1.7.0_04-ea" Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b225) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b09, mixed mode) OpenJDK 7 64bits didn't support -d32 by default (ie: in non universal mode) > # List of JVMs that can be used as an option to java, javac, etc. > # Order is important -- first in this list is the default JVM. > # NOTE that this both this file and its format are UNSUPPORTED and > # WILL GO AWAY in a future release. > -server KNOWN > -client KNOWN > > -hotspot ERROR > -classic WARN > -native ERROR > -green ERROR > > I apologize for just making random suggestions, but I'm not in a position to > test it out right now. I updated jvm.cfg under jre/lib/jvm.cfg and switching from -client IGNORE to -client KNOWN but didn't see any changes From mik3hall at gmail.com Mon Apr 23 15:11:42 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 17:11:42 -0500 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> Message-ID: On Apr 23, 2012, at 4:09 PM, Henri Gomez wrote: >>> I'm studing on bringing back 32/64 (universal) OpenJDK 7 fo > >> If I'm understanding correctly this would mean by default compressed would be used for both and you should see more or less the same memory footprint. > > With Compressed Pointers a 64 bits JVM will consume less memory but it > will still be higher than a 32 bits JVM for same usage. > >> I'll check when a 32/64 bit openjdk jvm build is available that should match on this option. > > I built a TestDrive OpenJDK 7 universal (32/64) : > > http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-x64-u4-jdk-jdk7u4-b21-20120423.dmg > > Feedbacks welcomed I'll try it out. I sort of reproduced what I was seeing earlier in JConsole http://www195.pair.com/mik3hall/java16.tiff is the java 1.6 run of my app. I hit it with some activity and it goes into the sawtooth pattern I mentioned. http://www195.pair.com/mik3hall/java17.tiff is the java 1.7 run of the app. After the activity hit memory takes off and climbs 50MB before the next drop. Who knows might be a problem with something leaking in my app that 1.6 controls better. But 1.7 definitely seems to involve a lot more memory sloshing around. From mik3hall at gmail.com Mon Apr 23 18:42:57 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 23 Apr 2012 20:42:57 -0500 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> Message-ID: On Apr 23, 2012, at 4:09 PM, Henri Gomez wrote: >>> I'm studing on bringing back 32/64 (universal) OpenJDK 7 fo > >> If I'm understanding correctly this would mean by default compressed would be used for both and you should see more or less the same memory footprint. > > With Compressed Pointers a 64 bits JVM will consume less memory but it > will still be higher than a 32 bits JVM for same usage. > >> I'll check when a 32/64 bit openjdk jvm build is available that should match on this option. > > I built a TestDrive OpenJDK 7 universal (32/64) : > > http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-x64-u4-jdk-jdk7u4-b21-20120423.dmg > > Feedbacks welcomed OK, using Henri's with -server and Java 7 shows using only slightly more real memory in Activity Monitor than Java 6. Currently 118.2 mb to 102.1mb. Changing gc collectors got more matching jconsole graphs. Using Henri's even got me a full duke jconsole connection internal frame image. From henri.gomez at gmail.com Mon Apr 23 21:49:46 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 24 Apr 2012 06:49:46 +0200 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: <4F95D446.5000504@javaspecialists.eu> References: <4F952DD9.7010309@javaspecialists.eu> <0DB24238-2533-4283-B9F1-BD8E9015F669@oracle.com> <4F95D446.5000504@javaspecialists.eu> Message-ID: easy to fix : change in jre/lib/jvm.cfg -client IGNORE -> -client KNOWN 2012/4/24 Dr Heinz M. Kabutz : > Thanks Henri. > > In OpenJDK 7 for OSX, java -d32 -client now runs in 32-bit mode, but with > the -server JVM. > > Is it possible to also enable the option to select the client JVM in 32-bit > mode, same as we have with 1.6.0 at the moment? > > And would it be possible to do this for OpenJDK 8 also? > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun Java Champion > IEEE Certified Software Development Professional > http://www.javaspecialists.eu > Tel: +30 69 75 595 262 > Skype: kabutz > > > > On 4/24/12 1:01 AM, Henri Gomez wrote: > > I think you did the right thing with the name of the file and directory, but > the content of jvm.cfg should be slightly different. > > For the Oracle Java 7 release this is correct because there's only a 64-bit > JDK.?For a universal JDK, I think -client and -server should both be valid > choices. > > > Oracle Java 7 release support both -d32 and -d64 in command line but > still report a 64bits VM > > java -d32 -version > java version "1.7.0_04-ea" > Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b225) > Java HotSpot(TM) 64-Bit Server VM (build 23.0-b09, mixed mode) > > OpenJDK 7 64bits didn't support -d32 by default (ie: in non universal mode) > > > > # List of JVMs that can be used as an option to java, javac, etc. > # Order is important -- first in this list is the default JVM. > # NOTE that this both this file and its format are UNSUPPORTED and > # WILL GO AWAY in a future release. > -server KNOWN > -client KNOWN > > -hotspot ERROR > -classic WARN > -native ERROR > -green ERROR > > > > > > I apologize for just making random suggestions, but I'm not in a position to > test it out right now. > > > I updated jvm.cfg under jre/lib/jvm.cfg and switching from -client > IGNORE to -client KNOWN but didn't see any changes > > From henri.gomez at gmail.com Mon Apr 23 21:52:25 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 24 Apr 2012 06:52:25 +0200 Subject: Application memory use In-Reply-To: References: <538549CC-ABA6-4229-A77B-53F0DAC5AF79@gmail.com> <2EBF017F-B7EA-4648-B56F-05E915408E73@gmail.com> Message-ID: >> Feedbacks welcomed > > OK, using Henri's with -server and Java 7 shows using only slightly more real memory in Activity Monitor than Java 6. > Currently 118.2 mb to 102.1mb. > Changing gc collectors got more matching jconsole graphs. > Using Henri's even got me a full duke jconsole connection internal frame image. What do you means by full duke jconsole connection internal frame image ? From henri.gomez at gmail.com Mon Apr 23 22:56:02 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 24 Apr 2012 07:56:02 +0200 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: <4F95D446.5000504@javaspecialists.eu> References: <4F952DD9.7010309@javaspecialists.eu> <0DB24238-2533-4283-B9F1-BD8E9015F669@oracle.com> <4F95D446.5000504@javaspecialists.eu> Message-ID: > Is it possible to also enable the option to select the client JVM in 32-bit > mode, same as we have with 1.6.0 at the moment? I should check, for now -client select a client VM and -d32 -client select a 32 bits VM client VM > And would it be possible to do this for OpenJDK 8 also? It could be back ported I guess, but we'll be more comfortable if provided patch was reviewed and applied to OpenJDK 7 first. From henri.gomez at gmail.com Tue Apr 24 00:49:40 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 24 Apr 2012 09:49:40 +0200 Subject: Oracle Java 7 Developper Preview for OSX vs OpenJDK 7 In-Reply-To: <4F964660.6090206@javaspecialists.eu> References: <4F952DD9.7010309@javaspecialists.eu> <0DB24238-2533-4283-B9F1-BD8E9015F669@oracle.com> <4F95D446.5000504@javaspecialists.eu> <4F964660.6090206@javaspecialists.eu> Message-ID: > Thanks Henri, now it works. > > BTW, there was a snafu in that jvm.cfg file in the latest bundle - the > entire file contents were duplicated. I'll fix it :) From anthony.petrov at oracle.com Tue Apr 24 03:52:39 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 24 Apr 2012 14:52:39 +0400 Subject: [8] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F95AD60.8020600@oracle.com> References: <4F95AD60.8020600@oracle.com> Message-ID: <4F9685F7.9080806@oracle.com> Looks fine. -- best regards, Anthony On 4/23/2012 11:28 PM, Alexander Potochkin wrote: > Hello > > Please review the forward port to JDK 8 > http://cr.openjdk.java.net/~alexp/7124328/webrev.01/ > > the patch is the same as previously approved for 7u6, > I applied it to JDK8 and checked that it works as expected > > Thanks > alexp From alexandr.scherbatiy at oracle.com Tue Apr 24 04:18:02 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 24 Apr 2012 15:18:02 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F9567DA.3010306@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> <4F953825.20508@oracle.com> <4F9567DA.3010306@oracle.com> Message-ID: <4F968BEA.8040801@oracle.com> On 4/23/2012 6:31 PM, Anthony Petrov wrote: > Hi Alexander, > > Thanks! The fix looks fine to me. > > I appreciate the newly added tests, however, I haven't reviewed them > thoroughly. One question though, do the tests pass on other platforms > (Win & X11) as well? Yes. The tests pass on the Mac OS X, Windows 7 and Linux Ubuntu. Thanks, Alexandr. > > -- > best regards, > Anthony > > On 04/23/12 15:08, Alexander Scherbatiy wrote: >> >> Thank you for the review. >> >> Here is the new version: >> http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ >> >> 1. The synthesizeMouseEnteredExitedEvents method is added as a native >> method to the CPlatformWindow class. >> Now it is invoked only in places that programmatically change a window >> size: >> - nativeSetNSWindowBounds method from the AWTWindow >> - setVisible and setWindowState methods from the CPlatformWindow >> >> 2. The objective-c code is formatted. >> >> 3. I do not think that setting the lastMouseEventPeer after sending the >> MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in >> the peer. >> The postEvent method just post the MOUSE_ENTERED events to the queue. It >> does not use the lastMouseEventPeer variable and there is no a recursion >> that invokes the dispatchMouseEvent method again. >> >> 4. Dragging a window under a panel should not generate mouse >> entered/exited events for components. However the events should be >> generated if the window is moved out of the frame or moved in to the >> frame. So one more condition that checks is the mouse crosess the frame >> borders are added to the dispatchMouseEvent method from the LWWindowPeer >> class. >> The DragWindowOutOfFrameTest test is added that these events are >> properly generated. >> >> Thanks, >> Alexandr. >> >> On 4/19/2012 5:14 PM, Anthony Petrov wrote: >>> Hi Alexander, >>> >>> 1. I don't think that it's a good idea to add >>> synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These >>> methods are supposed to perform direct calls to Cocoa API w/o any >>> side-effects. They may be used for windows that even aren't AWT >>> windows, and as such sending them the >>> synthesizeMouseEnteredExitedEvents message is useless, and just >>> doesn't seem right from CWrapper's purpose perspective. You may want >>> to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() >>> native method that would call this native method, and then add a call >>> to it where needed in Java code. >>> >>> 2. Please follow formatting guidelines and reformat lines like this: >>> >>>> if(id != MouseEvent.MOUSE_DRAGGED){ >>> >>> to read as >>> >>> if (id != MouseEvent.MOUSE_DRAGGED) { >>> >>> instead. I see lots of such mis-formatted if() statements all over >>> your code. >>> >>> 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer >>> after sending the MOUSE_ENTERED event. Before your fix it's been set >>> earlier. Can this change affect some logic in the peer code while >>> processing ENTERED events at a user event handler? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 04/18/12 19:40, Alexander Scherbatiy wrote: >>>> >>>> Please review a fix for CR 7154048. >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >>>> >>>> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >>>> >>>> Let's see the following test case: >>>> - Frame contains two components JLabel and JButton >>>> - The JLabel component has a mouse listener >>>> mousePressed: create a Window under the mouse click >>>> mouseDragged: drag the created window >>>> mouseReleased: close the Window >>>> - A user clicks on the JLabel component, drags the mouse to the >>>> JButton >>>> component and releases the mouse button >>>> >>>> The current JDK 8 implementation shows the following events on Mac >>>> OS X: >>>> -------------------------------------------------------- >>>> mouse pressed: javax.swing.JLabel >>>> mouse exited: javax.swing.JLabel >>>> mouse entered: javax.swing.JLabel >>>> mouse dragged: javax.swing.JLabel >>>> mouse exited: javax.swing.JLabel >>>> mouse entered: javax.swing.JButton >>>> mouse dragged: javax.swing.JLabel >>>> mouse exited: javax.swing.JButton >>>> mouse entered: Drag Window >>>> mouse exited: Drag Window >>>> mouse entered: javax.swing.JButton >>>> mouse released: javax.swing.JButton >>>> -------------------------------------------------------- >>>> >>>> There are several issues: >>>> 1) The window does not receive the mouse entered event when it is >>>> created under the mouse >>>> 2) There are JLabel exited/JButton entered events during the window >>>> dragging >>>> 3) JLabel does not receive the mouse released event >>>> >>>> The fix synthesizes the mouse entered/exited events manually if >>>> they are >>>> not received. >>>> >>>> The entered/exited events synthesizing is added to setFrame, toFront, >>>> toBack, and zoom methods of the AWTWindow and CWrapper classes. >>>> >>>> There is an option to add the events synthesizing to the >>>> windowDidResize >>>> notification. However this notification is sent when a window size is >>>> changed in both cases, programmatically and when user is resized the >>>> window. So in a lot of case there is no need for the our use case >>>> events >>>> generation. >>>> >>>> The LWWindowPeer class is updated to not generate extra mouse >>>> enter/exit >>>> events during the mouse dragging. >>>> >>>> Tho automated tests are added. >>>> >>>> Thanks, >>>> Alexandr. >> From alexandr.scherbatiy at oracle.com Tue Apr 24 04:22:29 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 24 Apr 2012 15:22:29 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <8600BFDB-9091-4F9C-93A9-7F29B42CC5AD@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> <4F953825.20508@oracle.com> <8600BFDB-9091-4F9C-93A9-7F29B42CC5AD@oracle.com> Message-ID: <4F968CF5.4050500@oracle.com> On 4/23/2012 7:39 PM, Leonid Romanov wrote: > Hi, > I can't find where you set initial value of mouseIsOver variable. Does Objective-C guarantee that it gets some defined default value? I really missed this part. Please review the new version: http://cr.openjdk.java.net/~alexsch/7154048/webrev.02/ The only thing that is changed is the initialization of the mouseIsOver variable to false in the -initWithRect: method of the AWTView class. Thanks, Alexandr. > On 23.04.2012, at 15:08, Alexander Scherbatiy wrote: > >> Thank you for the review. >> >> Here is the new version: >> http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ >> >> 1. The synthesizeMouseEnteredExitedEvents method is added as a native method to the CPlatformWindow class. >> Now it is invoked only in places that programmatically change a window size: >> - nativeSetNSWindowBounds method from the AWTWindow >> - setVisible and setWindowState methods from the CPlatformWindow >> >> 2. The objective-c code is formatted. >> >> 3. I do not think that setting the lastMouseEventPeer after sending the MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in the peer. >> The postEvent method just post the MOUSE_ENTERED events to the queue. It does not use the lastMouseEventPeer variable and there is no a recursion that invokes the dispatchMouseEvent method again. >> >> 4. Dragging a window under a panel should not generate mouse entered/exited events for components. However the events should be generated if the window is moved out of the frame or moved in to the frame. So one more condition that checks is the mouse crosess the frame borders are added to the dispatchMouseEvent method from the LWWindowPeer class. >> The DragWindowOutOfFrameTest test is added that these events are properly generated. >> >> Thanks, >> Alexandr. >> >> On 4/19/2012 5:14 PM, Anthony Petrov wrote: >>> Hi Alexander, >>> >>> 1. I don't think that it's a good idea to add synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These methods are supposed to perform direct calls to Cocoa API w/o any side-effects. They may be used for windows that even aren't AWT windows, and as such sending them the synthesizeMouseEnteredExitedEvents message is useless, and just doesn't seem right from CWrapper's purpose perspective. You may want to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() native method that would call this native method, and then add a call to it where needed in Java code. >>> >>> 2. Please follow formatting guidelines and reformat lines like this: >>> >>>> if(id != MouseEvent.MOUSE_DRAGGED){ >>> to read as >>> >>> if (id != MouseEvent.MOUSE_DRAGGED) { >>> >>> instead. I see lots of such mis-formatted if() statements all over your code. >>> >>> 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer after sending the MOUSE_ENTERED event. Before your fix it's been set earlier. Can this change affect some logic in the peer code while processing ENTERED events at a user event handler? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 04/18/12 19:40, Alexander Scherbatiy wrote: >>>> Please review a fix for CR 7154048. >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >>>> >>>> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >>>> >>>> Let's see the following test case: >>>> - Frame contains two components JLabel and JButton >>>> - The JLabel component has a mouse listener >>>> mousePressed: create a Window under the mouse click >>>> mouseDragged: drag the created window >>>> mouseReleased: close the Window >>>> - A user clicks on the JLabel component, drags the mouse to the JButton >>>> component and releases the mouse button >>>> >>>> The current JDK 8 implementation shows the following events on Mac OS X: >>>> -------------------------------------------------------- >>>> mouse pressed: javax.swing.JLabel >>>> mouse exited: javax.swing.JLabel >>>> mouse entered: javax.swing.JLabel >>>> mouse dragged: javax.swing.JLabel >>>> mouse exited: javax.swing.JLabel >>>> mouse entered: javax.swing.JButton >>>> mouse dragged: javax.swing.JLabel >>>> mouse exited: javax.swing.JButton >>>> mouse entered: Drag Window >>>> mouse exited: Drag Window >>>> mouse entered: javax.swing.JButton >>>> mouse released: javax.swing.JButton >>>> -------------------------------------------------------- >>>> >>>> There are several issues: >>>> 1) The window does not receive the mouse entered event when it is >>>> created under the mouse >>>> 2) There are JLabel exited/JButton entered events during the window >>>> dragging >>>> 3) JLabel does not receive the mouse released event >>>> >>>> The fix synthesizes the mouse entered/exited events manually if they are >>>> not received. >>>> >>>> The entered/exited events synthesizing is added to setFrame, toFront, >>>> toBack, and zoom methods of the AWTWindow and CWrapper classes. >>>> >>>> There is an option to add the events synthesizing to the windowDidResize >>>> notification. However this notification is sent when a window size is >>>> changed in both cases, programmatically and when user is resized the >>>> window. So in a lot of case there is no need for the our use case events >>>> generation. >>>> >>>> The LWWindowPeer class is updated to not generate extra mouse enter/exit >>>> events during the mouse dragging. >>>> >>>> Tho automated tests are added. >>>> >>>> Thanks, >>>> Alexandr. From anthony.petrov at oracle.com Tue Apr 24 04:31:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 24 Apr 2012 15:31:01 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F968BEA.8040801@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> <4F953825.20508@oracle.com> <4F9567DA.3010306@oracle.com> <4F968BEA.8040801@oracle.com> Message-ID: <4F968EF5.7040103@oracle.com> On 4/24/2012 3:18 PM, Alexander Scherbatiy wrote: > On 4/23/2012 6:31 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> Thanks! The fix looks fine to me. >> >> I appreciate the newly added tests, however, I haven't reviewed them >> thoroughly. One question though, do the tests pass on other platforms >> (Win & X11) as well? > > Yes. The tests pass on the Mac OS X, Windows 7 and Linux Ubuntu. Thanks for verifying that! I'm fine with the fix (incl. the latest version with the mouseIsOver flag initialized.) -- best regards, Anthony > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 04/23/12 15:08, Alexander Scherbatiy wrote: >>> >>> Thank you for the review. >>> >>> Here is the new version: >>> http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ >>> >>> 1. The synthesizeMouseEnteredExitedEvents method is added as a native >>> method to the CPlatformWindow class. >>> Now it is invoked only in places that programmatically change a window >>> size: >>> - nativeSetNSWindowBounds method from the AWTWindow >>> - setVisible and setWindowState methods from the CPlatformWindow >>> >>> 2. The objective-c code is formatted. >>> >>> 3. I do not think that setting the lastMouseEventPeer after sending the >>> MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in >>> the peer. >>> The postEvent method just post the MOUSE_ENTERED events to the queue. It >>> does not use the lastMouseEventPeer variable and there is no a recursion >>> that invokes the dispatchMouseEvent method again. >>> >>> 4. Dragging a window under a panel should not generate mouse >>> entered/exited events for components. However the events should be >>> generated if the window is moved out of the frame or moved in to the >>> frame. So one more condition that checks is the mouse crosess the frame >>> borders are added to the dispatchMouseEvent method from the LWWindowPeer >>> class. >>> The DragWindowOutOfFrameTest test is added that these events are >>> properly generated. >>> >>> Thanks, >>> Alexandr. >>> >>> On 4/19/2012 5:14 PM, Anthony Petrov wrote: >>>> Hi Alexander, >>>> >>>> 1. I don't think that it's a good idea to add >>>> synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These >>>> methods are supposed to perform direct calls to Cocoa API w/o any >>>> side-effects. They may be used for windows that even aren't AWT >>>> windows, and as such sending them the >>>> synthesizeMouseEnteredExitedEvents message is useless, and just >>>> doesn't seem right from CWrapper's purpose perspective. You may want >>>> to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() >>>> native method that would call this native method, and then add a call >>>> to it where needed in Java code. >>>> >>>> 2. Please follow formatting guidelines and reformat lines like this: >>>> >>>>> if(id != MouseEvent.MOUSE_DRAGGED){ >>>> >>>> to read as >>>> >>>> if (id != MouseEvent.MOUSE_DRAGGED) { >>>> >>>> instead. I see lots of such mis-formatted if() statements all over >>>> your code. >>>> >>>> 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer >>>> after sending the MOUSE_ENTERED event. Before your fix it's been set >>>> earlier. Can this change affect some logic in the peer code while >>>> processing ENTERED events at a user event handler? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 04/18/12 19:40, Alexander Scherbatiy wrote: >>>>> >>>>> Please review a fix for CR 7154048. >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >>>>> >>>>> Let's see the following test case: >>>>> - Frame contains two components JLabel and JButton >>>>> - The JLabel component has a mouse listener >>>>> mousePressed: create a Window under the mouse click >>>>> mouseDragged: drag the created window >>>>> mouseReleased: close the Window >>>>> - A user clicks on the JLabel component, drags the mouse to the >>>>> JButton >>>>> component and releases the mouse button >>>>> >>>>> The current JDK 8 implementation shows the following events on Mac >>>>> OS X: >>>>> -------------------------------------------------------- >>>>> mouse pressed: javax.swing.JLabel >>>>> mouse exited: javax.swing.JLabel >>>>> mouse entered: javax.swing.JLabel >>>>> mouse dragged: javax.swing.JLabel >>>>> mouse exited: javax.swing.JLabel >>>>> mouse entered: javax.swing.JButton >>>>> mouse dragged: javax.swing.JLabel >>>>> mouse exited: javax.swing.JButton >>>>> mouse entered: Drag Window >>>>> mouse exited: Drag Window >>>>> mouse entered: javax.swing.JButton >>>>> mouse released: javax.swing.JButton >>>>> -------------------------------------------------------- >>>>> >>>>> There are several issues: >>>>> 1) The window does not receive the mouse entered event when it is >>>>> created under the mouse >>>>> 2) There are JLabel exited/JButton entered events during the window >>>>> dragging >>>>> 3) JLabel does not receive the mouse released event >>>>> >>>>> The fix synthesizes the mouse entered/exited events manually if >>>>> they are >>>>> not received. >>>>> >>>>> The entered/exited events synthesizing is added to setFrame, toFront, >>>>> toBack, and zoom methods of the AWTWindow and CWrapper classes. >>>>> >>>>> There is an option to add the events synthesizing to the >>>>> windowDidResize >>>>> notification. However this notification is sent when a window size is >>>>> changed in both cases, programmatically and when user is resized the >>>>> window. So in a lot of case there is no need for the our use case >>>>> events >>>>> generation. >>>>> >>>>> The LWWindowPeer class is updated to not generate extra mouse >>>>> enter/exit >>>>> events during the mouse dragging. >>>>> >>>>> Tho automated tests are added. >>>>> >>>>> Thanks, >>>>> Alexandr. >>> > From artem.ananiev at oracle.com Tue Apr 24 05:38:33 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 24 Apr 2012 16:38:33 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F95A900.6050008@oracle.com> References: <4F846D22.4030706@oracle.com> <4F95796B.9080204@oracle.com> <4F95A900.6050008@oracle.com> Message-ID: <4F969EC9.1000001@oracle.com> On 4/23/2012 11:09 PM, Alexander Potochkin wrote: > Hello Artem >> Hi, Alex, >> >> the fix looks fine. Just a minor comment: >> >> I would use LinkedList instead of ArrayList as the type of "results" >> as this collection is mostly used to add elements: this operation is >> faster in linked lists than in array ones. > > The second version of the fix (approved by Anthony) > also uses the list to remove the elements in one case add/remove are of the same kind :) Anyway, I'm leaving it up to you. The fix looks fine. Thanks, Artem > so I guess it is fine to use ArrayList here > > Thanks > alexp > >> >> Thanks, >> >> Artem >> >> On 4/10/2012 9:25 PM, Alexander Potochkin wrote: >>> Hello >>> >>> Please review the following fix: >>> http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ >>> >>> for this bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 >>> >>> the spec for the method >>> javax.swing.JDesktopPane.getAllFrames() >>> >>> says >>> >>> * Returns all JInternalFrames currently displayed in the >>> * desktop. Returns iconified frames as well as expanded frames. >>> >>> but the AquaLookAndFeel on MacOS uses a special container for the >>> minimized internal frames >>> and that's why the current implementation doesn't see them >>> >>> the proposed fix recursively looks for the internal frames >>> among the JDesktopPane's children >>> >>> the test can be found here: >>> http://java.net/jira/browse/MACOSX_PORT-557 >>> >>> Thanks >>> alexp > From Alexander.Potochkin at oracle.com Tue Apr 24 07:40:23 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 24 Apr 2012 18:40:23 +0400 Subject: [7u6] request for review: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F969EC9.1000001@oracle.com> References: <4F846D22.4030706@oracle.com> <4F95796B.9080204@oracle.com> <4F95A900.6050008@oracle.com> <4F969EC9.1000001@oracle.com> Message-ID: <4F96BB57.4070302@oracle.com> Hello Artem > > add/remove are of the same kind :) Anyway, I'm leaving it up to you. > The fix looks fine. Thanks! alexp > > Thanks, > > Artem > >> so I guess it is fine to use ArrayList here >> >> Thanks >> alexp >> >>> >>> Thanks, >>> >>> Artem >>> >>> On 4/10/2012 9:25 PM, Alexander Potochkin wrote: >>>> Hello >>>> >>>> Please review the following fix: >>>> http://cr.openjdk.java.net/~alexp/7124328/webrev.00/ >>>> >>>> for this bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 >>>> >>>> the spec for the method >>>> javax.swing.JDesktopPane.getAllFrames() >>>> >>>> says >>>> >>>> * Returns all JInternalFrames currently displayed in the >>>> * desktop. Returns iconified frames as well as expanded frames. >>>> >>>> but the AquaLookAndFeel on MacOS uses a special container for the >>>> minimized internal frames >>>> and that's why the current implementation doesn't see them >>>> >>>> the proposed fix recursively looks for the internal frames >>>> among the JDesktopPane's children >>>> >>>> the test can be found here: >>>> http://java.net/jira/browse/MACOSX_PORT-557 >>>> >>>> Thanks >>>> alexp >> From Sergey.Bylokhov at oracle.com Tue Apr 24 11:09:51 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Apr 2012 22:09:51 +0400 Subject: [8] request for review: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent In-Reply-To: <4F95AED7.8000902@oracle.com> References: <4F95AED7.8000902@oracle.com> Message-ID: <4F96EC6F.4080306@oracle.com> Hi, Alexander. Fix looks good 23.04.2012 23:34, Alexander Potochkin wrote: > Hello > > Please review the forward port to JDK 8 > http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ > > the patch is the same as previously approved for 7u6, > I applied it to JDK8 and checked that it works as expected > > Thanks > alexp From henri.gomez at gmail.com Wed Apr 25 00:21:41 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 25 Apr 2012 09:21:41 +0200 Subject: OSX 32/64 bits support for JDK7 patch for review Message-ID: Hi to all, I worked on bringing back universal (32/64 bits) JVM support for JDK7 under OSX, feature who disappears when we switch from macosx-port to jdk7u. Please find attached a patch against jdk7/jdk7u4. Could someone review it ? OSX need an universal VM, there is so many case where a 32bits VM is enough and even on 64bits, CompressedPointers are not available with current base code. Cheers From leonid.romanov at oracle.com Wed Apr 25 03:46:33 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 25 Apr 2012 14:46:33 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F968CF5.4050500@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> <4F953825.20508@oracle.com> <8600BFDB-9091-4F9C-93A9-7F29B42CC5AD@oracle.com> <4F968CF5.4050500@oracle.com> Message-ID: <3836447A-4013-4135-9F80-B80155D86A8B@oracle.com> it is not obvious what isTopmostWindowUnderMouse is supposed to check without reading its source code. It would be great if you could add a brief comment describing method's purpose. Otherwise, the fix looks good. On 24.04.2012, at 15:22, Alexander Scherbatiy wrote: > On 4/23/2012 7:39 PM, Leonid Romanov wrote: >> Hi, >> I can't find where you set initial value of mouseIsOver variable. Does Objective-C guarantee that it gets some defined default value? > I really missed this part. > > Please review the new version: > http://cr.openjdk.java.net/~alexsch/7154048/webrev.02/ > > The only thing that is changed is the initialization of the mouseIsOver variable to false in the -initWithRect: method of the AWTView class. > > Thanks, > Alexandr. > >> On 23.04.2012, at 15:08, Alexander Scherbatiy wrote: >> >>> Thank you for the review. >>> >>> Here is the new version: >>> http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ >>> >>> 1. The synthesizeMouseEnteredExitedEvents method is added as a native method to the CPlatformWindow class. >>> Now it is invoked only in places that programmatically change a window size: >>> - nativeSetNSWindowBounds method from the AWTWindow >>> - setVisible and setWindowState methods from the CPlatformWindow >>> >>> 2. The objective-c code is formatted. >>> >>> 3. I do not think that setting the lastMouseEventPeer after sending the MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in the peer. >>> The postEvent method just post the MOUSE_ENTERED events to the queue. It does not use the lastMouseEventPeer variable and there is no a recursion that invokes the dispatchMouseEvent method again. >>> >>> 4. Dragging a window under a panel should not generate mouse entered/exited events for components. However the events should be generated if the window is moved out of the frame or moved in to the frame. So one more condition that checks is the mouse crosess the frame borders are added to the dispatchMouseEvent method from the LWWindowPeer class. >>> The DragWindowOutOfFrameTest test is added that these events are properly generated. >>> >>> Thanks, >>> Alexandr. >>> >>> On 4/19/2012 5:14 PM, Anthony Petrov wrote: >>>> Hi Alexander, >>>> >>>> 1. I don't think that it's a good idea to add synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These methods are supposed to perform direct calls to Cocoa API w/o any side-effects. They may be used for windows that even aren't AWT windows, and as such sending them the synthesizeMouseEnteredExitedEvents message is useless, and just doesn't seem right from CWrapper's purpose perspective. You may want to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() native method that would call this native method, and then add a call to it where needed in Java code. >>>> >>>> 2. Please follow formatting guidelines and reformat lines like this: >>>> >>>>> if(id != MouseEvent.MOUSE_DRAGGED){ >>>> to read as >>>> >>>> if (id != MouseEvent.MOUSE_DRAGGED) { >>>> >>>> instead. I see lots of such mis-formatted if() statements all over your code. >>>> >>>> 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer after sending the MOUSE_ENTERED event. Before your fix it's been set earlier. Can this change affect some logic in the peer code while processing ENTERED events at a user event handler? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 04/18/12 19:40, Alexander Scherbatiy wrote: >>>>> Please review a fix for CR 7154048. >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >>>>> >>>>> Let's see the following test case: >>>>> - Frame contains two components JLabel and JButton >>>>> - The JLabel component has a mouse listener >>>>> mousePressed: create a Window under the mouse click >>>>> mouseDragged: drag the created window >>>>> mouseReleased: close the Window >>>>> - A user clicks on the JLabel component, drags the mouse to the JButton >>>>> component and releases the mouse button >>>>> >>>>> The current JDK 8 implementation shows the following events on Mac OS X: >>>>> -------------------------------------------------------- >>>>> mouse pressed: javax.swing.JLabel >>>>> mouse exited: javax.swing.JLabel >>>>> mouse entered: javax.swing.JLabel >>>>> mouse dragged: javax.swing.JLabel >>>>> mouse exited: javax.swing.JLabel >>>>> mouse entered: javax.swing.JButton >>>>> mouse dragged: javax.swing.JLabel >>>>> mouse exited: javax.swing.JButton >>>>> mouse entered: Drag Window >>>>> mouse exited: Drag Window >>>>> mouse entered: javax.swing.JButton >>>>> mouse released: javax.swing.JButton >>>>> -------------------------------------------------------- >>>>> >>>>> There are several issues: >>>>> 1) The window does not receive the mouse entered event when it is >>>>> created under the mouse >>>>> 2) There are JLabel exited/JButton entered events during the window >>>>> dragging >>>>> 3) JLabel does not receive the mouse released event >>>>> >>>>> The fix synthesizes the mouse entered/exited events manually if they are >>>>> not received. >>>>> >>>>> The entered/exited events synthesizing is added to setFrame, toFront, >>>>> toBack, and zoom methods of the AWTWindow and CWrapper classes. >>>>> >>>>> There is an option to add the events synthesizing to the windowDidResize >>>>> notification. However this notification is sent when a window size is >>>>> changed in both cases, programmatically and when user is resized the >>>>> window. So in a lot of case there is no need for the our use case events >>>>> generation. >>>>> >>>>> The LWWindowPeer class is updated to not generate extra mouse enter/exit >>>>> events during the mouse dragging. >>>>> >>>>> Tho automated tests are added. >>>>> >>>>> Thanks, >>>>> Alexandr. > From edvard.wendelin at oracle.com Wed Apr 25 06:02:04 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 25 Apr 2012 15:02:04 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html Message-ID: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> Hi, I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". You can find the webrev here: http://cr.openjdk.java.net/~ewendeli/7154130/webrev.00/ CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154130 Thanks, Edvard [1] http://hg.openjdk.java.net/jdk8/build/raw-file/e01201e727da/README-builds.html [2] http://openjdk.java.net/projects/macosx-port/ [3] https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Prerequisites [4] http://www.apple.com/macosx/ From daniel.daugherty at oracle.com Wed Apr 25 06:48:17 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Apr 2012 07:48:17 -0600 Subject: OSX 32/64 bits support for JDK7 patch for review In-Reply-To: References: Message-ID: <4F9800A1.8000301@oracle.com> Henri, Your patch is not attached. I suspect that the OpenJDK mailer strips attachments... Dan On 4/25/12 1:21 AM, Henri Gomez wrote: > Hi to all, > > I worked on bringing back universal (32/64 bits) JVM support for JDK7 > under OSX, feature who disappears when we switch from macosx-port to > jdk7u. > > Please find attached a patch against jdk7/jdk7u4. > > Could someone review it ? > > OSX need an universal VM, there is so many case where a 32bits VM is > enough and even on 64bits, CompressedPointers are not available with > current base code. > > Cheers From henri.gomez at gmail.com Wed Apr 25 07:26:04 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 25 Apr 2012 16:26:04 +0200 Subject: OSX 32/64 bits support for JDK7 patch for review In-Reply-To: <4F9800A1.8000301@oracle.com> References: <4F9800A1.8000301@oracle.com> Message-ID: > Henri, > > Your patch is not attached. I suspect that the OpenJDK mailer strips > attachments... > > Dan Hopefully, you could find it on openjdk-osx-build : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch Cheers and thanks for your interest From scott.kovatch at oracle.com Wed Apr 25 08:10:00 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 25 Apr 2012 08:10:00 -0700 Subject: OSX 32/64 bits support for JDK7 patch for review In-Reply-To: References: Message-ID: <3209547B-AE76-4906-B642-F31CD5ADD495@oracle.com> On Apr 25, 2012, at 12:21 AM, Henri Gomez wrote: > I worked on bringing back universal (32/64 bits) JVM support for JDK7 > under OSX, feature who disappears when we switch from macosx-port to > jdk7u. > > Please find attached a patch against jdk7/jdk7u4. > > Could someone review it ? First, let me say this is greatly appreciated. I would also say 'it looks good, go for it' but we are going to need to coordinate this with our release engineering team. This change turns on the universal build by default. Does it still allow the ability to compile 64-bit only, with either a -D flag or other external switch? -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From henri.gomez at gmail.com Wed Apr 25 08:24:33 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 25 Apr 2012 17:24:33 +0200 Subject: OSX 32/64 bits support for JDK7 patch for review In-Reply-To: <3209547B-AE76-4906-B642-F31CD5ADD495@oracle.com> References: <3209547B-AE76-4906-B642-F31CD5ADD495@oracle.com> Message-ID: > First, let me say this is greatly appreciated. I would also say 'it looks > good, go for it' but we are going to need to coordinate this with our > release engineering team. I saw and commented a potential issue yesterday (basic Tomcat/Jenkins running in -d32 -server and core dumped). Switching same application under -d32 -client fixed problem, unsure if it's a bug or not. > This change turns on the universal build by default. Does it still allow the > ability to compile 64-bit only, with either a -D flag or other external > switch? Default is universal build with this patch but we could switch back to 64bits default. In this case, providing ARCH=universal to make will activate universal mode From scott.kovatch at oracle.com Wed Apr 25 08:30:15 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 25 Apr 2012 08:30:15 -0700 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> Message-ID: <6C1467CB-FBA1-4B53-9ADF-E72E542FD750@oracle.com> On Apr 25, 2012, at 6:02 AM, Edvard Wendelin wrote: > Hi, > > I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". I don't think anyone will be confused if you continue to use Mac OS X. Until we hear otherwise, I think it's safe to leave it that way. Instead of indicating 'JDK 6u18' at line 231, we should put "Java for OS X Lion Update 1". Someone will invariably ask which OS X Java Update 6u18 corresponds to, so it's best to just spell it out explicitly. That update corresponds to 6u31, if the JDK 6 version is important. Looks fine otherwise. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From dalibor.topic at oracle.com Wed Apr 25 09:25:09 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 25 Apr 2012 18:25:09 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> Message-ID: <4F982565.3020309@oracle.com> On 4/25/12 3:02 PM, Edvard Wendelin wrote: > Hi, > > I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". > > I'd suggest adding a line a la "After installing XCode, you must install the XCode command line tools. They are available for download through XCode itself." cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 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 Oracle is committed to developing practices and products that help protect the environment From scott.kovatch at oracle.com Wed Apr 25 11:25:51 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 25 Apr 2012 11:25:51 -0700 Subject: OS X JRE 7u6-ea now on java.net Message-ID: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> Hello, I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: To get the 7u6 Mac port Plugin: http://jdk7.java.net/macportpreview/7u6index.html For known issues, please see release notes: http://jdk7.java.net/macportpreview/7u6releasenotes.html Please report any bugs at http://bugreport.sun.com or post to this thread. We would like to hear both success stories and issues you have encountered. This EA release includes a beta of JavaFx 2.2 as well - no additional install needed. JavaFx will always be bundled with the JRE on the Mac. The JRE uses Sparkle to update itself. When you run a Web Start app or Java applet we will look for a new version, and as new builds of the plugin are promoted, you will be prompted to update the plugin. This should happen about once a week. When you do update you will need to quit and restart whatever you were running manually. We are working on the restart behavior. A few things to call out: -- JavaFx-based applets do not work yet. We expect to have support soon. -- DeployToolkit (http://java.com/js/dtjava.js) does not handle Mac OS X yet. If you are relying on that, watch this mailing list or the OTN forums and we will let you know when it has been updated. -- There's no installer at the moment, but we will have one by the time we ship. There are a few manual steps needed to get all of the functionality up and running. -- Web Start shortcuts aren't working yet, but Web Start itself works fine. If you have "Java for OS X 2012-001" or later, double-clicking on a JNLP file will use the Java 7 runtime. Please do not use this JRE for bundling. If you are distributing an application, use the JRE inside the JDK for bundling purposes. Thanks, Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From henri.gomez at gmail.com Wed Apr 25 12:19:45 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 25 Apr 2012 21:19:45 +0200 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> Message-ID: Yeah. Scott, could I know against which jdk7 branch it was built ? jdk7/jdk7-udev ? I'd like to do the same for openjdk-osx-build :) 2012/4/25 Scott Kovatch : > Hello, > > I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: > > To get the 7u6 Mac port Plugin: > http://jdk7.java.net/macportpreview/7u6index.html > > For known issues, please see release notes: > http://jdk7.java.net/macportpreview/7u6releasenotes.html > > Please report any bugs at http://bugreport.sun.com or post to this thread. We would like to hear both success stories and issues you have encountered. > > This EA release includes a beta of JavaFx 2.2 as well - no additional install needed. JavaFx will always be bundled with the JRE on the Mac. > > The JRE uses Sparkle to update itself. When you run a Web Start app or Java applet we will look for a new version, and as new builds of the plugin are promoted, you will be prompted to update the plugin. This should happen about once a week. When you do update you will need to quit and restart whatever you were running manually. We are working on the restart behavior. > > A few things to call out: > > -- JavaFx-based applets do not work yet. We expect to have support soon. > -- DeployToolkit (http://java.com/js/dtjava.js) does not handle Mac OS X yet. If you are relying on that, watch this mailing list or the OTN forums and we will let you know when it has been updated. > -- There's no installer at the moment, but we will have one by the time we ship. There are a few manual steps needed to get all of the functionality up and running. > -- Web Start shortcuts aren't working yet, but Web Start itself works fine. If you have "Java for OS X 2012-001" or later, double-clicking on a JNLP file will use the Java 7 runtime. > > Please do not use this JRE for bundling. If you are distributing an application, use the JRE inside the JDK for bundling purposes. > > Thanks, > Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > From scott.kovatch at oracle.com Wed Apr 25 12:24:56 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 25 Apr 2012 12:24:56 -0700 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> Message-ID: <847589D1-ED9D-4B33-80D6-FCF2D1FFE6E4@oracle.com> This came from the mainline, so it's jdk7u. Web Start and the plugin are not open-sourced, though, so you won't be able to reproduce it on your builds. -- Scott K. On Apr 25, 2012, at 12:19 PM, Henri Gomez wrote: > Yeah. > > Scott, could I know against which jdk7 branch it was built ? > > jdk7/jdk7-udev ? > > I'd like to do the same for openjdk-osx-build :) > > 2012/4/25 Scott Kovatch : >> Hello, >> >> I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: >> >> To get the 7u6 Mac port Plugin: >> http://jdk7.java.net/macportpreview/7u6index.html >> >> For known issues, please see release notes: >> http://jdk7.java.net/macportpreview/7u6releasenotes.html >> >> Please report any bugs at http://bugreport.sun.com or post to this thread. We would like to hear both success stories and issues you have encountered. >> >> This EA release includes a beta of JavaFx 2.2 as well - no additional install needed. JavaFx will always be bundled with the JRE on the Mac. >> >> The JRE uses Sparkle to update itself. When you run a Web Start app or Java applet we will look for a new version, and as new builds of the plugin are promoted, you will be prompted to update the plugin. This should happen about once a week. When you do update you will need to quit and restart whatever you were running manually. We are working on the restart behavior. >> >> A few things to call out: >> >> -- JavaFx-based applets do not work yet. We expect to have support soon. >> -- DeployToolkit (http://java.com/js/dtjava.js) does not handle Mac OS X yet. If you are relying on that, watch this mailing list or the OTN forums and we will let you know when it has been updated. >> -- There's no installer at the moment, but we will have one by the time we ship. There are a few manual steps needed to get all of the functionality up and running. >> -- Web Start shortcuts aren't working yet, but Web Start itself works fine. If you have "Java for OS X 2012-001" or later, double-clicking on a JNLP file will use the Java 7 runtime. >> >> Please do not use this JRE for bundling. If you are distributing an application, use the JRE inside the JDK for bundling purposes. >> >> Thanks, >> Scott K. >> >> ---------------------------------------- >> Scott Kovatch >> scott.kovatch at oracle.com >> Santa Clara/Pleasanton, CA >> >> From henri.gomez at gmail.com Wed Apr 25 12:30:35 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 25 Apr 2012 21:30:35 +0200 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: <847589D1-ED9D-4B33-80D6-FCF2D1FFE6E4@oracle.com> References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> <847589D1-ED9D-4B33-80D6-FCF2D1FFE6E4@oracle.com> Message-ID: > This came from the mainline, so it's jdk7u. ?Web Start and the plugin are not open-sourced, though, so you won't be able to reproduce it on your builds. jdk7/jdk7u so. My builds are here to provide packages from open-source stuff, so no problem with WebStart and plugin. May be they will be bring back to oss one day. From jcpalmer at rochester.rr.com Wed Apr 25 14:09:56 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 25 Apr 2012 17:09:56 -0400 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> Message-ID: Will do. Was planning to add Lion in a partition left over from a Ubuntu experiment a while back anyway. All kinds of errors from DiskUtility trying to get rid of it. Cannot put it off any longer, even if a bare metal rebuild required. On the JNLP front, if this is not going possible on Snow Leopard need to forgo all Java 7 enhancements. Also need to construct a JNLP to reflect this. This is close to what I have now, which works: I cannot figure out to segregate Java version for a specific version of an OS. I absolutely will NOT support Java 6 on Windows or Linux. The JNLP was my enforcement vehicle. How can this be done? From mik3hall at gmail.com Wed Apr 25 14:36:35 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 25 Apr 2012 16:36:35 -0500 Subject: OSX 32/64 bits support for JDK7 patch for review In-Reply-To: References: <3209547B-AE76-4906-B642-F31CD5ADD495@oracle.com> Message-ID: <1C0134F2-5A55-493F-B32E-E5980AEDBC01@gmail.com> On Apr 25, 2012, at 10:24 AM, Henri Gomez wrote: > In this case, providing ARCH=universal to make will activate universal mode You know this ends up with os.arch=universal. I had noticed this on your build before when checking out of curiosity. Not sure if anyone checks the property for anything but that might not be what they're expecting if they do. I was at one point going to base different 32/64 bit JRuby FFI code on this property. But then figured out I could get the pointer size some other way as I remember. From mik3hall at gmail.com Wed Apr 25 16:07:02 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 25 Apr 2012 18:07:02 -0500 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> Message-ID: <504682C2-6788-4032-9AF6-D5415FC20B73@gmail.com> On Apr 25, 2012, at 1:25 PM, Scott Kovatch wrote: > Hello, > > I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: > > Your system must be running Mac OS X 10.7.3 Permanent pre-req? From scott.kovatch at oracle.com Wed Apr 25 17:18:52 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 25 Apr 2012 17:18:52 -0700 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: <504682C2-6788-4032-9AF6-D5415FC20B73@gmail.com> References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> <504682C2-6788-4032-9AF6-D5415FC20B73@gmail.com> Message-ID: On Apr 25, 2012, at 4:07 PM, Michael Hall wrote: > > On Apr 25, 2012, at 1:25 PM, Scott Kovatch wrote: > >> Hello, >> >> I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: >> > >> Your system must be running Mac OS X 10.7.3 > Permanent pre-req? Yes. By the time 7u6 is final, we expect Mountain Lion to be available, and we will always support the current OS at time of release + one previous. You can always try installing it on 10.6.8, but we make no guarantees. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From mik3hall at gmail.com Wed Apr 25 17:31:24 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 25 Apr 2012 19:31:24 -0500 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> <504682C2-6788-4032-9AF6-D5415FC20B73@gmail.com> Message-ID: On Apr 25, 2012, at 7:18 PM, Scott Kovatch wrote: > Yes. By the time 7u6 is final, we expect Mountain Lion to be available, and we will always support the current OS at time of release + one previous. > > You can always try installing it on 10.6.8, but we make no guarantees. > Thanks. (Did - no luck [Then checked for pre-reqs] but might of did something wrong. Checked Firefox - I thought they used to hook up with their own code but this no longer appears to be the case there either). From ray at ganymede.org Wed Apr 25 20:13:34 2012 From: ray at ganymede.org (Ray Kiddy) Date: Wed, 25 Apr 2012 20:13:34 -0700 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: <4F982565.3020309@oracle.com> References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> <4F982565.3020309@oracle.com> Message-ID: On Apr 25, 2012, at 9:25 AM, Dalibor Topic wrote: > On 4/25/12 3:02 PM, Edvard Wendelin wrote: >> Hi, >> >> I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". >> >> > I'd suggest adding a line a la > > "After installing XCode, you must install the XCode command line tools. They are available for download through XCode itself." > > cheers, > dalibor topic I would also suggest pointing out that X11 is required to build. I do not think it is part of the base install of the Dev Tools, it is not separately downloadable (so I need to try to find those @#$%@&! DVDs) and it is not a command-line tool. Or is it part of what you get with that install option? I am still on SnowLeopard, so I do not know. And I cannot build the JDK for lack of freetype, which seems to come with X11. cheers - ray ps: That's quite a signature there, Dalibor. Do you drive a really big car, also? :-) From henri.gomez at gmail.com Wed Apr 25 23:55:01 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 26 Apr 2012 08:55:01 +0200 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> <504682C2-6788-4032-9AF6-D5415FC20B73@gmail.com> Message-ID: > Thanks. > ?(Did - no luck [Then checked for pre-reqs] but might of did something wrong. Checked Firefox - I thought they used to hook up with their own code but this no longer appears to be the case there either). I'll try to produce OpenJDK 7 for Snow, Lion and Mountain Lion. For now, it became a bit complicated with a single MacBookPro running on Lion and having to switch to Snow to redo Snow version of OpenJDK. Build process could be easier with a pack of MacMinis, each with its own OS and running 24/24 7/7 and driven by my Jenkins engine but I had to do with what I've now. C'est la vie :) From edvard.wendelin at oracle.com Thu Apr 26 02:22:34 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 26 Apr 2012 11:22:34 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> <4F982565.3020309@oracle.com> Message-ID: <818599F4-86B8-4E56-B610-4D097F4F2F31@oracle.com> It seems like X11 is included with Lion: http://www.apple.com/macosx/apps/all.html#x11 I haven't installed it separately either and the JDK builds fine. Cheers, Edvard On Apr 26, 2012, at 5:13 AM, Ray Kiddy wrote: > > On Apr 25, 2012, at 9:25 AM, Dalibor Topic wrote: > >> On 4/25/12 3:02 PM, Edvard Wendelin wrote: >>> Hi, >>> >>> I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". >>> >>> >> I'd suggest adding a line a la >> >> "After installing XCode, you must install the XCode command line tools. They are available for download through XCode itself." >> >> cheers, >> dalibor topic > > I would also suggest pointing out that X11 is required to build. I do not think it is part of the base install of the Dev Tools, it is not separately downloadable (so I need to try to find those @#$%@&! DVDs) and it is not a command-line tool. Or is it part of what you get with that install option? I am still on SnowLeopard, so I do not know. And I cannot build the JDK for lack of freetype, which seems to come with X11. > > cheers - ray > > > ps: That's quite a signature there, Dalibor. Do you drive a really big car, also? :-) > From henri.gomez at gmail.com Thu Apr 26 02:37:44 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 26 Apr 2012 11:37:44 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: <818599F4-86B8-4E56-B610-4D097F4F2F31@oracle.com> References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> <4F982565.3020309@oracle.com> <818599F4-86B8-4E56-B610-4D097F4F2F31@oracle.com> Message-ID: X11 support will be removed in Mountain Lion : http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-x-mountain-lion-shifts-support-to-open-source-xquartz/ There is some dependencies required on OpenJDK like FreeType. libfontmanager.dylib: @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, current version 14.2.0) @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) Removing this dependency should be easy by embedding FreeType in OpenJDK 7/8 I plan to works on it ASAP 2012/4/26 Edvard Wendelin : > It seems like X11 is included with Lion: http://www.apple.com/macosx/apps/all.html#x11 I haven't installed it separately either and the JDK builds fine. > > Cheers, > Edvard > > On Apr 26, 2012, at 5:13 AM, Ray Kiddy wrote: > >> >> On Apr 25, 2012, at 9:25 AM, Dalibor Topic wrote: >> >>> On 4/25/12 3:02 PM, Edvard Wendelin wrote: >>>> Hi, >>>> >>>> I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. ?It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. ?Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". >>>> >>>> >>> I'd suggest adding a line a la >>> >>> "After installing XCode, you must install the XCode command line tools. They are available for download through XCode itself." >>> >>> cheers, >>> dalibor topic >> >> I would also suggest pointing out that X11 is required to build. I do not think it is part of the base install of the Dev Tools, it is not separately downloadable (so I need to try to find those @#$%@&! DVDs) and it is not a command-line tool. Or is it part of what you get with that install option? I am still on SnowLeopard, so I do not know. And I cannot build the JDK for lack of freetype, which seems to come with X11. >> >> cheers - ray >> >> >> ps: That's quite a signature there, Dalibor. Do you drive a really big car, also? :-) >> > From dmitry.cherepanov at oracle.com Thu Apr 26 05:14:42 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Thu, 26 Apr 2012 16:14:42 +0400 Subject: Request for review 7154062: [macosx] Mouse cursor isn't updated in applets Message-ID: <4F993C32.20900@oracle.com> http://cr.openjdk.java.net/~dcherepanov/7154062/webrev.0/ Here's a patch for the issue with cursor in applets. The cause of the issue is that -[NSCursor set] doesn't update cursor when application isn't the active application. The fix starts using new method -javaSetAllowsCursorSetInBackground: (introduced in the latest developer package) to allow cursor changes in applets. Thanks, Dmitry From joe.mcglynn at oracle.com Thu Apr 26 06:46:20 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Thu, 26 Apr 2012 06:46:20 -0700 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> <504682C2-6788-4032-9AF6-D5415FC20B73@gmail.com> Message-ID: Make sure FF isn't being run in 32 bit mode, we've run into that. Also take a look at about:plugins in FF and see what is registered for Java. On Apr 25, 2012, at 5:31 PM, Michael Hall wrote: > > On Apr 25, 2012, at 7:18 PM, Scott Kovatch wrote: > >> Yes. By the time 7u6 is final, we expect Mountain Lion to be available, and we will always support the current OS at time of release + one previous. >> >> You can always try installing it on 10.6.8, but we make no guarantees. >> > > Thanks. > (Did - no luck [Then checked for pre-reqs] but might of did something wrong. Checked Firefox - I thought they used to hook up with their own code but this no longer appears to be the case there either). From anthony.petrov at oracle.com Thu Apr 26 06:47:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 26 Apr 2012 17:47:53 +0400 Subject: Request for review 7154062: [macosx] Mouse cursor isn't updated in applets In-Reply-To: <4F993C32.20900@oracle.com> References: <4F993C32.20900@oracle.com> Message-ID: <4F995209.2090001@oracle.com> Looks fine to me. -- best regards, Anthony On 04/26/12 16:14, Dmitry Cherepanov wrote: > http://cr.openjdk.java.net/~dcherepanov/7154062/webrev.0/ > > Here's a patch for the issue with cursor in applets. The cause of the > issue is that -[NSCursor set] doesn't update cursor when application > isn't the active application. The fix starts using new method > -javaSetAllowsCursorSetInBackground: (introduced in the latest developer > package) to allow cursor changes in applets. > > Thanks, > Dmitry > From alexandr.scherbatiy at oracle.com Thu Apr 26 06:47:55 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 26 Apr 2012 17:47:55 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <3836447A-4013-4135-9F80-B80155D86A8B@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> <4F953825.20508@oracle.com> <8600BFDB-9091-4F9C-93A9-7F29B42CC5AD@oracle.com> <4F968CF5.4050500@oracle.com> <3836447A-4013-4135-9F80-B80155D86A8B@oracle.com> Message-ID: <4F99520B.4020704@oracle.com> On 4/25/2012 2:46 PM, Leonid Romanov wrote: > it is not obvious what isTopmostWindowUnderMouse is supposed to check without reading its source code. > It would be great if you could add a brief comment describing method's purpose. Otherwise, the fix looks good. I have added the following comment: // checks that this window is under the mouse cursor and this point is not overlapped by others windows Here is the updated version: http://cr.openjdk.java.net/~alexsch/7154048/webrev.03/ Thanks, Alexandr. > On 24.04.2012, at 15:22, Alexander Scherbatiy wrote: > >> On 4/23/2012 7:39 PM, Leonid Romanov wrote: >>> Hi, >>> I can't find where you set initial value of mouseIsOver variable. Does Objective-C guarantee that it gets some defined default value? >> I really missed this part. >> >> Please review the new version: >> http://cr.openjdk.java.net/~alexsch/7154048/webrev.02/ >> >> The only thing that is changed is the initialization of the mouseIsOver variable to false in the -initWithRect: method of the AWTView class. >> >> Thanks, >> Alexandr. >> >>> On 23.04.2012, at 15:08, Alexander Scherbatiy wrote: >>> >>>> Thank you for the review. >>>> >>>> Here is the new version: >>>> http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ >>>> >>>> 1. The synthesizeMouseEnteredExitedEvents method is added as a native method to the CPlatformWindow class. >>>> Now it is invoked only in places that programmatically change a window size: >>>> - nativeSetNSWindowBounds method from the AWTWindow >>>> - setVisible and setWindowState methods from the CPlatformWindow >>>> >>>> 2. The objective-c code is formatted. >>>> >>>> 3. I do not think that setting the lastMouseEventPeer after sending the MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in the peer. >>>> The postEvent method just post the MOUSE_ENTERED events to the queue. It does not use the lastMouseEventPeer variable and there is no a recursion that invokes the dispatchMouseEvent method again. >>>> >>>> 4. Dragging a window under a panel should not generate mouse entered/exited events for components. However the events should be generated if the window is moved out of the frame or moved in to the frame. So one more condition that checks is the mouse crosess the frame borders are added to the dispatchMouseEvent method from the LWWindowPeer class. >>>> The DragWindowOutOfFrameTest test is added that these events are properly generated. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 4/19/2012 5:14 PM, Anthony Petrov wrote: >>>>> Hi Alexander, >>>>> >>>>> 1. I don't think that it's a good idea to add synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These methods are supposed to perform direct calls to Cocoa API w/o any side-effects. They may be used for windows that even aren't AWT windows, and as such sending them the synthesizeMouseEnteredExitedEvents message is useless, and just doesn't seem right from CWrapper's purpose perspective. You may want to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() native method that would call this native method, and then add a call to it where needed in Java code. >>>>> >>>>> 2. Please follow formatting guidelines and reformat lines like this: >>>>> >>>>>> if(id != MouseEvent.MOUSE_DRAGGED){ >>>>> to read as >>>>> >>>>> if (id != MouseEvent.MOUSE_DRAGGED) { >>>>> >>>>> instead. I see lots of such mis-formatted if() statements all over your code. >>>>> >>>>> 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer after sending the MOUSE_ENTERED event. Before your fix it's been set earlier. Can this change affect some logic in the peer code while processing ENTERED events at a user event handler? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 04/18/12 19:40, Alexander Scherbatiy wrote: >>>>>> Please review a fix for CR 7154048. >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >>>>>> >>>>>> Let's see the following test case: >>>>>> - Frame contains two components JLabel and JButton >>>>>> - The JLabel component has a mouse listener >>>>>> mousePressed: create a Window under the mouse click >>>>>> mouseDragged: drag the created window >>>>>> mouseReleased: close the Window >>>>>> - A user clicks on the JLabel component, drags the mouse to the JButton >>>>>> component and releases the mouse button >>>>>> >>>>>> The current JDK 8 implementation shows the following events on Mac OS X: >>>>>> -------------------------------------------------------- >>>>>> mouse pressed: javax.swing.JLabel >>>>>> mouse exited: javax.swing.JLabel >>>>>> mouse entered: javax.swing.JLabel >>>>>> mouse dragged: javax.swing.JLabel >>>>>> mouse exited: javax.swing.JLabel >>>>>> mouse entered: javax.swing.JButton >>>>>> mouse dragged: javax.swing.JLabel >>>>>> mouse exited: javax.swing.JButton >>>>>> mouse entered: Drag Window >>>>>> mouse exited: Drag Window >>>>>> mouse entered: javax.swing.JButton >>>>>> mouse released: javax.swing.JButton >>>>>> -------------------------------------------------------- >>>>>> >>>>>> There are several issues: >>>>>> 1) The window does not receive the mouse entered event when it is >>>>>> created under the mouse >>>>>> 2) There are JLabel exited/JButton entered events during the window >>>>>> dragging >>>>>> 3) JLabel does not receive the mouse released event >>>>>> >>>>>> The fix synthesizes the mouse entered/exited events manually if they are >>>>>> not received. >>>>>> >>>>>> The entered/exited events synthesizing is added to setFrame, toFront, >>>>>> toBack, and zoom methods of the AWTWindow and CWrapper classes. >>>>>> >>>>>> There is an option to add the events synthesizing to the windowDidResize >>>>>> notification. However this notification is sent when a window size is >>>>>> changed in both cases, programmatically and when user is resized the >>>>>> window. So in a lot of case there is no need for the our use case events >>>>>> generation. >>>>>> >>>>>> The LWWindowPeer class is updated to not generate extra mouse enter/exit >>>>>> events during the mouse dragging. >>>>>> >>>>>> Tho automated tests are added. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. From scott.kovatch at oracle.com Thu Apr 26 08:01:49 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 26 Apr 2012 08:01:49 -0700 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: <262A70C1-03DD-4A74-BEA8-1E3EEE0EE3C4@oracle.com> <504682C2-6788-4032-9AF6-D5415FC20B73@gmail.com> Message-ID: <05C0C1EC-7074-4D6C-8747-58D897212D01@oracle.com> On Apr 25, 2012, at 5:31 PM, Michael Hall wrote: > > On Apr 25, 2012, at 7:18 PM, Scott Kovatch wrote: > >> Yes. By the time 7u6 is final, we expect Mountain Lion to be available, and we will always support the current OS at time of release + one previous. >> >> You can always try installing it on 10.6.8, but we make no guarantees. >> > > Thanks. > (Did - no luck [Then checked for pre-reqs] but might of did something wrong. Checked Firefox - I thought they used to hook up with their own code but this no longer appears to be the case there either). This was true in FF 3.6, but not in Firefox 7 and later. We are officially supporting Firefox 7+ -- basically, any FF version that supports CALayer-based rendering. Safari 5.1.2 is the first supported version of Safari. -- Scott K. From derekprior at gmail.com Thu Apr 26 08:09:52 2012 From: derekprior at gmail.com (Derek Prior) Date: Thu, 26 Apr 2012 11:09:52 -0400 Subject: OS X JRE 7u6-ea now on java.net Message-ID: Apologies if this is an naive question (I'm new here), but is there an equivalent JDK download available now or imminently? If not, how do I find the JDK download for 7u4 that used to live at http://jdk7.java.net/macportpreview/? As best I can tell, its been wiped from existence. > Hello, > > I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: > > To get the 7u6 Mac port Plugin: > http://jdk7.java.net/macportpreview/7u6index.html > > For known issues, please see release notes: > http://jdk7.java.net/macportpreview/7u6releasenotes.html From scott.kovatch at oracle.com Thu Apr 26 08:18:12 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 26 Apr 2012 08:18:12 -0700 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> <4F982565.3020309@oracle.com> <818599F4-86B8-4E56-B610-4D097F4F2F31@oracle.com> Message-ID: I was able to build on Mountain Lion with XQuartz installed: http://xquartz.macosforge.org/landing/, but I had to do some makefile hacking to get it to work. I don't have a cross-version patch yet, sorry. I'd personally like an option to build a JDK without the X11 support. I'm trying to imagine a scenario when I would ever want an X11-based AWT, but can't. -- Scott K. On Apr 26, 2012, at 2:37 AM, Henri Gomez wrote: > X11 support will be removed in Mountain Lion : > > http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-x-mountain-lion-shifts-support-to-open-source-xquartz/ > > There is some dependencies required on OpenJDK like FreeType. > > libfontmanager.dylib: > @rpath/libfontmanager.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, > current version 14.2.0) > @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 159.1.0) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current > version 52.0.0) > @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) > @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) > > Removing this dependency should be easy by embedding FreeType in OpenJDK 7/8 > I plan to works on it ASAP > > > 2012/4/26 Edvard Wendelin : >> It seems like X11 is included with Lion: http://www.apple.com/macosx/apps/all.html#x11 I haven't installed it separately either and the JDK builds fine. >> >> Cheers, >> Edvard >> >> On Apr 26, 2012, at 5:13 AM, Ray Kiddy wrote: >> >>> >>> On Apr 25, 2012, at 9:25 AM, Dalibor Topic wrote: >>> >>>> On 4/25/12 3:02 PM, Edvard Wendelin wrote: >>>>> Hi, >>>>> >>>>> I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". >>>>> >>>>> >>>> I'd suggest adding a line a la >>>> >>>> "After installing XCode, you must install the XCode command line tools. They are available for download through XCode itself." >>>> >>>> cheers, >>>> dalibor topic >>> >>> I would also suggest pointing out that X11 is required to build. I do not think it is part of the base install of the Dev Tools, it is not separately downloadable (so I need to try to find those @#$%@&! DVDs) and it is not a command-line tool. Or is it part of what you get with that install option? I am still on SnowLeopard, so I do not know. And I cannot build the JDK for lack of freetype, which seems to come with X11. >>> >>> cheers - ray >>> >>> >>> ps: That's quite a signature there, Dalibor. Do you drive a really big car, also? :-) >>> >> From henri.gomez at gmail.com Thu Apr 26 08:21:19 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 26 Apr 2012 17:21:19 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> <4F982565.3020309@oracle.com> <818599F4-86B8-4E56-B610-4D097F4F2F31@oracle.com> Message-ID: > I was able to build on Mountain Lion with XQuartz installed: http://xquartz.macosforge.org/landing/, but I had to do some makefile hacking to get it to work. I don't have a cross-version patch yet, sorry. > > I'd personally like an option to build a JDK without the X11 support. I'm trying to imagine a scenario when I would ever want an X11-based AWT, but can't. Scott, X11 dependencies are only for FreeType. Embedding FreeType in OpenJDK OSX package could avoid current problem, ie binaries produced on Lion didn't works on Snow From alexander.zuev at oracle.com Thu Apr 26 08:54:59 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 26 Apr 2012 19:54:59 +0400 Subject: [7u6] Please review my fix for 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame Message-ID: <4F996FD3.9080702@oracle.com> Hello, please review my fix for the CR 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame Bug description is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148289 Fix can be found at http://cr.openjdk.java.net/~kizune/7148289/webrev.00 With best regards, Alex From scott.kovatch at oracle.com Thu Apr 26 09:26:13 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 26 Apr 2012 09:26:13 -0700 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: Message-ID: Sorry about that -- it looks like things moved around a bit. Start at http://jdk7.java.net/archive/7u6-b07.html and you can get the full JDK. I'm not sure what happened to the 7u4 builds. I know they are in final ramp down. -- Scott K. On Apr 26, 2012, at 8:09 AM, Derek Prior wrote: > Apologies if this is an naive question (I'm new here), but is there an > equivalent JDK download available now or imminently? If not, how do I find > the JDK download for 7u4 that used to live at > http://jdk7.java.net/macportpreview/? As best I can tell, its been wiped > from existence. > >> Hello, >> >> I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: >> >> To get the 7u6 Mac port Plugin: >> http://jdk7.java.net/macportpreview/7u6index.html >> >> For known issues, please see release notes: >> http://jdk7.java.net/macportpreview/7u6releasenotes.html From scott.kovatch at oracle.com Thu Apr 26 09:50:22 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 26 Apr 2012 09:50:22 -0700 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: Message-ID: <60F16CE3-0876-4635-8C20-EE4CF28D0CF2@oracle.com> On Apr 26, 2012, at 8:09 AM, Derek Prior wrote: > Apologies if this is an naive question (I'm new here), but is there an > equivalent JDK download available now or imminently? If not, how do I find > the JDK download for 7u4 that used to live at > http://jdk7.java.net/macportpreview/? As best I can tell, its been wiped > from existence. On Apr 26, 2012, at 9:26 AM, Scott Kovatch wrote: > I'm not sure what happened to the 7u4 builds. I know they are in final ramp down. Replying to yourself is generally bad form, but in this case I'm correcting myself. 7u4 is now available according to , but the download page still references 7u3. http://jdk7.java.net/archive/7u6-b07.html is what you want if you can't wait for the main download page to be fixed. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From igor.nekrestyanov at oracle.com Thu Apr 26 09:50:23 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Thu, 26 Apr 2012 09:50:23 -0700 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: Message-ID: <4F997CCF.8030906@oracle.com> On 4/26/12 9:26 AM, Scott Kovatch wrote: > Sorry about that -- it looks like things moved around a bit. Start at > > http://jdk7.java.net/archive/7u6-b07.html > > and you can get the full JDK. Above page will get you fixed build (whilst it is currently latest). Better start point is http://jdk7.java.net/ then go to whatever is current developer preview release. -igor > > I'm not sure what happened to the 7u4 builds. I know they are in final ramp down. > > -- Scott K. > > On Apr 26, 2012, at 8:09 AM, Derek Prior wrote: > >> Apologies if this is an naive question (I'm new here), but is there an >> equivalent JDK download available now or imminently? If not, how do I find >> the JDK download for 7u4 that used to live at >> http://jdk7.java.net/macportpreview/? As best I can tell, its been wiped >> from existence. >> >>> Hello, >>> >>> I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: >>> >>> To get the 7u6 Mac port Plugin: >>> http://jdk7.java.net/macportpreview/7u6index.html >>> >>> For known issues, please see release notes: >>> http://jdk7.java.net/macportpreview/7u6releasenotes.html From Alexander.Potochkin at oracle.com Thu Apr 26 10:03:53 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 26 Apr 2012 21:03:53 +0400 Subject: [7u6] Request for approval: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent Message-ID: <4F997FF9.6000101@oracle.com> Requesting approval to commit fix for CR 7124210. http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ Reviewed by Sergey Bylokhov http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-April/003979.html the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124210 This bug breaks our regression test on MacOS, it has already been fixed in JDK8. Thanks alexp From Alexander.Potochkin at oracle.com Thu Apr 26 10:07:27 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 26 Apr 2012 21:07:27 +0400 Subject: [7u6] Request for approval: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value Message-ID: <4F9980CF.1060705@oracle.com> Requesting approval to commit fix for CR 7124328. http://cr.openjdk.java.net/~alexp/7124328/webrev.01/ Reviewed by Anthony Petrov http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-April/003884.html the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 This bug breaks the method's specification for JDK on MacOS, it has already been fixed in JDK8. Thanks alexp From edvard.wendelin at oracle.com Thu Apr 26 10:56:59 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 26 Apr 2012 19:56:59 +0200 Subject: [7u6] Request for approval: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent In-Reply-To: <4F997FF9.6000101@oracle.com> References: <4F997FF9.6000101@oracle.com> Message-ID: <29CC67D7-A745-458A-AC44-BA480316C9B4@oracle.com> Approved. On Apr 26, 2012, at 7:03 PM, Alexander Potochkin wrote: > Requesting approval to commit fix for CR 7124210. > > http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ > > Reviewed by Sergey Bylokhov > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-April/003979.html > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124210 > > This bug breaks our regression test on MacOS, > it has already been fixed in JDK8. > > Thanks > alexp > > From edvard.wendelin at oracle.com Thu Apr 26 10:57:03 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 26 Apr 2012 19:57:03 +0200 Subject: [7u6] Request for approval: 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value In-Reply-To: <4F9980CF.1060705@oracle.com> References: <4F9980CF.1060705@oracle.com> Message-ID: <62A54A01-ACE5-4E36-912B-5E90CE9D45B8@oracle.com> Approved. On Apr 26, 2012, at 7:07 PM, Alexander Potochkin wrote: > Requesting approval to commit fix for CR 7124328. > > http://cr.openjdk.java.net/~alexp/7124328/webrev.01/ > > Reviewed by Anthony Petrov > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-April/003884.html > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124328 > > This bug breaks the method's specification for JDK on MacOS, > it has already been fixed in JDK8. > > Thanks > alexp > > From roger.yeung at oracle.com Thu Apr 26 11:56:55 2012 From: roger.yeung at oracle.com (Roger Yeung) Date: Thu, 26 Apr 2012 11:56:55 -0700 Subject: OS X JRE 7u6-ea now on java.net In-Reply-To: References: Message-ID: <4F999A77.3020702@oracle.com> Hi Derek, 7u4 was removed yesterday as it is just released: http://www.oracle.com/technetwork/java/javase/downloads/index.html You can get the latest of 7u6 Developer Preview at: http://jdk7.java.net/download.html -- RY On 4/26/12 9:26 AM, Scott Kovatch wrote: > Sorry about that -- it looks like things moved around a bit. Start at > > http://jdk7.java.net/archive/7u6-b07.html > > and you can get the full JDK. > > I'm not sure what happened to the 7u4 builds. I know they are in final ramp down. > > -- Scott K. > > On Apr 26, 2012, at 8:09 AM, Derek Prior wrote: > >> Apologies if this is an naive question (I'm new here), but is there an >> equivalent JDK download available now or imminently? If not, how do I find >> the JDK download for 7u4 that used to live at >> http://jdk7.java.net/macportpreview/? As best I can tell, its been wiped >> from existence. >> >>> Hello, >>> >>> I wanted to let everyone know that the EA release of the 7u6 JRE for OS X is now on java.net: >>> >>> To get the 7u6 Mac port Plugin: >>> http://jdk7.java.net/macportpreview/7u6index.html >>> >>> For known issues, please see release notes: >>> http://jdk7.java.net/macportpreview/7u6releasenotes.html From edvard.wendelin at oracle.com Fri Apr 27 00:46:07 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 27 Apr 2012 09:46:07 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> Message-ID: <97AE8BF5-0349-46EA-BCF5-7CC746E0A8AB@oracle.com> Hi, Here is a link to an updated version where I've incorporated the feedback I got from Scott and Dalibor: http://cr.openjdk.java.net/~ewendeli/7154130/webrev.01/ Cheers, Edvard On Apr 25, 2012, at 3:02 PM, Edvard Wendelin wrote: > Hi, > > I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". > > You can find the webrev here: http://cr.openjdk.java.net/~ewendeli/7154130/webrev.00/ > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154130 > > Thanks, > Edvard > > [1] http://hg.openjdk.java.net/jdk8/build/raw-file/e01201e727da/README-builds.html > [2] http://openjdk.java.net/projects/macosx-port/ > [3] https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Prerequisites > [4] http://www.apple.com/macosx/ From dalibor.topic at oracle.com Fri Apr 27 01:08:53 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 27 Apr 2012 10:08:53 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: <97AE8BF5-0349-46EA-BCF5-7CC746E0A8AB@oracle.com> References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> <97AE8BF5-0349-46EA-BCF5-7CC746E0A8AB@oracle.com> Message-ID: <4F9A5415.4020904@oracle.com> On 4/27/12 9:46 AM, Edvard Wendelin wrote: > Hi, > > Here is a link to an updated version where I've incorporated the feedback I got from Scott and Dalibor: http://cr.openjdk.java.net/~ewendeli/7154130/webrev.01/ Looks fine to me. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 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 Oracle is committed to developing practices and products that help protect the environment From artem.ananiev at oracle.com Fri Apr 27 04:58:02 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 27 Apr 2012 15:58:02 +0400 Subject: Request for review 7154062: [macosx] Mouse cursor isn't updated in applets In-Reply-To: <4F993C32.20900@oracle.com> References: <4F993C32.20900@oracle.com> Message-ID: <4F9A89CA.3000604@oracle.com> Looks fine. Thanks, Artem On 4/26/2012 4:14 PM, Dmitry Cherepanov wrote: > http://cr.openjdk.java.net/~dcherepanov/7154062/webrev.0/ > > Here's a patch for the issue with cursor in applets. The cause of the > issue is that -[NSCursor set] doesn't update cursor when application > isn't the active application. The fix starts using new method > -javaSetAllowsCursorSetInBackground: (introduced in the latest developer > package) to allow cursor changes in applets. > > Thanks, > Dmitry > From leonid.romanov at oracle.com Fri Apr 27 07:11:01 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 27 Apr 2012 18:11:01 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus Message-ID: Hi, Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Fri Apr 27 09:54:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 27 Apr 2012 20:54:59 +0400 Subject: [7u6] Please review my fix for 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame In-Reply-To: <4F996FD3.9080702@oracle.com> References: <4F996FD3.9080702@oracle.com> Message-ID: <4F9ACF63.5080406@oracle.com> Hi Alexander, Could you provide some details about the ToolkitThreadBlockedHandler interface? How is it used by the DnD code? Also, I suggest to replace the word Native with Nested in enter/exitNativeEventLoop() method names. -- best regards, Anthony On 4/26/2012 7:54 PM, Alexander Zuev wrote: > Hello, > > please review my fix for the CR 7148289: [macosx] Deadlock in > sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame > > Bug description is > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148289 > > Fix can be found at http://cr.openjdk.java.net/~kizune/7148289/webrev.00 > > With best regards, > Alex From anthony.petrov at oracle.com Fri Apr 27 10:39:19 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 27 Apr 2012 21:39:19 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: References: Message-ID: <4F9AD9C7.6020707@oracle.com> Hi Leonid, I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. Regarding the fix itself: 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? -- best regards, Anthony On 4/27/2012 6:11 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 > webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ > > Thanks, > Leonid. > From leonid.romanov at oracle.com Fri Apr 27 10:53:31 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 27 Apr 2012 21:53:31 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: <4F9AD9C7.6020707@oracle.com> References: <4F9AD9C7.6020707@oracle.com> Message-ID: <5855B8CB-664F-4DCC-B55F-9DA8C1731258@oracle.com> Hi, 1. Yep, I've verified whether my solution works for AWT and indeed it does: returning NO from canBecomeMain/KeyWindow does prevent OS from bringing window to the front. Wonder why it doesn't work for FX. The thing is, if we allow OS to bring blocked window to the front, even for a fraction of second required to restack window back, then user would see window jumping forth and back in z-order, and this is something we want to avoid. 2. I need to check on this. Thanks for pointing it out. Leonid. On 27.04.2012, at 21:39, Anthony Petrov wrote: > Hi Leonid, > > I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. > > Regarding the fix itself: > > 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? > > 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? > > -- > best regards, > Anthony > > On 4/27/2012 6:11 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 >> webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ >> Thanks, >> Leonid. From anthony.petrov at oracle.com Fri Apr 27 11:01:05 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 27 Apr 2012 22:01:05 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: <5855B8CB-664F-4DCC-B55F-9DA8C1731258@oracle.com> References: <4F9AD9C7.6020707@oracle.com> <5855B8CB-664F-4DCC-B55F-9DA8C1731258@oracle.com> Message-ID: <4F9ADEE1.7000307@oracle.com> On 4/27/2012 9:53 PM, Leonid Romanov wrote: > 1. Yep, I've verified whether my solution works for AWT and indeed it does: returning NO from canBecomeMain/KeyWindow does prevent OS from bringing window to the front. Wonder why it doesn't work for FX. The thing is, if we allow OS to bring blocked window to the front, even for a fraction of second required to restack window back, then user would see window jumping forth and back in z-order, and this is something we want to avoid. Please try clicking the title-bar of a blocked window, not its content area. Does it still not jump to the front? Perhaps Apple fixed this in 10.7, but on my old 10.6.8 system the canBecome-NO windows did go to the top of the stacking order when being clicked. Note that the restacking is unnoticed since in FX it's performed during the windowDidBecomeKey event processing. If we postpone this operation, then indeed, some flickering will be visible. -- best regards, Anthony > > 2. I need to check on this. Thanks for pointing it out. > > Leonid. > > On 27.04.2012, at 21:39, Anthony Petrov wrote: > >> Hi Leonid, >> >> I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. >> >> Regarding the fix itself: >> >> 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? >> >> 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? >> >> -- >> best regards, >> Anthony >> >> On 4/27/2012 6:11 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 >>> webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ >>> Thanks, >>> Leonid. > From leonid.romanov at oracle.com Fri Apr 27 11:02:10 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 27 Apr 2012 22:02:10 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: <4F9AD9C7.6020707@oracle.com> References: <4F9AD9C7.6020707@oracle.com> Message-ID: <57BD5F10-B0B3-4091-8777-2A084643DC4C@oracle.com> I've looked at 7124395 and the fixes you did for FX and it looks like we need setEnabled method for AWTWindow. I'll redo my fix accordingly. On 27.04.2012, at 21:39, Anthony Petrov wrote: > Hi Leonid, > > I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. > > Regarding the fix itself: > > 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? > > 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? > > -- > best regards, > Anthony > > On 4/27/2012 6:11 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 >> webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ >> Thanks, >> Leonid. From anthony.petrov at oracle.com Fri Apr 27 11:04:46 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 27 Apr 2012 22:04:46 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: <57BD5F10-B0B3-4091-8777-2A084643DC4C@oracle.com> References: <4F9AD9C7.6020707@oracle.com> <57BD5F10-B0B3-4091-8777-2A084643DC4C@oracle.com> Message-ID: <4F9ADFBE.5070909@oracle.com> I've noticed that too. I didn't point this out though, because you're also checking the MODAL_EXCLUDED flag in your modallyBlocked(), so I thought it was OK. But if you can pull this check to the Java code before even calling modallyBLocked(), then I guess the "setEnabled" name would make more sense. -- best regards, Anthony On 4/27/2012 10:02 PM, Leonid Romanov wrote: > I've looked at 7124395 and the fixes you did for FX and it looks like we need setEnabled method for AWTWindow. I'll redo my fix accordingly. > > On 27.04.2012, at 21:39, Anthony Petrov wrote: > >> Hi Leonid, >> >> I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. >> >> Regarding the fix itself: >> >> 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? >> >> 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? >> >> -- >> best regards, >> Anthony >> >> On 4/27/2012 6:11 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 >>> webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ >>> Thanks, >>> Leonid. > From leonid.romanov at oracle.com Fri Apr 27 11:06:04 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 27 Apr 2012 22:06:04 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: <4F9ADEE1.7000307@oracle.com> References: <4F9AD9C7.6020707@oracle.com> <5855B8CB-664F-4DCC-B55F-9DA8C1731258@oracle.com> <4F9ADEE1.7000307@oracle.com> Message-ID: Hmmm? Perhaps we too restack window during windowDidBecomeKey event processing or do something similar. I'll check it tomorrow. On 27.04.2012, at 22:01, Anthony Petrov wrote: > On 4/27/2012 9:53 PM, Leonid Romanov wrote: >> 1. Yep, I've verified whether my solution works for AWT and indeed it does: returning NO from canBecomeMain/KeyWindow does prevent OS from bringing window to the front. Wonder why it doesn't work for FX. The thing is, if we allow OS to bring blocked window to the front, even for a fraction of second required to restack window back, then user would see window jumping forth and back in z-order, and this is something we want to avoid. > > Please try clicking the title-bar of a blocked window, not its content area. Does it still not jump to the front? > > Perhaps Apple fixed this in 10.7, but on my old 10.6.8 system the canBecome-NO windows did go to the top of the stacking order when being clicked. > > Note that the restacking is unnoticed since in FX it's performed during the windowDidBecomeKey event processing. If we postpone this operation, then indeed, some flickering will be visible. > > -- > best regards, > Anthony > >> 2. I need to check on this. Thanks for pointing it out. >> Leonid. >> On 27.04.2012, at 21:39, Anthony Petrov wrote: >>> Hi Leonid, >>> >>> I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. >>> >>> Regarding the fix itself: >>> >>> 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? >>> >>> 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/27/2012 6:11 PM, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 >>>> webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ >>>> Thanks, >>>> Leonid. From alexander.zuev at oracle.com Sat Apr 28 01:16:40 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Sat, 28 Apr 2012 12:16:40 +0400 Subject: [7u6] Please review my fix for 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame In-Reply-To: <4F9ACF63.5080406@oracle.com> References: <4F996FD3.9080702@oracle.com> <4F9ACF63.5080406@oracle.com> Message-ID: <4F9BA768.1070404@oracle.com> Anthony, sure, the details are: the ToolkitThreadBlockerHandler is an interface that is supposed to be used when program has to wait for the event pushed to the EDT finish its task and he calls like this: while (!dispatcher.isDone()) { DataTransferer.getInstance().getToolkitThreadBlockedHandler().enter(); } and the event handler in its unregisterEvent() method calls for handler.exit() The method is supposed to make sure that waiting on the EDT doesn't create deadlocks. The implementation depends on the toolkit architecture - on some toolkits it's NoOp since they don't care if EDT is waiting, but in LWCToolkit our AWT components are backed by Swing delegates so there are a lot of calls from native application thread to EDT and vice versa so we can't afford to stop both threads. Solution is the code that makes secondary AppKit event loop to handle native events so waiting on EDT will leave at least one event loop pumping. The name is correct because despite the fact that we are in AWT code (LWCToolkit) we don't create nested EDT loop but running nested native (AppKit) loop - hence the name: enter/exitNativeEventLoop() With best regards, Alex On 4/27/12 20:54, Anthony Petrov wrote: > Hi Alexander, > > Could you provide some details about the ToolkitThreadBlockedHandler > interface? How is it used by the DnD code? > > Also, I suggest to replace the word Native with Nested in > enter/exitNativeEventLoop() method names. > > -- > best regards, > Anthony > > On 4/26/2012 7:54 PM, Alexander Zuev wrote: >> Hello, >> >> please review my fix for the CR 7148289: [macosx] Deadlock in >> sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame >> >> Bug description is >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148289 >> >> Fix can be found at >> http://cr.openjdk.java.net/~kizune/7148289/webrev.00 >> >> With best regards, >> Alex From anthony.petrov at oracle.com Sat Apr 28 03:52:15 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Sat, 28 Apr 2012 14:52:15 +0400 Subject: [7u6] Please review my fix for 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame In-Reply-To: <4F9BA768.1070404@oracle.com> References: <4F996FD3.9080702@oracle.com> <4F9ACF63.5080406@oracle.com> <4F9BA768.1070404@oracle.com> Message-ID: <4F9BCBDF.6040709@oracle.com> Hi Alexander, On 4/28/2012 12:16 PM, Alexander Zuev wrote: > the ToolkitThreadBlockerHandler is an interface that is supposed to be > used > when program has to wait for the event pushed to the EDT finish its task > and > he calls like this: > while (!dispatcher.isDone()) { > > DataTransferer.getInstance().getToolkitThreadBlockedHandler().enter(); > } > and the event handler in its unregisterEvent() method calls for > handler.exit() > The method is supposed to make sure that waiting on the EDT doesn't > create deadlocks. > The implementation depends on the toolkit architecture - on some > toolkits it's NoOp since > they don't care if EDT is waiting, but in LWCToolkit our AWT components > are backed by Swing > delegates so there are a lot of calls from native application thread to > EDT and vice versa so we > can't afford to stop both threads. Solution is the code that makes > secondary AppKit event loop > to handle native events so waiting on EDT will leave at least one event > loop pumping. Thanks! > The name is correct because despite the fact that we are in AWT code > (LWCToolkit) we don't > create nested EDT loop but running nested native (AppKit) loop - hence > the name: enter/exitNativeEventLoop() Since the main event loop is already spinning, I would still suggest to rename it to, say, enter/exitNestedNativeEventLoop() to stress that this event loop is going to be an inner loop, rather than the main (outer) event loop. -- best regards, Anthony > > With best regards, > Alex > > On 4/27/12 20:54, Anthony Petrov wrote: >> Hi Alexander, >> >> Could you provide some details about the ToolkitThreadBlockedHandler >> interface? How is it used by the DnD code? >> >> Also, I suggest to replace the word Native with Nested in >> enter/exitNativeEventLoop() method names. >> >> -- >> best regards, >> Anthony >> >> On 4/26/2012 7:54 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix for the CR 7148289: [macosx] Deadlock in >>> sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame >>> >>> Bug description is >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148289 >>> >>> Fix can be found at >>> http://cr.openjdk.java.net/~kizune/7148289/webrev.00 >>> >>> With best regards, >>> Alex > From henri.gomez at gmail.com Sun Apr 29 01:48:26 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 29 Apr 2012 10:48:26 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> <4F982565.3020309@oracle.com> <818599F4-86B8-4E56-B610-4D097F4F2F31@oracle.com> Message-ID: I'm experimenting using a pre-built FreeType, included in OpenJDK7 ire/lib at install time. 2012/4/26 Scott Kovatch : > I was able to build on Mountain Lion with XQuartz installed: http://xquartz.macosforge.org/landing/, but I had to do some makefile hacking to get it to work. I don't have a cross-version patch yet, sorry. > > I'd personally like an option to build a JDK without the X11 support. I'm trying to imagine a scenario when I would ever want an X11-based AWT, but can't. > > -- Scott K. > > On Apr 26, 2012, at 2:37 AM, Henri Gomez wrote: > >> X11 support will be removed in Mountain Lion : >> >> http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-x-mountain-lion-shifts-support-to-open-source-xquartz/ >> >> There is some dependencies required on OpenJDK like FreeType. >> >> libfontmanager.dylib: >> ? ? ? @rpath/libfontmanager.dylib (compatibility version 1.0.0, current >> version 1.0.0) >> ? ? ? /usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, >> current version 14.2.0) >> ? ? ? @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) >> ? ? ? /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 159.1.0) >> ? ? ? /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current >> version 52.0.0) >> ? ? ? @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) >> ? ? ? @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) >> >> Removing this dependency should be easy by embedding FreeType in OpenJDK 7/8 >> I plan to works on it ASAP >> >> >> 2012/4/26 Edvard Wendelin : >>> It seems like X11 is included with Lion: http://www.apple.com/macosx/apps/all.html#x11 I haven't installed it separately either and the JDK builds fine. >>> >>> Cheers, >>> Edvard >>> >>> On Apr 26, 2012, at 5:13 AM, Ray Kiddy wrote: >>> >>>> >>>> On Apr 25, 2012, at 9:25 AM, Dalibor Topic wrote: >>>> >>>>> On 4/25/12 3:02 PM, Edvard Wendelin wrote: >>>>>> Hi, >>>>>> >>>>>> I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. ?It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. ?Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". >>>>>> >>>>>> >>>>> I'd suggest adding a line a la >>>>> >>>>> "After installing XCode, you must install the XCode command line tools. They are available for download through XCode itself." >>>>> >>>>> cheers, >>>>> dalibor topic >>>> >>>> I would also suggest pointing out that X11 is required to build. I do not think it is part of the base install of the Dev Tools, it is not separately downloadable (so I need to try to find those @#$%@&! DVDs) and it is not a command-line tool. Or is it part of what you get with that install option? I am still on SnowLeopard, so I do not know. And I cannot build the JDK for lack of freetype, which seems to come with X11. >>>> >>>> cheers - ray >>>> >>>> >>>> ps: That's quite a signature there, Dalibor. Do you drive a really big car, also? :-) >>>> >>> > From henri.gomez at gmail.com Sun Apr 29 23:47:55 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 30 Apr 2012 08:47:55 +0200 Subject: Request for Review: Add Mac OS X Instructions to README-builds.html In-Reply-To: References: <71061CDF-179D-4DEB-AC94-5D20F1FF7383@oracle.com> <4F982565.3020309@oracle.com> <818599F4-86B8-4E56-B610-4D097F4F2F31@oracle.com> Message-ID: <038862E6-6981-45A7-9B12-0A17E9E31A92@gmail.com> Relative question : I take a look at http://www.opensource.apple.com/ to see if Freetype configure/build options are detailed but didn't find anything usefull. I want to check my configure options, using clang and dual arch settings. Any feedbacks welcomed. Le 29 avr. 2012 ? 10:48, Henri Gomez a ?crit : > I'm experimenting using a pre-built FreeType, included in OpenJDK7 > ire/lib at install time. > > 2012/4/26 Scott Kovatch : >> I was able to build on Mountain Lion with XQuartz installed: http://xquartz.macosforge.org/landing/, but I had to do some makefile hacking to get it to work. I don't have a cross-version patch yet, sorry. >> >> I'd personally like an option to build a JDK without the X11 support. I'm trying to imagine a scenario when I would ever want an X11-based AWT, but can't. >> >> -- Scott K. >> >> On Apr 26, 2012, at 2:37 AM, Henri Gomez wrote: >> >>> X11 support will be removed in Mountain Lion : >>> >>> http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-x-mountain-lion-shifts-support-to-open-source-xquartz/ >>> >>> There is some dependencies required on OpenJDK like FreeType. >>> >>> libfontmanager.dylib: >>> @rpath/libfontmanager.dylib (compatibility version 1.0.0, current >>> version 1.0.0) >>> /usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, >>> current version 14.2.0) >>> @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 159.1.0) >>> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current >>> version 52.0.0) >>> @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) >>> @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) >>> >>> Removing this dependency should be easy by embedding FreeType in OpenJDK 7/8 >>> I plan to works on it ASAP >>> >>> >>> 2012/4/26 Edvard Wendelin : >>>> It seems like X11 is included with Lion: http://www.apple.com/macosx/apps/all.html#x11 I haven't installed it separately either and the JDK builds fine. >>>> >>>> Cheers, >>>> Edvard >>>> >>>> On Apr 26, 2012, at 5:13 AM, Ray Kiddy wrote: >>>> >>>>> >>>>> On Apr 25, 2012, at 9:25 AM, Dalibor Topic wrote: >>>>> >>>>>> On 4/25/12 3:02 PM, Edvard Wendelin wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm working on some updates in the README-builds.html [1]. The first step is to add the Mac OS X platform. I have gathered the requirements from the Mac OS X port wiki [2][3]. It seems like Apple has dropped the "Mac" part of "Mac OS X" and now only call the product "OS X Lion" [4]. Question is if this is only a marketing term or if it's now the official name. In this webrev I've used "Mac OS X". >>>>>>> >>>>>>> >>>>>> I'd suggest adding a line a la >>>>>> >>>>>> "After installing XCode, you must install the XCode command line tools. They are available for download through XCode itself." >>>>>> >>>>>> cheers, >>>>>> dalibor topic >>>>> >>>>> I would also suggest pointing out that X11 is required to build. I do not think it is part of the base install of the Dev Tools, it is not separately downloadable (so I need to try to find those @#$%@&! DVDs) and it is not a command-line tool. Or is it part of what you get with that install option? I am still on SnowLeopard, so I do not know. And I cannot build the JDK for lack of freetype, which seems to come with X11. >>>>> >>>>> cheers - ray >>>>> >>>>> >>>>> ps: That's quite a signature there, Dalibor. Do you drive a really big car, also? :-) >>>>> >>>> >>