From Sergey.Bylokhov at oracle.com Sat Dec 1 00:12:19 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Nov 2018 16:12:19 -0800 Subject: [12] Review request for JDK-8209123: [Macosx] Maximized frame is resizable on Mac but not on Windows and Ubuntu In-Reply-To: References: <65743c3f-8f90-f167-cd56-97af8d3b5c53@oracle.com> <01925cdc-46d3-a6c6-a1b7-f19086c98562@oracle.com> Message-ID: <34c8859d-6479-32cd-16c4-3f6b8fda078a@oracle.com> Hi, Manajit. > When the use clicks on the title bar then frame is moved to the either zoom or minimize depending upon the System Preferences -> Dock setting. > With my fix if a frame state is MAXIMIZED_BOTH, the frame resizibility is set to true to allow the frame to go to the set state (zoom or minimize). The frame resizibility is reset back to false to maintain the MAXIMIZED_BOTH frame behaviour proposed in my fix. If the ?updateResizableAndMaximizeState(true) is not called then a MAXIMIZED_BOTH frame becomes resizable and breaks the behaviour. I'm not sure that it works as intended: Frame f = new Frame(); f.setSize(300,300); f.setVisible(true); f.setMaximizedBounds(new Rectangle(100,100,100,100)); f.setExtendedState(Frame.MAXIMIZED_BOTH); Try to click on the title of the frame above a few times. The frame will be non-resizable even in the normal state. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Dec 1 00:17:40 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Nov 2018 16:17:40 -0800 Subject: RFR: [XS] 8214380: AwtDragSource function LoadCache misses a ReleaseLongArrayElements in special case In-Reply-To: References: <37762172-43ad-1103-eb21-258d421e75d8@oracle.com> Message-ID: Looks fine. On 30/11/2018 05:22, Baesken, Matthias wrote: > Hi Sergey, I prepared a second webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.1/ > > - removed the unused isCopy > - added a NULL check after GetLongArrayElements > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Donnerstag, 29. November 2018 10:01 >> To: 'Sergey Bylokhov' ; 'awt- >> dev at openjdk.java.net' >> Subject: RE: RFR: [XS] 8214380: AwtDragSource function >> LoadCache misses a ReleaseLongArrayElements in special case >> >> Btw when looking at the coding, I wonder why we save the copy-state in >> isCopy : >> >> Docu : "If isCopy is not NULL, then *isCopy is set to JNI_TRUE if a copy is >> made; or it is set to JNI_FALSE if no copy is made" >> >> 397 jboolean isCopy; >> 398 jlong *lFormats = env->GetLongArrayElements(formats, &isCopy), >> >> But then we do not use it afterwards , so should we better call it with >> NULL instead? >> >> Regards, Matthias >> >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Donnerstag, 29. November 2018 09:17 >>> To: 'Sergey Bylokhov' ; awt- >>> dev at openjdk.java.net >>> Subject: RE: RFR: [XS] 8214380: AwtDragSource function >>> LoadCache misses a ReleaseLongArrayElements in special case >>> >>> Hi Sergey, I think it is (at least) a good practice to NULL - check the result >>> of env->GetLongArrayElements . >>> Probably it should be done right after the >>> >>> jlong *lFormats = env->GetLongArrayElements(formats, &isCopy), >>> >>> call. >>> See jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c for >>> examples of usages of the function (with NULL checks) . >>> >>> Or see the documentation at >>> >> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/function >>> s.html >>> Where we find : >>> >>> >>> GetArrayElements Routines >>> .... >>> PARAMETERS: >>> >>> env: the JNI interface pointer. >>> array: a Java string object. >>> isCopy: a pointer to a boolean. >>> >>> >>> RETURNS: >>> >>> Returns a pointer to the array elements, ****or NULL if the operation >>> fails.**** >>> >>> >>> So returning NULL might happen . >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Donnerstag, 29. November 2018 00:22 >>>> To: Baesken, Matthias ; awt- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR: [XS] 8214380: AwtDragSource function >>>> LoadCache misses a ReleaseLongArrayElements in special case >>>> >>>> Hi, Matthias. >>>> >>>> Do we need the null check in the fix, if "yes" then probably >>>> the same check should be added before this line as well? >>>> 465 env->ReleaseLongArrayElements(formats, saveFormats, 0); >>>> >>>> On 28/11/2018 00:33, Baesken, Matthias wrote: >>>>> Hello, please review? this small fix. >>>>> >>>>> It adds a missing ReleaseLongArrayElements ?to >>>>> >>>>> void AwtDragSource::LoadCache(jlongArray formats) >>>>> >>>>> in an early special ??"pseudo return"? (leave function via throw)? case. >>>>> >>>>> Webrev/bug : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.0/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8214380 >>>>> >>>>> Thanks, Matthias >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Dec 1 00:35:37 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Nov 2018 16:35:37 -0800 Subject: RFR: 8214298 Add non interactive test case for JDK-8211267 In-Reply-To: <7638a441405abe3b5919baf2b6a75501@linux.vnet.ibm.com> References: <7638a441405abe3b5919baf2b6a75501@linux.vnet.ibm.com> Message-ID: Hello, I think that you can use invokeAndWait instead of invokeLater(), which will wait while the code is executed on EDT, and I am not sure that you need to interrupt the main thread of the test. On 26/11/2018 09:19, Ichiroh Takiguchi wrote: > Hello. > Could you review the fix ? > > Issue: > JDK-8211267 requires non interactive test case > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214298 > Change: https://cr.openjdk.java.net/~itakiguchi/8214298/webrev.00/ > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Dec 1 00:41:22 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Nov 2018 16:41:22 -0800 Subject: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar In-Reply-To: <0f8cb722-515b-4d99-9da5-0c4d0edfa7f8@default> References: <61fbe29e-22af-b5b2-47bc-14cd7853d5bc@oracle.com> <91344f31-9c1a-e5e0-a246-a92b36374ac6@oracle.com> <14494971-153c-d5d2-e4a4-ed078a444643@oracle.com> <667aceec-609b-49fd-a610-1d208c59031a@default> <69b22191-796e-a26a-c0e2-50b3e43d1b1a@oracle.com> <22f34125-4a68-57ed-c7fb-4e233a687007@oracle.com> <47c4f32a-c895-99d3-b8d2-90a1bcf65f58@oracle.com> <69542b48-24c3-7954-7ec7-7dfa38e16eef@oracle.com> <1f3b3a73-65ad-4ce7-5bda-269562b6fd7e@oracle.com> <0f8cb722-515b-4d99-9da5-0c4d0edfa7f8@default> Message-ID: <6c6313ff-3c2d-6fb2-9aad-c9bb68536727@oracle.com> Hi, Shashi. On 26/11/2018 01:15, Shashidhara Veerabhadraiah wrote: >> Hi Alexey, The accessible information is already set for the component >> in question and that is the reason it works with the accessibility >> short cut(without this fix). Did you check that VO announces when the ProgressBar is update its progress? When I checked it last time, when the demo is in progress("Start loading text" button was pressed) the VO did not read information about the new values of the progress bar. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Dec 1 00:49:13 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Nov 2018 16:49:13 -0800 Subject: RFR: X11 default visual support for IM status window on VNC In-Reply-To: <47596f79d10fcfac856172db4d8cffd2@linux.vnet.ibm.com> References: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com> <4cb2abda-706f-8b1a-320c-64285ebfafae@oracle.com> <34954ce768b5b3254a3122cb8c0ed268@linux.vnet.ibm.com> <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com> <068fccf8-05a9-0e32-0540-551ade446f96@oracle.com> <5B2A6160.5000107@oracle.com> <674fa1d548764758a051953ce9a97d95@linux.vnet.ibm.com> <47596f79d10fcfac856172db4d8cffd2@linux.vnet.ibm.com> Message-ID: <533c8ab5-31d9-58bd-4250-03e1c24f6f23@oracle.com> Looks fine, if there are no other comments I'll push the fix. On 26/11/2018 05:02, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212677 > Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.00/ > > Screen shots are in JDK-8212677. > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-06-21 21:58, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> I'm sorry, I forgot to put my comment against your question. >> >>> Is this changing the default visual? for all WIndows, not just the IM status window? >>> I think we need to understand the implications before this can be accepted. >> I put following debug code: >> ======= >> diff -r e1b3def12624 >> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> ?Wed Jun 13 06:35:04 2018 +0200 >> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> ?Thu Jun 21 21:23:11 2018 +0900 >> @@ -667,6 +667,7 @@ >> ???????????????????????????? InputOutput, >> ???????????????????????????? adata->awt_visInfo.visual, >> ???????????????????????????? attribmask, &attrib); >> +??? fprintf(stderr, "status window id = 0x%X\n", status); >> ???? XSelectInput(dpy, status, >> ????????????????? ExposureMask | StructureNotifyMask | EnterWindowMask | >> ????????????????? LeaveWindowMask | VisibilityChangeMask); >> @@ -680,6 +681,21 @@ >> ???? statusWindow->fontset = XCreateFontSet(dpy, >> >> "-*-*-medium-r-normal-*-*-120-*-*-*-*", >> ??????????????????????????????????????????? &mclr, &mccr, &dsr); >> +??? { >> +??????? int cntFonts; >> +??????? for(cntFonts = 0; cntFonts < mccr; cntFonts++) { >> +??????????? fprintf(stderr, "[M][%d] %s\n", cntFonts, mclr[cntFonts]); >> +??????? } >> +??? } >> +??? { >> +??????? XFontStruct **font_struct_list; >> +??????? char **font_name_list; >> +??????? int cntFonts; >> +??????? int numFonts = XFontsOfFontSet(statusWindow->fontset, >> &font_struct_list, &font_name_list); >> +??????? for(cntFonts = 0; cntFonts < numFonts; cntFonts++) { >> +??????????? fprintf(stderr, "[L][%d] %s\n", cntFonts, >> font_name_list[cntFonts]); >> +??????? } >> +??? } >> ???? /* In case we didn't find the font set, release the list of >> missing characters */ >> ???? if (mccr > 0) { >> ???????? XFreeStringList(mclr); >> ======= >> >> I tested it on RHEL7. >> I thought since window id was assigned, but it was gone on current code. >> ======= >> $ java -jar Notepad.jar >> status window id = 0x4000055 >> ... >> $ xwininfo -id 0x4000055 >> X Error: 9: Bad Drawable: 0x4000055 >> ? Request Major code: 14 >> ? Request serial number: 3 >> xwininfo: error: No such window with id 0x4000055. >> ======= >> >> ======= >> $ java -jar Notepad.jar >> status window id = 0x40000CA >> ... >> $ xwininfo -id 0x40000CA >> >> xwininfo: Window id: 0x40000ca (has no name) >> >> ? Absolute upper-left X:? 0 >> ? Absolute upper-left Y:? 600 >> ? Relative upper-left X:? 0 >> ? Relative upper-left Y:? 600 >> ? Width: 80 >> ? Height: 22 >> ? Depth: 24 >> ? Visual: 0x21 >> ? Visual Class: TrueColor >> ? Border width: 0 >> ? Class: InputOutput >> ? Colormap: 0x20 (installed) >> ? Bit Gravity State: ForgetGravity >> ? Window Gravity State: NorthWestGravity >> ? Backing Store State: NotUseful >> ? Save Under State: no >> ? Map State: IsUnMapped >> ? Override Redirect State: yes >> ? Corners:? +0+600? -944+600? -944-146? +0-146 >> ? -geometry 80x22+0+600 >> ======= >> >> According to main window: (Left side: without fix, right side: with fix) >> ======= >> xwininfo: Window id: 0x4000009 " (failure?? |?? xwininfo: Window id: >> 0x460007e " (failure >> >> ? Absolute upper-left X:? 4?????????????????????? Absolute upper-left X:? 4 >> ? Absolute upper-left Y:? 25????????????????????? Absolute upper-left Y:? 25 >> ? Relative upper-left X:? 0?????????????????????? Relative upper-left X:? 0 >> ? Relative upper-left Y:? 0?????????????????????? Relative upper-left Y:? 0 >> ? Width: 492????????????????????????????????????? Width: 492 >> ? Height: 571???????????????????????????????????? Height: 571 >> ? Depth: 24?????????????????????????????????????? Depth: 24 >> ? Visual: 0x169???????????????????????????? |???? Visual: 0x21 >> ? Visual Class: TrueColor???????????????????????? Visual Class: TrueColor >> ? Border width: 0???????????????????????????????? Border width: 0 >> ? Class: InputOutput????????????????????????????? Class: InputOutput >> ? Colormap: 0x4000008 (not installed)?????? |???? Colormap: 0x20 (installed) >> ? Bit Gravity State: NorthWestGravity???????????? Bit Gravity State: >> NorthWestGravity >> ? Window Gravity State: NorthWestGravity????????? Window Gravity >> State: NorthWestGravity >> ? Backing Store State: NotUseful????????????????? Backing Store State: NotUseful >> ? Save Under State: no??????????????????????????? Save Under State: no >> ? Map State: IsViewable?????????????????????????? Map State: IsViewable >> ? Override Redirect State: no???????????????????? Override Redirect State: no >> ? Corners:? +4+25? -528+25? -528-172? +4-1??????? Corners:? +4+25 >> -528+25? -528-172? +4-1 >> ? -geometry 492x571+0+0?????????????????????????? -geometry 492x571+0+0 >> ======= >> >> So main window's visual also changed by this fix. >> >>> Similarly for the fontset change .. this might change what others get. >>> The fontset spec. there seems very loose to me .. >> >> Without fix >> ======= >> $ java -jar Notepad.jar >> status window id = 0x4000055 >> [M][0] JISX0208.1983-0 >> [M][1] GB2312.1980-0 >> [L][0] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 >> [L][1] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 >> [L][2] -daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0 >> [L][3] -sony-fixed-medium-r-normal--16-120-100-100-c-80-jisx0201.1976-0 >> [L][4] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1 >> ======= >> >> With fix >> ======= >> $ java -jar Notepad.jar >> status window id = 0x40000CA >> [M][0] GB2312.1980-0 >> [L][0] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 >> [L][1] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 >> [L][2] -misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0 >> [L][3] -daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0 >> [L][4] -sony-fixed-medium-r-normal--16-120-100-100-c-80-jisx0201.1976-0 >> [L][5] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1 >> ======= >> >> [M] means "Missing" font, [L] means "Loaded". >> >> On 2018-06-20 23:14, Philip Race wrote: >>> My question has not been answered. I don't think this is ready to go in. >>> >>> -phil. >>> >>> On 6/20/18, 4:23 AM, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> New fixed code is in: >>>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.02/ >>>> >>>> Could you check fixed files again ? >>>> >>>> I only updated following part between webrev.01 and webrev.02 >>>> ====== >>>> diff -r 70a582d110a1 -r 6f04164a9d62 src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c ? Wed Jun 06 21:03:25 2018 +0900 >>>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c ? Wed Jun 20 16:54:24 2018 +0900 >>>> @@ -677,7 +677,7 @@ >>>> ???????? return NULL; >>>> ???? } >>>> ???? statusWindow->w = status; >>>> -??? //12-point font >>>> +??? //12, 13-point fonts >>>> ???? statusWindow->fontset = XCreateFontSet(dpy, >>>> "-*-*-medium-r-normal-*-*-120-*-*-*-*," \ >>>> "-*-*-medium-r-normal-*-*-130-*-*-*-*", >>>> ====== >>>> >>>> >>>> Please create bugid and handle it. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-06-20 04:59, Naoto Sato wrote: >>>>> Please change the comment in line 680, which should also mention 13 point font. >>>>> >>>>> Naoto >>>>> >>>>> On 6/19/18 12:54 PM, Naoto Sato wrote: >>>>>> Looks OK wrt awt_InputMethod.c change. >>>>>> >>>>>> Naoto >>>>>> >>>>>> On 6/19/18 11:32 AM, Phil Race wrote: >>>>>>> Where's the bug ID ? >>>>>>> >>>>>>> The review should have a bug ID in the subject line so we can all find it later ! >>>>>>> >>>>>>> Is this changing the default visual? for all WIndows, not just the IM status window? >>>>>>> I think we need to understand the implications before this can be accepted. >>>>>>> >>>>>>> Similarly for the fontset change .. this might change what others get. >>>>>>> The fontset spec. there seems very loose to me .. >>>>>>> >>>>>>> I think I18N-DEV should be asked about this too. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 06/19/2018 11:07 AM, Sergey Bylokhov wrote: >>>>>>>> Looks fine, if there are no other comments I'll push the fix using the new bugid. >>>>>>>> >>>>>>>> On 06/06/2018 17:54, Ichiroh Takiguchi wrote: >>>>>>>>> Hello Sergey. >>>>>>>>> Thank you for your review. >>>>>>>>> >>>>>>>>> Could you review following patch ? >>>>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ichiroh Takiguchi >>>>>>>>> IBM Japan, Ltd. >>>>>>>>> >>>>>>>>> On 2018-06-06 07:15, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Ichiroh. >>>>>>>>>> The approach looks fine, but maybe it is possible to decrees code >>>>>>>>>> duplication in findWithTemplate(). After the fix it will have two >>>>>>>>>> similar loops. >>>>>>>>>> >>>>>>>>>> On 24/05/2018 22:24, Ichiroh Takiguchi wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> IBM would like to contribute X11 default visual support for IM status window patch to OpenJDK project. >>>>>>>>>>> >>>>>>>>>>> Issue: >>>>>>>>>>> Java's Native IM status window is not displayed even if it's there. >>>>>>>>>>> Because of this issue, user cannot get proper visual feedback during key input operation. >>>>>>>>>>> We found this issue on Tiger VNC. >>>>>>>>>>> >>>>>>>>>>> Reason: >>>>>>>>>>> Java may pick up unexpected visual for Java's Native IM status window when? Xserver supports multiple visual. >>>>>>>>>>> >>>>>>>>>>> Workaround: >>>>>>>>>>> X11 default visual can be changed by FORCEDEFVIS environment variable, but it's not easy to find out default visual id. >>>>>>>>>>> >>>>>>>>>>> I'd like contribute following 2 files: >>>>>>>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c >>>>>>>>>>> (Change X11 visual setting) >>>>>>>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>>>>>>>> (Support 13 point X11 misc fonts (like k14 font for Japanese), since the fonts may defined for unscaled fonts.) >>>>>>>>>>> >>>>>>>>>>> webrev files are in >>>>>>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/ >>>>>>>>>>> >>>>>>>>>>> I appreciate any feedback please, and how I would go about obtaining a sponsor and contributor? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Ichiroh Takiguchi >>>>>>>>>>> IBM Japan, Ltd. >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Dec 1 02:03:45 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Nov 2018 18:03:45 -0800 Subject: [12] Review Request: 8214461 Some unused classes may be removed Message-ID: Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8214461 Webrev: http://cr.openjdk.java.net/~serb/8214461/webrev.00 We have a few internal classes/interfaces which currently unused and may be removed: - sun.awt.image.BadDepthException.java: looks like it was never used - sun.awt.TracedEventQueue.java: was used for logging - sun.awt.Graphics2Delegate.java: currently unused -- Best regards, Sergey. From krishna.addepalli at oracle.com Sat Dec 1 02:33:13 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Sat, 1 Dec 2018 08:03:13 +0530 Subject: [OpenJDK 2D-Dev] [12] Review Request: 8214461 Some unused classes may be removed In-Reply-To: References: Message-ID: <0B7C189D-D615-4024-BAAC-8E33C0EDE3C4@oracle.com> Looks good to me. Krishna > On 01-Dec-2018, at 7:33 AM, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk 12. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214461 > Webrev: http://cr.openjdk.java.net/~serb/8214461/webrev.00 > > We have a few internal classes/interfaces which currently unused and may be removed: > - sun.awt.image.BadDepthException.java: looks like it was never used > - sun.awt.TracedEventQueue.java: was used for logging > - sun.awt.Graphics2Delegate.java: currently unused > > > -- > Best regards, Sergey. From matthias.baesken at sap.com Sat Dec 1 07:55:01 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Sat, 1 Dec 2018 07:55:01 +0000 Subject: RFR: [XS] 8214380: AwtDragSource function LoadCache misses a ReleaseLongArrayElements in special case In-Reply-To: References: <37762172-43ad-1103-eb21-258d421e75d8@oracle.com> , Message-ID: Thanks. Can I have a second Review please? > Am 01.12.2018 um 01:20 schrieb Sergey Bylokhov : > > Looks fine. > >> On 30/11/2018 05:22, Baesken, Matthias wrote: >> Hi Sergey, I prepared a second webrev : >> http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.1/ >> - removed the unused isCopy >> - added a NULL check after GetLongArrayElements >> Best regards, Matthias >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Donnerstag, 29. November 2018 10:01 >>> To: 'Sergey Bylokhov' ; 'awt- >>> dev at openjdk.java.net' >>> Subject: RE: RFR: [XS] 8214380: AwtDragSource function >>> LoadCache misses a ReleaseLongArrayElements in special case >>> >>> Btw when looking at the coding, I wonder why we save the copy-state in >>> isCopy : >>> >>> Docu : "If isCopy is not NULL, then *isCopy is set to JNI_TRUE if a copy is >>> made; or it is set to JNI_FALSE if no copy is made" >>> >>> 397 jboolean isCopy; >>> 398 jlong *lFormats = env->GetLongArrayElements(formats, &isCopy), >>> >>> But then we do not use it afterwards , so should we better call it with >>> NULL instead? >>> >>> Regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Baesken, Matthias >>>> Sent: Donnerstag, 29. November 2018 09:17 >>>> To: 'Sergey Bylokhov' ; awt- >>>> dev at openjdk.java.net >>>> Subject: RE: RFR: [XS] 8214380: AwtDragSource function >>>> LoadCache misses a ReleaseLongArrayElements in special case >>>> >>>> Hi Sergey, I think it is (at least) a good practice to NULL - check the result >>>> of env->GetLongArrayElements . >>>> Probably it should be done right after the >>>> >>>> jlong *lFormats = env->GetLongArrayElements(formats, &isCopy), >>>> >>>> call. >>>> See jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c for >>>> examples of usages of the function (with NULL checks) . >>>> >>>> Or see the documentation at >>>> >>> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/function >>>> s.html >>>> Where we find : >>>> >>>> >>>> GetArrayElements Routines >>>> .... >>>> PARAMETERS: >>>> >>>> env: the JNI interface pointer. >>>> array: a Java string object. >>>> isCopy: a pointer to a boolean. >>>> >>>> >>>> RETURNS: >>>> >>>> Returns a pointer to the array elements, ****or NULL if the operation >>>> fails.**** >>>> >>>> >>>> So returning NULL might happen . >>>> >>>> Best regards, Matthias >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Sergey Bylokhov >>>>> Sent: Donnerstag, 29. November 2018 00:22 >>>>> To: Baesken, Matthias ; awt- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR: [XS] 8214380: AwtDragSource function >>>>> LoadCache misses a ReleaseLongArrayElements in special case >>>>> >>>>> Hi, Matthias. >>>>> >>>>> Do we need the null check in the fix, if "yes" then probably >>>>> the same check should be added before this line as well? >>>>> 465 env->ReleaseLongArrayElements(formats, saveFormats, 0); >>>>> >>>>>> On 28/11/2018 00:33, Baesken, Matthias wrote: >>>>>> Hello, please review this small fix. >>>>>> >>>>>> It adds a missing ReleaseLongArrayElements to >>>>>> >>>>>> void AwtDragSource::LoadCache(jlongArray formats) >>>>>> >>>>>> in an early special "pseudo return" (leave function via throw) case. >>>>>> >>>>>> Webrev/bug : >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.0/ >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8214380 >>>>>> >>>>>> Thanks, Matthias >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. > > > -- > Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Mon Dec 3 05:14:24 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Sun, 2 Dec 2018 21:14:24 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <2b0d65ff-002e-4923-835a-89ce24b2f607@default> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> Message-ID: <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. Otherwise the changes looks good to me. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Wednesday, October 17, 2018 1:04 AM To: Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Sergey, Per our conversation, I have made the following changes: 1. Add logging support to WindowsAccessBridge as well. 2. Added timestamp info in the log file. 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, September 18, 2018 3:26 AM To: Prasanta Sadhukhan ; Krishna Addepalli ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. On 14/09/2018 05:18, Prasanta Sadhukhan wrote: > one question: why nullptr is used? I see we used NULL in other places > in this file, why cant we use the same? > > Regards > Prasanta > On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >> >> Thanks for the comments. Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >> >> >> --Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 3:23 PM >> *To:* Krishna Addepalli ; >> awt-dev at openjdk.java.net >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> ok. The formatting is screwed up, needs to be rectified. Also l194, >> there should be a space before { >> >> Regards >> Prasantaa >> >> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >> >> Thanks for the review Prasanta. Although there is not much >> difference between using fprintf and vfprintf, I have changed all >> the calls to vfprintf. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >> >> >> Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 11:38 AM >> *To:* Krishna Addepalli >> ; awt-dev at openjdk.java.net >> >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> One thing, since you are passing va_list as the last parameter, >> shouldn't all fprintf be actually vfprintf? >> >> Regards >> Prasanta >> >> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >> >> Hi All, >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >> >> Webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >> >> >> Please review an enhancement for supporting the logging of >> Java Access Bridge, so that customers/users facing problems >> with Accessibility can turn on/off logging to debug problems >> with this feature. >> >> The proposed solution is to have the user/developer define an >> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >> with the path to the log file. >> >> The JavaAccessBridge will read the variable, and write to the >> file in the path provided. >> Note that the implementation is simplistic, and doesnot have >> any way to handle multiple applications, since it is a debug >> only feature. >> >> Thanks, >> >> Krishna >> > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Mon Dec 3 05:39:20 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Sun, 2 Dec 2018 21:39:20 -0800 (PST) Subject: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar In-Reply-To: <6c6313ff-3c2d-6fb2-9aad-c9bb68536727@oracle.com> References: <61fbe29e-22af-b5b2-47bc-14cd7853d5bc@oracle.com> <91344f31-9c1a-e5e0-a246-a92b36374ac6@oracle.com> <14494971-153c-d5d2-e4a4-ed078a444643@oracle.com> <667aceec-609b-49fd-a610-1d208c59031a@default> <69b22191-796e-a26a-c0e2-50b3e43d1b1a@oracle.com> <22f34125-4a68-57ed-c7fb-4e233a687007@oracle.com> <47c4f32a-c895-99d3-b8d2-90a1bcf65f58@oracle.com> <69542b48-24c3-7954-7ec7-7dfa38e16eef@oracle.com> <1f3b3a73-65ad-4ce7-5bda-269562b6fd7e@oracle.com> <0f8cb722-515b-4d99-9da5-0c4d0edfa7f8@default> <6c6313ff-3c2d-6fb2-9aad-c9bb68536727@oracle.com> Message-ID: <4bd0f766-e2d5-4307-94e8-6258943a60f9@default> Hi Sergey, The button and the progress bars are different types of component and there is no relation built between the 2 components(like parent-child relationship). Hence pressing the button component does not voice out the progress bar component's status. Since we concluded that there exists short cuts to voice out the status of the progress bar in each platform(ctrl+option+left/right/up/down) it is no more an issue and we closed this issue as "not an issue". Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Saturday, December 1, 2018 6:11 AM To: Shashidhara Veerabhadraiah ; Alexey Ivanov ; Krishna Addepalli Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net Subject: Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar Hi, Shashi. On 26/11/2018 01:15, Shashidhara Veerabhadraiah wrote: >> Hi Alexey, The accessible information is already set for the >> component in question and that is the reason it works with the >> accessibility short cut(without this fix). Did you check that VO announces when the ProgressBar is update its progress? When I checked it last time, when the demo is in progress("Start loading text" button was pressed) the VO did not read information about the new values of the progress bar. -- Best regards, Sergey. From takiguc at linux.vnet.ibm.com Mon Dec 3 08:22:58 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 03 Dec 2018 17:22:58 +0900 Subject: RFR: 8211267: StackOverflowError happened by TextField.setFont(...) & Add non interactive test case for JDK-8211267 In-Reply-To: References: <7638a441405abe3b5919baf2b6a75501@linux.vnet.ibm.com> Message-ID: <32e30403ea59baa0a52ddeff0fe41827@linux.vnet.ibm.com> Hello. Thanks, Sergey. I created new test case for JDK-8214298. I merged JDK-8211267 & JDK-8214298. I removed interactive test case and added JDK-8214298's code. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8211267 Change: https://cr.openjdk.java.net/~itakiguchi/8211267/webrev.02/ Thanks, Ichiroh Takiguchi On 2018-12-01 09:35, Sergey Bylokhov wrote: > Hello, > > I think that you can use invokeAndWait instead of invokeLater(), > which will wait while the code is executed on EDT, and I am not > sure that you need to interrupt the main thread of the test. > > On 26/11/2018 09:19, Ichiroh Takiguchi wrote: >> Hello. >> Could you review the fix ? >> >> Issue: >> JDK-8211267 requires non interactive test case >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214298 >> Change: https://cr.openjdk.java.net/~itakiguchi/8214298/webrev.00/ >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> From alexey.ivanov at oracle.com Mon Dec 3 08:46:30 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 3 Dec 2018 08:46:30 +0000 Subject: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar In-Reply-To: <4bd0f766-e2d5-4307-94e8-6258943a60f9@default> References: <61fbe29e-22af-b5b2-47bc-14cd7853d5bc@oracle.com> <91344f31-9c1a-e5e0-a246-a92b36374ac6@oracle.com> <14494971-153c-d5d2-e4a4-ed078a444643@oracle.com> <667aceec-609b-49fd-a610-1d208c59031a@default> <69b22191-796e-a26a-c0e2-50b3e43d1b1a@oracle.com> <22f34125-4a68-57ed-c7fb-4e233a687007@oracle.com> <47c4f32a-c895-99d3-b8d2-90a1bcf65f58@oracle.com> <69542b48-24c3-7954-7ec7-7dfa38e16eef@oracle.com> <1f3b3a73-65ad-4ce7-5bda-269562b6fd7e@oracle.com> <0f8cb722-515b-4d99-9da5-0c4d0edfa7f8@default> <6c6313ff-3c2d-6fb2-9aad-c9bb68536727@oracle.com> <4bd0f766-e2d5-4307-94e8-6258943a60f9@default> Message-ID: <9005a888-cdd5-1cfc-e299-476df868d932@oracle.com> Hi Shashi, Sergey's question was whether the change in progress bar state is announced by VO or not while the text is loading. So you click the button to start text loading and then move VO selection to progress bar. It should announce the current state and, as I understand, announce progress changes over time. Regards, Alexey On 03/12/2018 05:39, Shashidhara Veerabhadraiah wrote: > Hi Sergey, The button and the progress bars are different types of component and there is no relation built between the 2 components(like parent-child relationship). Hence pressing the button component does not voice out the progress bar component's status. > Since we concluded that there exists short cuts to voice out the status of the progress bar in each platform(ctrl+option+left/right/up/down) it is no more an issue and we closed this issue as "not an issue". > > Thanks and regards, > Shashi > > -----Original Message----- > From: Sergey Bylokhov > Sent: Saturday, December 1, 2018 6:11 AM > To: Shashidhara Veerabhadraiah ; Alexey Ivanov ; Krishna Addepalli > Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net > Subject: Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar > > Hi, Shashi. > On 26/11/2018 01:15, Shashidhara Veerabhadraiah wrote: >>> Hi Alexey, The accessible information is already set for the >>> component in question and that is the reason it works with the >>> accessibility short cut(without this fix). > Did you check that VO announces when the ProgressBar is update its progress? > When I checked it last time, when the demo is in progress("Start loading text" button was pressed) the VO did not read information about the new values of the progress bar. > > -- > Best regards, Sergey. From krishna.addepalli at oracle.com Mon Dec 3 14:35:02 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 3 Dec 2018 06:35:02 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> Message-ID: <29319819-282f-49f0-9b0f-e1439ef44acf@default> Hi Shashi, 1. It is strange that the Windows Log file did not have any extension and the Java log file had an extension. The code for reading the environment variable content and creating the appropriate file is common between JavaAccessBridge.dll and WindowsAccessBridge.dll, so if one is able to read the environment variable with the extension, so should the other. The scenario where I see this could be broken could be that, you update the environment variable, and not restart either the JAWs application or the Cygwin/Java IDE from which you run the java program. 2. Since this is a debug feature, it is expected that the developers are aware of the log file getting written out from JAWs side as well (WindowsAccessBridge.dll). Nevertheless, I agree with your point that if the JAWs is active for long time, the log file can get pretty big. But, even if we add another environment variable, the problem remains the same. So, I think we can only add a note saying that it is recommended to close JAWs after each debug session. Thanks, Krishna -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Monday, December 3, 2018 10:44 AM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. Otherwise the changes looks good to me. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Wednesday, October 17, 2018 1:04 AM To: Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Sergey, Per our conversation, I have made the following changes: 1. Add logging support to WindowsAccessBridge as well. 2. Added timestamp info in the log file. 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, September 18, 2018 3:26 AM To: Prasanta Sadhukhan ; Krishna Addepalli ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. On 14/09/2018 05:18, Prasanta Sadhukhan wrote: > one question: why nullptr is used? I see we used NULL in other places > in this file, why cant we use the same? > > Regards > Prasanta > On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >> >> Thanks for the comments. Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >> >> >> --Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 3:23 PM >> *To:* Krishna Addepalli ; >> awt-dev at openjdk.java.net >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> ok. The formatting is screwed up, needs to be rectified. Also l194, >> there should be a space before { >> >> Regards >> Prasantaa >> >> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >> >> Thanks for the review Prasanta. Although there is not much >> difference between using fprintf and vfprintf, I have changed all >> the calls to vfprintf. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >> >> >> Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 11:38 AM >> *To:* Krishna Addepalli >> ; awt-dev at openjdk.java.net >> >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> One thing, since you are passing va_list as the last parameter, >> shouldn't all fprintf be actually vfprintf? >> >> Regards >> Prasanta >> >> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >> >> Hi All, >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >> >> Webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >> >> >> Please review an enhancement for supporting the logging of >> Java Access Bridge, so that customers/users facing problems >> with Accessibility can turn on/off logging to debug problems >> with this feature. >> >> The proposed solution is to have the user/developer define an >> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >> with the path to the log file. >> >> The JavaAccessBridge will read the variable, and write to the >> file in the path provided. >> Note that the implementation is simplistic, and doesnot have >> any way to handle multiple applications, since it is a debug >> only feature. >> >> Thanks, >> >> Krishna >> > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Mon Dec 3 17:16:18 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 3 Dec 2018 17:16:18 +0000 (UTC) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <29319819-282f-49f0-9b0f-e1439ef44acf@default> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> Message-ID: <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> Hi Krishna, Sure I will check it once again tomorrow for the logger file extension as I am not able to get the JAWS license from home network. Another problem that I see is that the way we use the environment variable. We need to set the flag pointing to a single text file it will end up in creating 2 text files from 2 different sources but both the names does not match the environment variable value. So it is good to separate them out or you can clearly mention the notes in detail. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Monday, December 3, 2018 8:05 PM To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Shashi, 1. It is strange that the Windows Log file did not have any extension and the Java log file had an extension. The code for reading the environment variable content and creating the appropriate file is common between JavaAccessBridge.dll and WindowsAccessBridge.dll, so if one is able to read the environment variable with the extension, so should the other. The scenario where I see this could be broken could be that, you update the environment variable, and not restart either the JAWs application or the Cygwin/Java IDE from which you run the java program. 2. Since this is a debug feature, it is expected that the developers are aware of the log file getting written out from JAWs side as well (WindowsAccessBridge.dll). Nevertheless, I agree with your point that if the JAWs is active for long time, the log file can get pretty big. But, even if we add another environment variable, the problem remains the same. So, I think we can only add a note saying that it is recommended to close JAWs after each debug session. Thanks, Krishna -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Monday, December 3, 2018 10:44 AM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. Otherwise the changes looks good to me. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Wednesday, October 17, 2018 1:04 AM To: Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Sergey, Per our conversation, I have made the following changes: 1. Add logging support to WindowsAccessBridge as well. 2. Added timestamp info in the log file. 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, September 18, 2018 3:26 AM To: Prasanta Sadhukhan ; Krishna Addepalli ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. On 14/09/2018 05:18, Prasanta Sadhukhan wrote: > one question: why nullptr is used? I see we used NULL in other places > in this file, why cant we use the same? > > Regards > Prasanta > On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >> >> Thanks for the comments. Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >> >> >> --Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 3:23 PM >> *To:* Krishna Addepalli ; >> awt-dev at openjdk.java.net >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> ok. The formatting is screwed up, needs to be rectified. Also l194, >> there should be a space before { >> >> Regards >> Prasantaa >> >> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >> >> Thanks for the review Prasanta. Although there is not much >> difference between using fprintf and vfprintf, I have changed all >> the calls to vfprintf. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >> >> >> Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 11:38 AM >> *To:* Krishna Addepalli >> ; awt-dev at openjdk.java.net >> >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> One thing, since you are passing va_list as the last parameter, >> shouldn't all fprintf be actually vfprintf? >> >> Regards >> Prasanta >> >> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >> >> Hi All, >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >> >> Webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >> >> >> Please review an enhancement for supporting the logging of >> Java Access Bridge, so that customers/users facing problems >> with Accessibility can turn on/off logging to debug problems >> with this feature. >> >> The proposed solution is to have the user/developer define an >> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >> with the path to the log file. >> >> The JavaAccessBridge will read the variable, and write to the >> file in the path provided. >> Note that the implementation is simplistic, and doesnot have >> any way to handle multiple applications, since it is a debug >> only feature. >> >> Thanks, >> >> Krishna >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Dec 3 19:37:14 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 3 Dec 2018 11:37:14 -0800 Subject: [12] Review Request: 8212680 (JDK12b14/Solaris-sparc) SplashScreen::getSplashScreen call fails with ULE: "libsplashscreen.so: ld.so.1: java: fatal: libz.so.1: open failed: No such file or directory" In-Reply-To: References: <9a22393a-08e7-7686-26a6-fd893631d073@oracle.com> <5BFF6A1A.6030504@oracle.com> <5C0084CF.5080207@oracle.com> <5C00AE7E.2050307@oracle.com> Message-ID: <51325e38-361f-5140-b175-917db16ad3b3@oracle.com> Hi, Magnus. > This looks good to me too, but as I said before, I still think you should write a note about this change in UPDATING.txt, so this fix is not lost if pnglibconf.h were to be re-generated. All lines which started by "/*#undef " in the "pnglibconf.h" are commented manually and this is an existed note in the UPDATING.txt: ========= 4) Special and careful handling of pnglibconf.h OpenJDK has a heavily modified copy of pnglibconf.h. This is the trickiest part of the whole exercise. This file is generated by png at build time. Except for the dates and version, you should generally not need to update OpenJDK's copy unless the new version of PNG has added rquired new #defines that cause problems building. You can run configure && make on the downloaded source and compare but we do not want to enable any of the WRITE support, and there are many more modifications as well. So do NOT just copy in a file from the new libpng. So lots of reasons to not copy over the new version, and instead just tweak the existing one. ========= -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Mon Dec 3 20:29:38 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 21:29:38 +0100 Subject: [12] Review Request: 8212680 (JDK12b14/Solaris-sparc) SplashScreen::getSplashScreen call fails with ULE: "libsplashscreen.so: ld.so.1: java: fatal: libz.so.1: open failed: No such file or directory" In-Reply-To: <51325e38-361f-5140-b175-917db16ad3b3@oracle.com> References: <9a22393a-08e7-7686-26a6-fd893631d073@oracle.com> <5BFF6A1A.6030504@oracle.com> <5C0084CF.5080207@oracle.com> <5C00AE7E.2050307@oracle.com> <51325e38-361f-5140-b175-917db16ad3b3@oracle.com> Message-ID: <06FE7679-16FC-4646-B0C9-D5CC97B154AF@oracle.com> Fair enough, that warning is enough. You don't need to add anything else. I'm ok with the patch. /Magnus > 3 dec. 2018 kl. 20:37 skrev Sergey Bylokhov : > > Hi, Magnus. > >> This looks good to me too, but as I said before, I still think you should write a note about this change in UPDATING.txt, so this fix is not lost if pnglibconf.h were to be re-generated. > All lines which started by "/*#undef " in the "pnglibconf.h" are commented manually > and this is an existed note in the UPDATING.txt: > ========= > 4) Special and careful handling of pnglibconf.h > OpenJDK has a heavily modified copy of pnglibconf.h. > This is the trickiest part of the whole exercise. > This file is generated by png at build time. > Except for the dates and version, you should generally not need to update > OpenJDK's copy unless the new version of PNG has added rquired new #defines > that cause problems building. > You can run configure && make on the downloaded source and compare but we > do not want to enable any of the WRITE support, and there are many more > modifications as well. > So do NOT just copy in a file from the new libpng. > So lots of reasons to not copy over the new version, > and instead just tweak the existing one. > ========= > > -- > Best regards, Sergey. From takiguc at linux.vnet.ibm.com Tue Dec 4 02:22:37 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 04 Dec 2018 11:22:37 +0900 Subject: RFR: 8213232 Unix/X11 setCompositionEnableNative issue In-Reply-To: <9ad6f2166ea8eabcf7391feccf9d8915@linux.vnet.ibm.com> References: <9ad6f2166ea8eabcf7391feccf9d8915@linux.vnet.ibm.com> Message-ID: <0a651f1099a96e314573b6b8c9f60e6c@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8213232 Change: https://cr.openjdk.java.net/~itakiguchi/8213232/webrev.00/ This issue is related by wrong usage of XNPreeditState on XSetICValues(). Because of wrong usage, UnsupportedOperationException exception happened with Xlib bundled input method. Test instructions is in JDK-8213232. I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-06-19 02:15, Ichiroh Takiguchi wrote: > Hello, > IBM would like to contribute Unix/X11 setCompositionEnableNative issue > patch to OpenJDK project. > > Issue: > To turn on or turn off IME via Java, XNPreeditState should be used > with XSetValues(). > But it should be nested via XVaCreateNestedList() since XNPreeditState > is a part of XNPreeditAttributes. > Current code is, like: > - ret = XSetICValues(pX11IMData->current_ic, XNPreeditState, > - (enable ? XIMPreeditEnable : > XIMPreeditDisable), NULL); > But it should be, like: > + pr_atrb = XVaCreateNestedList(0, > + XNPreeditState, (enable ? XIMPreeditEnable : > XIMPreeditDisable), > + NULL); > + ret = XSetICValues(pX11IMData->current_ic, XNPreeditAttributes, > pr_atrb, NULL); > > On Linux platform, the issue can check with following test program and > kinput2 XIM server and > Wnn8 for Linux/BSD (htt). > ================== > import java.awt.*; > import java.awt.event.*; > import javax.swing.*; > > public class CompositionEnabledTest extends JFrame { > CompositionEnabledTest() { > Container c = getContentPane(); > c.setLayout(new GridLayout(0,2)); > JButton btn; > JTextField tf; > btn = new JButton("Undefined"); > c.add(btn); > tf = new JTextField("Undefined"); > c.add(tf); > btn = new JButton("Disabled"); > btn.addFocusListener(new MyFocusListener(false)); > c.add(btn); > tf = new JTextField("Disabled"); > tf.addFocusListener(new MyFocusListener(false)); > c.add(tf); > btn = new JButton("Enabled"); > btn.addFocusListener(new MyFocusListener(true)); > c.add(btn); > tf = new JTextField("Enabled"); > tf.addFocusListener(new MyFocusListener(true)); > c.add(tf); > setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > pack(); > setVisible(true); > } > class MyFocusListener implements FocusListener { > boolean state; > MyFocusListener(boolean state) { > this.state = state; > } > public void focusGained(FocusEvent fe) { > fe.getComponent().getInputContext().setCompositionEnabled(state); > } > public void focusLost(FocusEvent fe) { } > } > public static void main(String[] args) { > new CompositionEnabledTest(); > } > } > ================== > > Click JTextField and JButton, then XIM server status may be changed. > If XIM server does not support XNPreeditState, it does not work. > > I'd like contribute following 3 files: > M src/java.desktop/share/classes/sun/awt/im/InputContext.java > M src/java.desktop/unix/classes/sun/awt/X11InputMethod.java > M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > > http://cr.openjdk.java.net/~aleonard/set_composition_enabled/webrev.00/ > > I appreciate any feedback please, and how I would go about obtaining a > sponsor and contributor? > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. From shashidhara.veerabhadraiah at oracle.com Tue Dec 4 08:58:46 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 4 Dec 2018 00:58:46 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> Message-ID: Hi Krishna, Environment variable set to a file name(with an extension), did created a file with that extension. But without it, the extensions were blank. So I suggest to default to .log if there is no extension set by the user(then the system can choose) as it is a log of debug prints and the file can be opened instantly. Thanks and regards, Shashi -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Monday, December 3, 2018 10:46 PM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, Sure I will check it once again tomorrow for the logger file extension as I am not able to get the JAWS license from home network. Another problem that I see is that the way we use the environment variable. We need to set the flag pointing to a single text file it will end up in creating 2 text files from 2 different sources but both the names does not match the environment variable value. So it is good to separate them out or you can clearly mention the notes in detail. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Monday, December 3, 2018 8:05 PM To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Shashi, 1. It is strange that the Windows Log file did not have any extension and the Java log file had an extension. The code for reading the environment variable content and creating the appropriate file is common between JavaAccessBridge.dll and WindowsAccessBridge.dll, so if one is able to read the environment variable with the extension, so should the other. The scenario where I see this could be broken could be that, you update the environment variable, and not restart either the JAWs application or the Cygwin/Java IDE from which you run the java program. 2. Since this is a debug feature, it is expected that the developers are aware of the log file getting written out from JAWs side as well (WindowsAccessBridge.dll). Nevertheless, I agree with your point that if the JAWs is active for long time, the log file can get pretty big. But, even if we add another environment variable, the problem remains the same. So, I think we can only add a note saying that it is recommended to close JAWs after each debug session. Thanks, Krishna -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Monday, December 3, 2018 10:44 AM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. Otherwise the changes looks good to me. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Wednesday, October 17, 2018 1:04 AM To: Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Sergey, Per our conversation, I have made the following changes: 1. Add logging support to WindowsAccessBridge as well. 2. Added timestamp info in the log file. 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, September 18, 2018 3:26 AM To: Prasanta Sadhukhan ; Krishna Addepalli ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. On 14/09/2018 05:18, Prasanta Sadhukhan wrote: > one question: why nullptr is used? I see we used NULL in other places > in this file, why cant we use the same? > > Regards > Prasanta > On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >> >> Thanks for the comments. Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >> >> >> --Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 3:23 PM >> *To:* Krishna Addepalli ; >> awt-dev at openjdk.java.net >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> ok. The formatting is screwed up, needs to be rectified. Also l194, >> there should be a space before { >> >> Regards >> Prasantaa >> >> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >> >> Thanks for the review Prasanta. Although there is not much >> difference between using fprintf and vfprintf, I have changed all >> the calls to vfprintf. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >> >> >> Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 11:38 AM >> *To:* Krishna Addepalli >> ; awt-dev at openjdk.java.net >> >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> One thing, since you are passing va_list as the last parameter, >> shouldn't all fprintf be actually vfprintf? >> >> Regards >> Prasanta >> >> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >> >> Hi All, >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >> >> Webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >> >> >> Please review an enhancement for supporting the logging of >> Java Access Bridge, so that customers/users facing problems >> with Accessibility can turn on/off logging to debug problems >> with this feature. >> >> The proposed solution is to have the user/developer define an >> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >> with the path to the log file. >> >> The JavaAccessBridge will read the variable, and write to the >> file in the path provided. >> Note that the implementation is simplistic, and doesnot have >> any way to handle multiple applications, since it is a debug >> only feature. >> >> Thanks, >> >> Krishna >> > -- Best regards, Sergey. From thomas.stuefe at gmail.com Tue Dec 4 09:12:20 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Dec 2018 10:12:20 +0100 Subject: FW: RFR: [XS] 8214380: AwtDragSource function LoadCache misses a ReleaseLongArrayElements in special case In-Reply-To: <3724504293714cc9a95d137e9a7b6bbf@sap.com> References: <37762172-43ad-1103-eb21-258d421e75d8@oracle.com> <3724504293714cc9a95d137e9a7b6bbf@sap.com> Message-ID: Hi Matthias, looks fine to me as well, though I wonder whether this lformats/saveformats coding could be simplified by simply using lformats[i] in the loops to access the array elements and getting rid of saveformats. But this has nothing to do with your patch. Cheers, Thomas On Tue, Dec 4, 2018 at 10:09 AM Stuefe, Thomas wrote: > > > > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 4. Dezember 2018 09:01 > To: Langer, Christoph ; Stuefe, Thomas ; Lindenmaier, Goetz > Subject: FW: RFR: [XS] 8214380: AwtDragSource function LoadCache misses a ReleaseLongArrayElements in special case > > Hallo, kann jemand noch ein 2. Review beitragen ? > > Danke und Gru?, Matthias > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Samstag, 1. Dezember 2018 01:18 > To: Baesken, Matthias ; awt-dev at openjdk.java.net > Subject: Re: RFR: [XS] 8214380: AwtDragSource function LoadCache misses a ReleaseLongArrayElements in special case > > Looks fine. > > On 30/11/2018 05:22, Baesken, Matthias wrote: > > Hi Sergey, I prepared a second webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.1/ > > > > - removed the unused isCopy > > - added a NULL check after GetLongArrayElements > > > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: Baesken, Matthias > >> Sent: Donnerstag, 29. November 2018 10:01 > >> To: 'Sergey Bylokhov' ; 'awt- > >> dev at openjdk.java.net' > >> Subject: RE: RFR: [XS] 8214380: AwtDragSource function > >> LoadCache misses a ReleaseLongArrayElements in special case > >> > >> Btw when looking at the coding, I wonder why we save the copy-state in > >> isCopy : > >> > >> Docu : "If isCopy is not NULL, then *isCopy is set to JNI_TRUE if a copy is > >> made; or it is set to JNI_FALSE if no copy is made" > >> > >> 397 jboolean isCopy; > >> 398 jlong *lFormats = env->GetLongArrayElements(formats, &isCopy), > >> > >> But then we do not use it afterwards , so should we better call it with > >> NULL instead? > >> > >> Regards, Matthias > >> > >> > >>> -----Original Message----- > >>> From: Baesken, Matthias > >>> Sent: Donnerstag, 29. November 2018 09:17 > >>> To: 'Sergey Bylokhov' ; awt- > >>> dev at openjdk.java.net > >>> Subject: RE: RFR: [XS] 8214380: AwtDragSource function > >>> LoadCache misses a ReleaseLongArrayElements in special case > >>> > >>> Hi Sergey, I think it is (at least) a good practice to NULL - check the result > >>> of env->GetLongArrayElements . > >>> Probably it should be done right after the > >>> > >>> jlong *lFormats = env->GetLongArrayElements(formats, &isCopy), > >>> > >>> call. > >>> See jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c for > >>> examples of usages of the function (with NULL checks) . > >>> > >>> Or see the documentation at > >>> > >> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/function > >>> s.html > >>> Where we find : > >>> > >>> > >>> GetArrayElements Routines > >>> .... > >>> PARAMETERS: > >>> > >>> env: the JNI interface pointer. > >>> array: a Java string object. > >>> isCopy: a pointer to a boolean. > >>> > >>> > >>> RETURNS: > >>> > >>> Returns a pointer to the array elements, ****or NULL if the operation > >>> fails.**** > >>> > >>> > >>> So returning NULL might happen . > >>> > >>> Best regards, Matthias > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Sergey Bylokhov > >>>> Sent: Donnerstag, 29. November 2018 00:22 > >>>> To: Baesken, Matthias ; awt- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR: [XS] 8214380: AwtDragSource function > >>>> LoadCache misses a ReleaseLongArrayElements in special case > >>>> > >>>> Hi, Matthias. > >>>> > >>>> Do we need the null check in the fix, if "yes" then probably > >>>> the same check should be added before this line as well? > >>>> 465 env->ReleaseLongArrayElements(formats, saveFormats, 0); > >>>> > >>>> On 28/11/2018 00:33, Baesken, Matthias wrote: > >>>>> Hello, please review this small fix. > >>>>> > >>>>> It adds a missing ReleaseLongArrayElements to > >>>>> > >>>>> void AwtDragSource::LoadCache(jlongArray formats) > >>>>> > >>>>> in an early special "pseudo return" (leave function via throw) case. > >>>>> > >>>>> Webrev/bug : > >>>>> > >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8214380.0/ > >>>>> > >>>>> https://bugs.openjdk.java.net/browse/JDK-8214380 > >>>>> > >>>>> Thanks, Matthias > >>>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, Sergey. > > > -- > Best regards, Sergey. > From krishna.addepalli at oracle.com Tue Dec 4 11:14:01 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 4 Dec 2018 03:14:01 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> Message-ID: <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> Hi Shashi, Thanks for the comments, here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev05 Krishna -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Tuesday, December 4, 2018 2:29 PM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, Environment variable set to a file name(with an extension), did created a file with that extension. But without it, the extensions were blank. So I suggest to default to .log if there is no extension set by the user(then the system can choose) as it is a log of debug prints and the file can be opened instantly. Thanks and regards, Shashi -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Monday, December 3, 2018 10:46 PM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, Sure I will check it once again tomorrow for the logger file extension as I am not able to get the JAWS license from home network. Another problem that I see is that the way we use the environment variable. We need to set the flag pointing to a single text file it will end up in creating 2 text files from 2 different sources but both the names does not match the environment variable value. So it is good to separate them out or you can clearly mention the notes in detail. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Monday, December 3, 2018 8:05 PM To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Shashi, 1. It is strange that the Windows Log file did not have any extension and the Java log file had an extension. The code for reading the environment variable content and creating the appropriate file is common between JavaAccessBridge.dll and WindowsAccessBridge.dll, so if one is able to read the environment variable with the extension, so should the other. The scenario where I see this could be broken could be that, you update the environment variable, and not restart either the JAWs application or the Cygwin/Java IDE from which you run the java program. 2. Since this is a debug feature, it is expected that the developers are aware of the log file getting written out from JAWs side as well (WindowsAccessBridge.dll). Nevertheless, I agree with your point that if the JAWs is active for long time, the log file can get pretty big. But, even if we add another environment variable, the problem remains the same. So, I think we can only add a note saying that it is recommended to close JAWs after each debug session. Thanks, Krishna -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Monday, December 3, 2018 10:44 AM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. Otherwise the changes looks good to me. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Wednesday, October 17, 2018 1:04 AM To: Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Sergey, Per our conversation, I have made the following changes: 1. Add logging support to WindowsAccessBridge as well. 2. Added timestamp info in the log file. 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, September 18, 2018 3:26 AM To: Prasanta Sadhukhan ; Krishna Addepalli ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. On 14/09/2018 05:18, Prasanta Sadhukhan wrote: > one question: why nullptr is used? I see we used NULL in other places > in this file, why cant we use the same? > > Regards > Prasanta > On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >> >> Thanks for the comments. Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >> >> >> --Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 3:23 PM >> *To:* Krishna Addepalli ; >> awt-dev at openjdk.java.net >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> ok. The formatting is screwed up, needs to be rectified. Also l194, >> there should be a space before { >> >> Regards >> Prasantaa >> >> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >> >> Thanks for the review Prasanta. Although there is not much >> difference between using fprintf and vfprintf, I have changed all >> the calls to vfprintf. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >> >> >> Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 11:38 AM >> *To:* Krishna Addepalli >> ; awt-dev at openjdk.java.net >> >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> One thing, since you are passing va_list as the last parameter, >> shouldn't all fprintf be actually vfprintf? >> >> Regards >> Prasanta >> >> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >> >> Hi All, >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >> >> Webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >> >> >> Please review an enhancement for supporting the logging of >> Java Access Bridge, so that customers/users facing problems >> with Accessibility can turn on/off logging to debug problems >> with this feature. >> >> The proposed solution is to have the user/developer define an >> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >> with the path to the log file. >> >> The JavaAccessBridge will read the variable, and write to the >> file in the path provided. >> Note that the implementation is simplistic, and doesnot have >> any way to handle multiple applications, since it is a debug >> only feature. >> >> Thanks, >> >> Krishna >> > -- Best regards, Sergey. From takiguc at linux.vnet.ibm.com Tue Dec 4 16:53:18 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 05 Dec 2018 01:53:18 +0900 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> Message-ID: <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> Hello again. Could you give me review comment and/or suggestion ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ Thanks, Ichiroh Takiguchi On 2018-11-26 21:27, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 > Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ > > Test instructions and screen shots are in JDK-8212676. > > GUI environment for AIX platform still needs CDE support. > This fix is required to avoid unexpected working behavior on AIX > platform. > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >> Hello. >> >> This fix is really required for AIX's GUI. >> System color setting and window manager's working behavior are very >> important. >> >> I appreciate any feedback, and how I would go about obtaining a >> sponsor and contributor ? >> >> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> webrev file was extracted. >>> Please see >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>> >>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>> Hello Phil. >>>> >>>> Webrev.zip file is stored into >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>> >>>> Test programs are also stored: >>>> No testcase is available for FontUtilities.java and >>>> XDecoratedPeer.java. >>>> >>>> MotifColorUtilities.java >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>> Run SystemColorTest2, system colors should be displayed >>>> AIX sample is >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>> >>>> XWM.java >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>> On AIX CDE, isMotif and isCDE were true. >>>> On AIX MWM, every entry is false. >>>> >>>> XWindowPeer.java >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>> frame). >>>> Window focus should not be changed because of "click on focus" >>>> feature. >>>> But input focus is moved to "Non-Focusable" window. >>>> >>>> >>>> On 2018-05-18 01:00, Phil Race wrote: >>>>> I think we'd need to see the actual proposed changes and understand >>>>> the implications >>>>> for ongoing support as we no longer support any platform which has >>>>> a >>>>> CDE desktop. >>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out >>>>> such support rather >>>>> than adding to it. >>>>> >>>>> -phil. >>>>> >>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>> Hello, >>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>> Manager) support to OpenJDK project. >>>>>> >>>>>> I'd like contribute following 5 files: >>>>>> >>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>> M >>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>> Color) [1] >>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>> XMapRaised/XMapWindow) >>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>> (Detect MWM on AIX platform) >>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>>> DTWM/MWM does not have enough features for ICCCM) >>>>>> >>>>>> I appreciate any feedback please, and how I would go about >>>>>> obtaining a sponsor and contributor ? >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>>>> [1] >>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>> From philip.race at oracle.com Tue Dec 4 18:06:52 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 4 Dec 2018 10:06:52 -0800 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> Message-ID: <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> I haven't evaluated the merits of this proposal but this https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html is not the right place to support a flag used in all these X11 files. And why is i18n-dev on the review ? I can't see any I18N related changes. -phil. On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote: > Hello again. > > Could you give me review comment and/or suggestion ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676 > Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ > > Thanks, > Ichiroh Takiguchi > > On 2018-11-26 21:27, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >> >> Test instructions and screen shots are in JDK-8212676. >> >> GUI environment for AIX platform still needs CDE support. >> This fix is required to avoid unexpected working behavior on AIX >> platform. >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> This fix is really required for AIX's GUI. >>> System color setting and window manager's working behavior are very >>> important. >>> >>> I appreciate any feedback, and how I would go about obtaining a >>> sponsor and contributor ? >>> >>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>>> Hello Phil. >>>> >>>> webrev file was extracted. >>>> Please see >>>> ? http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>>> >>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>>> Hello Phil. >>>>> >>>>> Webrev.zip file is stored into >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>>> >>>>> Test programs are also stored: >>>>> No testcase is available for FontUtilities.java and >>>>> XDecoratedPeer.java. >>>>> >>>>> MotifColorUtilities.java >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>>> Run SystemColorTest2, system colors should be displayed >>>>> AIX sample is >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>>> >>>>> XWM.java >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>>> On AIX CDE, isMotif and isCDE were true. >>>>> On AIX MWM, every entry is false. >>>>> >>>>> XWindowPeer.java >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>>> frame). >>>>> Window focus should not be changed because of "click on focus" >>>>> feature. >>>>> But input focus is moved to "Non-Focusable" window. >>>>> >>>>> >>>>> On 2018-05-18 01:00, Phil Race wrote: >>>>>> I think we'd need to see the actual proposed changes and understand >>>>>> the implications >>>>>> for ongoing support as we no longer support any platform which has a >>>>>> CDE desktop. >>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out >>>>>> such support rather >>>>>> than adding to it. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>>> Hello, >>>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>>> Manager) support to OpenJDK project. >>>>>>> >>>>>>> I'd like contribute following 5 files: >>>>>>> >>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>>> M >>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>>> Color) [1] >>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>>> XMapRaised/XMapWindow) >>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>>> (Detect MWM on AIX platform) >>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>>>> DTWM/MWM does not have enough features for ICCCM) >>>>>>> >>>>>>> I appreciate any feedback please, and how I would go about >>>>>>> obtaining a sponsor and contributor ? >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> IBM Japan, Ltd. >>>>>>> >>>>>>> [1] >>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>>> > From Sergey.Bylokhov at oracle.com Wed Dec 5 00:15:29 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 4 Dec 2018 16:15:29 -0800 Subject: RFR: 8211267: StackOverflowError happened by TextField.setFont(...) & Add non interactive test case for JDK-8211267 In-Reply-To: <32e30403ea59baa0a52ddeff0fe41827@linux.vnet.ibm.com> References: <7638a441405abe3b5919baf2b6a75501@linux.vnet.ibm.com> <32e30403ea59baa0a52ddeff0fe41827@linux.vnet.ibm.com> Message-ID: <0d789099-8975-58f3-ca25-2dad095fa95f@oracle.com> Looks fine. On 03/12/2018 00:22, Ichiroh Takiguchi wrote: > Hello. > > Thanks, Sergey. > I created new test case for JDK-8214298. > > I merged JDK-8211267 & JDK-8214298. > I removed interactive test case and added JDK-8214298's code. > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211267 > Change: https://cr.openjdk.java.net/~itakiguchi/8211267/webrev.02/ > > Thanks, > Ichiroh Takiguchi > > On 2018-12-01 09:35, Sergey Bylokhov wrote: >> Hello, >> >> I think that you can use invokeAndWait instead of invokeLater(), >> which will wait while the code is executed on EDT, and I am not >> sure that you need to interrupt the main thread of the test. >> >> On 26/11/2018 09:19, Ichiroh Takiguchi wrote: >>> Hello. >>> Could you review the fix ? >>> >>> Issue: >>> JDK-8211267 requires non interactive test case >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214298 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8214298/webrev.00/ >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Dec 5 00:42:44 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 4 Dec 2018 16:42:44 -0800 Subject: [12] Review Request: 8214823 Javadoc cleanup of java.awt.desktop package Message-ID: <929ad896-0e32-5031-2ae8-baf481eceb3f@oracle.com> Hello. Please review a javadoc "weekend cleanup" in jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8214823 Webrev: http://cr.openjdk.java.net/~serb/8214823/webrev.00 Description of the changes: - 80 column limit - description of the class/method/field should be followed by dot - @param, @return should not end with a dot, except a case when more than one sentences are used - empty line after description/before the first tag was added - unnecessary empty lines were removed - @param, @throws, @return should be aligned, to be more readable - some text can be rephrased Also in a few places the "final" keyword was removed from the parameters of methods in the interfaces, because it does not make any sense. -- Best regards, Sergey. From takiguc at linux.vnet.ibm.com Wed Dec 5 01:10:09 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 05 Dec 2018 10:10:09 +0900 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> Message-ID: Hello Phil. > I haven't evaluated the merits of this proposal but this > https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html > is not the right place to support a flag used in all these X11 files. Could you give me your recommendation ? > And why is i18n-dev on the review ? I can't see any I18N related > changes. I thought focus issue was related input method. AIX IM was activated even if focus was moved to non focusable window (middle window). [1] So I posted this issue into I18N, but it was not good. Actually, all key events were forwarded to middle window if user clicked inside of right window. [1] https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png Thanks, Ichiroh Takiguchi On 2018-12-05 03:06, Phil Race wrote: > I haven't evaluated the merits of this proposal but this > https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html > is not the right place to support a flag used in all these X11 files. > > And why is i18n-dev on the review ? I can't see any I18N related > changes. > > -phil. > > On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote: >> Hello again. >> >> Could you give me review comment and/or suggestion ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-11-26 21:27, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>> >>> Test instructions and screen shots are in JDK-8212676. >>> >>> GUI environment for AIX platform still needs CDE support. >>> This fix is required to avoid unexpected working behavior on AIX >>> platform. >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> This fix is really required for AIX's GUI. >>>> System color setting and window manager's working behavior are very >>>> important. >>>> >>>> I appreciate any feedback, and how I would go about obtaining a >>>> sponsor and contributor ? >>>> >>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>>>> Hello Phil. >>>>> >>>>> webrev file was extracted. >>>>> Please see >>>>> ? http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>>>> >>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>>>> Hello Phil. >>>>>> >>>>>> Webrev.zip file is stored into >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>>>> >>>>>> Test programs are also stored: >>>>>> No testcase is available for FontUtilities.java and >>>>>> XDecoratedPeer.java. >>>>>> >>>>>> MotifColorUtilities.java >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>>>> Run SystemColorTest2, system colors should be displayed >>>>>> AIX sample is >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>>>> >>>>>> XWM.java >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>>>> On AIX CDE, isMotif and isCDE were true. >>>>>> On AIX MWM, every entry is false. >>>>>> >>>>>> XWindowPeer.java >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>>>> frame). >>>>>> Window focus should not be changed because of "click on focus" >>>>>> feature. >>>>>> But input focus is moved to "Non-Focusable" window. >>>>>> >>>>>> >>>>>> On 2018-05-18 01:00, Phil Race wrote: >>>>>>> I think we'd need to see the actual proposed changes and >>>>>>> understand >>>>>>> the implications >>>>>>> for ongoing support as we no longer support any platform which >>>>>>> has a >>>>>>> CDE desktop. >>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping >>>>>>> out >>>>>>> such support rather >>>>>>> than adding to it. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>>>> Hello, >>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>>>> Manager) support to OpenJDK project. >>>>>>>> >>>>>>>> I'd like contribute following 5 files: >>>>>>>> >>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>>>> M >>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>>>> Color) [1] >>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>>>> XMapRaised/XMapWindow) >>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>>>> (Detect MWM on AIX platform) >>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>>>>> DTWM/MWM does not have enough features for ICCCM) >>>>>>>> >>>>>>>> I appreciate any feedback please, and how I would go about >>>>>>>> obtaining a sponsor and contributor ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ichiroh Takiguchi >>>>>>>> IBM Japan, Ltd. >>>>>>>> >>>>>>>> [1] >>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>>>> >> From philip.race at oracle.com Wed Dec 5 01:11:17 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 04 Dec 2018 17:11:17 -0800 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> Message-ID: <5C0725B5.3080907@oracle.com> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote: > Hello Phil. > >> I haven't evaluated the merits of this proposal but this >> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html >> >> is not the right place to support a flag used in all these X11 files. > Could you give me your recommendation ? Somewhere closer to the code that needs it. > >> And why is i18n-dev on the review ? I can't see any I18N related >> changes. > I thought focus issue was related input method. No. I mean input focus is necessary for input methods but focus does not automatically mean input methods are in play. -phil > AIX IM was activated even if focus was moved to non focusable window > (middle window). [1] > So I posted this issue into I18N, but it was not good. > Actually, all key events were forwarded to middle window if user > clicked inside of right window. > > [1] > https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png > > Thanks, > Ichiroh Takiguchi > > On 2018-12-05 03:06, Phil Race wrote: >> I haven't evaluated the merits of this proposal but this >> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html >> >> is not the right place to support a flag used in all these X11 files. >> >> And why is i18n-dev on the review ? I can't see any I18N related >> changes. >> >> -phil. >> >> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote: >>> Hello again. >>> >>> Could you give me review comment and/or suggestion ? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix ? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>>> >>>> Test instructions and screen shots are in JDK-8212676. >>>> >>>> GUI environment for AIX platform still needs CDE support. >>>> This fix is required to avoid unexpected working behavior on AIX >>>> platform. >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> This fix is really required for AIX's GUI. >>>>> System color setting and window manager's working behavior are >>>>> very important. >>>>> >>>>> I appreciate any feedback, and how I would go about obtaining a >>>>> sponsor and contributor ? >>>>> >>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>>>>> Hello Phil. >>>>>> >>>>>> webrev file was extracted. >>>>>> Please see >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>>>>> >>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>>>>> Hello Phil. >>>>>>> >>>>>>> Webrev.zip file is stored into >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>>>>> >>>>>>> Test programs are also stored: >>>>>>> No testcase is available for FontUtilities.java and >>>>>>> XDecoratedPeer.java. >>>>>>> >>>>>>> MotifColorUtilities.java >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>>>>> Run SystemColorTest2, system colors should be displayed >>>>>>> AIX sample is >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>>>>> >>>>>>> XWM.java >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>>>>> On AIX CDE, isMotif and isCDE were true. >>>>>>> On AIX MWM, every entry is false. >>>>>>> >>>>>>> XWindowPeer.java >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>>>>> frame). >>>>>>> Window focus should not be changed because of "click on focus" >>>>>>> feature. >>>>>>> But input focus is moved to "Non-Focusable" window. >>>>>>> >>>>>>> >>>>>>> On 2018-05-18 01:00, Phil Race wrote: >>>>>>>> I think we'd need to see the actual proposed changes and >>>>>>>> understand >>>>>>>> the implications >>>>>>>> for ongoing support as we no longer support any platform which >>>>>>>> has a >>>>>>>> CDE desktop. >>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping >>>>>>>> out >>>>>>>> such support rather >>>>>>>> than adding to it. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>>>>> Hello, >>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>>>>> Manager) support to OpenJDK project. >>>>>>>>> >>>>>>>>> I'd like contribute following 5 files: >>>>>>>>> >>>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>>>>> M >>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>>>>> >>>>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>>>>> Color) [1] >>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>>>>> XMapRaised/XMapWindow) >>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>>>>> (Detect MWM on AIX platform) >>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>>>>>> DTWM/MWM does not have enough features for ICCCM) >>>>>>>>> >>>>>>>>> I appreciate any feedback please, and how I would go about >>>>>>>>> obtaining a sponsor and contributor ? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ichiroh Takiguchi >>>>>>>>> IBM Japan, Ltd. >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>>>>> >>> > From TOSHIONA at jp.ibm.com Wed Dec 5 02:45:01 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Wed, 5 Dec 2018 11:45:01 +0900 Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting In-Reply-To: References: Message-ID: Hello, Can anyone support this proposal? I appreciate any suggestion or comment. issue: https://bugs.openjdk.java.net/browse/JDK-8213183 webrev: http://cr.openjdk.java.net/~tnakamura/8213183/webrev.01/ Fix descriptions: - XSelectInput() in XMSelection.java may erase existing XRegisterIMInstantiateCallback entry. It should keep the current masks. - All input method data in the linked list should be cleared when DestroyXIMCallback() was called. Best regards, Toshio Nakamura "awt-dev" wrote on 2018/11/22 15:48:10: > From: "Toshio 5 Nakamura" > To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > Date: 2018/11/22 15:50 > Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be > used after its restarting > Sent by: "awt-dev" > > Ping. > > Thanks, > Toshio Nakamura > > "awt-dev" wrote on 2018/11/15 17:15:25: > > > From: "Toshio 5 Nakamura" > > To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > > Date: 2018/11/15 17:16 > > Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > > used after its restarting > > Sent by: "awt-dev" > > > > Hello, > > > > I'd like to re-propose minimized patch in this thread. > > > > The key fix of this patch is for XMSelection.java. Its initScreen() cleared > > previous XRegisterIMInstantiateCallback() entry, but it should keep the > > current mask. By this change only, we can reuse Input Method after > > changing focus. > > (Original patch didn't need focus change, but it may be hard to bereviewed.) > > > > Additionally, this change may unveil a potential problem in > awt_InputMethod.c. > > It needs to clear all pX11IMData, not only the current one. Without > > the change, > > multi-window application with IM may crash after IM restart. > > > > So, I'd like to propose only two parts in this thread. > > Can I obtain a sponsor for this minimized fix? > > > > Revised webrev: > > http://cr.openjdk.java.net/~tnakamura/8213183/webrev.01/ > > > > Thanks, > > Toshio Nakamura > > > > From: "Toshio 5 Nakamura" > > To: Sergey Bylokhov > > Cc: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > > Date: 2018/11/12 20:22 > > Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > > used after its restarting > > Sent by: "awt-dev" > > > > > > > > Hi Sergey, > > > > Thank you for your reply. Yes, I've added the steps to the bug. > > https://bugs.openjdk.java.net/browse/JDK-8213183 > > > > Please let me know if you have any question or any advice. > > > > Thanks, > > Toshio Nakamura > > > > From: Sergey Bylokhov > > To: Toshio 5 Nakamura , awt- > > dev at openjdk.java.net, i18n-dev at openjdk.java.net > > Date: 2018/11/10 12:46 > > Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > > used after its restarting > > > > > > > > Hi, Toshio. > > > > Can you please add the steps to reproduce to the bug description. > > > > On 06/11/2018 01:19, Toshio 5 Nakamura wrote: > > > Hello, > > > > > > Can I obtain a sponsor of this proposal about InputMethod issue on Linux? > > > > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8213183 > > > Webrev: > > > http://cr.openjdk.java.net/~tnakamura/8213183/webrev.00/ > > > > > > I've got an author role and filled the bug report. > > > Please refer the attached mail about the detail of this patch. > > > > > > Best Regards, > > > Toshio Nakamura > > > > -- > > Best regards, Sergey. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Dec 5 03:21:16 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 Dec 2018 19:21:16 -0800 Subject: [12] RFR: JDK-8214805: Mark deprecated netscape.javascript.JSObject::getWindow API forRemoval=true Message-ID: <06e27097-abdc-c1f9-15b0-4c3a184525ad@oracle.com> Please review the webrev [1] for JDK-8214805 [2] to mark the already-deprecated netscape.javascript.JSObject::getWindow method as "forRemoval=true". This method is no longer useful. We intend to remove it in a future release, which will also allow removing the dependency from the jdk.jsobject module to the java.desktop module. I have filed a CSR [3] for this, which also needs to be reviewed. Thanks. -- Kevin [1] http://cr.openjdk.java.net/~kcr/8214805/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8214805 [3] https://bugs.openjdk.java.net/browse/JDK-8214832 From shashidhara.veerabhadraiah at oracle.com Wed Dec 5 04:46:08 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Tue, 4 Dec 2018 20:46:08 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> Message-ID: <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> Hi Krishna, The changes looks good to me and I did imported this patch and found that the debug logs are useful in debugging the accessibility related issues. I could see the actions being done on the java program reflected in the corresponding java and windows native logs. And thanks for adding the classification for the logs. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Tuesday, December 4, 2018 4:44 PM To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Shashi, Thanks for the comments, here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev05 Krishna -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Tuesday, December 4, 2018 2:29 PM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, Environment variable set to a file name(with an extension), did created a file with that extension. But without it, the extensions were blank. So I suggest to default to .log if there is no extension set by the user(then the system can choose) as it is a log of debug prints and the file can be opened instantly. Thanks and regards, Shashi -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Monday, December 3, 2018 10:46 PM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, Sure I will check it once again tomorrow for the logger file extension as I am not able to get the JAWS license from home network. Another problem that I see is that the way we use the environment variable. We need to set the flag pointing to a single text file it will end up in creating 2 text files from 2 different sources but both the names does not match the environment variable value. So it is good to separate them out or you can clearly mention the notes in detail. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Monday, December 3, 2018 8:05 PM To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Shashi, 1. It is strange that the Windows Log file did not have any extension and the Java log file had an extension. The code for reading the environment variable content and creating the appropriate file is common between JavaAccessBridge.dll and WindowsAccessBridge.dll, so if one is able to read the environment variable with the extension, so should the other. The scenario where I see this could be broken could be that, you update the environment variable, and not restart either the JAWs application or the Cygwin/Java IDE from which you run the java program. 2. Since this is a debug feature, it is expected that the developers are aware of the log file getting written out from JAWs side as well (WindowsAccessBridge.dll). Nevertheless, I agree with your point that if the JAWs is active for long time, the log file can get pretty big. But, even if we add another environment variable, the problem remains the same. So, I think we can only add a note saying that it is recommended to close JAWs after each debug session. Thanks, Krishna -----Original Message----- From: Shashidhara Veerabhadraiah Sent: Monday, December 3, 2018 10:44 AM To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. Otherwise the changes looks good to me. Thanks and regards, Shashi -----Original Message----- From: Krishna Addepalli Sent: Wednesday, October 17, 2018 1:04 AM To: Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Sergey, Per our conversation, I have made the following changes: 1. Add logging support to WindowsAccessBridge as well. 2. Added timestamp info in the log file. 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, September 18, 2018 3:26 AM To: Prasanta Sadhukhan ; Krishna Addepalli ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. On 14/09/2018 05:18, Prasanta Sadhukhan wrote: > one question: why nullptr is used? I see we used NULL in other places > in this file, why cant we use the same? > > Regards > Prasanta > On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >> >> Thanks for the comments. Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >> >> >> --Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 3:23 PM >> *To:* Krishna Addepalli ; >> awt-dev at openjdk.java.net >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> ok. The formatting is screwed up, needs to be rectified. Also l194, >> there should be a space before { >> >> Regards >> Prasantaa >> >> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >> >> Thanks for the review Prasanta. Although there is not much >> difference between using fprintf and vfprintf, I have changed all >> the calls to vfprintf. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >> >> >> Krishna >> >> *From:*Prasanta Sadhukhan >> *Sent:* Friday, September 14, 2018 11:38 AM >> *To:* Krishna Addepalli >> ; awt-dev at openjdk.java.net >> >> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> One thing, since you are passing va_list as the last parameter, >> shouldn't all fprintf be actually vfprintf? >> >> Regards >> Prasanta >> >> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >> >> Hi All, >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >> >> Webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >> >> >> Please review an enhancement for supporting the logging of >> Java Access Bridge, so that customers/users facing problems >> with Accessibility can turn on/off logging to debug problems >> with this feature. >> >> The proposed solution is to have the user/developer define an >> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >> with the path to the log file. >> >> The JavaAccessBridge will read the variable, and write to the >> file in the path provided. >> Note that the implementation is simplistic, and doesnot have >> any way to handle multiple applications, since it is a debug >> only feature. >> >> Thanks, >> >> Krishna >> > -- Best regards, Sergey. From krishna.addepalli at oracle.com Wed Dec 5 05:29:59 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 5 Dec 2018 10:59:59 +0530 Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> Message-ID: <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> Thanks for the review Shashi. Sergey could you also review? Thanks, Krishna > On 05-Dec-2018, at 10:16 AM, Shashidhara Veerabhadraiah wrote: > > Hi Krishna, The changes looks good to me and I did imported this patch and found that the debug logs are useful in debugging the accessibility related issues. I could see the actions being done on the java program reflected in the corresponding java and windows native logs. And thanks for adding the classification for the logs. > > Thanks and regards, > Shashi > > -----Original Message----- > From: Krishna Addepalli > Sent: Tuesday, December 4, 2018 4:44 PM > To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > Hi Shashi, > > Thanks for the comments, here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev05 > > Krishna > > -----Original Message----- > From: Shashidhara Veerabhadraiah > Sent: Tuesday, December 4, 2018 2:29 PM > To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > Hi Krishna, Environment variable set to a file name(with an extension), did created a file with that extension. But without it, the extensions were blank. So I suggest to default to .log if there is no extension set by the user(then the system can choose) as it is a log of debug prints and the file can be opened instantly. > > Thanks and regards, > Shashi > > -----Original Message----- > From: Shashidhara Veerabhadraiah > Sent: Monday, December 3, 2018 10:46 PM > To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > Hi Krishna, Sure I will check it once again tomorrow for the logger file extension as I am not able to get the JAWS license from home network. > > Another problem that I see is that the way we use the environment variable. We need to set the flag pointing to a single text file it will end up in creating 2 text files from 2 different sources but both the names does not match the environment variable value. So it is good to separate them out or you can clearly mention the notes in detail. > > Thanks and regards, > Shashi > > -----Original Message----- > From: Krishna Addepalli > Sent: Monday, December 3, 2018 8:05 PM > To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > Hi Shashi, > > 1. It is strange that the Windows Log file did not have any extension and the Java log file had an extension. The code for reading the environment variable content and creating the appropriate file is common between JavaAccessBridge.dll and WindowsAccessBridge.dll, so if one is able to read the environment variable with the extension, so should the other. > The scenario where I see this could be broken could be that, you update the environment variable, and not restart either the JAWs application or the Cygwin/Java IDE from which you run the java program. > > 2. Since this is a debug feature, it is expected that the developers are aware of the log file getting written out from JAWs side as well (WindowsAccessBridge.dll). > Nevertheless, I agree with your point that if the JAWs is active for long time, the log file can get pretty big. > But, even if we add another environment variable, the problem remains the same. So, I think we can only add a note saying that it is recommended to close JAWs after each debug session. > > Thanks, > Krishna > > -----Original Message----- > From: Shashidhara Veerabhadraiah > Sent: Monday, December 3, 2018 10:44 AM > To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: > > 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. > 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. > > Otherwise the changes looks good to me. > > Thanks and regards, > Shashi > > -----Original Message----- > From: Krishna Addepalli > Sent: Wednesday, October 17, 2018 1:04 AM > To: Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > Hi Sergey, > > Per our conversation, I have made the following changes: > 1. Add logging support to WindowsAccessBridge as well. > 2. Added timestamp info in the log file. > 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. > 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". > > Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ > > Thanks, > Krishna > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, September 18, 2018 3:26 AM > To: Prasanta Sadhukhan ; Krishna Addepalli ; awt-dev at openjdk.java.net > Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. > > On 14/09/2018 05:18, Prasanta Sadhukhan wrote: >> one question: why nullptr is used? I see we used NULL in other places >> in this file, why cant we use the same? >> >> Regards >> Prasanta >> On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >>> >>> Thanks for the comments. Here is the new webrev: >>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >>> >>> >>> --Krishna >>> >>> *From:*Prasanta Sadhukhan >>> *Sent:* Friday, September 14, 2018 3:23 PM >>> *To:* Krishna Addepalli ; >>> awt-dev at openjdk.java.net >>> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >>> logging and debug flags dynamically controlled >>> >>> ok. The formatting is screwed up, needs to be rectified. Also l194, >>> there should be a space before { >>> >>> Regards >>> Prasantaa >>> >>> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >>> >>> Thanks for the review Prasanta. Although there is not much >>> difference between using fprintf and vfprintf, I have changed all >>> the calls to vfprintf. >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >>> >>> >>> Krishna >>> >>> *From:*Prasanta Sadhukhan >>> *Sent:* Friday, September 14, 2018 11:38 AM >>> *To:* Krishna Addepalli >>> ; awt-dev at openjdk.java.net >>> >>> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >>> logging and debug flags dynamically controlled >>> >>> One thing, since you are passing va_list as the last parameter, >>> shouldn't all fprintf be actually vfprintf? >>> >>> Regards >>> Prasanta >>> >>> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >>> >>> Hi All, >>> >>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >>> >>> >>> Please review an enhancement for supporting the logging of >>> Java Access Bridge, so that customers/users facing problems >>> with Accessibility can turn on/off logging to debug problems >>> with this feature. >>> >>> The proposed solution is to have the user/developer define an >>> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >>> with the path to the log file. >>> >>> The JavaAccessBridge will read the variable, and write to the >>> file in the path provided. >>> Note that the implementation is simplistic, and doesnot have >>> any way to handle multiple applications, since it is a debug >>> only feature. >>> >>> Thanks, >>> >>> Krishna >>> >> > > > -- > Best regards, Sergey. From philip.race at oracle.com Wed Dec 5 06:44:55 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 04 Dec 2018 22:44:55 -0800 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: <5C0725B5.3080907@oracle.com> References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> <5C0725B5.3080907@oracle.com> Message-ID: <5C0773E7.8030108@oracle.com> . and I think I need to be convinced about whether "aix" is the right thing to check here. "I know AIX works like this today" isn't a very robust, or very portable approach. The fix is more about the CDE/Motif environment than AIX, isn't it ? -phil. On 12/4/18, 5:11 PM, Philip Race wrote: > > > On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote: >> Hello Phil. >> >>> I haven't evaluated the merits of this proposal but this >>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html >>> >>> is not the right place to support a flag used in all these X11 files. >> Could you give me your recommendation ? > > Somewhere closer to the code that needs it. >> >>> And why is i18n-dev on the review ? I can't see any I18N related >>> changes. >> I thought focus issue was related input method. > > No. I mean input focus is necessary for input methods but focus does not > automatically mean input methods are in play. > > -phil > >> AIX IM was activated even if focus was moved to non focusable window >> (middle window). [1] >> So I posted this issue into I18N, but it was not good. >> Actually, all key events were forwarded to middle window if user >> clicked inside of right window. >> >> [1] >> https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-05 03:06, Phil Race wrote: >>> I haven't evaluated the merits of this proposal but this >>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html >>> >>> is not the right place to support a flag used in all these X11 files. >>> >>> And why is i18n-dev on the review ? I can't see any I18N related >>> changes. >>> >>> -phil. >>> >>> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote: >>>> Hello again. >>>> >>>> Could you give me review comment and/or suggestion ? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> >>>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>>>> >>>>> Test instructions and screen shots are in JDK-8212676. >>>>> >>>>> GUI environment for AIX platform still needs CDE support. >>>>> This fix is required to avoid unexpected working behavior on AIX >>>>> platform. >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> >>>>>> This fix is really required for AIX's GUI. >>>>>> System color setting and window manager's working behavior are >>>>>> very important. >>>>>> >>>>>> I appreciate any feedback, and how I would go about obtaining a >>>>>> sponsor and contributor ? >>>>>> >>>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>>>>>> Hello Phil. >>>>>>> >>>>>>> webrev file was extracted. >>>>>>> Please see >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>>>>>> >>>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>>>>>> Hello Phil. >>>>>>>> >>>>>>>> Webrev.zip file is stored into >>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>>>>>> >>>>>>>> Test programs are also stored: >>>>>>>> No testcase is available for FontUtilities.java and >>>>>>>> XDecoratedPeer.java. >>>>>>>> >>>>>>>> MotifColorUtilities.java >>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>>>>>> Run SystemColorTest2, system colors should be displayed >>>>>>>> AIX sample is >>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>>>>>> >>>>>>>> XWM.java >>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>>>>>> On AIX CDE, isMotif and isCDE were true. >>>>>>>> On AIX MWM, every entry is false. >>>>>>>> >>>>>>>> XWindowPeer.java >>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>>>>>> frame). >>>>>>>> Window focus should not be changed because of "click on focus" >>>>>>>> feature. >>>>>>>> But input focus is moved to "Non-Focusable" window. >>>>>>>> >>>>>>>> >>>>>>>> On 2018-05-18 01:00, Phil Race wrote: >>>>>>>>> I think we'd need to see the actual proposed changes and >>>>>>>>> understand >>>>>>>>> the implications >>>>>>>>> for ongoing support as we no longer support any platform which >>>>>>>>> has a >>>>>>>>> CDE desktop. >>>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be >>>>>>>>> ripping out >>>>>>>>> such support rather >>>>>>>>> than adding to it. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>>>>>> Hello, >>>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>>>>>> Manager) support to OpenJDK project. >>>>>>>>>> >>>>>>>>>> I'd like contribute following 5 files: >>>>>>>>>> >>>>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>>>>>> M >>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>>>>>> >>>>>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>>>>>> Color) [1] >>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>>>>>> XMapRaised/XMapWindow) >>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>>>>>> (Detect MWM on AIX platform) >>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, >>>>>>>>>> because DTWM/MWM does not have enough features for ICCCM) >>>>>>>>>> >>>>>>>>>> I appreciate any feedback please, and how I would go about >>>>>>>>>> obtaining a sponsor and contributor ? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Ichiroh Takiguchi >>>>>>>>>> IBM Japan, Ltd. >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>>>>>> >>>> >> From takiguc at linux.vnet.ibm.com Wed Dec 5 09:22:40 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 05 Dec 2018 18:22:40 +0900 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: <5C0773E7.8030108@oracle.com> References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> <5C0725B5.3080907@oracle.com> <5C0773E7.8030108@oracle.com> Message-ID: Hello Phil. I heard some of AIX users used RealVNC VNC Enterprise Edition for AIX maintenance. [1] I assume they still use CDE. [1] https://www.realvnc.com/en/connect/download/vnc/aix/#older-versions Thanks, Ichiroh Takiguchi On 2018-12-05 15:44, Philip Race wrote: > . and I think I need to be convinced about whether "aix" is the right > thing to check here. > "I know AIX works like this today" isn't a very robust, or very > portable approach. > The fix is more about the CDE/Motif environment than AIX, isn't it ? > > -phil. > > > On 12/4/18, 5:11 PM, Philip Race wrote: >> >> >> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>>> I haven't evaluated the merits of this proposal but this >>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html >>>> is not the right place to support a flag used in all these X11 >>>> files. >>> Could you give me your recommendation ? >> >> Somewhere closer to the code that needs it. >>> >>>> And why is i18n-dev on the review ? I can't see any I18N related >>>> changes. >>> I thought focus issue was related input method. >> >> No. I mean input focus is necessary for input methods but focus does >> not >> automatically mean input methods are in play. >> >> -phil >> >>> AIX IM was activated even if focus was moved to non focusable window >>> (middle window). [1] >>> So I posted this issue into I18N, but it was not good. >>> Actually, all key events were forwarded to middle window if user >>> clicked inside of right window. >>> >>> [1] >>> https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-12-05 03:06, Phil Race wrote: >>>> I haven't evaluated the merits of this proposal but this >>>> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html >>>> is not the right place to support a flag used in all these X11 >>>> files. >>>> >>>> And why is i18n-dev on the review ? I can't see any I18N related >>>> changes. >>>> >>>> -phil. >>>> >>>> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote: >>>>> Hello again. >>>>> >>>>> Could you give me review comment and/or suggestion ? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> >>>>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> >>>>>> Could you review the fix ? >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>>>>> >>>>>> Test instructions and screen shots are in JDK-8212676. >>>>>> >>>>>> GUI environment for AIX platform still needs CDE support. >>>>>> This fix is required to avoid unexpected working behavior on AIX >>>>>> platform. >>>>>> >>>>>> I'd like to obtain a sponsor for this issue. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >>>>>>> Hello. >>>>>>> >>>>>>> This fix is really required for AIX's GUI. >>>>>>> System color setting and window manager's working behavior are >>>>>>> very important. >>>>>>> >>>>>>> I appreciate any feedback, and how I would go about obtaining a >>>>>>> sponsor and contributor ? >>>>>>> >>>>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>>>>>>> Hello Phil. >>>>>>>> >>>>>>>> webrev file was extracted. >>>>>>>> Please see >>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>>>>>>> >>>>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>>>>>>> Hello Phil. >>>>>>>>> >>>>>>>>> Webrev.zip file is stored into >>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>>>>>>> >>>>>>>>> Test programs are also stored: >>>>>>>>> No testcase is available for FontUtilities.java and >>>>>>>>> XDecoratedPeer.java. >>>>>>>>> >>>>>>>>> MotifColorUtilities.java >>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>>>>>>> Run SystemColorTest2, system colors should be displayed >>>>>>>>> AIX sample is >>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>>>>>>> >>>>>>>>> XWM.java >>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>>>>>>> On AIX CDE, isMotif and isCDE were true. >>>>>>>>> On AIX MWM, every entry is false. >>>>>>>>> >>>>>>>>> XWindowPeer.java >>>>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>>>>>>> frame). >>>>>>>>> Window focus should not be changed because of "click on focus" >>>>>>>>> feature. >>>>>>>>> But input focus is moved to "Non-Focusable" window. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-05-18 01:00, Phil Race wrote: >>>>>>>>>> I think we'd need to see the actual proposed changes and >>>>>>>>>> understand >>>>>>>>>> the implications >>>>>>>>>> for ongoing support as we no longer support any platform which >>>>>>>>>> has a >>>>>>>>>> CDE desktop. >>>>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be >>>>>>>>>> ripping out >>>>>>>>>> such support rather >>>>>>>>>> than adding to it. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>>>>>>> Manager) support to OpenJDK project. >>>>>>>>>>> >>>>>>>>>>> I'd like contribute following 5 files: >>>>>>>>>>> >>>>>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>>>>>>> (Add isAIX flag to determine AIX platform for GUI >>>>>>>>>>> environment) >>>>>>>>>>> M >>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>>>>>>> Color) [1] >>>>>>>>>>> M >>>>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>>>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>>>>>>> XMapRaised/XMapWindow) >>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>>>>>>> (Detect MWM on AIX platform) >>>>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, >>>>>>>>>>> because DTWM/MWM does not have enough features for ICCCM) >>>>>>>>>>> >>>>>>>>>>> I appreciate any feedback please, and how I would go about >>>>>>>>>>> obtaining a sponsor and contributor ? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Ichiroh Takiguchi >>>>>>>>>>> IBM Japan, Ltd. >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>>>>>>> >>>>> >>> From philip.race at oracle.com Wed Dec 5 21:22:44 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 5 Dec 2018 13:22:44 -0800 Subject: [12] RFR: JDK-8214805: Mark deprecated netscape.javascript.JSObject::getWindow API forRemoval=true In-Reply-To: <06e27097-abdc-c1f9-15b0-4c3a184525ad@oracle.com> References: <06e27097-abdc-c1f9-15b0-4c3a184525ad@oracle.com> Message-ID: Approved. -phil. On 12/4/18 7:21 PM, Kevin Rushforth wrote: > Please review the webrev [1] for JDK-8214805 [2] to mark the > already-deprecated netscape.javascript.JSObject::getWindow method as > "forRemoval=true". This method is no longer useful. We intend to > remove it in a future release, which will also allow removing the > dependency from the jdk.jsobject module to the java.desktop module. I > have filed a CSR [3] for this, which also needs to be reviewed. > > Thanks. > > -- Kevin > > [1] http://cr.openjdk.java.net/~kcr/8214805/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8214805 > [3] https://bugs.openjdk.java.net/browse/JDK-8214832 > From Sergey.Bylokhov at oracle.com Wed Dec 5 23:16:04 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 5 Dec 2018 15:16:04 -0800 Subject: [12] RFR: JDK-8214805: Mark deprecated netscape.javascript.JSObject::getWindow API forRemoval=true In-Reply-To: References: <06e27097-abdc-c1f9-15b0-4c3a184525ad@oracle.com> Message-ID: Looks fine, but I am not sure how the reference to "java.applet package documentation" may help, currently it contain the same text "The APIs in this package are all deprecated without replacement." On 05/12/2018 13:22, Phil Race wrote: > Approved. > > -phil. > > On 12/4/18 7:21 PM, Kevin Rushforth wrote: >> Please review the webrev [1] for JDK-8214805 [2] to mark the already-deprecated netscape.javascript.JSObject::getWindow method as "forRemoval=true". This method is no longer useful. We intend to remove it in a future release, which will also allow removing the dependency from the jdk.jsobject module to the java.desktop module. I have filed a CSR [3] for this, which also needs to be reviewed. >> >> Thanks. >> >> -- Kevin >> >> [1] http://cr.openjdk.java.net/~kcr/8214805/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8214805 >> [3] https://bugs.openjdk.java.net/browse/JDK-8214832 >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Dec 5 23:23:22 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 5 Dec 2018 15:23:22 -0800 Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> Message-ID: <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> Hi, Krishna. Why did you disable one of the compiler warning? Is it possible to change a fix to skip the changes in the make file? Looks like filePath in the "AccessBridgeDebug.cpp" may be local var? On 04/12/2018 21:29, Krishna Addepalli wrote: > Thanks for the review Shashi. > > Sergey could you also review? > > Thanks, > Krishna > >> On 05-Dec-2018, at 10:16 AM, Shashidhara Veerabhadraiah wrote: >> >> Hi Krishna, The changes looks good to me and I did imported this patch and found that the debug logs are useful in debugging the accessibility related issues. I could see the actions being done on the java program reflected in the corresponding java and windows native logs. And thanks for adding the classification for the logs. >> >> Thanks and regards, >> Shashi >> >> -----Original Message----- >> From: Krishna Addepalli >> Sent: Tuesday, December 4, 2018 4:44 PM >> To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net >> Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled >> >> Hi Shashi, >> >> Thanks for the comments, here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev05 >> >> Krishna >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Tuesday, December 4, 2018 2:29 PM >> To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net >> Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled >> >> Hi Krishna, Environment variable set to a file name(with an extension), did created a file with that extension. But without it, the extensions were blank. So I suggest to default to .log if there is no extension set by the user(then the system can choose) as it is a log of debug prints and the file can be opened instantly. >> >> Thanks and regards, >> Shashi >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Monday, December 3, 2018 10:46 PM >> To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net >> Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled >> >> Hi Krishna, Sure I will check it once again tomorrow for the logger file extension as I am not able to get the JAWS license from home network. >> >> Another problem that I see is that the way we use the environment variable. We need to set the flag pointing to a single text file it will end up in creating 2 text files from 2 different sources but both the names does not match the environment variable value. So it is good to separate them out or you can clearly mention the notes in detail. >> >> Thanks and regards, >> Shashi >> >> -----Original Message----- >> From: Krishna Addepalli >> Sent: Monday, December 3, 2018 8:05 PM >> To: Shashidhara Veerabhadraiah ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net >> Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled >> >> Hi Shashi, >> >> 1. It is strange that the Windows Log file did not have any extension and the Java log file had an extension. The code for reading the environment variable content and creating the appropriate file is common between JavaAccessBridge.dll and WindowsAccessBridge.dll, so if one is able to read the environment variable with the extension, so should the other. >> The scenario where I see this could be broken could be that, you update the environment variable, and not restart either the JAWs application or the Cygwin/Java IDE from which you run the java program. >> >> 2. Since this is a debug feature, it is expected that the developers are aware of the log file getting written out from JAWs side as well (WindowsAccessBridge.dll). >> Nevertheless, I agree with your point that if the JAWs is active for long time, the log file can get pretty big. >> But, even if we add another environment variable, the problem remains the same. So, I think we can only add a note saying that it is recommended to close JAWs after each debug session. >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Monday, December 3, 2018 10:44 AM >> To: Krishna Addepalli ; Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net >> Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled >> >> Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: >> >> 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. >> 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. >> >> Otherwise the changes looks good to me. >> >> Thanks and regards, >> Shashi >> >> -----Original Message----- >> From: Krishna Addepalli >> Sent: Wednesday, October 17, 2018 1:04 AM >> To: Sergey Bylokhov ; Prasanta Sadhukhan ; awt-dev at openjdk.java.net >> Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled >> >> Hi Sergey, >> >> Per our conversation, I have made the following changes: >> 1. Add logging support to WindowsAccessBridge as well. >> 2. Added timestamp info in the log file. >> 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. >> 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". >> >> Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, September 18, 2018 3:26 AM >> To: Prasanta Sadhukhan ; Krishna Addepalli ; awt-dev at openjdk.java.net >> Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled >> >> I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. >> >> On 14/09/2018 05:18, Prasanta Sadhukhan wrote: >>> one question: why nullptr is used? I see we used NULL in other places >>> in this file, why cant we use the same? >>> >>> Regards >>> Prasanta >>> On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >>>> >>>> Thanks for the comments. Here is the new webrev: >>>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >>>> >>>> >>>> --Krishna >>>> >>>> *From:*Prasanta Sadhukhan >>>> *Sent:* Friday, September 14, 2018 3:23 PM >>>> *To:* Krishna Addepalli ; >>>> awt-dev at openjdk.java.net >>>> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >>>> logging and debug flags dynamically controlled >>>> >>>> ok. The formatting is screwed up, needs to be rectified. Also l194, >>>> there should be a space before { >>>> >>>> Regards >>>> Prasantaa >>>> >>>> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >>>> >>>> Thanks for the review Prasanta. Although there is not much >>>> difference between using fprintf and vfprintf, I have changed all >>>> the calls to vfprintf. >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >>>> >>>> >>>> Krishna >>>> >>>> *From:*Prasanta Sadhukhan >>>> *Sent:* Friday, September 14, 2018 11:38 AM >>>> *To:* Krishna Addepalli >>>> ; awt-dev at openjdk.java.net >>>> >>>> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >>>> logging and debug flags dynamically controlled >>>> >>>> One thing, since you are passing va_list as the last parameter, >>>> shouldn't all fprintf be actually vfprintf? >>>> >>>> Regards >>>> Prasanta >>>> >>>> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >>>> >>>> Hi All, >>>> >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196681 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >>>> >>>> >>>> Please review an enhancement for supporting the logging of >>>> Java Access Bridge, so that customers/users facing problems >>>> with Accessibility can turn on/off logging to debug problems >>>> with this feature. >>>> >>>> The proposed solution is to have the user/developer define an >>>> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >>>> with the path to the log file. >>>> >>>> The JavaAccessBridge will read the variable, and write to the >>>> file in the path provided. >>>> Note that the implementation is simplistic, and doesnot have >>>> any way to handle multiple applications, since it is a debug >>>> only feature. >>>> >>>> Thanks, >>>> >>>> Krishna >>>> >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From kevin.rushforth at oracle.com Wed Dec 5 23:27:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 5 Dec 2018 15:27:25 -0800 Subject: [12] RFR: JDK-8214805: Mark deprecated netscape.javascript.JSObject::getWindow API forRemoval=true In-Reply-To: References: <06e27097-abdc-c1f9-15b0-4c3a184525ad@oracle.com> Message-ID: Thanks. The reference to java.applet package docs was preexisting, so I opted not to change it. -- Kevin On 12/5/2018 3:16 PM, Sergey Bylokhov wrote: > Looks fine, but I am not sure how the reference to "java.applet > package documentation" may help, > currently it contain the same text "The APIs in this package are all > deprecated without replacement." > > > On 05/12/2018 13:22, Phil Race wrote: >> Approved. >> >> -phil. >> >> On 12/4/18 7:21 PM, Kevin Rushforth wrote: >>> Please review the webrev [1] for JDK-8214805 [2] to mark the >>> already-deprecated netscape.javascript.JSObject::getWindow method as >>> "forRemoval=true". This method is no longer useful. We intend to >>> remove it in a future release, which will also allow removing the >>> dependency from the jdk.jsobject module to the java.desktop module. >>> I have filed a CSR [3] for this, which also needs to be reviewed. >>> >>> Thanks. >>> >>> -- Kevin >>> >>> [1] http://cr.openjdk.java.net/~kcr/8214805/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8214805 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8214832 >>> >> > > From Sergey.Bylokhov at oracle.com Thu Dec 6 00:10:24 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 5 Dec 2018 16:10:24 -0800 Subject: =?utf-8?q?=5B12=5D_RFR_8213983=3A_=5Bmacosx=5D_Keyboard?= =?utf-8?q?_shortcut_=E2=80=9Ccmd_+=60=E2=80=9D_stops_working_properly_if_?= =?utf-8?q?popup_window_is_displayed?= In-Reply-To: <8219F9B6-D626-4CB9-881B-8DDD1698F250@oracle.com> References: <273AF26E-1D81-4E56-87D7-93970ED23C22@oracle.com> <167977cf-b029-fa90-0e7b-13eff7ca7437@oracle.com> <8219F9B6-D626-4CB9-881B-8DDD1698F250@oracle.com> Message-ID: Looks fine. On 30/11/2018 01:53, Dmitry Markov wrote: > Hi Sergey, > > The occurrence of the problem does not depend on child windows, their type and visibility. The issue is caused by orderFront operation when it is called for the focused window, (i.e. window which is already located above other windows). In other words double invocation of order operation for the same window will break cycling shortcut. > > I have updated the fix, see http://cr.openjdk.java.net/~dmarkov/8213983/webrev.03/ > Changes summary: > ?- Added check to suppress ordering if the window is already active, (i.e. owns focus) > ?- Backed out the changes made under?JDK-8206392 [1] since they are not necessary anymore > > I have verified that the test for JDK-8206392 still works properly with my fix. > Thanks, > Dmitry > > [1] - https://bugs.openjdk.java.net/browse/JDK-8206392 > >> On 28 Nov 2018, at 21:09, Sergey Bylokhov > wrote: >> >> Hi, Dmitry. >> >> Can you please clarify why the invisible children affect this behavior? >> Is it possible that some of the invisible child(which we skip after the fix) will have visible child window? >> >> On 22/11/2018 06:43, Dmitry Markov wrote: >>> Hi Sergey, >>> I am sorry, but the problem is not related to popup windows at all. Actually the root cause of the issue is that we perform ordering operation for the window which has only invisible child windows. I have updated the fix: http://cr.openjdk.java.net/~dmarkov/8213983/webrev.02/ >>> Could you review the new version, please? >>> Thanks, >>> Dmitry >>>> On 21 Nov 2018, at 23:22, Sergey Bylokhov > wrote: >>>> >>>> On 21/11/2018 12:51, Dmitry Markov wrote: >>>>> When we are going to display the popup, all related windows, (i.e. the owner, its child windows and their child an so on) are already ordered. They were ordered once the owner received focus. >>>> >>>> I guess it is always true if the user click on the window >>>> and popup was shown, but how it will work if the popup window >>>> was shown programmatically without making window focused? >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From dmitry.markov at oracle.com Thu Dec 6 08:59:38 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 6 Dec 2018 08:59:38 +0000 Subject: =?utf-8?q?=5B12=5D_RFR_8213983=3A_=5Bmacosx=5D_Keyboard?= =?utf-8?q?_shortcut_=E2=80=9Ccmd_+=60=E2=80=9D_stops_working_properly_if_?= =?utf-8?q?popup_window_is_displayed?= In-Reply-To: References: <273AF26E-1D81-4E56-87D7-93970ED23C22@oracle.com> <167977cf-b029-fa90-0e7b-13eff7ca7437@oracle.com> <8219F9B6-D626-4CB9-881B-8DDD1698F250@oracle.com> Message-ID: Thank you, Sergey! Looking for the second ?+1? from someone else. Thanks, Dmitry > On 6 Dec 2018, at 00:10, Sergey Bylokhov wrote: > > Looks fine. > > On 30/11/2018 01:53, Dmitry Markov wrote: >> Hi Sergey, >> The occurrence of the problem does not depend on child windows, their type and visibility. The issue is caused by orderFront operation when it is called for the focused window, (i.e. window which is already located above other windows). In other words double invocation of order operation for the same window will break cycling shortcut. >> I have updated the fix, see http://cr.openjdk.java.net/~dmarkov/8213983/webrev.03/ >> Changes summary: >> - Added check to suppress ordering if the window is already active, (i.e. owns focus) >> - Backed out the changes made under JDK-8206392 [1] since they are not necessary anymore >> I have verified that the test for JDK-8206392 still works properly with my fix. >> Thanks, >> Dmitry >> [1] - https://bugs.openjdk.java.net/browse/JDK-8206392 >>> On 28 Nov 2018, at 21:09, Sergey Bylokhov > wrote: >>> >>> Hi, Dmitry. >>> >>> Can you please clarify why the invisible children affect this behavior? >>> Is it possible that some of the invisible child(which we skip after the fix) will have visible child window? >>> >>> On 22/11/2018 06:43, Dmitry Markov wrote: >>>> Hi Sergey, >>>> I am sorry, but the problem is not related to popup windows at all. Actually the root cause of the issue is that we perform ordering operation for the window which has only invisible child windows. I have updated the fix: http://cr.openjdk.java.net/~dmarkov/8213983/webrev.02/ >>>> Could you review the new version, please? >>>> Thanks, >>>> Dmitry >>>>> On 21 Nov 2018, at 23:22, Sergey Bylokhov > wrote: >>>>> >>>>> On 21/11/2018 12:51, Dmitry Markov wrote: >>>>>> When we are going to display the popup, all related windows, (i.e. the owner, its child windows and their child an so on) are already ordered. They were ordered once the owner received focus. >>>>> >>>>> I guess it is always true if the user click on the window >>>>> and popup was shown, but how it will work if the popup window >>>>> was shown programmatically without making window focused? >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey. From krishna.addepalli at oracle.com Thu Dec 6 09:06:42 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 6 Dec 2018 14:36:42 +0530 Subject: =?utf-8?q?=5B12=5D_RFR_8213983=3A_=5Bmacosx=5D_Keyboard?= =?utf-8?q?_shortcut_=E2=80=9Ccmd_+=60=E2=80=9D_stops_working_properly_if_?= =?utf-8?q?popup_window_is_displayed?= In-Reply-To: References: <273AF26E-1D81-4E56-87D7-93970ED23C22@oracle.com> <167977cf-b029-fa90-0e7b-13eff7ca7437@oracle.com> <8219F9B6-D626-4CB9-881B-8DDD1698F250@oracle.com> Message-ID: <5D94AC18-B5EC-4A21-B87E-FBC21FF35BE6@oracle.com> +1 Thanks, Krishna > On 06-Dec-2018, at 2:29 PM, Dmitry Markov wrote: > > Thank you, Sergey! > Looking for the second ?+1? from someone else. > > Thanks, > Dmitry > >> On 6 Dec 2018, at 00:10, Sergey Bylokhov wrote: >> >> Looks fine. >> >> On 30/11/2018 01:53, Dmitry Markov wrote: >>> Hi Sergey, >>> The occurrence of the problem does not depend on child windows, their type and visibility. The issue is caused by orderFront operation when it is called for the focused window, (i.e. window which is already located above other windows). In other words double invocation of order operation for the same window will break cycling shortcut. >>> I have updated the fix, see http://cr.openjdk.java.net/~dmarkov/8213983/webrev.03/ >>> Changes summary: >>> - Added check to suppress ordering if the window is already active, (i.e. owns focus) >>> - Backed out the changes made under JDK-8206392 [1] since they are not necessary anymore >>> I have verified that the test for JDK-8206392 still works properly with my fix. >>> Thanks, >>> Dmitry >>> [1] - https://bugs.openjdk.java.net/browse/JDK-8206392 >>>> On 28 Nov 2018, at 21:09, Sergey Bylokhov > wrote: >>>> >>>> Hi, Dmitry. >>>> >>>> Can you please clarify why the invisible children affect this behavior? >>>> Is it possible that some of the invisible child(which we skip after the fix) will have visible child window? >>>> >>>> On 22/11/2018 06:43, Dmitry Markov wrote: >>>>> Hi Sergey, >>>>> I am sorry, but the problem is not related to popup windows at all. Actually the root cause of the issue is that we perform ordering operation for the window which has only invisible child windows. I have updated the fix: http://cr.openjdk.java.net/~dmarkov/8213983/webrev.02/ >>>>> Could you review the new version, please? >>>>> Thanks, >>>>> Dmitry >>>>>> On 21 Nov 2018, at 23:22, Sergey Bylokhov > wrote: >>>>>> >>>>>> On 21/11/2018 12:51, Dmitry Markov wrote: >>>>>>> When we are going to display the popup, all related windows, (i.e. the owner, its child windows and their child an so on) are already ordered. They were ordered once the owner received focus. >>>>>> >>>>>> I guess it is always true if the user click on the window >>>>>> and popup was shown, but how it will work if the popup window >>>>>> was shown programmatically without making window focused? >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. > From krishna.addepalli at oracle.com Thu Dec 6 09:10:17 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 6 Dec 2018 01:10:17 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> Message-ID: <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> Hi Sergey, I got this error while compiling: warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc. I couldn't immediately figure out how to specify that option, so I disabled that warning (4530). Now I corrected this as well as making the filePath a local variable. Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev06 Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Thursday, December 6, 2018 4:53 AM To: Krishna Addepalli ; Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi, Krishna. Why did you disable one of the compiler warning? Is it possible to change a fix to skip the changes in the make file? Looks like filePath in the "AccessBridgeDebug.cpp" may be local var? On 04/12/2018 21:29, Krishna Addepalli wrote: > Thanks for the review Shashi. > > Sergey could you also review? > > Thanks, > Krishna > >> On 05-Dec-2018, at 10:16 AM, Shashidhara Veerabhadraiah wrote: >> >> Hi Krishna, The changes looks good to me and I did imported this patch and found that the debug logs are useful in debugging the accessibility related issues. I could see the actions being done on the java program reflected in the corresponding java and windows native logs. And thanks for adding the classification for the logs. >> >> Thanks and regards, >> Shashi >> >> -----Original Message----- >> From: Krishna Addepalli >> Sent: Tuesday, December 4, 2018 4:44 PM >> To: Shashidhara Veerabhadraiah >> ; Sergey Bylokhov >> ; Prasanta Sadhukhan >> ; awt-dev at openjdk.java.net >> Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> Hi Shashi, >> >> Thanks for the comments, here is the updated webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev05 >> >> Krishna >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Tuesday, December 4, 2018 2:29 PM >> To: Krishna Addepalli ; Sergey Bylokhov >> ; Prasanta Sadhukhan >> ; awt-dev at openjdk.java.net >> Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> Hi Krishna, Environment variable set to a file name(with an extension), did created a file with that extension. But without it, the extensions were blank. So I suggest to default to .log if there is no extension set by the user(then the system can choose) as it is a log of debug prints and the file can be opened instantly. >> >> Thanks and regards, >> Shashi >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Monday, December 3, 2018 10:46 PM >> To: Krishna Addepalli ; Sergey Bylokhov >> ; Prasanta Sadhukhan >> ; awt-dev at openjdk.java.net >> Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> Hi Krishna, Sure I will check it once again tomorrow for the logger file extension as I am not able to get the JAWS license from home network. >> >> Another problem that I see is that the way we use the environment variable. We need to set the flag pointing to a single text file it will end up in creating 2 text files from 2 different sources but both the names does not match the environment variable value. So it is good to separate them out or you can clearly mention the notes in detail. >> >> Thanks and regards, >> Shashi >> >> -----Original Message----- >> From: Krishna Addepalli >> Sent: Monday, December 3, 2018 8:05 PM >> To: Shashidhara Veerabhadraiah >> ; Sergey Bylokhov >> ; Prasanta Sadhukhan >> ; awt-dev at openjdk.java.net >> Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> Hi Shashi, >> >> 1. It is strange that the Windows Log file did not have any extension and the Java log file had an extension. The code for reading the environment variable content and creating the appropriate file is common between JavaAccessBridge.dll and WindowsAccessBridge.dll, so if one is able to read the environment variable with the extension, so should the other. >> The scenario where I see this could be broken could be that, you update the environment variable, and not restart either the JAWs application or the Cygwin/Java IDE from which you run the java program. >> >> 2. Since this is a debug feature, it is expected that the developers are aware of the log file getting written out from JAWs side as well (WindowsAccessBridge.dll). >> Nevertheless, I agree with your point that if the JAWs is active for long time, the log file can get pretty big. >> But, even if we add another environment variable, the problem remains the same. So, I think we can only add a note saying that it is recommended to close JAWs after each debug session. >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Monday, December 3, 2018 10:44 AM >> To: Krishna Addepalli ; Sergey Bylokhov >> ; Prasanta Sadhukhan >> ; awt-dev at openjdk.java.net >> Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> Hi Krishna, I have imported the patch and used it for some testing. The debug logs helped with debug information of the actions that I performed with a demo application. Below are few suggestions: >> >> 1. The Windows log file did not had any extensions whereas the java log had the file extension. May be a default extension could be built in. >> 2. Another thing I felt was that the windows log file was populated by the access bridge module causing it to write it for any version of java usage and whereas Java log file will be written for the built java module. Since both of them are behaving differently can we have 2 separate variables for it instead of one? Since the windows log file can grow to larger size and for debugging java log is sufficient at times, we can keep it separate. >> >> Otherwise the changes looks good to me. >> >> Thanks and regards, >> Shashi >> >> -----Original Message----- >> From: Krishna Addepalli >> Sent: Wednesday, October 17, 2018 1:04 AM >> To: Sergey Bylokhov ; Prasanta Sadhukhan >> ; awt-dev at openjdk.java.net >> Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> Hi Sergey, >> >> Per our conversation, I have made the following changes: >> 1. Add logging support to WindowsAccessBridge as well. >> 2. Added timestamp info in the log file. >> 3. Added INFO/WARN/ERROR tags as appropriate in all the places where the logging function is called. >> 4. JavaAccessBridge will generate the file suffixed with "_java_access_bridge", whereas WindowsAccessBridge generates file suffixed with "_windows_access_bridge". >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev04/ >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, September 18, 2018 3:26 AM >> To: Prasanta Sadhukhan ; Krishna >> Addepalli ; awt-dev at openjdk.java.net >> Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge >> logging and debug flags dynamically controlled >> >> I guess that it is a good thing to use nullptr, but I think it is better to follow the style used in the file, and replace NULL to nullptr in the whole file in some separate fix. >> >> On 14/09/2018 05:18, Prasanta Sadhukhan wrote: >>> one question: why nullptr is used? I see we used NULL in other >>> places in this file, why cant we use the same? >>> >>> Regards >>> Prasanta >>> On 14-Sep-18 4:05 PM, Krishna Addepalli wrote: >>>> >>>> Thanks for the comments. Here is the new webrev: >>>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev02/ >>>> >>>> >>>> --Krishna >>>> >>>> *From:*Prasanta Sadhukhan >>>> *Sent:* Friday, September 14, 2018 3:23 PM >>>> *To:* Krishna Addepalli ; >>>> awt-dev at openjdk.java.net >>>> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >>>> logging and debug flags dynamically controlled >>>> >>>> ok. The formatting is screwed up, needs to be rectified. Also l194, >>>> there should be a space before { >>>> >>>> Regards >>>> Prasantaa >>>> >>>> On 14-Sep-18 2:45 PM, Krishna Addepalli wrote: >>>> >>>> Thanks for the review Prasanta. Although there is not much >>>> difference between using fprintf and vfprintf, I have changed all >>>> the calls to vfprintf. >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev01/ >>>> >>>> >>>> Krishna >>>> >>>> *From:*Prasanta Sadhukhan >>>> *Sent:* Friday, September 14, 2018 11:38 AM >>>> *To:* Krishna Addepalli >>>> ; awt-dev at openjdk.java.net >>>> >>>> *Subject:* Re: RFR: [12] JDK-8196681: Java Access Bridge >>>> logging and debug flags dynamically controlled >>>> >>>> One thing, since you are passing va_list as the last parameter, >>>> shouldn't all fprintf be actually vfprintf? >>>> >>>> Regards >>>> Prasanta >>>> >>>> On 14-Sep-18 12:55 AM, Krishna Addepalli wrote: >>>> >>>> Hi All, >>>> >>>> Enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8196681 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev00/ >>>> >>>> >>>> >>>> Please review an enhancement for supporting the logging of >>>> Java Access Bridge, so that customers/users facing problems >>>> with Accessibility can turn on/off logging to debug problems >>>> with this feature. >>>> >>>> The proposed solution is to have the user/developer define an >>>> environment variable "*JAVA_ACCESSBRIDGE_LOGFILE*" and filling >>>> with the path to the log file. >>>> >>>> The JavaAccessBridge will read the variable, and write to the >>>> file in the path provided. >>>> Note that the implementation is simplistic, and doesnot have >>>> any way to handle multiple applications, since it is a debug >>>> only feature. >>>> >>>> Thanks, >>>> >>>> Krishna >>>> >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Dec 6 17:18:38 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 6 Dec 2018 09:18:38 -0800 Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> Message-ID: On 06/12/2018 01:10, Krishna Addepalli wrote: > Hi Sergey, > > I got this error while compiling: warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc. > I couldn't immediately figure out how to specify that option, so I disabled that warning (4530). > Now I corrected this as well as making the filePath a local variable. > Here is the updated webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev06 But what new code required this option? As far as I understand part of this option is to "tells the compiler to assume that functions declared as extern "C" never throw a C++ exception." I am not sure that this is correct assumption, is it? -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Dec 6 17:26:06 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 6 Dec 2018 09:26:06 -0800 Subject: [12] Review Request: 8214918 Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms Message-ID: Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8214918 Webrev: http://cr.openjdk.java.net/~serb/8214918/webrev.00 In the fix for JDK-8076313 I need to implement possibility of switch between xinerama and non-xinerama modes at runtime. As a separate part I would like to investigate the usage of X11GraphicsEnvironment.runningXinerama() and replace it by some other generic for single/multi-screen solution. This bug is about one of the place where the flag above is used. In jdk 1.4 two new methods were added to the GraphicsEnvironment class: - getCenterPoint() - getMaximumWindowBounds() see https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering Take a look to this descriptions from the link above: "X-Window, Xinerama All monitors share a single virtual coordinate space, as on Microsoft Windows. However, it is possible for the user to specify through X resources where windows should be centered. If these resources are set, getCenterPoint reflects their value. Otherwise, it returns the point at the center of the virtual coordinate space. (In practice, this will almost always be set - CDE sets it by default.)" Since the case above was implemented on the Solaris, and uses an extension of the xinerama, I suggest to remove this and align implementation across the platforms: - getCenterPoint returns the coordinates of the center of the primary display for all platforms - getMaximumWindowBounds returns the bounds of the primary display minus display insets for all platforms -- Best regards, Sergey. From krishna.addepalli at oracle.com Thu Dec 6 17:39:57 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 6 Dec 2018 09:39:57 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> Message-ID: Since I added string.h and its related code for manipulating the path, I encountered this warning. The standard way to deal with this is to specify /EHsc, which is to enable catching of asynchronous exceptions. https://docs.microsoft.com/en-us/previous-versions/1deeycx5(v=vs.140) Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Thursday, December 6, 2018 10:49 PM To: Krishna Addepalli ; Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled On 06/12/2018 01:10, Krishna Addepalli wrote: > Hi Sergey, > > I got this error while compiling: warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc. > I couldn't immediately figure out how to specify that option, so I disabled that warning (4530). > Now I corrected this as well as making the filePath a local variable. > Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8196681/webrev06 But what new code required this option? As far as I understand part of this option is to "tells the compiler to assume that functions declared as extern "C" never throw a C++ exception." I am not sure that this is correct assumption, is it? -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Dec 6 18:06:42 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 6 Dec 2018 10:06:42 -0800 Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> Message-ID: <2d674b82-75db-3a94-5cc7-8257b40b50da@oracle.com> > Since I added string.h and its related code for manipulating the path, I encountered this warning. The standard way to deal with this is to specify /EHsc, which is to enable catching of asynchronous exceptions. > > https://docs.microsoft.com/en-us/previous-versions/1deeycx5(v=vs.140) And my text from the previous email was copied from this link. "tells the compiler to assume that functions declared as extern "C" never throw a C++ exception." I am not sure that this is correct assumption, because the new code actually may throw an exception. > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, December 6, 2018 10:49 PM > To: Krishna Addepalli ; Shashidhara Veerabhadraiah > Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > On 06/12/2018 01:10, Krishna Addepalli wrote: >> Hi Sergey, >> >> I got this error while compiling: warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc. >> I couldn't immediately figure out how to specify that option, so I disabled that warning (4530). >> Now I corrected this as well as making the filePath a local variable. >> Here is the updated webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev06 > > But what new code required this option? As far as I understand part of this option is to "tells the compiler to assume that functions declared as extern "C" never throw a C++ exception." > I am not sure that this is correct assumption, is it? > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From krishna.addepalli at oracle.com Fri Dec 7 07:10:41 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 6 Dec 2018 23:10:41 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <2d674b82-75db-3a94-5cc7-8257b40b50da@oracle.com> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> <2d674b82-75db-3a94-5cc7-8257b40b50da@oracle.com> Message-ID: <2fba4859-30df-404b-9082-5f66dd0a6c39@default> Hi Sergey, I checked the code with only /EHs - which says: "The exception-handling model that catches synchronous (C++) exceptions only and tells the compiler to assume that functions declared as extern "C" may throw an exception." With this, our code compiles, so here is the modified webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev07 Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Thursday, December 6, 2018 11:37 PM To: Krishna Addepalli ; Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > Since I added string.h and its related code for manipulating the path, I encountered this warning. The standard way to deal with this is to specify /EHsc, which is to enable catching of asynchronous exceptions. > > https://docs.microsoft.com/en-us/previous-versions/1deeycx5(v=vs.140) And my text from the previous email was copied from this link. "tells the compiler to assume that functions declared as extern "C" never throw a C++ exception." I am not sure that this is correct assumption, because the new code actually may throw an exception. > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, December 6, 2018 10:49 PM > To: Krishna Addepalli ; Shashidhara Veerabhadraiah > Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > On 06/12/2018 01:10, Krishna Addepalli wrote: >> Hi Sergey, >> >> I got this error while compiling: warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc. >> I couldn't immediately figure out how to specify that option, so I disabled that warning (4530). >> Now I corrected this as well as making the filePath a local variable. >> Here is the updated webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev06 > > But what new code required this option? As far as I understand part of this option is to "tells the compiler to assume that functions declared as extern "C" never throw a C++ exception." > I am not sure that this is correct assumption, is it? > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From krishna.addepalli at oracle.com Mon Dec 10 14:38:47 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 10 Dec 2018 06:38:47 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <2fba4859-30df-404b-9082-5f66dd0a6c39@default> References: <7da8c95e-3415-8c6e-0a79-79682bc98fe1@oracle.com> <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> <2d674b82-75db-3a94-5cc7-8257b40b50da@oracle.com> <2fba4859-30df-404b-9082-5f66dd0a6c39@default> Message-ID: Hi Sergey, The only way to avoid changes to make file is by using C string manipulation API. Here is the webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev08 , although I would personally prefer using the C++ api. Thanks, Krishna -----Original Message----- From: Krishna Addepalli Sent: Friday, December 7, 2018 12:41 PM To: Sergey Bylokhov ; Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Sergey, I checked the code with only /EHs - which says: "The exception-handling model that catches synchronous (C++) exceptions only and tells the compiler to assume that functions declared as extern "C" may throw an exception." With this, our code compiles, so here is the modified webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev07 Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Thursday, December 6, 2018 11:37 PM To: Krishna Addepalli ; Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > Since I added string.h and its related code for manipulating the path, I encountered this warning. The standard way to deal with this is to specify /EHsc, which is to enable catching of asynchronous exceptions. > > https://docs.microsoft.com/en-us/previous-versions/1deeycx5(v=vs.140) And my text from the previous email was copied from this link. "tells the compiler to assume that functions declared as extern "C" never throw a C++ exception." I am not sure that this is correct assumption, because the new code actually may throw an exception. > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, December 6, 2018 10:49 PM > To: Krishna Addepalli ; Shashidhara Veerabhadraiah > Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net > Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled > > On 06/12/2018 01:10, Krishna Addepalli wrote: >> Hi Sergey, >> >> I got this error while compiling: warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc. >> I couldn't immediately figure out how to specify that option, so I disabled that warning (4530). >> Now I corrected this as well as making the filePath a local variable. >> Here is the updated webrev: >> http://cr.openjdk.java.net/~kaddepalli/8196681/webrev06 > > But what new code required this option? As far as I understand part of this option is to "tells the compiler to assume that functions declared as extern "C" never throw a C++ exception." > I am not sure that this is correct assumption, is it? > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Dec 10 21:06:43 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Dec 2018 13:06:43 -0800 Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: References: <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> <2d674b82-75db-3a94-5cc7-8257b40b50da@oracle.com> <2fba4859-30df-404b-9082-5f66dd0a6c39@default> Message-ID: <8c290a51-3c8d-bf05-8cc8-5dd942bc3492@oracle.com> Hi, Krishna. On 10/12/2018 06:38, Krishna Addepalli wrote: > The only way to avoid changes to make file is by using C string manipulation API. > Here is the webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev08 , although I would personally prefer using the C++ api. Throwing a c++ exception out of "extern C", when the method is called from the other language is UB, so we should not throw any exception and use c++, or use plain c. Comment about the current version: - Do we handle the absent of the slash at the end of the path in "JAVA_ACCESSBRIDGE_LOGFILE"? - in some place you use auto and in another same situation you use "size_t", please unify. -- Best regards, Sergey. From krishna.addepalli at oracle.com Tue Dec 11 11:44:00 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 11 Dec 2018 03:44:00 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <8c290a51-3c8d-bf05-8cc8-5dd942bc3492@oracle.com> References: <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> <2d674b82-75db-3a94-5cc7-8257b40b50da@oracle.com> <2fba4859-30df-404b-9082-5f66dd0a6c39@default> <8c290a51-3c8d-bf05-8cc8-5dd942bc3492@oracle.com> Message-ID: Hi Sergey, I understand about the UB, but currently just including is causing this warning to appear, and there doesn't seem to be a way without doing irrelevant changes, so somewhat reluctantly I'm proposing plain C changes. Regarding the questions: 1. Currently, we expect that the user provides us the file name with the path. The only correction we are doing is that, if there is no explicit mention of extension, we add ".log". We donot expect to read a path and create a file (if that is what you meant by handling the absent slash at the end of the path). 2. I made all the declarations auto. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev09 Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, December 11, 2018 2:37 AM To: Krishna Addepalli ; Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi, Krishna. On 10/12/2018 06:38, Krishna Addepalli wrote: > The only way to avoid changes to make file is by using C string manipulation API. > Here is the webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev08 , although I would personally prefer using the C++ api. Throwing a c++ exception out of "extern C", when the method is called from the other language is UB, so we should not throw any exception and use c++, or use plain c. Comment about the current version: - Do we handle the absent of the slash at the end of the path in "JAVA_ACCESSBRIDGE_LOGFILE"? - in some place you use auto and in another same situation you use "size_t", please unify. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Dec 11 13:47:05 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Dec 2018 05:47:05 -0800 Subject: [12] Review request for JDK-8209123: [Macosx] Maximized frame is resizable on Mac but not on Windows and Ubuntu In-Reply-To: <34c8859d-6479-32cd-16c4-3f6b8fda078a@oracle.com> References: <65743c3f-8f90-f167-cd56-97af8d3b5c53@oracle.com> <01925cdc-46d3-a6c6-a1b7-f19086c98562@oracle.com> <34c8859d-6479-32cd-16c4-3f6b8fda078a@oracle.com> Message-ID: <7e1314e2-d365-ee07-7518-cc7e783403fa@oracle.com> Hi, Manajit. Did you check the test below? It looks like a regression. On 30/11/2018 16:12, Sergey Bylokhov wrote: > I'm not sure that it works as intended: > ??? Frame f = new Frame(); > ??? f.setSize(300,300); > ??? f.setVisible(true); > ??? f.setMaximizedBounds(new Rectangle(100,100,100,100)); > ??? f.setExtendedState(Frame.MAXIMIZED_BOTH); > > Try to click on the title of the frame above a few times. > The frame will be non-resizable even in the normal state. -- Best regards, Sergey. From philip.race at oracle.com Tue Dec 11 17:54:05 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 11 Dec 2018 09:54:05 -0800 Subject: [OpenJDK 2D-Dev] [12] Review Request: 8214461 Some unused classes may be removed In-Reply-To: <0B7C189D-D615-4024-BAAC-8E33C0EDE3C4@oracle.com> References: <0B7C189D-D615-4024-BAAC-8E33C0EDE3C4@oracle.com> Message-ID: I guess this is OK.? But for 13 now. -phil. On 11/30/18 6:33 PM, Krishna Addepalli wrote: > Looks good to me. > > Krishna > >> On 01-Dec-2018, at 7:33 AM, Sergey Bylokhov wrote: >> >> Hello. >> Please review the fix for jdk 12. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214461 >> Webrev: http://cr.openjdk.java.net/~serb/8214461/webrev.00 >> >> We have a few internal classes/interfaces which currently unused and may be removed: >> - sun.awt.image.BadDepthException.java: looks like it was never used >> - sun.awt.TracedEventQueue.java: was used for logging >> - sun.awt.Graphics2Delegate.java: currently unused >> >> >> -- >> Best regards, Sergey. From naoto.sato at oracle.com Tue Dec 11 21:27:46 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 11 Dec 2018 13:27:46 -0800 Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting In-Reply-To: References: Message-ID: <689c7234-c008-f709-e630-4dff0da83233@oracle.com> Hello, I would rather not create a new test directory ReconnectTest. Instead, moving the test under InputContext would just be fine. Other than that, looks good to me. Naoto On 12/4/18 6:45 PM, Toshio 5 Nakamura wrote: > Hello, > > Can anyone support this proposal? I appreciate any suggestion or comment. > > issue: > https://bugs.openjdk.java.net/browse/JDK-8213183 > webrev: > http://cr.openjdk.java.net/~tnakamura/8213183/webrev.01/ > > Fix descriptions: > - XSelectInput() in XMSelection.java may erase existing > XRegisterIMInstantiateCallback entry. It should keep the current masks. > - All input method data in the linked list should be cleared when > DestroyXIMCallback() was called. > > Best regards, > Toshio Nakamura > > "awt-dev" wrote on 2018/11/22 15:48:10: > >> From: "Toshio 5 Nakamura" >> To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net >> Date: 2018/11/22 15:50 >> Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be >> used after its restarting >> Sent by: "awt-dev" >> >> Ping. >> >> Thanks, >> Toshio Nakamura >> >> "awt-dev" wrote on 2018/11/15 > 17:15:25: >> >>> From: "Toshio 5 Nakamura" >>> To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net >>> Date: 2018/11/15 17:16 >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be >>> used after its restarting >>> Sent by: "awt-dev" >>> >>> Hello, >>> >>> I'd like to re-propose minimized patch in this thread. >>> >>> The key fix of this patch is for XMSelection.java. Its initScreen() > cleared >>> previous XRegisterIMInstantiateCallback() entry, but it should keep the >>> current mask. By this change only, we can reuse Input Method after >>> changing focus. >>> (Original patch didn't need focus change, but it may be hard to > bereviewed.) >>> >>> Additionally, this change may unveil a potential problem in >> awt_InputMethod.c. >>> It needs to clear all pX11IMData, not only the current one. Without >>> the change, >>> multi-window application with IM may crash after IM restart. >>> >>> So, I'd like to propose only two parts in this thread. >>> Can I obtain a sponsor for this minimized fix? >>> >>> Revised webrev: >>> http://cr.openjdk.java.net/~tnakamura/8213183/webrev.01/ >>> >>> Thanks, >>> Toshio Nakamura >>> >>> From: "Toshio 5 Nakamura" >>> To: Sergey Bylokhov >>> Cc: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net >>> Date: 2018/11/12 20:22 >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be >>> used after its restarting >>> Sent by: "awt-dev" >>> >>> >>> >>> Hi Sergey, >>> >>> Thank you for your reply. Yes, I've added the steps to the bug. >>> https://bugs.openjdk.java.net/browse/JDK-8213183 >>> >>> Please let me know if you have any question or any advice. >>> >>> Thanks, >>> Toshio Nakamura >>> >>> From: Sergey Bylokhov >>> To: Toshio 5 Nakamura , awt- >>> dev at openjdk.java.net, i18n-dev at openjdk.java.net >>> Date: 2018/11/10 12:46 >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be >>> used after its restarting >>> >>> >>> >>> Hi, Toshio. >>> >>> Can you please add the steps to reproduce to the bug description. >>> >>> On 06/11/2018 01:19, Toshio 5 Nakamura wrote: >>>> Hello, >>>> >>>> Can I obtain a sponsor of this proposal about InputMethod issue on > Linux? >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8213183 >>>> Webrev: >>>> http://cr.openjdk.java.net/~tnakamura/8213183/webrev.00/ >>>> >>>> I've got an author role and filled the bug report. >>>> Please refer the attached mail about the detail of this patch. >>>> >>>> Best Regards, >>>> Toshio Nakamura >>> >>> -- >>> Best regards, Sergey. >>> From TOSHIONA at jp.ibm.com Wed Dec 12 04:32:02 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Wed, 12 Dec 2018 13:32:02 +0900 Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting In-Reply-To: <689c7234-c008-f709-e630-4dff0da83233@oracle.com> References: <689c7234-c008-f709-e630-4dff0da83233@oracle.com> Message-ID: Hello Naoto, Thank you for your review. The updated webrev: http://cr.openjdk.java.net/~tnakamura/8213183/webrev.02/ Thanks, Toshio Nakamura Naoto Sato wrote on 2018/12/12 06:27:46: > From: Naoto Sato > To: Toshio 5 Nakamura , awt- > dev at openjdk.java.net, i18n-dev at openjdk.java.net > Date: 2018/12/12 06:30 > Subject: Re: Fw: [PATCH] JDK-8213183: > InputMethod cannot be used after its restarting > > Hello, > > I would rather not create a new test directory ReconnectTest. Instead, > moving the test under InputContext would just be fine. Other than that, > looks good to me. > > Naoto > > On 12/4/18 6:45 PM, Toshio 5 Nakamura wrote: > > Hello, > > > > Can anyone support this proposal? I appreciate any suggestion or comment. > > > > issue: > > INVALID URI REMOVED > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213183&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=EVbFABcgo-X99_TGI2- > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > KQAP0ap59aIgx7JdMXnkMf0&s=q6uPI3Ypu4juvcyBI8aEenYXLO-yGglZe9fOzYWHni4&e= > > webrev: > > INVALID URI REMOVED > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8213183_webrev. > 01_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > KQAP0ap59aIgx7JdMXnkMf0&s=78XQhanHugJH88R5X5xh_QIq54Wzi4ZR52f4iTjMhH8&e= > > > > Fix descriptions: > > - XSelectInput() in XMSelection.java may erase existing > > XRegisterIMInstantiateCallback entry. It should keep the current masks. > > - All input method data in the linked list should be cleared when > > DestroyXIMCallback() was called. > > > > Best regards, > > Toshio Nakamura > > > > "awt-dev" wrote on 2018/11/22 15:48:10: > > > >> From: "Toshio 5 Nakamura" > >> To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > >> Date: 2018/11/22 15:50 > >> Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be > >> used after its restarting > >> Sent by: "awt-dev" > >> > >> Ping. > >> > >> Thanks, > >> Toshio Nakamura > >> > >> "awt-dev" wrote on 2018/11/15 > > 17:15:25: > >> > >>> From: "Toshio 5 Nakamura" > >>> To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > >>> Date: 2018/11/15 17:16 > >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > >>> used after its restarting > >>> Sent by: "awt-dev" > >>> > >>> Hello, > >>> > >>> I'd like to re-propose minimized patch in this thread. > >>> > >>> The key fix of this patch is for XMSelection.java. Its initScreen() > > cleared > >>> previous XRegisterIMInstantiateCallback() entry, but it should keep the > >>> current mask. By this change only, we can reuse Input Method after > >>> changing focus. > >>> (Original patch didn't need focus change, but it may be hard to > > bereviewed.) > >>> > >>> Additionally, this change may unveil a potential problem in > >> awt_InputMethod.c. > >>> It needs to clear all pX11IMData, not only the current one. Without > >>> the change, > >>> multi-window application with IM may crash after IM restart. > >>> > >>> So, I'd like to propose only two parts in this thread. > >>> Can I obtain a sponsor for this minimized fix? > >>> > >>> Revised webrev: > >>> INVALID URI REMOVED > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8213183_webrev. > 01_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > KQAP0ap59aIgx7JdMXnkMf0&s=78XQhanHugJH88R5X5xh_QIq54Wzi4ZR52f4iTjMhH8&e= > >>> > >>> Thanks, > >>> Toshio Nakamura > >>> > >>> From: "Toshio 5 Nakamura" > >>> To: Sergey Bylokhov > >>> Cc: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > >>> Date: 2018/11/12 20:22 > >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > >>> used after its restarting > >>> Sent by: "awt-dev" > >>> > >>> > >>> > >>> Hi Sergey, > >>> > >>> Thank you for your reply. Yes, I've added the steps to the bug. > >>> INVALID URI REMOVED > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213183&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=EVbFABcgo-X99_TGI2- > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > KQAP0ap59aIgx7JdMXnkMf0&s=q6uPI3Ypu4juvcyBI8aEenYXLO-yGglZe9fOzYWHni4&e= > >>> > >>> Please let me know if you have any question or any advice. > >>> > >>> Thanks, > >>> Toshio Nakamura > >>> > >>> From: Sergey Bylokhov > >>> To: Toshio 5 Nakamura , awt- > >>> dev at openjdk.java.net, i18n-dev at openjdk.java.net > >>> Date: 2018/11/10 12:46 > >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > >>> used after its restarting > >>> > >>> > >>> > >>> Hi, Toshio. > >>> > >>> Can you please add the steps to reproduce to the bug description. > >>> > >>> On 06/11/2018 01:19, Toshio 5 Nakamura wrote: > >>>> Hello, > >>>> > >>>> Can I obtain a sponsor of this proposal about InputMethod issue on > > Linux? > >>>> > >>>> Bug: > >>>> INVALID URI REMOVED > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213183&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=EVbFABcgo-X99_TGI2- > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > KQAP0ap59aIgx7JdMXnkMf0&s=q6uPI3Ypu4juvcyBI8aEenYXLO-yGglZe9fOzYWHni4&e= > >>>> Webrev: > >>>> INVALID URI REMOVED > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8213183_webrev. > 00_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > KQAP0ap59aIgx7JdMXnkMf0&s=7sUCNNIiK-6T-20D0en2W-KJszmeUsMpqdngQxBDafM&e= > >>>> > >>>> I've got an author role and filled the bug report. > >>>> Please refer the attached mail about the detail of this patch. > >>>> > >>>> Best Regards, > >>>> Toshio Nakamura > >>> > >>> -- > >>> Best regards, Sergey. > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto.sato at oracle.com Wed Dec 12 05:23:05 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 11 Dec 2018 21:23:05 -0800 Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting In-Reply-To: References: <689c7234-c008-f709-e630-4dff0da83233@oracle.com> Message-ID: Looks good to me. Naoto On 12/11/18 8:32 PM, Toshio 5 Nakamura wrote: > Hello Naoto, > > Thank you for your review. > > The updated webrev: > http://cr.openjdk.java.net/~tnakamura/8213183/webrev.02/ > > Thanks, > Toshio Nakamura > > Naoto Sato wrote on 2018/12/12 06:27:46: > > > From: Naoto Sato > > To: Toshio 5 Nakamura , awt- > > dev at openjdk.java.net, i18n-dev at openjdk.java.net > > Date: 2018/12/12 06:30 > > Subject: Re: Fw: [PATCH] JDK-8213183: > > InputMethod cannot be used after its restarting > > > > Hello, > > > > I would rather not create a new test directory ReconnectTest. Instead, > > moving the test under InputContext would just be fine. Other than that, > > looks good to me. > > > > Naoto > > > > On 12/4/18 6:45 PM, Toshio 5 Nakamura wrote: > > > Hello, > > > > > > Can anyone support this proposal? I appreciate any suggestion or > comment. > > > > > > issue: > > > INVALID URI REMOVED > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213183&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=EVbFABcgo-X99_TGI2- > > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > > KQAP0ap59aIgx7JdMXnkMf0&s=q6uPI3Ypu4juvcyBI8aEenYXLO-yGglZe9fOzYWHni4&e= > > > webrev: > > > INVALID URI REMOVED > > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8213183_webrev. > > 01_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > > KQAP0ap59aIgx7JdMXnkMf0&s=78XQhanHugJH88R5X5xh_QIq54Wzi4ZR52f4iTjMhH8&e= > > > > > > Fix descriptions: > > > - XSelectInput() in XMSelection.java may erase existing > > > ? ?XRegisterIMInstantiateCallback entry. It should keep the current > masks. > > > - All input method data in the linked list should be cleared when > > > ? ?DestroyXIMCallback() was called. > > > > > > Best regards, > > > Toshio Nakamura > > > > > > "awt-dev" wrote on 2018/11/22 > 15:48:10: > > > > > >> From: "Toshio 5 Nakamura" > > >> To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > > >> Date: 2018/11/22 15:50 > > >> Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be > > >> used after its restarting > > >> Sent by: "awt-dev" > > >> > > >> Ping. > > >> > > >> Thanks, > > >> Toshio Nakamura > > >> > > >> "awt-dev" wrote on 2018/11/15 > > > 17:15:25: > > >> > > >>> From: "Toshio 5 Nakamura" > > >>> To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > > >>> Date: 2018/11/15 17:16 > > >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > > >>> used after its restarting > > >>> Sent by: "awt-dev" > > >>> > > >>> Hello, > > >>> > > >>> I'd like to re-propose minimized patch in this thread. > > >>> > > >>> The key fix of this patch is for XMSelection.java. Its initScreen() > > > cleared > > >>> previous XRegisterIMInstantiateCallback() entry, but it should > keep the > > >>> current mask. By this change only, we can reuse Input Method after > > >>> changing focus. > > >>> (Original patch didn't need focus change, but it may be hard to > > > bereviewed.) > > >>> > > >>> Additionally, this change may unveil a potential problem in > > >> awt_InputMethod.c. > > >>> It needs to clear all pX11IMData, not only the current one. Without > > >>> the change, > > >>> multi-window application with IM may crash after IM restart. > > >>> > > >>> So, I'd like to propose only two parts in this thread. > > >>> Can I obtain a sponsor for this minimized fix? > > >>> > > >>> Revised webrev: > > >>> INVALID URI REMOVED > > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8213183_webrev. > > 01_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > > KQAP0ap59aIgx7JdMXnkMf0&s=78XQhanHugJH88R5X5xh_QIq54Wzi4ZR52f4iTjMhH8&e= > > >>> > > >>> Thanks, > > >>> Toshio Nakamura > > >>> > > >>> From: "Toshio 5 Nakamura" > > >>> To: Sergey Bylokhov > > >>> Cc: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > > >>> Date: 2018/11/12 20:22 > > >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > > >>> used after its restarting > > >>> Sent by: "awt-dev" > > >>> > > >>> > > >>> > > >>> Hi Sergey, > > >>> > > >>> Thank you for your reply. Yes, I've added the steps to the bug. > > >>> INVALID URI REMOVED > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213183&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=EVbFABcgo-X99_TGI2- > > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > > KQAP0ap59aIgx7JdMXnkMf0&s=q6uPI3Ypu4juvcyBI8aEenYXLO-yGglZe9fOzYWHni4&e= > > >>> > > >>> Please let me know if you have any question or any advice. > > >>> > > >>> Thanks, > > >>> Toshio Nakamura > > >>> > > >>> From: Sergey Bylokhov > > >>> To: Toshio 5 Nakamura , awt- > > >>> dev at openjdk.java.net, i18n-dev at openjdk.java.net > > >>> Date: 2018/11/10 12:46 > > >>> Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > > >>> used after its restarting > > >>> > > >>> > > >>> > > >>> Hi, Toshio. > > >>> > > >>> Can you please add the steps to reproduce to the bug description. > > >>> > > >>> On 06/11/2018 01:19, Toshio 5 Nakamura wrote: > > >>>> Hello, > > >>>> > > >>>> Can I obtain a sponsor of this proposal about InputMethod issue on > > > Linux? > > >>>> > > >>>> Bug: > > >>>> INVALID URI REMOVED > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8213183&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=EVbFABcgo-X99_TGI2- > > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > > KQAP0ap59aIgx7JdMXnkMf0&s=q6uPI3Ypu4juvcyBI8aEenYXLO-yGglZe9fOzYWHni4&e= > > >>>> Webrev: > > >>>> INVALID URI REMOVED > > u=http-3A__cr.openjdk.java.net_-7Etnakamura_8213183_webrev. > > 00_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > > qsMtyulHUruf8lAzMlVpVRqw&m=D3pwA4uBvfYfcVDh8rx- > > KQAP0ap59aIgx7JdMXnkMf0&s=7sUCNNIiK-6T-20D0en2W-KJszmeUsMpqdngQxBDafM&e= > > >>>> > > >>>> I've got an author role and filled the bug report. > > >>>> Please refer the attached mail about the detail of this patch. > > >>>> > > >>>> Best Regards, > > >>>> Toshio Nakamura > > >>> > > >>> -- > > >>> Best regards, Sergey. > > >>> > > > From takiguc at linux.vnet.ibm.com Wed Dec 12 08:59:34 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 12 Dec 2018 17:59:34 +0900 Subject: RFR: 8211267: StackOverflowError happened by TextField.setFont(...) & Add non interactive test case for JDK-8211267 In-Reply-To: <0d789099-8975-58f3-ca25-2dad095fa95f@oracle.com> References: <7638a441405abe3b5919baf2b6a75501@linux.vnet.ibm.com> <32e30403ea59baa0a52ddeff0fe41827@linux.vnet.ibm.com> <0d789099-8975-58f3-ca25-2dad095fa95f@oracle.com> Message-ID: <959e5330cb9f6c50f87a75115b6128ec@linux.vnet.ibm.com> Hello. I'm very sorry. I forgot to put @test tag into FontChangeTest.java testcase. (Thanks, Phil) Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8211267 Change: https://cr.openjdk.java.net/~itakiguchi/8211267/webrev.03/ Thanks, Ichiroh Takiguchi On 2018-12-05 09:15, Sergey Bylokhov wrote: > Looks fine. > > On 03/12/2018 00:22, Ichiroh Takiguchi wrote: >> Hello. >> >> Thanks, Sergey. >> I created new test case for JDK-8214298. >> >> I merged JDK-8211267 & JDK-8214298. >> I removed interactive test case and added JDK-8214298's code. >> >> Could you review the fix ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211267 >> Change: https://cr.openjdk.java.net/~itakiguchi/8211267/webrev.02/ >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-01 09:35, Sergey Bylokhov wrote: >>> Hello, >>> >>> I think that you can use invokeAndWait instead of invokeLater(), >>> which will wait while the code is executed on EDT, and I am not >>> sure that you need to interrupt the main thread of the test. >>> >>> On 26/11/2018 09:19, Ichiroh Takiguchi wrote: >>>> Hello. >>>> Could you review the fix ? >>>> >>>> Issue: >>>> JDK-8211267 requires non interactive test case >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214298 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8214298/webrev.00/ >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >> From manajit.halder at oracle.com Wed Dec 12 12:37:22 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Wed, 12 Dec 2018 18:07:22 +0530 Subject: [12] Review request for JDK-8209123: [Macosx] Maximized frame is resizable on Mac but not on Windows and Ubuntu In-Reply-To: <7e1314e2-d365-ee07-7518-cc7e783403fa@oracle.com> References: <65743c3f-8f90-f167-cd56-97af8d3b5c53@oracle.com> <01925cdc-46d3-a6c6-a1b7-f19086c98562@oracle.com> <34c8859d-6479-32cd-16c4-3f6b8fda078a@oracle.com> <7e1314e2-d365-ee07-7518-cc7e783403fa@oracle.com> Message-ID: <5BDF91BA-EA10-4787-947B-6FE9F8DC26EF@oracle.com> Hi Sergey, You are right, the issue is observed sometimes on double clicking title bar for few times and sometimes it is not observed at all. I have created an issue to work on it. https://bugs.openjdk.java.net/browse/JDK-8215280 Regards, Manajit > On 11-Dec-2018, at 7:17 PM, Sergey Bylokhov wrote: > > Hi, Manajit. > > Did you check the test below? It looks like a regression. > > On 30/11/2018 16:12, Sergey Bylokhov wrote: >> I'm not sure that it works as intended: >> Frame f = new Frame(); >> f.setSize(300,300); >> f.setVisible(true); >> f.setMaximizedBounds(new Rectangle(100,100,100,100)); >> f.setExtendedState(Frame.MAXIMIZED_BOTH); >> Try to click on the title of the frame above a few times. >> The frame will be non-resizable even in the normal state. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Dec 12 17:04:28 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Dec 2018 09:04:28 -0800 Subject: RFR: 8211267: StackOverflowError happened by TextField.setFont(...) & Add non interactive test case for JDK-8211267 In-Reply-To: <959e5330cb9f6c50f87a75115b6128ec@linux.vnet.ibm.com> References: <7638a441405abe3b5919baf2b6a75501@linux.vnet.ibm.com> <32e30403ea59baa0a52ddeff0fe41827@linux.vnet.ibm.com> <0d789099-8975-58f3-ca25-2dad095fa95f@oracle.com> <959e5330cb9f6c50f87a75115b6128ec@linux.vnet.ibm.com> Message-ID: That looks better. -phil. On 12/12/18 12:59 AM, Ichiroh Takiguchi wrote: > Hello. > > I'm very sorry. > I forgot to put @test tag into FontChangeTest.java testcase. > (Thanks, Phil) > > Could you review the fix again ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211267 > Change: https://cr.openjdk.java.net/~itakiguchi/8211267/webrev.03/ > > Thanks, > Ichiroh Takiguchi > > On 2018-12-05 09:15, Sergey Bylokhov wrote: >> Looks fine. >> >> On 03/12/2018 00:22, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Thanks, Sergey. >>> I created new test case for JDK-8214298. >>> >>> I merged JDK-8211267 & JDK-8214298. >>> I removed interactive test case and added JDK-8214298's code. >>> >>> Could you review the fix ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211267 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8211267/webrev.02/ >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-12-01 09:35, Sergey Bylokhov wrote: >>>> Hello, >>>> >>>> I think that you can use invokeAndWait instead of invokeLater(), >>>> which will wait while the code is executed on EDT, and I am not >>>> sure that you need to interrupt the main thread of the test. >>>> >>>> On 26/11/2018 09:19, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> Could you review the fix ? >>>>> >>>>> Issue: >>>>> JDK-8211267 requires non interactive test case >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214298 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8214298/webrev.00/ >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>> > From magnus.ihse.bursie at oracle.com Thu Dec 13 10:11:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Dec 2018 11:11:17 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> References: <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> Message-ID: <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> On 2018-12-12 23:17, David Holmes wrote: > Hi Magnus, > > What did -Xa do? I believe Kim has answered this satisfactory. > > Do AWT folk need to check this. I'm adding awt and 2d lists to this review. > I find it hard to understand the connection between: I'm not sure there is a connection..? It's two different libraries, that were affected by the change to -std=c99. Two different fixes were required. > > -xc99=no_lib -xc99=no_lib is a subset of -xc99=none, the flag we removed, and it says that the file should not be compiled with the full c99 standard. "Do not enable the 1999 C standard library semantics of routines that appeared in both the 1990 and 1999 C standard. " says the maual. [1] This conflicted outright with -std=c99. > > and > > -D_XPG6 > > ?? To be honest, I'm not completely sure about this. Without this define, the build failed with the following error message: Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications This was triggered by the following section in /usr/include/sys/feature_tests.h: /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later * compiler. Therefore, we force an error in both cases. */ #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ and pre-2001 POSIX applications" #elif !defined(_STDC_C99) && \ (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications \ require the use of c99" #endif The solution, as also hinted to by searching for other resolutions to this error online, was to provide the _XPG6 system define. But exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, without _XPG6 set, and only when compiling this library and not others, I don't know. I also don't understand what the XPG standard refers to, nor what versions 2-5 means or what version 6 has that differs from them. By setting this flag, I am telling solaris include headers that we want to compile using the XPG standard version 6, instead of an older one. It solves the problem. I am happy enough with this. Are you? /Magnus > > Thanks, > David > > On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>> From the bug report: >>>> "Currently we disable C99 in the Solaris build by setting >>>> -xc99=%none%. >>>> This differs from a lot of other build environments like gcc/Linux >>>> or VS2013/2017 on Windows where C99 features work. >>>> We should remove this difference on Solaris and remove or replace >>>> the setting. >>>> >>>> Kim Barrett mentioned : >>>> "I merely mentioned the C++14 work as evidence that removing >>>> -xc99=%none% didn?t appear harmful." >>>> However it will take more time until the C++14 change is in." >>>> >>>> I am currently running a test build on our CI build system to >>>> confirm that this does not break the Solaris build (but I'd be >>>> highly surprised if it did). I will not push this until the builds >>>> are cleared. >>> Of course it was not that simple... :-( Two AWT libraries (at least) >>> failed to build. I'm currently investigating if there's a simple fix >>> to that. >> New attempt, that fixes the two AWT libraries: >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >> >> >> Now this passes the CI build test. >> >> /Magnus >>> >>> /Magnus >>>> >>>> /Magnus >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>> Patch inline: >>>> diff --git a/make/autoconf/flags-cflags.m4 >>>> b/make/autoconf/flags-cflags.m4 >>>> --- a/make/autoconf/flags-cflags.m4 >>>> +++ b/make/autoconf/flags-cflags.m4 >>>> @@ -559,7 +559,7 @@ >>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>> >>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >>>> $TOOLCHAIN_CFLAGS" # C only >>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>> $TOOLCHAIN_CFLAGS" # C only >>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>> -xnolib" # CXX only >>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef >>>> -features=no%split_init \ >>>> -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >>> >> From erik.joelsson at oracle.com Thu Dec 13 18:07:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Dec 2018 10:07:51 -0800 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> References: <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> Message-ID: On 2018-12-13 02:11, Magnus Ihse Bursie wrote: > >> -D_XPG6 >> >> ?? > To be honest, I'm not completely sure about this. Without this define, > the build failed with the following error message: > Compiler or options invalid for pre-UNIX 03 X/Open applications and > pre-2001 POSIX applications > > This was triggered by the following section in > /usr/include/sys/feature_tests.h: > /* > ?* It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application > ?* using c99.? The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, > ?* and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 > ?* or a POSIX.1-2001 application with anything other than a c99 or later > ?* compiler.? Therefore, we force an error in both cases. > ?*/ > #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) > #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ > ??????? and pre-2001 POSIX applications" > #elif !defined(_STDC_C99) && \ > ??????? (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) > #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 > applications \ > ??????? require the use of c99" > #endif > > The solution, as also hinted to by searching for other resolutions to > this error online, was to provide the _XPG6 system define. But exactly > how we end up in feature_tests.h with __XOPEN_OR_POSIX set, without > _XPG6 set, and only when compiling this library and not others, I > don't know. I also don't understand what the XPG standard refers to, > nor what versions 2-5 means or what version 6 has that differs from them. > > By setting this flag, I am telling solaris include headers that we > want to compile using the XPG standard version 6, instead of an older > one. It solves the problem. I am happy enough with this. Are you? > It looks like this comes from libpng. It has this in src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: /* Feature Test Macros.? The following are defined here to ensure that correctly ?* implemented libraries reveal the APIs libpng needs to build and hide those ?* that are not needed and potentially damaging to the compilation. ?* ?* Feature Test Macros must be defined before any system header is included (see ?* POSIX 1003.1 2.8.2 "POSIX Symbols." ?* ?* These macros only have an effect if the operating system supports either ?* POSIX 1003.1 or C99, or both.? On other operating systems (particularly ?* Windows/Visual Studio) there is no effect; the OS specific tests below are ?* still required (as of 2011-05-02.) ?*/ #ifndef _POSIX_SOURCE # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ #endif This in turn triggers _XOPEN_OR_POSIX to be defined in /usr/include/sys/feature_tests.h and so triggers the error. What I'm not clear about is if libpng is trying to declare that it should not be compiled with any newer standards, and so by doing that, we risk introducing problems. Reading in the system header, it seems the _XPG6 macro is internal and should not be used by the application. It's derived from _XOPEN_SOURCE=600 or _POSIX_C_SOURCE=200112L which is what applications should use. So the the question is, is it ok to override the requirements of libpng or should it receive special treatment? If we are fine with overriding, then we should use one of the public APIs instead. /Erik > /Magnus > >> >> Thanks, >> David >> >> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>> From the bug report: >>>>> "Currently? we disable C99 in the Solaris build by setting >>>>> -xc99=%none%. >>>>> This differs from a lot of other build environments like gcc/Linux >>>>> or VS2013/2017 on Windows where C99 features work. >>>>> We should remove this difference on Solaris and remove or replace >>>>> the setting. >>>>> >>>>> Kim Barrett mentioned : >>>>> "I merely mentioned the C++14 work as evidence that removing >>>>> -xc99=%none% didn?t appear harmful." >>>>> However it will take more time until? the C++14? change is in." >>>>> >>>>> I am currently running a test build on our CI build system to >>>>> confirm that this does not break the Solaris build (but I'd be >>>>> highly surprised if it did). I will not push this until the builds >>>>> are cleared. >>>> Of course it was not that simple... :-( Two AWT libraries (at >>>> least) failed to build. I'm currently investigating if there's a >>>> simple fix to that. >>> New attempt, that fixes the two AWT libraries: >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >>> >>> >>> Now this passes the CI build test. >>> >>> /Magnus >>>> >>>> /Magnus >>>>> >>>>> /Magnus >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>> Patch inline: >>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>> b/make/autoconf/flags-cflags.m4 >>>>> --- a/make/autoconf/flags-cflags.m4 >>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>> @@ -559,7 +559,7 @@ >>>>> ???? TOOLCHAIN_CFLAGS="-errshort=tags" >>>>> >>>>> ???? TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>> -??? TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa >>>>> -W0,-noglobal $TOOLCHAIN_CFLAGS" # C only >>>>> +??? TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>> $TOOLCHAIN_CFLAGS" # C only >>>>> ???? TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>>> -xnolib" # CXX only >>>>> ???? TOOLCHAIN_CFLAGS_JVM="-template=no%extdef >>>>> -features=no%split_init \ >>>>> ???????? -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >>>> >>> > From philip.race at oracle.com Thu Dec 13 19:34:06 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Dec 2018 11:34:06 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> Message-ID: <4e1513f7-5425-b7a3-7470-a805bc05c7b4@oracle.com> On 12/13/18 10:07 AM, Erik Joelsson wrote: > ?* These macros only have an effect if the operating system supports > either > ?* POSIX 1003.1 or C99, or both.? On other operating systems > (particularly > ?* Windows/Visual Studio) there is no effect; the OS specific tests > below are > ?* still required (as of 2011-05-02.) > ?*/ > #ifndef _POSIX_SOURCE > # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > #endif > > This in turn triggers _XOPEN_OR_POSIX to be defined in > /usr/include/sys/feature_tests.h and so triggers the error. > > What I'm not clear about is if libpng is trying to declare that it > should not be compiled with any newer standards, That is my reading of what it is saying .. ie in case the compiler supports POSIX 1003.1 or C99, this tells it what version of the standard it would like. Since POSIX_SOURCE is apparently obsolete, it presumably would be interpreted by compilers as telling it that it is reading "old" code written to the earlier version of the standard. The use of the word "Just" is key to how I read their intent .. -phil. > > On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >> >>> -D_XPG6 >>> >>> ?? >> To be honest, I'm not completely sure about this. Without this >> define, the build failed with the following error message: >> Compiler or options invalid for pre-UNIX 03 X/Open applications and >> pre-2001 POSIX applications >> >> This was triggered by the following section in >> /usr/include/sys/feature_tests.h: >> /* >> ?* It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >> ?* using c99.? The same is true for POSIX.1-1990, POSIX.2-1992, >> POSIX.1b, >> ?* and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 >> ?* or a POSIX.1-2001 application with anything other than a c99 or later >> ?* compiler.? Therefore, we force an error in both cases. >> ?*/ >> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) >> #error "Compiler or options invalid for pre-UNIX 03 X/Open >> applications \ >> ??????? and pre-2001 POSIX applications" >> #elif !defined(_STDC_C99) && \ >> ??????? (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >> applications \ >> ??????? require the use of c99" >> #endif >> >> The solution, as also hinted to by searching for other resolutions to >> this error online, was to provide the _XPG6 system define. But >> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >> without _XPG6 set, and only when compiling this library and not >> others, I don't know. I also don't understand what the XPG standard >> refers to, nor what versions 2-5 means or what version 6 has that >> differs from them. >> >> By setting this flag, I am telling solaris include headers that we >> want to compile using the XPG standard version 6, instead of an older >> one. It solves the problem. I am happy enough with this. Are you? >> > It looks like this comes from libpng. It has this in > src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > > /* Feature Test Macros.? The following are defined here to ensure that > correctly > ?* implemented libraries reveal the APIs libpng needs to build and > hide those > ?* that are not needed and potentially damaging to the compilation. > ?* > ?* Feature Test Macros must be defined before any system header is > included (see > ?* POSIX 1003.1 2.8.2 "POSIX Symbols." > ?* > ?* These macros only have an effect if the operating system supports > either > ?* POSIX 1003.1 or C99, or both.? On other operating systems > (particularly > ?* Windows/Visual Studio) there is no effect; the OS specific tests > below are > ?* still required (as of 2011-05-02.) > ?*/ > #ifndef _POSIX_SOURCE > # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > #endif > > This in turn triggers _XOPEN_OR_POSIX to be defined in > /usr/include/sys/feature_tests.h and so triggers the error. > > What I'm not clear about is if libpng is trying to declare that it > should not be compiled with any newer standards, and so by doing that, > we risk introducing problems. Reading in the system header, it seems > the _XPG6 macro is internal and should not be used by the application. > It's derived from _XOPEN_SOURCE=600 or _POSIX_C_SOURCE=200112L which > is what applications should use. > > So the the question is, is it ok to override the requirements of > libpng or should it receive special treatment? If we are fine with > overriding, then we should use one of the public APIs instead. > > /Erik > >> /Magnus >> >>> >>> Thanks, >>> David >>> >>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>> From the bug report: >>>>>> "Currently? we disable C99 in the Solaris build by setting >>>>>> -xc99=%none%. >>>>>> This differs from a lot of other build environments like >>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>> We should remove this difference on Solaris and remove or replace >>>>>> the setting. >>>>>> >>>>>> Kim Barrett mentioned : >>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>> -xc99=%none% didn?t appear harmful." >>>>>> However it will take more time until? the C++14? change is in." >>>>>> >>>>>> I am currently running a test build on our CI build system to >>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>> highly surprised if it did). I will not push this until the >>>>>> builds are cleared. >>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>> least) failed to build. I'm currently investigating if there's a >>>>> simple fix to that. >>>> New attempt, that fixes the two AWT libraries: >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >>>> >>>> >>>> Now this passes the CI build test. >>>> >>>> /Magnus >>>>> >>>>> /Magnus >>>>>> >>>>>> /Magnus >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>> Patch inline: >>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>> b/make/autoconf/flags-cflags.m4 >>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>> @@ -559,7 +559,7 @@ >>>>>> ???? TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>> >>>>>> ???? TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>> -??? TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa >>>>>> -W0,-noglobal $TOOLCHAIN_CFLAGS" # C only >>>>>> +??? TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>> ???? TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>>>> -xnolib" # CXX only >>>>>> ???? TOOLCHAIN_CFLAGS_JVM="-template=no%extdef >>>>>> -features=no%split_init \ >>>>>> ???????? -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >>>>> >>>> >> From krishna.addepalli at oracle.com Fri Dec 14 02:16:46 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 13 Dec 2018 18:16:46 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: References: <55242033-cda1-6a5f-a9db-2cf2983b2e70@oracle.com> <2b0d65ff-002e-4923-835a-89ce24b2f607@default> <1b07b69f-67f3-4db5-b522-6e994a317f0e@default> <29319819-282f-49f0-9b0f-e1439ef44acf@default> <2dc502a9-0ade-40b3-98ca-4ddf09cefc14@default> <8a8bdc73-c896-48d0-97e8-8af968a79c5b@default> <08a7fbf1-24cb-45db-b9b6-c23c868828e0@default> <41440B2E-FEFD-4580-81A9-DDA83390477E@oracle.com> <36e04c0d-d2dc-3c1e-9cce-357f58d314bb@oracle.com> <0541f59e-6ab2-431d-a54e-deece5e13b8a@default> <2d674b82-75db-3a94-5cc7-8257b40b50da@oracle.com> <2fba4859-30df-404b-9082-5f66dd0a6c39@default> <8c290a51-3c8d-bf05-8cc8-5dd942bc3492@oracle.com> Message-ID: Hi Sergey, I hope that your query is answered. Could you review the new webrev and approve it? Thanks, Krishna -----Original Message----- From: Krishna Addepalli Sent: Tuesday, December 11, 2018 5:14 PM To: Sergey Bylokhov ; Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: RE: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi Sergey, I understand about the UB, but currently just including is causing this warning to appear, and there doesn't seem to be a way without doing irrelevant changes, so somewhat reluctantly I'm proposing plain C changes. Regarding the questions: 1. Currently, we expect that the user provides us the file name with the path. The only correction we are doing is that, if there is no explicit mention of extension, we add ".log". We donot expect to read a path and create a file (if that is what you meant by handling the absent slash at the end of the path). 2. I made all the declarations auto. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev09 Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, December 11, 2018 2:37 AM To: Krishna Addepalli ; Shashidhara Veerabhadraiah Cc: Prasanta Sadhukhan ; awt-dev at openjdk.java.net Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Hi, Krishna. On 10/12/2018 06:38, Krishna Addepalli wrote: > The only way to avoid changes to make file is by using C string manipulation API. > Here is the webrev: http://cr.openjdk.java.net/~kaddepalli/8196681/webrev08 , although I would personally prefer using the C++ api. Throwing a c++ exception out of "extern C", when the method is called from the other language is UB, so we should not throw any exception and use c++, or use plain c. Comment about the current version: - Do we handle the absent of the slash at the end of the path in "JAVA_ACCESSBRIDGE_LOGFILE"? - in some place you use auto and in another same situation you use "size_t", please unify. -- Best regards, Sergey. From sergey.bylokhov at oracle.com Fri Dec 14 04:37:26 2018 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 13 Dec 2018 20:37:26 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Message-ID: <0ac9c8a6-4615-4a7d-b815-6671313b22ff@default> Looks fine. > 2. I made all the declarations auto. Here is the new webrev: > http://cr.openjdk.java.net/~kaddepalli/8196681/webrev09 -- Best regards, Sergey. From krishna.addepalli at oracle.com Fri Dec 14 05:40:24 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 13 Dec 2018 21:40:24 -0800 (PST) Subject: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled In-Reply-To: <0ac9c8a6-4615-4a7d-b815-6671313b22ff@default> References: <0ac9c8a6-4615-4a7d-b815-6671313b22ff@default> Message-ID: <4573e716-d226-4f01-9185-1a4d4585e7d9@default> Thanks for the review Sergey! -----Original Message----- From: Sergey Bylokhov Sent: Friday, December 14, 2018 10:07 AM To: Krishna Addepalli Cc: Shashidhara Veerabhadraiah ; awt-dev at openjdk.java.net; Prasanta Sadhukhan Subject: Re: RFR: [12] JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled Looks fine. > 2. I made all the declarations auto. Here is the new webrev: > http://cr.openjdk.java.net/~kaddepalli/8196681/webrev09 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Dec 14 07:32:42 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 13 Dec 2018 23:32:42 -0800 Subject: [12] Review Request: 8215200 IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow Message-ID: <3954c039-6a75-2444-f650-b611c26424cb@oracle.com> Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8215200 Webrev: http://cr.openjdk.java.net/~serb/8215200/webrev.00 In the fix for JDK-8190230 we started to sort the list of owned windows to maintain their z-order. But there is a small issue in the compactor, because of this code: ======= if (p1 instanceof LWWindowPeer && p2 instanceof LWWindowPeer) { ..... } return 0; ======= It means that the window without the peer(p1==null or p2==null) is equal to any other windows, and this breaks the timsort. After the fix a windows without peers will be equal to each other only, and their lastBecomeMainTime timestamp will be zero. -- Best regards, Sergey. From krishna.addepalli at oracle.com Fri Dec 14 09:43:42 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 14 Dec 2018 01:43:42 -0800 (PST) Subject: [12] Review Request: 8215200 IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow In-Reply-To: <3954c039-6a75-2444-f650-b611c26424cb@oracle.com> References: <3954c039-6a75-2444-f650-b611c26424cb@oracle.com> Message-ID: <9ee22403-b940-412a-8d06-95f70bf05e55@default> Hi Sergey, The fix looks good to me. Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Friday, December 14, 2018 1:03 PM To: awt-dev at openjdk.java.net; dmitry markov Subject: [12] Review Request: 8215200 IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8215200 Webrev: http://cr.openjdk.java.net/~serb/8215200/webrev.00 In the fix for JDK-8190230 we started to sort the list of owned windows to maintain their z-order. But there is a small issue in the compactor, because of this code: ======= if (p1 instanceof LWWindowPeer && p2 instanceof LWWindowPeer) { ..... } return 0; ======= It means that the window without the peer(p1==null or p2==null) is equal to any other windows, and this breaks the timsort. After the fix a windows without peers will be equal to each other only, and their lastBecomeMainTime timestamp will be zero. -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Fri Dec 14 11:49:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 12:49:17 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> Message-ID: <457476de-096d-d65f-5d0b-e330dfeaf855@oracle.com> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >: > > On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >> >>> -D_XPG6 >>> >>> ?? >> To be honest, I'm not completely sure about this. Without this >> define, the build failed with the following error message: >> Compiler or options invalid for pre-UNIX 03 X/Open applications and >> pre-2001 POSIX applications >> >> This was triggered by the following section in >> /usr/include/sys/feature_tests.h: >> /* >> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, >> * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 >> * or a POSIX.1-2001 application with anything other than a c99 or later >> * compiler. Therefore, we force an error in both cases. >> */ >> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) >> #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ >> and pre-2001 POSIX applications" >> #elif !defined(_STDC_C99) && \ >> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >> applications \ >> require the use of c99" >> #endif >> >> The solution, as also hinted to by searching for other resolutions to >> this error online, was to provide the _XPG6 system define. But >> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >> without _XPG6 set, and only when compiling this library and not >> others, I don't know. I also don't understand what the XPG standard >> refers to, nor what versions 2-5 means or what version 6 has that >> differs from them. >> >> By setting this flag, I am telling solaris include headers that we >> want to compile using the XPG standard version 6, instead of an older >> one. It solves the problem. I am happy enough with this. Are you? >> > It looks like this comes from libpng. It has this in > src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > > /* Feature Test Macros. The following are defined here to ensure that > correctly > * implemented libraries reveal the APIs libpng needs to build and > hide those > * that are not needed and potentially damaging to the compilation. > * > * Feature Test Macros must be defined before any system header is > included (see > * POSIX 1003.1 2.8.2 "POSIX Symbols." > * > * These macros only have an effect if the operating system supports > either > * POSIX 1003.1 or C99, or both. On other operating systems (particularly > * Windows/Visual Studio) there is no effect; the OS specific tests > below are > * still required (as of 2011-05-02.) > */ > #ifndef _POSIX_SOURCE > # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > #endif > > This in turn triggers _XOPEN_OR_POSIX to be defined in > /usr/include/sys/feature_tests.h and so triggers the error. > > What I'm not clear about is if libpng is trying to declare that it > should not be compiled with any newer standards, and so by doing that, > we risk introducing problems. Reading in the system header, it seems > the _XPG6 macro is internal and should not be used by the application. > It's derived from _XOPEN_SOURCE=600 or _POSIX_C_SOURCE=200112L which > is what applications should use. Interesting. We should probably define one, or both of these. Perhaps globally for all native files and compilers. It might have been the case that the solstudio compiler set _POSIX_C_SOURCE for us before, prior to setting -std=c99. The following stack overflow article claims that this is at least the behavior of gcc/clang: https://stackoverflow.com/questions/21867897/c89-and-posix-at-the-same-time So we might have had an implicit _POSIX_C_SOURCE that we now miss. That would explain why this starts to fail. I'll see if I can confirm this the next time I log into a Solaris computer. Otoh, the same article claims, and it sounds reasonable, that we should set these variables ourself, to be well behaved and to minimize surprises. And I think this applies to all unix platforms, regardless of compiler being used. I'll see if I can kick off a test job with this to see how/if it influences other platforms. But it sounds like something we should do; the level of posix conformance should be controlled by us, not left to chance. We also need to verify, of course, that all platforms we want to support is capable of supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem though. Possibly on AIX... /Magnus > > So the the question is, is it ok to override the requirements of > libpng or should it receive special treatment? If we are fine with > overriding, then we should use one of the public APIs instead. > > /Erik > >> /Magnus >> >>> >>> Thanks, >>> David >>> >>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>> From the bug report: >>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>> -xc99=%none%. >>>>>> This differs from a lot of other build environments like >>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>> We should remove this difference on Solaris and remove or replace >>>>>> the setting. >>>>>> >>>>>> Kim Barrett mentioned : >>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>> -xc99=%none% didn?t appear harmful." >>>>>> However it will take more time until the C++14 change is in." >>>>>> >>>>>> I am currently running a test build on our CI build system to >>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>> highly surprised if it did). I will not push this until the >>>>>> builds are cleared. >>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>> least) failed to build. I'm currently investigating if there's a >>>>> simple fix to that. >>>> New attempt, that fixes the two AWT libraries: >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >>>> >>>> >>>> >>>> Now this passes the CI build test. >>>> >>>> /Magnus >>>>> >>>>> /Magnus >>>>>> >>>>>> /Magnus >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>> Patch inline: >>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>> b/make/autoconf/flags-cflags.m4 >>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>> @@ -559,7 +559,7 @@ >>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>> >>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>>>> -xnolib" # CXX only >>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ >>>>>> -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.b.bansal at oracle.com Fri Dec 14 13:48:55 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 14 Dec 2018 05:48:55 -0800 (PST) Subject: [12] Review Request: JDK-8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using Swing-FX interop Message-ID: <546e70ac-eff8-4d58-802a-25d8f04914a6@default> Hi All, Please review fix for the below bug jdk12: Bug: https://bugs.openjdk.java.net/browse/JDK-8215364 Webrev: http://cr.openjdk.java.net/~pbansal/8215364/webrev.00/ Issue: JavaFX uses both X11 and gtk code and gtk3 uses Wayland backend while running Ubuntu 18.04 in Wayland mode. This results in crash in JavaFX. This crash is being done under [1] by setting the gtk3 backend to x11 on all systems by setting GDK_BACKEND=x11. This fixes the JavaFX crash. However, while using the a JFXPanel inside Swing components in Swing-FX interop with GTKLookAndFeel set as L&F for Swing, the AWT loads the gtk3 first and as the GDK_BACKEND=x11 is not yet set even after the fix for [1], the gtk3 starts using the Wayland backend. Then while initializing the JFXPanel, JavaFX uses the same gtk library loaded by AWT and this results in crash. Fix: The fix is to set the gtk backend to x11 in AWT as well by setting the GDK_BACKEND=x11. This fixes the Swing-FX interop crash as well. [1] https://bugs.openjdk.java.net/browse/JDK-8210411 Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Fri Dec 14 14:39:26 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 15:39:26 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <457476de-096d-d65f-5d0b-e330dfeaf855@oracle.com> References: <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> <457476de-096d-d65f-5d0b-e330dfeaf855@oracle.com> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994@oracle.com> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: > > 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >: > >> >> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>> >>>> -D_XPG6 >>>> >>>> ?? >>> To be honest, I'm not completely sure about this. Without this >>> define, the build failed with the following error message: >>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>> pre-2001 POSIX applications >>> >>> This was triggered by the following section in >>> /usr/include/sys/feature_tests.h: >>> /* >>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>> POSIX.1b, >>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>> XPG6 >>> * or a POSIX.1-2001 application with anything other than a c99 or >>> later >>> * compiler. Therefore, we force an error in both cases. >>> */ >>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>> !defined(_XPG6)) >>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>> applications \ >>> and pre-2001 POSIX applications" >>> #elif !defined(_STDC_C99) && \ >>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>> applications \ >>> require the use of c99" >>> #endif >>> >>> The solution, as also hinted to by searching for other resolutions >>> to this error online, was to provide the _XPG6 system define. But >>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>> without _XPG6 set, and only when compiling this library and not >>> others, I don't know. I also don't understand what the XPG standard >>> refers to, nor what versions 2-5 means or what version 6 has that >>> differs from them. >>> >>> By setting this flag, I am telling solaris include headers that we >>> want to compile using the XPG standard version 6, instead of an >>> older one. It solves the problem. I am happy enough with this. Are you? >>> >> It looks like this comes from libpng. It has this in >> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >> >> /* Feature Test Macros. The following are defined here to ensure >> that correctly >> * implemented libraries reveal the APIs libpng needs to build and >> hide those >> * that are not needed and potentially damaging to the compilation. >> * >> * Feature Test Macros must be defined before any system header is >> included (see >> * POSIX 1003.1 2.8.2 "POSIX Symbols." >> * >> * These macros only have an effect if the operating system supports >> either >> * POSIX 1003.1 or C99, or both. On other operating systems >> (particularly >> * Windows/Visual Studio) there is no effect; the OS specific tests >> below are >> * still required (as of 2011-05-02.) >> */ >> #ifndef _POSIX_SOURCE >> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >> #endif >> >> This in turn triggers _XOPEN_OR_POSIX to be defined in >> /usr/include/sys/feature_tests.h and so triggers the error. >> >> What I'm not clear about is if libpng is trying to declare that it >> should not be compiled with any newer standards, and so by doing >> that, we risk introducing problems. Reading in the system header, it >> seems the _XPG6 macro is internal and should not be used by the >> application. It's derived from _XOPEN_SOURCE=600 or >> _POSIX_C_SOURCE=200112L which is what applications should use. > > Interesting. We should probably define one, or both of these. Perhaps > globally for all native files and compilers. It might have been the > case that the solstudio compiler set _POSIX_C_SOURCE for us before, > prior to setting -std=c99. The following stack overflow article claims > that this is at least the behavior of gcc/clang: > > https://stackoverflow.com/questions/21867897/c89-and-posix-at-the-same-time > > > So we might have had an implicit _POSIX_C_SOURCE that we now miss. > That would explain why this starts to fail. I'll see if I can confirm > this the next time I log into a Solaris computer. Of course it was not as simple. Setting: ifeq ($(OPENJDK_TARGET_OS), solaris) LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 endif instead made us fail with: open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", line 143: error: incomplete struct/union/enum timezone: tz I don't have more time to dig into this now. Overall, changes such as these make it all feel a bit scary; I recommend that any change to this be made in JDK 13 and not 12. /Magnus > > Otoh, the same article claims, and it sounds reasonable, that we > should set these variables ourself, to be well behaved and to minimize > surprises. And I think this applies to all unix platforms, regardless > of compiler being used. I'll see if I can kick off a test job with > this to see how/if it influences other platforms. But it sounds like > something we should do; the level of posix conformance should be > controlled by us, not left to chance. We also need to verify, of > course, that all platforms we want to support is capable of > supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem though. > Possibly on AIX... > > /Magnus > >> >> So the the question is, is it ok to override the requirements of >> libpng or should it receive special treatment? If we are fine with >> overriding, then we should use one of the public APIs instead. >> >> /Erik >> >>> /Magnus >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>> From the bug report: >>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>> -xc99=%none%. >>>>>>> This differs from a lot of other build environments like >>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>> We should remove this difference on Solaris and remove or >>>>>>> replace the setting. >>>>>>> >>>>>>> Kim Barrett mentioned : >>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>> However it will take more time until the C++14 change is in." >>>>>>> >>>>>>> I am currently running a test build on our CI build system to >>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>> highly surprised if it did). I will not push this until the >>>>>>> builds are cleared. >>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>> least) failed to build. I'm currently investigating if there's a >>>>>> simple fix to that. >>>>> New attempt, that fixes the two AWT libraries: >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >>>>> >>>>> >>>>> >>>>> Now this passes the CI build test. >>>>> >>>>> /Magnus >>>>>> >>>>>> /Magnus >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>> Patch inline: >>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>> @@ -559,7 +559,7 @@ >>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>> >>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>>>>> -xnolib" # CXX only >>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ >>>>>>> -library=stlport4 -mt -features=no%except >>>>>>> $TOOLCHAIN_FLAGS" >>>>>> >>>>> >>> From matthias.baesken at sap.com Mon Dec 17 13:12:12 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 17 Dec 2018 13:12:12 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris Message-ID: Hello, please review http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ in my change just -xc99=%none is removed, so we do not forbid c99 coding. The -Xa compile flag is kept, no special additional settings are needed to compile png/awt . Thanks, Matthias > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 Dec 2018 15:39:26 +0100 > From: Magnus Ihse Bursie > To: Erik Joelsson , build-dev > , "awt-dev at openjdk.java.net" > , 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on > Solaris > Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > > > On 2018-12-14 12:49, Magnus Ihse Bursie wrote: > > > > 13 dec. 2018 kl. 19:07 skrev Erik Joelsson > >: > > > >> > >> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: > >>> > >>>> -D_XPG6 > >>>> > >>>> ?? > >>> To be honest, I'm not completely sure about this. Without this > >>> define, the build failed with the following error message: > >>> Compiler or options invalid for pre-UNIX 03 X/Open applications and > >>> pre-2001 POSIX applications > >>> > >>> This was triggered by the following section in > >>> /usr/include/sys/feature_tests.h: > >>> /* > >>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application > >>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, > >>> POSIX.1b, > >>> * and POSIX.1c applications. Likewise, it is invalid to compile an > >>> XPG6 > >>> * or a POSIX.1-2001 application with anything other than a c99 or > >>> later > >>> * compiler. Therefore, we force an error in both cases. > >>> */ > >>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && > >>> !defined(_XPG6)) > >>> #error "Compiler or options invalid for pre-UNIX 03 X/Open > >>> applications \ > >>> and pre-2001 POSIX applications" > >>> #elif !defined(_STDC_C99) && \ > >>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) > >>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 > >>> applications \ > >>> require the use of c99" > >>> #endif > >>> > >>> The solution, as also hinted to by searching for other resolutions > >>> to this error online, was to provide the _XPG6 system define. But > >>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, > >>> without _XPG6 set, and only when compiling this library and not > >>> others, I don't know. I also don't understand what the XPG standard > >>> refers to, nor what versions 2-5 means or what version 6 has that > >>> differs from them. > >>> > >>> By setting this flag, I am telling solaris include headers that we > >>> want to compile using the XPG standard version 6, instead of an > >>> older one. It solves the problem. I am happy enough with this. Are you? > >>> > >> It looks like this comes from libpng. It has this in > >> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > >> > >> /* Feature Test Macros. The following are defined here to ensure > >> that correctly > >> * implemented libraries reveal the APIs libpng needs to build and > >> hide those > >> * that are not needed and potentially damaging to the compilation. > >> * > >> * Feature Test Macros must be defined before any system header is > >> included (see > >> * POSIX 1003.1 2.8.2 "POSIX Symbols." > >> * > >> * These macros only have an effect if the operating system supports > >> either > >> * POSIX 1003.1 or C99, or both. On other operating systems > >> (particularly > >> * Windows/Visual Studio) there is no effect; the OS specific tests > >> below are > >> * still required (as of 2011-05-02.) > >> */ > >> #ifndef _POSIX_SOURCE > >> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > >> #endif > >> > >> This in turn triggers _XOPEN_OR_POSIX to be defined in > >> /usr/include/sys/feature_tests.h and so triggers the error. > >> > >> What I'm not clear about is if libpng is trying to declare that it > >> should not be compiled with any newer standards, and so by doing > >> that, we risk introducing problems. Reading in the system header, it > >> seems the _XPG6 macro is internal and should not be used by the > >> application. It's derived from _XOPEN_SOURCE=600 or > >> _POSIX_C_SOURCE=200112L which is what applications should use. > > > > Interesting. We should probably define one, or both of these. Perhaps > > globally for all native files and compilers. It might have been the > > case that the solstudio compiler set _POSIX_C_SOURCE for us before, > > prior to setting -std=c99. The following stack overflow article claims > > that this is at least the behavior of gcc/clang: > > > > https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- > same-time > > > > > > So we might have had an implicit _POSIX_C_SOURCE that we now miss. > > That would explain why this starts to fail. I'll see if I can confirm > > this the next time I log into a Solaris computer. > Of course it was not as simple. Setting: > ifeq ($(OPENJDK_TARGET_OS), solaris) > LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - > D_XOPEN_SOURCE=600 > endif > > instead made us fail with: > open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", > line 143: error: incomplete struct/union/enum timezone: tz > > I don't have more time to dig into this now. Overall, changes such as > these make it all feel a bit scary; I recommend that any change to this > be made in JDK 13 and not 12. > > /Magnus > > > > Otoh, the same article claims, and it sounds reasonable, that we > > should set these variables ourself, to be well behaved and to minimize > > surprises. And I think this applies to all unix platforms, regardless > > of compiler being used. I'll see if I can kick off a test job with > > this to see how/if it influences other platforms. But it sounds like > > something we should do; the level of posix conformance should be > > controlled by us, not left to chance. We also need to verify, of > > course, that all platforms we want to support is capable of > > supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem > though. > > Possibly on AIX... > > > > /Magnus > > > >> > >> So the the question is, is it ok to override the requirements of > >> libpng or should it receive special treatment? If we are fine with > >> overriding, then we should use one of the public APIs instead. > >> > >> /Erik > >> > >>> /Magnus > >>> > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: > >>>>> > >>>>> > >>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: > >>>>>> > >>>>>> > >>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: > >>>>>>> From the bug report: > >>>>>>> "Currently we disable C99 in the Solaris build by setting > >>>>>>> -xc99=%none%. > >>>>>>> This differs from a lot of other build environments like > >>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. > >>>>>>> We should remove this difference on Solaris and remove or > >>>>>>> replace the setting. > >>>>>>> > >>>>>>> Kim Barrett mentioned : > >>>>>>> "I merely mentioned the C++14 work as evidence that removing > >>>>>>> -xc99=%none% didn?t appear harmful." > >>>>>>> However it will take more time until the C++14 change is in." > >>>>>>> > >>>>>>> I am currently running a test build on our CI build system to > >>>>>>> confirm that this does not break the Solaris build (but I'd be > >>>>>>> highly surprised if it did). I will not push this until the > >>>>>>> builds are cleared. > >>>>>> Of course it was not that simple... :-( Two AWT libraries (at > >>>>>> least) failed to build. I'm currently investigating if there's a > >>>>>> simple fix to that. > >>>>> New attempt, that fixes the two AWT libraries: > >>>>> WebRev: > >>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- > c99/webrev.01 > >>>>> with-c99/webrev.01> > >>>>> > >>>>> > >>>>> Now this passes the CI build test. > >>>>> > >>>>> /Magnus > >>>>>> > >>>>>> /Magnus > >>>>>>> > >>>>>>> /Magnus > >>>>>>> > >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 > >>>>>>> Patch inline: > >>>>>>> diff --git a/make/autoconf/flags-cflags.m4 > >>>>>>> b/make/autoconf/flags-cflags.m4 > >>>>>>> --- a/make/autoconf/flags-cflags.m4 > >>>>>>> +++ b/make/autoconf/flags-cflags.m4 > >>>>>>> @@ -559,7 +559,7 @@ > >>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" > >>>>>>> > >>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" > >>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- > noglobal > >>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal > >>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - > norunpath > >>>>>>> -xnolib" # CXX only > >>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - > features=no%split_init \ > >>>>>>> -library=stlport4 -mt -features=no%except > >>>>>>> $TOOLCHAIN_FLAGS" > >>>>>> > >>>>> > >>> > From dmitry.markov at oracle.com Mon Dec 17 13:42:25 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 17 Dec 2018 13:42:25 +0000 Subject: [12] Review Request: 8215200 IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow In-Reply-To: <3954c039-6a75-2444-f650-b611c26424cb@oracle.com> References: <3954c039-6a75-2444-f650-b611c26424cb@oracle.com> Message-ID: <4F69C3EA-A231-4E4C-8890-D57258D67FB8@oracle.com> Hi Sergey, The fix looks good. Thanks, Dmitry > On 14 Dec 2018, at 07:32, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk 12. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215200 > Webrev: http://cr.openjdk.java.net/~serb/8215200/webrev.00 > > In the fix for JDK-8190230 we started to sort the list > of owned windows to maintain their z-order. But there is a small > issue in the compactor, because of this code: > > ======= > if (p1 instanceof LWWindowPeer && p2 instanceof LWWindowPeer) { > ..... > } > return 0; > ======= > > It means that the window without the peer(p1==null or p2==null) > is equal to any other windows, and this breaks the timsort. > > After the fix a windows without peers will be equal to each other only, and their > lastBecomeMainTime timestamp will be zero. > > -- > Best regards, Sergey. From magnus.ihse.bursie at oracle.com Mon Dec 17 15:10:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Dec 2018 16:10:40 +0100 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: Message-ID: Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do you intend to push to 12 or 13? Looks good to me, as long as it doesn't break anything. /Magnus > 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias : > > > Hello, please review > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > > in my change just -xc99=%none is removed, so we do not forbid c99 coding. > > The -Xa compile flag is kept, no special additional settings are needed to compile png/awt . > > > Thanks, Matthias > > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 14 Dec 2018 15:39:26 +0100 >> From: Magnus Ihse Bursie >> To: Erik Joelsson , build-dev >> , "awt-dev at openjdk.java.net" >> , 2d-dev <2d-dev at openjdk.java.net> >> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >> Solaris >> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> >> >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>> >>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >> >: >>> >>>> >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>> >>>>>> -D_XPG6 >>>>>> >>>>>> ?? >>>>> To be honest, I'm not completely sure about this. Without this >>>>> define, the build failed with the following error message: >>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>> pre-2001 POSIX applications >>>>> >>>>> This was triggered by the following section in >>>>> /usr/include/sys/feature_tests.h: >>>>> /* >>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>> POSIX.1b, >>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>> XPG6 >>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>> later >>>>> * compiler. Therefore, we force an error in both cases. >>>>> */ >>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>> !defined(_XPG6)) >>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>> applications \ >>>>> and pre-2001 POSIX applications" >>>>> #elif !defined(_STDC_C99) && \ >>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>> applications \ >>>>> require the use of c99" >>>>> #endif >>>>> >>>>> The solution, as also hinted to by searching for other resolutions >>>>> to this error online, was to provide the _XPG6 system define. But >>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>>>> without _XPG6 set, and only when compiling this library and not >>>>> others, I don't know. I also don't understand what the XPG standard >>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>> differs from them. >>>>> >>>>> By setting this flag, I am telling solaris include headers that we >>>>> want to compile using the XPG standard version 6, instead of an >>>>> older one. It solves the problem. I am happy enough with this. Are you? >>>> It looks like this comes from libpng. It has this in >>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>> >>>> /* Feature Test Macros. The following are defined here to ensure >>>> that correctly >>>> * implemented libraries reveal the APIs libpng needs to build and >>>> hide those >>>> * that are not needed and potentially damaging to the compilation. >>>> * >>>> * Feature Test Macros must be defined before any system header is >>>> included (see >>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>> * >>>> * These macros only have an effect if the operating system supports >>>> either >>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>> (particularly >>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>> below are >>>> * still required (as of 2011-05-02.) >>>> */ >>>> #ifndef _POSIX_SOURCE >>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>> #endif >>>> >>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>> >>>> What I'm not clear about is if libpng is trying to declare that it >>>> should not be compiled with any newer standards, and so by doing >>>> that, we risk introducing problems. Reading in the system header, it >>>> seems the _XPG6 macro is internal and should not be used by the >>>> application. It's derived from _XOPEN_SOURCE=600 or >>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>> >>> Interesting. We should probably define one, or both of these. Perhaps >>> globally for all native files and compilers. It might have been the >>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>> prior to setting -std=c99. The following stack overflow article claims >>> that this is at least the behavior of gcc/clang: >>> >>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >> same-time >>> >>> >>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>> That would explain why this starts to fail. I'll see if I can confirm >>> this the next time I log into a Solaris computer. >> Of course it was not as simple. Setting: >> ifeq ($(OPENJDK_TARGET_OS), solaris) >> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >> D_XOPEN_SOURCE=600 >> endif >> >> instead made us fail with: >> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >> line 143: error: incomplete struct/union/enum timezone: tz >> >> I don't have more time to dig into this now. Overall, changes such as >> these make it all feel a bit scary; I recommend that any change to this >> be made in JDK 13 and not 12. >> >> /Magnus >>> >>> Otoh, the same article claims, and it sounds reasonable, that we >>> should set these variables ourself, to be well behaved and to minimize >>> surprises. And I think this applies to all unix platforms, regardless >>> of compiler being used. I'll see if I can kick off a test job with >>> this to see how/if it influences other platforms. But it sounds like >>> something we should do; the level of posix conformance should be >>> controlled by us, not left to chance. We also need to verify, of >>> course, that all platforms we want to support is capable of >>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >> though. >>> Possibly on AIX... >>> >>> /Magnus >>> >>>> >>>> So the the question is, is it ok to override the requirements of >>>> libpng or should it receive special treatment? If we are fine with >>>> overriding, then we should use one of the public APIs instead. >>>> >>>> /Erik >>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>> From the bug report: >>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>> -xc99=%none%. >>>>>>>>> This differs from a lot of other build environments like >>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>> replace the setting. >>>>>>>>> >>>>>>>>> Kim Barrett mentioned : >>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>> >>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>> builds are cleared. >>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>> simple fix to that. >>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>> WebRev: >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- >> c99/webrev.01 >>>>>>> > with-c99/webrev.01> >>>>>>> >>>>>>> >>>>>>> Now this passes the CI build test. >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>> Patch inline: >>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>> >>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- >> noglobal >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >> norunpath >>>>>>>>> -xnolib" # CXX only >>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >> features=no%split_init \ >>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>> $TOOLCHAIN_FLAGS" > From matthias.baesken at sap.com Mon Dec 17 15:24:22 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 17 Dec 2018 15:24:22 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: Message-ID: > Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do > you intend to push to 12 or 13? Hi Magus, thanks for the review. I think it is safer to go for 13 , what's your opinion ? I put it into our internal build+test queue first , after this is fine , I will go for jdk-submit (hopefully it works ). Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Montag, 17. Dezember 2018 16:11 > To: Baesken, Matthias > Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- > dev at openjdk.java.net; awt-dev at openjdk.java.net > Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > Solaris > > Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do > you intend to push to 12 or 13? > > Looks good to me, as long as it doesn't break anything. > > /Magnus > > > 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias > : > > > > > > Hello, please review > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > > > > in my change just -xc99=%none is removed, so we do not forbid c99 > coding. > > > > The -Xa compile flag is kept, no special additional settings are needed to > compile png/awt . > > > > > > Thanks, Matthias > > > > > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Fri, 14 Dec 2018 15:39:26 +0100 > >> From: Magnus Ihse Bursie > >> To: Erik Joelsson , build-dev > >> , "awt-dev at openjdk.java.net" > >> , 2d-dev <2d-dev at openjdk.java.net> > >> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on > >> Solaris > >> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> > >> Content-Type: text/plain; charset=utf-8; format=flowed > >> > >> > >> > >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: > >>> > >>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >>> >: > >>> > >>>> > >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: > >>>>> > >>>>>> -D_XPG6 > >>>>>> > >>>>>> ?? > >>>>> To be honest, I'm not completely sure about this. Without this > >>>>> define, the build failed with the following error message: > >>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and > >>>>> pre-2001 POSIX applications > >>>>> > >>>>> This was triggered by the following section in > >>>>> /usr/include/sys/feature_tests.h: > >>>>> /* > >>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application > >>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, > >>>>> POSIX.1b, > >>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an > >>>>> XPG6 > >>>>> * or a POSIX.1-2001 application with anything other than a c99 or > >>>>> later > >>>>> * compiler. Therefore, we force an error in both cases. > >>>>> */ > >>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && > >>>>> !defined(_XPG6)) > >>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open > >>>>> applications \ > >>>>> and pre-2001 POSIX applications" > >>>>> #elif !defined(_STDC_C99) && \ > >>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) > >>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 > >>>>> applications \ > >>>>> require the use of c99" > >>>>> #endif > >>>>> > >>>>> The solution, as also hinted to by searching for other resolutions > >>>>> to this error online, was to provide the _XPG6 system define. But > >>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX > set, > >>>>> without _XPG6 set, and only when compiling this library and not > >>>>> others, I don't know. I also don't understand what the XPG standard > >>>>> refers to, nor what versions 2-5 means or what version 6 has that > >>>>> differs from them. > >>>>> > >>>>> By setting this flag, I am telling solaris include headers that we > >>>>> want to compile using the XPG standard version 6, instead of an > >>>>> older one. It solves the problem. I am happy enough with this. Are > you? > >>>> It looks like this comes from libpng. It has this in > >>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > >>>> > >>>> /* Feature Test Macros. The following are defined here to ensure > >>>> that correctly > >>>> * implemented libraries reveal the APIs libpng needs to build and > >>>> hide those > >>>> * that are not needed and potentially damaging to the compilation. > >>>> * > >>>> * Feature Test Macros must be defined before any system header is > >>>> included (see > >>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." > >>>> * > >>>> * These macros only have an effect if the operating system supports > >>>> either > >>>> * POSIX 1003.1 or C99, or both. On other operating systems > >>>> (particularly > >>>> * Windows/Visual Studio) there is no effect; the OS specific tests > >>>> below are > >>>> * still required (as of 2011-05-02.) > >>>> */ > >>>> #ifndef _POSIX_SOURCE > >>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > >>>> #endif > >>>> > >>>> This in turn triggers _XOPEN_OR_POSIX to be defined in > >>>> /usr/include/sys/feature_tests.h and so triggers the error. > >>>> > >>>> What I'm not clear about is if libpng is trying to declare that it > >>>> should not be compiled with any newer standards, and so by doing > >>>> that, we risk introducing problems. Reading in the system header, it > >>>> seems the _XPG6 macro is internal and should not be used by the > >>>> application. It's derived from _XOPEN_SOURCE=600 or > >>>> _POSIX_C_SOURCE=200112L which is what applications should use. > >>> > >>> Interesting. We should probably define one, or both of these. Perhaps > >>> globally for all native files and compilers. It might have been the > >>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, > >>> prior to setting -std=c99. The following stack overflow article claims > >>> that this is at least the behavior of gcc/clang: > >>> > >>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- > >> same-time > >>> > >>> > >>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. > >>> That would explain why this starts to fail. I'll see if I can confirm > >>> this the next time I log into a Solaris computer. > >> Of course it was not as simple. Setting: > >> ifeq ($(OPENJDK_TARGET_OS), solaris) > >> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - > >> D_XOPEN_SOURCE=600 > >> endif > >> > >> instead made us fail with: > >> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", > >> line 143: error: incomplete struct/union/enum timezone: tz > >> > >> I don't have more time to dig into this now. Overall, changes such as > >> these make it all feel a bit scary; I recommend that any change to this > >> be made in JDK 13 and not 12. > >> > >> /Magnus > >>> > >>> Otoh, the same article claims, and it sounds reasonable, that we > >>> should set these variables ourself, to be well behaved and to minimize > >>> surprises. And I think this applies to all unix platforms, regardless > >>> of compiler being used. I'll see if I can kick off a test job with > >>> this to see how/if it influences other platforms. But it sounds like > >>> something we should do; the level of posix conformance should be > >>> controlled by us, not left to chance. We also need to verify, of > >>> course, that all platforms we want to support is capable of > >>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem > >> though. > >>> Possibly on AIX... > >>> > >>> /Magnus > >>> > >>>> > >>>> So the the question is, is it ok to override the requirements of > >>>> libpng or should it receive special treatment? If we are fine with > >>>> overriding, then we should use one of the public APIs instead. > >>>> > >>>> /Erik > >>>> > >>>>> /Magnus > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: > >>>>>>> > >>>>>>> > >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: > >>>>>>>>> From the bug report: > >>>>>>>>> "Currently we disable C99 in the Solaris build by setting > >>>>>>>>> -xc99=%none%. > >>>>>>>>> This differs from a lot of other build environments like > >>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. > >>>>>>>>> We should remove this difference on Solaris and remove or > >>>>>>>>> replace the setting. > >>>>>>>>> > >>>>>>>>> Kim Barrett mentioned : > >>>>>>>>> "I merely mentioned the C++14 work as evidence that removing > >>>>>>>>> -xc99=%none% didn?t appear harmful." > >>>>>>>>> However it will take more time until the C++14 change is in." > >>>>>>>>> > >>>>>>>>> I am currently running a test build on our CI build system to > >>>>>>>>> confirm that this does not break the Solaris build (but I'd be > >>>>>>>>> highly surprised if it did). I will not push this until the > >>>>>>>>> builds are cleared. > >>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at > >>>>>>>> least) failed to build. I'm currently investigating if there's a > >>>>>>>> simple fix to that. > >>>>>>> New attempt, that fixes the two AWT libraries: > >>>>>>> WebRev: > >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- > with- > >> c99/webrev.01 > >>>>>>> >> with-c99/webrev.01> > >>>>>>> > >>>>>>> > >>>>>>> Now this passes the CI build test. > >>>>>>> > >>>>>>> /Magnus > >>>>>>>> > >>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 > >>>>>>>>> Patch inline: > >>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 > >>>>>>>>> b/make/autoconf/flags-cflags.m4 > >>>>>>>>> --- a/make/autoconf/flags-cflags.m4 > >>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 > >>>>>>>>> @@ -559,7 +559,7 @@ > >>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" > >>>>>>>>> > >>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" > >>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - > W0,- > >> noglobal > >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- > noglobal > >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - > >> norunpath > >>>>>>>>> -xnolib" # CXX only > >>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - > >> features=no%split_init \ > >>>>>>>>> -library=stlport4 -mt -features=no%except > >>>>>>>>> $TOOLCHAIN_FLAGS" > > From david.holmes at oracle.com Mon Dec 17 22:02:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 08:02:16 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: Message-ID: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> Hi Matthias, On 17/12/2018 11:12 pm, Baesken, Matthias wrote: > > Hello, please review > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > > in my change just -xc99=%none is removed, so we do not forbid c99 coding. > > The -Xa compile flag is kept, no special additional settings are needed to compile png/awt . It's not at all clear to me that C99-isms will be allowed if -Xa is set. I don't think jdk-submit tests Solaris. I'm putting this through our internal builds. Thanks, David > > Thanks, Matthias > > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 14 Dec 2018 15:39:26 +0100 >> From: Magnus Ihse Bursie >> To: Erik Joelsson , build-dev >> , "awt-dev at openjdk.java.net" >> , 2d-dev <2d-dev at openjdk.java.net> >> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >> Solaris >> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> >> >> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>> >>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >> >: >>> >>>> >>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>> >>>>>> -D_XPG6 >>>>>> >>>>>> ?? >>>>> To be honest, I'm not completely sure about this. Without this >>>>> define, the build failed with the following error message: >>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>> pre-2001 POSIX applications >>>>> >>>>> This was triggered by the following section in >>>>> /usr/include/sys/feature_tests.h: >>>>> /* >>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>> POSIX.1b, >>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>> XPG6 >>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>> later >>>>> * compiler. Therefore, we force an error in both cases. >>>>> */ >>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>> !defined(_XPG6)) >>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>> applications \ >>>>> and pre-2001 POSIX applications" >>>>> #elif !defined(_STDC_C99) && \ >>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>> applications \ >>>>> require the use of c99" >>>>> #endif >>>>> >>>>> The solution, as also hinted to by searching for other resolutions >>>>> to this error online, was to provide the _XPG6 system define. But >>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>>>> without _XPG6 set, and only when compiling this library and not >>>>> others, I don't know. I also don't understand what the XPG standard >>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>> differs from them. >>>>> >>>>> By setting this flag, I am telling solaris include headers that we >>>>> want to compile using the XPG standard version 6, instead of an >>>>> older one. It solves the problem. I am happy enough with this. Are you? >>>>> >>>> It looks like this comes from libpng. It has this in >>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>> >>>> /* Feature Test Macros. The following are defined here to ensure >>>> that correctly >>>> * implemented libraries reveal the APIs libpng needs to build and >>>> hide those >>>> * that are not needed and potentially damaging to the compilation. >>>> * >>>> * Feature Test Macros must be defined before any system header is >>>> included (see >>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>> * >>>> * These macros only have an effect if the operating system supports >>>> either >>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>> (particularly >>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>> below are >>>> * still required (as of 2011-05-02.) >>>> */ >>>> #ifndef _POSIX_SOURCE >>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>> #endif >>>> >>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>> >>>> What I'm not clear about is if libpng is trying to declare that it >>>> should not be compiled with any newer standards, and so by doing >>>> that, we risk introducing problems. Reading in the system header, it >>>> seems the _XPG6 macro is internal and should not be used by the >>>> application. It's derived from _XOPEN_SOURCE=600 or >>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>> >>> Interesting. We should probably define one, or both of these. Perhaps >>> globally for all native files and compilers. It might have been the >>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>> prior to setting -std=c99. The following stack overflow article claims >>> that this is at least the behavior of gcc/clang: >>> >>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >> same-time >>> >>> >>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>> That would explain why this starts to fail. I'll see if I can confirm >>> this the next time I log into a Solaris computer. >> Of course it was not as simple. Setting: >> ifeq ($(OPENJDK_TARGET_OS), solaris) >> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >> D_XOPEN_SOURCE=600 >> endif >> >> instead made us fail with: >> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >> line 143: error: incomplete struct/union/enum timezone: tz >> >> I don't have more time to dig into this now. Overall, changes such as >> these make it all feel a bit scary; I recommend that any change to this >> be made in JDK 13 and not 12. >> >> /Magnus >>> >>> Otoh, the same article claims, and it sounds reasonable, that we >>> should set these variables ourself, to be well behaved and to minimize >>> surprises. And I think this applies to all unix platforms, regardless >>> of compiler being used. I'll see if I can kick off a test job with >>> this to see how/if it influences other platforms. But it sounds like >>> something we should do; the level of posix conformance should be >>> controlled by us, not left to chance. We also need to verify, of >>> course, that all platforms we want to support is capable of >>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >> though. >>> Possibly on AIX... >>> >>> /Magnus >>> >>>> >>>> So the the question is, is it ok to override the requirements of >>>> libpng or should it receive special treatment? If we are fine with >>>> overriding, then we should use one of the public APIs instead. >>>> >>>> /Erik >>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>> From the bug report: >>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>> -xc99=%none%. >>>>>>>>> This differs from a lot of other build environments like >>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>> replace the setting. >>>>>>>>> >>>>>>>>> Kim Barrett mentioned : >>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>> >>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>> builds are cleared. >>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>> simple fix to that. >>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>> WebRev: >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- >> c99/webrev.01 >>>>>>> > with-c99/webrev.01> >>>>>>> >>>>>>> >>>>>>> Now this passes the CI build test. >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>> Patch inline: >>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>> >>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- >> noglobal >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >> norunpath >>>>>>>>> -xnolib" # CXX only >>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >> features=no%split_init \ >>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>> $TOOLCHAIN_FLAGS" >>>>>>>> >>>>>>> >>>>> >> > From david.holmes at oracle.com Tue Dec 18 00:24:25 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 10:24:25 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> References: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> Message-ID: <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> Our internal builds pass okay. David On 18/12/2018 8:02 am, David Holmes wrote: > Hi Matthias, > > On 17/12/2018 11:12 pm, Baesken, Matthias wrote: >> >> Hello,? please review >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >> >> in my change just -xc99=%none? is removed, so we do not forbid c99 >> coding. >> >> The -Xa compile flag is kept,? no special additional settings are >> needed to compile png/awt . > > It's not at all clear to me that C99-isms will be allowed if -Xa is set. > > I don't think jdk-submit tests Solaris. I'm putting this through our > internal builds. > > Thanks, > David > >> >> Thanks, Matthias >> >> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>> From: Magnus Ihse Bursie >>> To: Erik Joelsson , build-dev >>> ????, "awt-dev at openjdk.java.net" >>> ????, 2d-dev <2d-dev at openjdk.java.net> >>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>> ????Solaris >>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> >>> >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>> >>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >>> >: >>>> >>>>> >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>> >>>>>>> -D_XPG6 >>>>>>> >>>>>>> ?? >>>>>> To be honest, I'm not completely sure about this. Without this >>>>>> define, the build failed with the following error message: >>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>> pre-2001 POSIX applications >>>>>> >>>>>> This was triggered by the following section in >>>>>> /usr/include/sys/feature_tests.h: >>>>>> /* >>>>>> ? * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 >>>>>> application >>>>>> ? * using c99.? The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>> POSIX.1b, >>>>>> ? * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>> XPG6 >>>>>> ? * or a POSIX.1-2001 application with anything other than a c99 or >>>>>> later >>>>>> ? * compiler.? Therefore, we force an error in both cases. >>>>>> ? */ >>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>> !defined(_XPG6)) >>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>> applications \ >>>>>> ???????? and pre-2001 POSIX applications" >>>>>> #elif !defined(_STDC_C99) && \ >>>>>> ???????? (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>> applications \ >>>>>> ???????? require the use of c99" >>>>>> #endif >>>>>> >>>>>> The solution, as also hinted to by searching for other resolutions >>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>>>>> without _XPG6 set, and only when compiling this library and not >>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>> differs from them. >>>>>> >>>>>> By setting this flag, I am telling solaris include headers that we >>>>>> want to compile using the XPG standard version 6, instead of an >>>>>> older one. It solves the problem. I am happy enough with this. Are >>>>>> you? >>>>>> >>>>> It looks like this comes from libpng. It has this in >>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>> >>>>> /* Feature Test Macros.? The following are defined here to ensure >>>>> that correctly >>>>> ? * implemented libraries reveal the APIs libpng needs to build and >>>>> hide those >>>>> ? * that are not needed and potentially damaging to the compilation. >>>>> ? * >>>>> ? * Feature Test Macros must be defined before any system header is >>>>> included (see >>>>> ? * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>> ? * >>>>> ? * These macros only have an effect if the operating system supports >>>>> either >>>>> ? * POSIX 1003.1 or C99, or both.? On other operating systems >>>>> (particularly >>>>> ? * Windows/Visual Studio) there is no effect; the OS specific tests >>>>> below are >>>>> ? * still required (as of 2011-05-02.) >>>>> ? */ >>>>> #ifndef _POSIX_SOURCE >>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>> #endif >>>>> >>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>> >>>>> What I'm not clear about is if libpng is trying to declare that it >>>>> should not be compiled with any newer standards, and so by doing >>>>> that, we risk introducing problems. Reading in the system header, it >>>>> seems the _XPG6 macro is internal and should not be used by the >>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>> >>>> Interesting. We should probably define one, or both of these. Perhaps >>>> globally for all native files and compilers. It might have been the >>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>> prior to setting -std=c99. The following stack overflow article claims >>>> that this is at least the behavior of gcc/clang: >>>> >>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>> same-time >>>> >>>> >>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>> That would explain why this starts to fail. I'll see if I can confirm >>>> this the next time I log into a Solaris computer. >>> Of course it was not as simple. Setting: >>> ??? ifeq ($(OPENJDK_TARGET_OS), solaris) >>> ????? LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>> D_XOPEN_SOURCE=600 >>> ??? endif >>> >>> instead made us fail with: >>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>> line 143: error: incomplete struct/union/enum timezone: tz >>> >>> I don't have more time to dig into this now. Overall, changes such as >>> these make it all feel a bit scary; I recommend that any change to this >>> be made in JDK 13 and not 12. >>> >>> /Magnus >>>> >>>> Otoh, the same article claims, and it sounds reasonable, that we >>>> should set these variables ourself, to be well behaved and to minimize >>>> surprises. And I think this applies to all unix platforms, regardless >>>> of compiler being used. I'll see if I can kick off a test job with >>>> this to see how/if it influences other platforms. But it sounds like >>>> something we should do; the level of posix conformance should be >>>> controlled by us, not left to chance. We also need to verify, of >>>> course, that all platforms we want to support is capable of >>>> supporting? _POSIX_C_SOURCE=200112L. I doubt there's a problem >>> though. >>>> Possibly on AIX... >>>> >>>> /Magnus >>>> >>>>> >>>>> So the the question is, is it ok to override the requirements of >>>>> libpng or should it receive special treatment? If we are fine with >>>>> overriding, then we should use one of the public APIs instead. >>>>> >>>>> /Erik >>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>> ?From the bug report: >>>>>>>>>> "Currently? we disable C99 in the Solaris build by setting >>>>>>>>>> -xc99=%none%. >>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>> replace the setting. >>>>>>>>>> >>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>> However it will take more time until? the C++14 change is in." >>>>>>>>>> >>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>> builds are cleared. >>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>> simple fix to that. >>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>> WebRev: >>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- >>> c99/webrev.01 >>>>>>>> >> with-c99/webrev.01> >>>>>>>> >>>>>>>> >>>>>>>> Now this passes the CI build test. >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>> Patch inline: >>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>> >>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- >>> noglobal >>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>> norunpath >>>>>>>>>> -xnolib" # CXX only >>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>> features=no%split_init \ >>>>>>>>>> ????????? -library=stlport4 -mt -features=no%except >>>>>>>>>> $TOOLCHAIN_FLAGS" >>>>>>>>> >>>>>>>> >>>>>> >>> >> From magnus.ihse.bursie at oracle.com Tue Dec 18 07:56:50 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Dec 2018 08:56:50 +0100 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: Message-ID: <61DE977A-7790-4888-99ED-ADF8E2B6D2BA@oracle.com> 17 dec. 2018 kl. 16:24 skrev Baesken, Matthias : >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do >> you intend to push to 12 or 13? > > Hi Magus, thanks for the review. > I think it is safer to go for 13 , what's your opinion ? Agree. /Magnus > > I put it into our internal build+test queue first , after this is fine , I will go for jdk-submit (hopefully it works ). > > Best regards, Matthias > > >> -----Original Message----- >> From: Magnus Ihse Bursie >> Sent: Montag, 17. Dezember 2018 16:11 >> To: Baesken, Matthias >> Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- >> dev at openjdk.java.net; awt-dev at openjdk.java.net >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do >> you intend to push to 12 or 13? >> >> Looks good to me, as long as it doesn't break anything. >> >> /Magnus >> >>> 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias >> : >>> >>> >>> Hello, please review >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>> >>> in my change just -xc99=%none is removed, so we do not forbid c99 >> coding. >>> >>> The -Xa compile flag is kept, no special additional settings are needed to >> compile png/awt . >>> >>> >>> Thanks, Matthias >>> >>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>>> From: Magnus Ihse Bursie >>>> To: Erik Joelsson , build-dev >>>> , "awt-dev at openjdk.java.net" >>>> , 2d-dev <2d-dev at openjdk.java.net> >>>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>>> Solaris >>>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> >>>> >>>>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>>> >>>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >>>> >: >>>>> >>>>>> >>>>>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> -D_XPG6 >>>>>>>> >>>>>>>> ?? >>>>>>> To be honest, I'm not completely sure about this. Without this >>>>>>> define, the build failed with the following error message: >>>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>>> pre-2001 POSIX applications >>>>>>> >>>>>>> This was triggered by the following section in >>>>>>> /usr/include/sys/feature_tests.h: >>>>>>> /* >>>>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>>> POSIX.1b, >>>>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>>> XPG6 >>>>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>>>> later >>>>>>> * compiler. Therefore, we force an error in both cases. >>>>>>> */ >>>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>>> !defined(_XPG6)) >>>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>>> applications \ >>>>>>> and pre-2001 POSIX applications" >>>>>>> #elif !defined(_STDC_C99) && \ >>>>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>>> applications \ >>>>>>> require the use of c99" >>>>>>> #endif >>>>>>> >>>>>>> The solution, as also hinted to by searching for other resolutions >>>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX >> set, >>>>>>> without _XPG6 set, and only when compiling this library and not >>>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>>> differs from them. >>>>>>> >>>>>>> By setting this flag, I am telling solaris include headers that we >>>>>>> want to compile using the XPG standard version 6, instead of an >>>>>>> older one. It solves the problem. I am happy enough with this. Are >> you? >>>>>> It looks like this comes from libpng. It has this in >>>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>>> >>>>>> /* Feature Test Macros. The following are defined here to ensure >>>>>> that correctly >>>>>> * implemented libraries reveal the APIs libpng needs to build and >>>>>> hide those >>>>>> * that are not needed and potentially damaging to the compilation. >>>>>> * >>>>>> * Feature Test Macros must be defined before any system header is >>>>>> included (see >>>>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>>> * >>>>>> * These macros only have an effect if the operating system supports >>>>>> either >>>>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>>>> (particularly >>>>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>>>> below are >>>>>> * still required (as of 2011-05-02.) >>>>>> */ >>>>>> #ifndef _POSIX_SOURCE >>>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>>> #endif >>>>>> >>>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>>> >>>>>> What I'm not clear about is if libpng is trying to declare that it >>>>>> should not be compiled with any newer standards, and so by doing >>>>>> that, we risk introducing problems. Reading in the system header, it >>>>>> seems the _XPG6 macro is internal and should not be used by the >>>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>>> >>>>> Interesting. We should probably define one, or both of these. Perhaps >>>>> globally for all native files and compilers. It might have been the >>>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>>> prior to setting -std=c99. The following stack overflow article claims >>>>> that this is at least the behavior of gcc/clang: >>>>> >>>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>>> same-time >>>>> >>>>> >>>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>>> That would explain why this starts to fail. I'll see if I can confirm >>>>> this the next time I log into a Solaris computer. >>>> Of course it was not as simple. Setting: >>>> ifeq ($(OPENJDK_TARGET_OS), solaris) >>>> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>>> D_XOPEN_SOURCE=600 >>>> endif >>>> >>>> instead made us fail with: >>>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>>> line 143: error: incomplete struct/union/enum timezone: tz >>>> >>>> I don't have more time to dig into this now. Overall, changes such as >>>> these make it all feel a bit scary; I recommend that any change to this >>>> be made in JDK 13 and not 12. >>>> >>>> /Magnus >>>>> >>>>> Otoh, the same article claims, and it sounds reasonable, that we >>>>> should set these variables ourself, to be well behaved and to minimize >>>>> surprises. And I think this applies to all unix platforms, regardless >>>>> of compiler being used. I'll see if I can kick off a test job with >>>>> this to see how/if it influences other platforms. But it sounds like >>>>> something we should do; the level of posix conformance should be >>>>> controlled by us, not left to chance. We also need to verify, of >>>>> course, that all platforms we want to support is capable of >>>>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >>>> though. >>>>> Possibly on AIX... >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> So the the question is, is it ok to override the requirements of >>>>>> libpng or should it receive special treatment? If we are fine with >>>>>> overriding, then we should use one of the public APIs instead. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>>> From the bug report: >>>>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>>>> -xc99=%none%. >>>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>>> replace the setting. >>>>>>>>>>> >>>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>>>> >>>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>>> builds are cleared. >>>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>>> simple fix to that. >>>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>>> WebRev: >>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- >> with- >>>> c99/webrev.01 >>>>>>>>> >>> with-c99/webrev.01> >>>>>>>>> >>>>>>>>> >>>>>>>>> Now this passes the CI build test. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>>> Patch inline: >>>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>>> >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - >> W0,- >>>> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- >> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>>> norunpath >>>>>>>>>>> -xnolib" # CXX only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>>> features=no%split_init \ >>>>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>>>> $TOOLCHAIN_FLAGS" >>> > From matthias.baesken at sap.com Tue Dec 18 08:02:36 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Dec 2018 08:02:36 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> References: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> Message-ID: Hi David, thanks for the update on your internal builds . Same is true for our internal builds . Regarding C99 with -Xa set : > > > > It's not at all clear to me that C99-isms will be allowed if -Xa is set. > > The C99 features I tested are allowed when -Xa is set (tested with SS12 update 4) - -Xa is set, without other compile flags : bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -Xa -o bool bash-4.1$ ./bool b is true. a: 1 -Xa is set together with the old flag forbidding C99 , this leads to a lot of compile errors : bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -xc99=%none -Xa -o bool "bool.c", line 5: undefined symbol: bool "bool.c", line 5: syntax error before or at: b "bool.c", line 6: undefined symbol: b "bool.c", line 9: syntax error before or at: / "bool.c", line 12: undefined symbol: a cc: acomp failed for bool.c The example program contains bool , C++-style comments and declaration of a after the if-statement. bash-4.1$ more bool.c #include #include int main() { bool b = true; if (b) { printf("b is true.\n"); } // C++ style comments // decl. int a = 1; printf("a: %d \n", a); return 0; } Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Dienstag, 18. Dezember 2018 01:24 > To: Baesken, Matthias ; 2d- > dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- > dev at openjdk.java.net' ; awt- > dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' > > Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > Solaris > > Our internal builds pass okay. > > David > > On 18/12/2018 8:02 am, David Holmes wrote: > > Hi Matthias, > > > > On 17/12/2018 11:12 pm, Baesken, Matthias wrote: > >> > >> Hello,? please review > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > >> > >> in my change just -xc99=%none? is removed, so we do not forbid c99 > >> coding. > >> > >> The -Xa compile flag is kept,? no special additional settings are > >> needed to compile png/awt . > > > > It's not at all clear to me that C99-isms will be allowed if -Xa is set. > > > > I don't think jdk-submit tests Solaris. I'm putting this through our > > internal builds. > > > > Thanks, > > David > > From david.holmes at oracle.com Tue Dec 18 08:44:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 18:44:40 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> Message-ID: <66c9368f-6c10-1a82-b20a-1dd3dab7e69d@oracle.com> On 18/12/2018 6:02 pm, Baesken, Matthias wrote: > Hi David, thanks for the update on your internal builds . Same is true for our internal builds . > > Regarding C99 with -Xa set : > >>> >>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. >>> > > The C99 features I tested are allowed when -Xa is set (tested with SS12 update 4) - Thanks for the info. Seems okay for now then. David > -Xa is set, without other compile flags : > > bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -Xa -o bool > bash-4.1$ ./bool > b is true. > a: 1 > > -Xa is set together with the old flag forbidding C99 , this leads to a lot of compile errors : > > bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -xc99=%none -Xa -o bool > "bool.c", line 5: undefined symbol: bool > "bool.c", line 5: syntax error before or at: b > "bool.c", line 6: undefined symbol: b > "bool.c", line 9: syntax error before or at: / > "bool.c", line 12: undefined symbol: a > cc: acomp failed for bool.c > > The example program contains bool , C++-style comments and declaration of a after the if-statement. > > bash-4.1$ more bool.c > #include > #include > > int main() { > bool b = true; > if (b) { > printf("b is true.\n"); > } > // C++ style comments > // decl. > int a = 1; > printf("a: %d \n", a); > > return 0; > } > > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 18. Dezember 2018 01:24 >> To: Baesken, Matthias ; 2d- >> dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- >> dev at openjdk.java.net' ; awt- >> dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' >> >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> Our internal builds pass okay. >> >> David >> >> On 18/12/2018 8:02 am, David Holmes wrote: >>> Hi Matthias, >>> >>> On 17/12/2018 11:12 pm, Baesken, Matthias wrote: >>>> >>>> Hello,? please review >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>>> >>>> in my change just -xc99=%none? is removed, so we do not forbid c99 >>>> coding. >>>> >>>> The -Xa compile flag is kept,? no special additional settings are >>>> needed to compile png/awt . >>> >>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. >>> >>> I don't think jdk-submit tests Solaris. I'm putting this through our >>> internal builds. >>> >>> Thanks, >>> David >>> > From matthias.baesken at sap.com Tue Dec 18 08:56:30 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Dec 2018 08:56:30 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <66c9368f-6c10-1a82-b20a-1dd3dab7e69d@oracle.com> References: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> <66c9368f-6c10-1a82-b20a-1dd3dab7e69d@oracle.com> Message-ID: Thanks David, can I add you as a reviewer ? Unfortunately the jdk/jdk Solaris sparc results are currently so broken (with or without the change) that it is hard to tell what difference it really makes ... Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Dienstag, 18. Dezember 2018 09:45 > To: Baesken, Matthias ; 2d- > dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- > dev at openjdk.java.net' ; awt- > dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' > > Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > Solaris > > On 18/12/2018 6:02 pm, Baesken, Matthias wrote: > > Hi David, thanks for the update on your internal builds . Same is true for > our internal builds . > > > > Regarding C99 with -Xa set : > > > >>> > >>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. > >>> > > > > The C99 features I tested are allowed when -Xa is set (tested with SS12 > update 4) - > > Thanks for the info. Seems okay for now then. > > David > > > -Xa is set, without other compile flags : > > > > bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -Xa -o bool > > bash-4.1$ ./bool > > b is true. > > a: 1 > > > > -Xa is set together with the old flag forbidding C99 , this leads to a lot of > compile errors : > > > > bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c - > xc99=%none -Xa -o bool > > "bool.c", line 5: undefined symbol: bool > > "bool.c", line 5: syntax error before or at: b > > "bool.c", line 6: undefined symbol: b > > "bool.c", line 9: syntax error before or at: / > > "bool.c", line 12: undefined symbol: a > > cc: acomp failed for bool.c > > > > The example program contains bool , C++-style comments and > declaration of a after the if-statement. > > > > bash-4.1$ more bool.c > > #include > > #include > > > > int main() { > > bool b = true; > > if (b) { > > printf("b is true.\n"); > > } > > // C++ style comments > > // decl. > > int a = 1; > > printf("a: %d \n", a); > > > > return 0; > > } > > > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Dienstag, 18. Dezember 2018 01:24 > >> To: Baesken, Matthias ; 2d- > >> dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- > >> dev at openjdk.java.net' ; awt- > >> dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' > >> > >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > >> Solaris > >> > >> Our internal builds pass okay. > >> > >> David > >> > >> On 18/12/2018 8:02 am, David Holmes wrote: > >>> Hi Matthias, > >>> > >>> On 17/12/2018 11:12 pm, Baesken, Matthias wrote: > >>>> > >>>> Hello,? please review > >>>> > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > >>>> > >>>> in my change just -xc99=%none? is removed, so we do not forbid c99 > >>>> coding. > >>>> > >>>> The -Xa compile flag is kept,? no special additional settings are > >>>> needed to compile png/awt . > >>> > >>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. > >>> > >>> I don't think jdk-submit tests Solaris. I'm putting this through our > >>> internal builds. > >>> > >>> Thanks, > >>> David > >>> > > From david.holmes at oracle.com Tue Dec 18 09:07:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 19:07:45 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> <66c9368f-6c10-1a82-b20a-1dd3dab7e69d@oracle.com> Message-ID: On 18/12/2018 6:56 pm, Baesken, Matthias wrote: > Thanks David, can I add you as a reviewer ? Yes. > Unfortunately the jdk/jdk Solaris sparc results are currently so broken (with or without the change) that it is hard to tell what difference it really makes ... This is a build flag change that relates to the source language used and the build is fine so I don't see there are any issues. My own tests had no new issues in our tiers 1 - 3. Cheers, David > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 18. Dezember 2018 09:45 >> To: Baesken, Matthias ; 2d- >> dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- >> dev at openjdk.java.net' ; awt- >> dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' >> >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> On 18/12/2018 6:02 pm, Baesken, Matthias wrote: >>> Hi David, thanks for the update on your internal builds . Same is true for >> our internal builds . >>> >>> Regarding C99 with -Xa set : >>> >>>>> >>>>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. >>>>> >>> >>> The C99 features I tested are allowed when -Xa is set (tested with SS12 >> update 4) - >> >> Thanks for the info. Seems okay for now then. >> >> David >> >>> -Xa is set, without other compile flags : >>> >>> bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -Xa -o bool >>> bash-4.1$ ./bool >>> b is true. >>> a: 1 >>> >>> -Xa is set together with the old flag forbidding C99 , this leads to a lot of >> compile errors : >>> >>> bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c - >> xc99=%none -Xa -o bool >>> "bool.c", line 5: undefined symbol: bool >>> "bool.c", line 5: syntax error before or at: b >>> "bool.c", line 6: undefined symbol: b >>> "bool.c", line 9: syntax error before or at: / >>> "bool.c", line 12: undefined symbol: a >>> cc: acomp failed for bool.c >>> >>> The example program contains bool , C++-style comments and >> declaration of a after the if-statement. >>> >>> bash-4.1$ more bool.c >>> #include >>> #include >>> >>> int main() { >>> bool b = true; >>> if (b) { >>> printf("b is true.\n"); >>> } >>> // C++ style comments >>> // decl. >>> int a = 1; >>> printf("a: %d \n", a); >>> >>> return 0; >>> } >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Dienstag, 18. Dezember 2018 01:24 >>>> To: Baesken, Matthias ; 2d- >>>> dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- >>>> dev at openjdk.java.net' ; awt- >>>> dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' >>>> >>>> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >>>> Solaris >>>> >>>> Our internal builds pass okay. >>>> >>>> David >>>> >>>> On 18/12/2018 8:02 am, David Holmes wrote: >>>>> Hi Matthias, >>>>> >>>>> On 17/12/2018 11:12 pm, Baesken, Matthias wrote: >>>>>> >>>>>> Hello,? please review >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>>>>> >>>>>> in my change just -xc99=%none? is removed, so we do not forbid c99 >>>>>> coding. >>>>>> >>>>>> The -Xa compile flag is kept,? no special additional settings are >>>>>> needed to compile png/awt . >>>>> >>>>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. >>>>> >>>>> I don't think jdk-submit tests Solaris. I'm putting this through our >>>>> internal builds. >>>>> >>>>> Thanks, >>>>> David >>>>> >>> From krishna.addepalli at oracle.com Wed Dec 19 12:21:30 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 19 Dec 2018 04:21:30 -0800 (PST) Subject: [12] Review Request: 8214918 Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms In-Reply-To: <40045cee-eca2-7f36-b116-d36fe5d1cbdf@oracle.com> References: <40045cee-eca2-7f36-b116-d36fe5d1cbdf@oracle.com> Message-ID: Hi Sergey, ? The changes look fine to me. ? Thanks, Krishna Subject: [12] Review Request: 8214918 Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms Date: Thu, 6 Dec 2018 09:26:06 -0800 From: Sergey Bylokhov HYPERLINK "mailto:Sergey.Bylokhov at oracle.com" To: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net HYPERLINK "mailto:awt-dev at openjdk.java.net" Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8214918 Webrev: http://cr.openjdk.java.net/~serb/8214918/webrev.00 In the fix for JDK-8076313 I need to implement possibility of switch between xinerama and non-xinerama modes at runtime. As a separate part I would like to investigate the usage of X11GraphicsEnvironment.runningXinerama() and replace it by some other generic for single/multi-screen solution. This bug is about one of the place where the flag above is used. In jdk 1.4 two new methods were added to the GraphicsEnvironment class: - getCenterPoint() - getMaximumWindowBounds() see https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering Take a look to this descriptions from the link above: "X-Window, Xinerama All monitors share a single virtual coordinate space, as on Microsoft Windows. However, it is possible for the user to specify through X resources where windows should be centered. If these resources are set, getCenterPoint reflects their value. Otherwise, it returns the point at the center of the virtual coordinate space. (In practice, this will almost always be set - CDE sets it by default.)" Since the case above was implemented on the Solaris, and uses an extension of the xinerama, I suggest to remove this and align implementation across the platforms: - getCenterPoint returns the coordinates of the center of the primary display for all platforms - getMaximumWindowBounds returns the bounds of the primary display minus display insets for all platforms -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Dec 19 15:31:11 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 19 Dec 2018 15:31:11 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: Message-ID: > > Sounds like a simpler change, at least for now. Does it pass jdk-submit? > Hello Magnus , pushed it to jdk/submit , however I do not expect much info from it because David told me Solaris is not tested there (and the other platforms are not affected by my path). However David tested it Oracle-internally with success . Can I add you and David as reviewers ? Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Montag, 17. Dezember 2018 16:11 > To: Baesken, Matthias > Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- > dev at openjdk.java.net; awt-dev at openjdk.java.net > Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > Solaris > > Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do > you intend to push to 12 or 13? > > Looks good to me, as long as it doesn't break anything. > > /Magnus > > > 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias > : > > > > > > Hello, please review > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > > > > in my change just -xc99=%none is removed, so we do not forbid c99 > coding. > > > > The -Xa compile flag is kept, no special additional settings are needed to > compile png/awt . > > > > > > Thanks, Matthias > > > > > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Fri, 14 Dec 2018 15:39:26 +0100 > >> From: Magnus Ihse Bursie > >> To: Erik Joelsson , build-dev > >> , "awt-dev at openjdk.java.net" > >> , 2d-dev <2d-dev at openjdk.java.net> > >> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on > >> Solaris > >> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> > >> Content-Type: text/plain; charset=utf-8; format=flowed > >> > >> > >> > >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: > >>> > >>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >>> >: > >>> > >>>> > >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: > >>>>> > >>>>>> -D_XPG6 > >>>>>> > >>>>>> ?? > >>>>> To be honest, I'm not completely sure about this. Without this > >>>>> define, the build failed with the following error message: > >>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and > >>>>> pre-2001 POSIX applications > >>>>> > >>>>> This was triggered by the following section in > >>>>> /usr/include/sys/feature_tests.h: > >>>>> /* > >>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application > >>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, > >>>>> POSIX.1b, > >>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an > >>>>> XPG6 > >>>>> * or a POSIX.1-2001 application with anything other than a c99 or > >>>>> later > >>>>> * compiler. Therefore, we force an error in both cases. > >>>>> */ > >>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && > >>>>> !defined(_XPG6)) > >>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open > >>>>> applications \ > >>>>> and pre-2001 POSIX applications" > >>>>> #elif !defined(_STDC_C99) && \ > >>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) > >>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 > >>>>> applications \ > >>>>> require the use of c99" > >>>>> #endif > >>>>> > >>>>> The solution, as also hinted to by searching for other resolutions > >>>>> to this error online, was to provide the _XPG6 system define. But > >>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX > set, > >>>>> without _XPG6 set, and only when compiling this library and not > >>>>> others, I don't know. I also don't understand what the XPG standard > >>>>> refers to, nor what versions 2-5 means or what version 6 has that > >>>>> differs from them. > >>>>> > >>>>> By setting this flag, I am telling solaris include headers that we > >>>>> want to compile using the XPG standard version 6, instead of an > >>>>> older one. It solves the problem. I am happy enough with this. Are > you? > >>>> It looks like this comes from libpng. It has this in > >>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > >>>> > >>>> /* Feature Test Macros. The following are defined here to ensure > >>>> that correctly > >>>> * implemented libraries reveal the APIs libpng needs to build and > >>>> hide those > >>>> * that are not needed and potentially damaging to the compilation. > >>>> * > >>>> * Feature Test Macros must be defined before any system header is > >>>> included (see > >>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." > >>>> * > >>>> * These macros only have an effect if the operating system supports > >>>> either > >>>> * POSIX 1003.1 or C99, or both. On other operating systems > >>>> (particularly > >>>> * Windows/Visual Studio) there is no effect; the OS specific tests > >>>> below are > >>>> * still required (as of 2011-05-02.) > >>>> */ > >>>> #ifndef _POSIX_SOURCE > >>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > >>>> #endif > >>>> > >>>> This in turn triggers _XOPEN_OR_POSIX to be defined in > >>>> /usr/include/sys/feature_tests.h and so triggers the error. > >>>> > >>>> What I'm not clear about is if libpng is trying to declare that it > >>>> should not be compiled with any newer standards, and so by doing > >>>> that, we risk introducing problems. Reading in the system header, it > >>>> seems the _XPG6 macro is internal and should not be used by the > >>>> application. It's derived from _XOPEN_SOURCE=600 or > >>>> _POSIX_C_SOURCE=200112L which is what applications should use. > >>> > >>> Interesting. We should probably define one, or both of these. Perhaps > >>> globally for all native files and compilers. It might have been the > >>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, > >>> prior to setting -std=c99. The following stack overflow article claims > >>> that this is at least the behavior of gcc/clang: > >>> > >>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- > >> same-time > >>> > >>> > >>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. > >>> That would explain why this starts to fail. I'll see if I can confirm > >>> this the next time I log into a Solaris computer. > >> Of course it was not as simple. Setting: > >> ifeq ($(OPENJDK_TARGET_OS), solaris) > >> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - > >> D_XOPEN_SOURCE=600 > >> endif > >> > >> instead made us fail with: > >> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", > >> line 143: error: incomplete struct/union/enum timezone: tz > >> > >> I don't have more time to dig into this now. Overall, changes such as > >> these make it all feel a bit scary; I recommend that any change to this > >> be made in JDK 13 and not 12. > >> > >> /Magnus > >>> > >>> Otoh, the same article claims, and it sounds reasonable, that we > >>> should set these variables ourself, to be well behaved and to minimize > >>> surprises. And I think this applies to all unix platforms, regardless > >>> of compiler being used. I'll see if I can kick off a test job with > >>> this to see how/if it influences other platforms. But it sounds like > >>> something we should do; the level of posix conformance should be > >>> controlled by us, not left to chance. We also need to verify, of > >>> course, that all platforms we want to support is capable of > >>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem > >> though. > >>> Possibly on AIX... > >>> > >>> /Magnus > >>> > >>>> > >>>> So the the question is, is it ok to override the requirements of > >>>> libpng or should it receive special treatment? If we are fine with > >>>> overriding, then we should use one of the public APIs instead. > >>>> > >>>> /Erik > >>>> > >>>>> /Magnus > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: > >>>>>>> > >>>>>>> > >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: > >>>>>>>>> From the bug report: > >>>>>>>>> "Currently we disable C99 in the Solaris build by setting > >>>>>>>>> -xc99=%none%. > >>>>>>>>> This differs from a lot of other build environments like > >>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. > >>>>>>>>> We should remove this difference on Solaris and remove or > >>>>>>>>> replace the setting. > >>>>>>>>> > >>>>>>>>> Kim Barrett mentioned : > >>>>>>>>> "I merely mentioned the C++14 work as evidence that removing > >>>>>>>>> -xc99=%none% didn?t appear harmful." > >>>>>>>>> However it will take more time until the C++14 change is in." > >>>>>>>>> > >>>>>>>>> I am currently running a test build on our CI build system to > >>>>>>>>> confirm that this does not break the Solaris build (but I'd be > >>>>>>>>> highly surprised if it did). I will not push this until the > >>>>>>>>> builds are cleared. > >>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at > >>>>>>>> least) failed to build. I'm currently investigating if there's a > >>>>>>>> simple fix to that. > >>>>>>> New attempt, that fixes the two AWT libraries: > >>>>>>> WebRev: > >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- > with- > >> c99/webrev.01 > >>>>>>> >> with-c99/webrev.01> > >>>>>>> > >>>>>>> > >>>>>>> Now this passes the CI build test. > >>>>>>> > >>>>>>> /Magnus > >>>>>>>> > >>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 > >>>>>>>>> Patch inline: > >>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 > >>>>>>>>> b/make/autoconf/flags-cflags.m4 > >>>>>>>>> --- a/make/autoconf/flags-cflags.m4 > >>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 > >>>>>>>>> @@ -559,7 +559,7 @@ > >>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" > >>>>>>>>> > >>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" > >>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - > W0,- > >> noglobal > >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- > noglobal > >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - > >> norunpath > >>>>>>>>> -xnolib" # CXX only > >>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - > >> features=no%split_init \ > >>>>>>>>> -library=stlport4 -mt -features=no%except > >>>>>>>>> $TOOLCHAIN_FLAGS" > > From david.holmes at oracle.com Wed Dec 19 21:13:58 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Dec 2018 07:13:58 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> References: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> Message-ID: Correction: jdk-submit does test Solaris. David On 18/12/2018 8:02 am, David Holmes wrote: > Hi Matthias, > > On 17/12/2018 11:12 pm, Baesken, Matthias wrote: >> >> Hello,? please review >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >> >> in my change just -xc99=%none? is removed, so we do not forbid c99 >> coding. >> >> The -Xa compile flag is kept,? no special additional settings are >> needed to compile png/awt . > > It's not at all clear to me that C99-isms will be allowed if -Xa is set. > > I don't think jdk-submit tests Solaris. I'm putting this through our > internal builds. > > Thanks, > David > >> >> Thanks, Matthias >> >> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>> From: Magnus Ihse Bursie >>> To: Erik Joelsson , build-dev >>> ????, "awt-dev at openjdk.java.net" >>> ????, 2d-dev <2d-dev at openjdk.java.net> >>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>> ????Solaris >>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> >>> >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>> >>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >>> >: >>>> >>>>> >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>> >>>>>>> -D_XPG6 >>>>>>> >>>>>>> ?? >>>>>> To be honest, I'm not completely sure about this. Without this >>>>>> define, the build failed with the following error message: >>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>> pre-2001 POSIX applications >>>>>> >>>>>> This was triggered by the following section in >>>>>> /usr/include/sys/feature_tests.h: >>>>>> /* >>>>>> ? * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 >>>>>> application >>>>>> ? * using c99.? The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>> POSIX.1b, >>>>>> ? * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>> XPG6 >>>>>> ? * or a POSIX.1-2001 application with anything other than a c99 or >>>>>> later >>>>>> ? * compiler.? Therefore, we force an error in both cases. >>>>>> ? */ >>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>> !defined(_XPG6)) >>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>> applications \ >>>>>> ???????? and pre-2001 POSIX applications" >>>>>> #elif !defined(_STDC_C99) && \ >>>>>> ???????? (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>> applications \ >>>>>> ???????? require the use of c99" >>>>>> #endif >>>>>> >>>>>> The solution, as also hinted to by searching for other resolutions >>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>>>>> without _XPG6 set, and only when compiling this library and not >>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>> differs from them. >>>>>> >>>>>> By setting this flag, I am telling solaris include headers that we >>>>>> want to compile using the XPG standard version 6, instead of an >>>>>> older one. It solves the problem. I am happy enough with this. Are >>>>>> you? >>>>>> >>>>> It looks like this comes from libpng. It has this in >>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>> >>>>> /* Feature Test Macros.? The following are defined here to ensure >>>>> that correctly >>>>> ? * implemented libraries reveal the APIs libpng needs to build and >>>>> hide those >>>>> ? * that are not needed and potentially damaging to the compilation. >>>>> ? * >>>>> ? * Feature Test Macros must be defined before any system header is >>>>> included (see >>>>> ? * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>> ? * >>>>> ? * These macros only have an effect if the operating system supports >>>>> either >>>>> ? * POSIX 1003.1 or C99, or both.? On other operating systems >>>>> (particularly >>>>> ? * Windows/Visual Studio) there is no effect; the OS specific tests >>>>> below are >>>>> ? * still required (as of 2011-05-02.) >>>>> ? */ >>>>> #ifndef _POSIX_SOURCE >>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>> #endif >>>>> >>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>> >>>>> What I'm not clear about is if libpng is trying to declare that it >>>>> should not be compiled with any newer standards, and so by doing >>>>> that, we risk introducing problems. Reading in the system header, it >>>>> seems the _XPG6 macro is internal and should not be used by the >>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>> >>>> Interesting. We should probably define one, or both of these. Perhaps >>>> globally for all native files and compilers. It might have been the >>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>> prior to setting -std=c99. The following stack overflow article claims >>>> that this is at least the behavior of gcc/clang: >>>> >>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>> same-time >>>> >>>> >>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>> That would explain why this starts to fail. I'll see if I can confirm >>>> this the next time I log into a Solaris computer. >>> Of course it was not as simple. Setting: >>> ??? ifeq ($(OPENJDK_TARGET_OS), solaris) >>> ????? LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>> D_XOPEN_SOURCE=600 >>> ??? endif >>> >>> instead made us fail with: >>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>> line 143: error: incomplete struct/union/enum timezone: tz >>> >>> I don't have more time to dig into this now. Overall, changes such as >>> these make it all feel a bit scary; I recommend that any change to this >>> be made in JDK 13 and not 12. >>> >>> /Magnus >>>> >>>> Otoh, the same article claims, and it sounds reasonable, that we >>>> should set these variables ourself, to be well behaved and to minimize >>>> surprises. And I think this applies to all unix platforms, regardless >>>> of compiler being used. I'll see if I can kick off a test job with >>>> this to see how/if it influences other platforms. But it sounds like >>>> something we should do; the level of posix conformance should be >>>> controlled by us, not left to chance. We also need to verify, of >>>> course, that all platforms we want to support is capable of >>>> supporting? _POSIX_C_SOURCE=200112L. I doubt there's a problem >>> though. >>>> Possibly on AIX... >>>> >>>> /Magnus >>>> >>>>> >>>>> So the the question is, is it ok to override the requirements of >>>>> libpng or should it receive special treatment? If we are fine with >>>>> overriding, then we should use one of the public APIs instead. >>>>> >>>>> /Erik >>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>> ?From the bug report: >>>>>>>>>> "Currently? we disable C99 in the Solaris build by setting >>>>>>>>>> -xc99=%none%. >>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>> replace the setting. >>>>>>>>>> >>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>> However it will take more time until? the C++14 change is in." >>>>>>>>>> >>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>> builds are cleared. >>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>> simple fix to that. >>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>> WebRev: >>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- >>> c99/webrev.01 >>>>>>>> >> with-c99/webrev.01> >>>>>>>> >>>>>>>> >>>>>>>> Now this passes the CI build test. >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>> Patch inline: >>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>> >>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- >>> noglobal >>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>> norunpath >>>>>>>>>> -xnolib" # CXX only >>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>> features=no%split_init \ >>>>>>>>>> ????????? -library=stlport4 -mt -features=no%except >>>>>>>>>> $TOOLCHAIN_FLAGS" >>>>>>>>> >>>>>>>> >>>>>> >>> >> From david.holmes at oracle.com Wed Dec 19 21:47:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Dec 2018 07:47:53 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: Message-ID: <96a2ea68-2b17-7531-a303-1cb1b1cfb272@oracle.com> On 20/12/2018 1:31 am, Baesken, Matthias wrote: >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? >> > > Hello Magnus , pushed it to jdk/submit , however I do not expect much info from it because David told me Solaris is not tested there I was incorrect. > (and the other platforms are not affected by my path). > > However David tested it Oracle-internally with success . Yes. > Can I add you and David as reviewers ? Yes from me. Thanks, David > > Best regards, Matthias > > > >> -----Original Message----- >> From: Magnus Ihse Bursie >> Sent: Montag, 17. Dezember 2018 16:11 >> To: Baesken, Matthias >> Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- >> dev at openjdk.java.net; awt-dev at openjdk.java.net >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do >> you intend to push to 12 or 13? >> >> Looks good to me, as long as it doesn't break anything. >> >> /Magnus >> >>> 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias >> : >>> >>> >>> Hello, please review >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>> >>> in my change just -xc99=%none is removed, so we do not forbid c99 >> coding. >>> >>> The -Xa compile flag is kept, no special additional settings are needed to >> compile png/awt . >>> >>> >>> Thanks, Matthias >>> >>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>>> From: Magnus Ihse Bursie >>>> To: Erik Joelsson , build-dev >>>> , "awt-dev at openjdk.java.net" >>>> , 2d-dev <2d-dev at openjdk.java.net> >>>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>>> Solaris >>>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> >>>> >>>>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>>> >>>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >>>> >: >>>>> >>>>>> >>>>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>>> -D_XPG6 >>>>>>>> >>>>>>>> ?? >>>>>>> To be honest, I'm not completely sure about this. Without this >>>>>>> define, the build failed with the following error message: >>>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>>> pre-2001 POSIX applications >>>>>>> >>>>>>> This was triggered by the following section in >>>>>>> /usr/include/sys/feature_tests.h: >>>>>>> /* >>>>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>>> POSIX.1b, >>>>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>>> XPG6 >>>>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>>>> later >>>>>>> * compiler. Therefore, we force an error in both cases. >>>>>>> */ >>>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>>> !defined(_XPG6)) >>>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>>> applications \ >>>>>>> and pre-2001 POSIX applications" >>>>>>> #elif !defined(_STDC_C99) && \ >>>>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>>> applications \ >>>>>>> require the use of c99" >>>>>>> #endif >>>>>>> >>>>>>> The solution, as also hinted to by searching for other resolutions >>>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX >> set, >>>>>>> without _XPG6 set, and only when compiling this library and not >>>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>>> differs from them. >>>>>>> >>>>>>> By setting this flag, I am telling solaris include headers that we >>>>>>> want to compile using the XPG standard version 6, instead of an >>>>>>> older one. It solves the problem. I am happy enough with this. Are >> you? >>>>>> It looks like this comes from libpng. It has this in >>>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>>> >>>>>> /* Feature Test Macros. The following are defined here to ensure >>>>>> that correctly >>>>>> * implemented libraries reveal the APIs libpng needs to build and >>>>>> hide those >>>>>> * that are not needed and potentially damaging to the compilation. >>>>>> * >>>>>> * Feature Test Macros must be defined before any system header is >>>>>> included (see >>>>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>>> * >>>>>> * These macros only have an effect if the operating system supports >>>>>> either >>>>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>>>> (particularly >>>>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>>>> below are >>>>>> * still required (as of 2011-05-02.) >>>>>> */ >>>>>> #ifndef _POSIX_SOURCE >>>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>>> #endif >>>>>> >>>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>>> >>>>>> What I'm not clear about is if libpng is trying to declare that it >>>>>> should not be compiled with any newer standards, and so by doing >>>>>> that, we risk introducing problems. Reading in the system header, it >>>>>> seems the _XPG6 macro is internal and should not be used by the >>>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>>> >>>>> Interesting. We should probably define one, or both of these. Perhaps >>>>> globally for all native files and compilers. It might have been the >>>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>>> prior to setting -std=c99. The following stack overflow article claims >>>>> that this is at least the behavior of gcc/clang: >>>>> >>>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>>> same-time >>>>> >>>>> >>>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>>> That would explain why this starts to fail. I'll see if I can confirm >>>>> this the next time I log into a Solaris computer. >>>> Of course it was not as simple. Setting: >>>> ifeq ($(OPENJDK_TARGET_OS), solaris) >>>> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>>> D_XOPEN_SOURCE=600 >>>> endif >>>> >>>> instead made us fail with: >>>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>>> line 143: error: incomplete struct/union/enum timezone: tz >>>> >>>> I don't have more time to dig into this now. Overall, changes such as >>>> these make it all feel a bit scary; I recommend that any change to this >>>> be made in JDK 13 and not 12. >>>> >>>> /Magnus >>>>> >>>>> Otoh, the same article claims, and it sounds reasonable, that we >>>>> should set these variables ourself, to be well behaved and to minimize >>>>> surprises. And I think this applies to all unix platforms, regardless >>>>> of compiler being used. I'll see if I can kick off a test job with >>>>> this to see how/if it influences other platforms. But it sounds like >>>>> something we should do; the level of posix conformance should be >>>>> controlled by us, not left to chance. We also need to verify, of >>>>> course, that all platforms we want to support is capable of >>>>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >>>> though. >>>>> Possibly on AIX... >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> So the the question is, is it ok to override the requirements of >>>>>> libpng or should it receive special treatment? If we are fine with >>>>>> overriding, then we should use one of the public APIs instead. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>>> From the bug report: >>>>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>>>> -xc99=%none%. >>>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>>> replace the setting. >>>>>>>>>>> >>>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>>>> >>>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>>> builds are cleared. >>>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>>> simple fix to that. >>>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>>> WebRev: >>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- >> with- >>>> c99/webrev.01 >>>>>>>>> >>> with-c99/webrev.01> >>>>>>>>> >>>>>>>>> >>>>>>>>> Now this passes the CI build test. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>>> Patch inline: >>>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>>> >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - >> W0,- >>>> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- >> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>>> norunpath >>>>>>>>>>> -xnolib" # CXX only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>>> features=no%split_init \ >>>>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>>>> $TOOLCHAIN_FLAGS" >>> > From magnus.ihse.bursie at oracle.com Thu Dec 20 10:48:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Dec 2018 11:48:28 +0100 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: References: Message-ID: Yes, you can add me as reviewer. /Magnus 19 dec. 2018 kl. 16:31 skrev Baesken, Matthias : >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? > > Hello Magnus , pushed it to jdk/submit , however I do not expect much info from it because David told me Solaris is not tested there > (and the other platforms are not affected by my path). > > However David tested it Oracle-internally with success . > > Can I add you and David as reviewers ? > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Magnus Ihse Bursie >> Sent: Montag, 17. Dezember 2018 16:11 >> To: Baesken, Matthias >> Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- >> dev at openjdk.java.net; awt-dev at openjdk.java.net >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do >> you intend to push to 12 or 13? >> >> Looks good to me, as long as it doesn't break anything. >> >> /Magnus >> >>>> 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias >>> : >>> >>> >>> Hello, please review >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>> >>> in my change just -xc99=%none is removed, so we do not forbid c99 >> coding. >>> >>> The -Xa compile flag is kept, no special additional settings are needed to >> compile png/awt . >>> >>> >>> Thanks, Matthias >>> >>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>>> From: Magnus Ihse Bursie >>>> To: Erik Joelsson , build-dev >>>> , "awt-dev at openjdk.java.net" >>>> , 2d-dev <2d-dev at openjdk.java.net> >>>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>>> Solaris >>>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> >>>> >>>>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>>> >>>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson >>>> >: >>>>> >>>>>> >>>>>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> -D_XPG6 >>>>>>>> >>>>>>>> ?? >>>>>>> To be honest, I'm not completely sure about this. Without this >>>>>>> define, the build failed with the following error message: >>>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>>> pre-2001 POSIX applications >>>>>>> >>>>>>> This was triggered by the following section in >>>>>>> /usr/include/sys/feature_tests.h: >>>>>>> /* >>>>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>>> POSIX.1b, >>>>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>>> XPG6 >>>>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>>>> later >>>>>>> * compiler. Therefore, we force an error in both cases. >>>>>>> */ >>>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>>> !defined(_XPG6)) >>>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>>> applications \ >>>>>>> and pre-2001 POSIX applications" >>>>>>> #elif !defined(_STDC_C99) && \ >>>>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>>> applications \ >>>>>>> require the use of c99" >>>>>>> #endif >>>>>>> >>>>>>> The solution, as also hinted to by searching for other resolutions >>>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX >> set, >>>>>>> without _XPG6 set, and only when compiling this library and not >>>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>>> differs from them. >>>>>>> >>>>>>> By setting this flag, I am telling solaris include headers that we >>>>>>> want to compile using the XPG standard version 6, instead of an >>>>>>> older one. It solves the problem. I am happy enough with this. Are >> you? >>>>>> It looks like this comes from libpng. It has this in >>>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>>> >>>>>> /* Feature Test Macros. The following are defined here to ensure >>>>>> that correctly >>>>>> * implemented libraries reveal the APIs libpng needs to build and >>>>>> hide those >>>>>> * that are not needed and potentially damaging to the compilation. >>>>>> * >>>>>> * Feature Test Macros must be defined before any system header is >>>>>> included (see >>>>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>>> * >>>>>> * These macros only have an effect if the operating system supports >>>>>> either >>>>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>>>> (particularly >>>>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>>>> below are >>>>>> * still required (as of 2011-05-02.) >>>>>> */ >>>>>> #ifndef _POSIX_SOURCE >>>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>>> #endif >>>>>> >>>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>>> >>>>>> What I'm not clear about is if libpng is trying to declare that it >>>>>> should not be compiled with any newer standards, and so by doing >>>>>> that, we risk introducing problems. Reading in the system header, it >>>>>> seems the _XPG6 macro is internal and should not be used by the >>>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>>> >>>>> Interesting. We should probably define one, or both of these. Perhaps >>>>> globally for all native files and compilers. It might have been the >>>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>>> prior to setting -std=c99. The following stack overflow article claims >>>>> that this is at least the behavior of gcc/clang: >>>>> >>>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>>> same-time >>>>> >>>>> >>>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>>> That would explain why this starts to fail. I'll see if I can confirm >>>>> this the next time I log into a Solaris computer. >>>> Of course it was not as simple. Setting: >>>> ifeq ($(OPENJDK_TARGET_OS), solaris) >>>> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>>> D_XOPEN_SOURCE=600 >>>> endif >>>> >>>> instead made us fail with: >>>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>>> line 143: error: incomplete struct/union/enum timezone: tz >>>> >>>> I don't have more time to dig into this now. Overall, changes such as >>>> these make it all feel a bit scary; I recommend that any change to this >>>> be made in JDK 13 and not 12. >>>> >>>> /Magnus >>>>> >>>>> Otoh, the same article claims, and it sounds reasonable, that we >>>>> should set these variables ourself, to be well behaved and to minimize >>>>> surprises. And I think this applies to all unix platforms, regardless >>>>> of compiler being used. I'll see if I can kick off a test job with >>>>> this to see how/if it influences other platforms. But it sounds like >>>>> something we should do; the level of posix conformance should be >>>>> controlled by us, not left to chance. We also need to verify, of >>>>> course, that all platforms we want to support is capable of >>>>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >>>> though. >>>>> Possibly on AIX... >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> So the the question is, is it ok to override the requirements of >>>>>> libpng or should it receive special treatment? If we are fine with >>>>>> overriding, then we should use one of the public APIs instead. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>>> From the bug report: >>>>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>>>> -xc99=%none%. >>>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>>> replace the setting. >>>>>>>>>>> >>>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>>>> >>>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>>> builds are cleared. >>>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>>> simple fix to that. >>>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>>> WebRev: >>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- >> with- >>>> c99/webrev.01 >>>>>>>>> >>> with-c99/webrev.01> >>>>>>>>> >>>>>>>>> >>>>>>>>> Now this passes the CI build test. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>>> Patch inline: >>>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>>> >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - >> W0,- >>>> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- >> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>>> norunpath >>>>>>>>>>> -xnolib" # CXX only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>>> features=no%split_init \ >>>>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>>>> $TOOLCHAIN_FLAGS" > From philip.race at oracle.com Thu Dec 20 18:57:31 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 20 Dec 2018 10:57:31 -0800 Subject: [12] Review Request: 8214918 Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms In-Reply-To: References: Message-ID: <02dfa80a-0cbf-ce8b-f93d-4dd7be5404ab@oracle.com> The synopsis made me think this was refactoring. But when I read it, it seems to be proposing removing the ability to centre a window on a Xinerama desktop, with the principal justification that this was only ever something that worked on Solaris. Is this absolutely necessary ? Does that mean this (xinerama centering) is fundamentally unsupportable on Linux ? Don't you need to update the docs / referenced spec ? -phil. On 12/6/18 9:26 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 12. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214918 > Webrev: http://cr.openjdk.java.net/~serb/8214918/webrev.00 > > In the fix for JDK-8076313 I need to implement possibility of switch > between xinerama and non-xinerama modes at runtime. As a separate part > I would like to investigate the usage of > X11GraphicsEnvironment.runningXinerama() and replace it by some other > generic for single/multi-screen solution. > > This bug is about one of the place where the flag above is used. > > In jdk 1.4 two new methods were added to the GraphicsEnvironment class: > ?- getCenterPoint() > ?- getMaximumWindowBounds() > see > https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering > > Take a look to this descriptions from the link above: > "X-Window, Xinerama > All monitors share a single virtual coordinate space, as on Microsoft > Windows. However, it is possible for the user to specify through X > resources where windows should be centered. If these resources are > set, getCenterPoint reflects their value. Otherwise, it returns the > point at the center of the virtual coordinate space. (In practice, > this will almost always be set - CDE sets it by default.)" > > Since the case above was implemented on the Solaris, and uses an > extension of the xinerama, I suggest to remove this and align > implementation across the platforms: > ?- getCenterPoint returns the coordinates of the center of the primary > display for all platforms > ?- getMaximumWindowBounds returns the bounds of the primary display > minus display insets for all platforms > > From philip.race at oracle.com Thu Dec 20 19:03:28 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 20 Dec 2018 11:03:28 -0800 Subject: [12] Review Request: JDK-8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using Swing-FX interop In-Reply-To: <546e70ac-eff8-4d58-802a-25d8f04914a6@default> References: <546e70ac-eff8-4d58-802a-25d8f04914a6@default> Message-ID: +1 -phil. On 12/14/18 5:48 AM, Pankaj Bansal wrote: > > Hi All, Please review fix for the below bug jdk12: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215364 > > Webrev: http://cr.openjdk.java.net/~pbansal/8215364/webrev.00/ > > Issue: > > JavaFX uses both X11 and gtk code and gtk3 uses Wayland backend while > running Ubuntu 18.04 in Wayland mode. This results in crash in JavaFX. > This crash is being done under [1] by setting the gtk3 backend to x11 > on all systems by setting GDK_BACKEND=x11. This fixes the JavaFX crash. > > However, while using the a JFXPanel inside Swing components in > Swing-FX interop with GTKLookAndFeel set as L&F for Swing, the AWT > loads the gtk3 first and as the GDK_BACKEND=x11 is not yet set even > after the fix for [1], the gtk3 starts using the Wayland backend. Then > while initializing the JFXPanel, JavaFX uses the same gtk library > loaded by AWT and this results in crash. > > Fix: > > The fix is to set the gtk backend to x11 in AWT as well by setting the > GDK_BACKEND=x11. This fixes the Swing-FX interop crash as well. > > [1] https://bugs.openjdk.java.net/browse/JDK-8210411 > > Regards, > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Thu Dec 20 19:33:12 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Dec 2018 11:33:12 -0800 Subject: [12] Review Request: JDK-8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using Swing-FX interop In-Reply-To: References: <546e70ac-eff8-4d58-802a-25d8f04914a6@default> Message-ID: +1 -- Kevin On 12/20/2018 11:03 AM, Phil Race wrote: > +1 > > -phil. > > On 12/14/18 5:48 AM, Pankaj Bansal wrote: >> >> Hi All, Please review fix for the below bug jdk12: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215364 >> >> Webrev: http://cr.openjdk.java.net/~pbansal/8215364/webrev.00/ >> >> >> Issue: >> >> JavaFX uses both X11 and gtk code and gtk3 uses Wayland backend while >> running Ubuntu 18.04 in Wayland mode. This results in crash in >> JavaFX. This crash is being done under [1] by setting the gtk3 >> backend to x11 on all systems by setting GDK_BACKEND=x11. This fixes >> the JavaFX crash. >> >> However, while using the a JFXPanel inside Swing components in >> Swing-FX interop with GTKLookAndFeel set as L&F for Swing, the AWT >> loads the gtk3 first and as the GDK_BACKEND=x11 is not yet set even >> after the fix for [1], the gtk3 starts using the Wayland backend. >> Then while initializing the JFXPanel, JavaFX uses the same gtk >> library loaded by AWT and this results in crash. >> >> Fix: >> >> The fix is to set the gtk backend to x11 in AWT as well by setting >> the GDK_BACKEND=x11. This fixes the Swing-FX interop crash as well. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8210411 >> >> Regards, >> Pankaj Bansal >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Dec 20 23:06:19 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 20 Dec 2018 15:06:19 -0800 Subject: [12] Review Request: 8214918 Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms In-Reply-To: <02dfa80a-0cbf-ce8b-f93d-4dd7be5404ab@oracle.com> References: <02dfa80a-0cbf-ce8b-f93d-4dd7be5404ab@oracle.com> Message-ID: On 20/12/2018 10:57, Phil Race wrote: > The synopsis made me think this was refactoring. > But when I read it, it seems to be proposing removing the ability to > centre a window on a Xinerama desktop, with the principal justification that > this was only ever something that worked on Solaris.> > Is this absolutely necessary ? Yes, I would like to drop it as it causes some surprising behavior, when the window is opened somewhere out of the main screen. I have reopened the similar bug for the splash screen: https://bugs.openjdk.java.net/browse/JDK-6481523 At some point we should follow this logic: - By default use the main screen for the window/splash(even better the screen where the app was run) - The user may customize it by the "XINERAMA_CENTER_HINT" atom. > Does that mean this (xinerama centering) is fundamentally unsupportable on Linux ? It is possible to implement even on windows/mac but we should not by default open the windows in between of screens. > Don't you need to update the docs / referenced spec ? It was a Solaris only implementation, and guess we have no strict specification on how it should work. > > -phil. > > > On 12/6/18 9:26 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 12. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214918 >> Webrev: http://cr.openjdk.java.net/~serb/8214918/webrev.00 >> >> In the fix for JDK-8076313 I need to implement possibility of switch between xinerama and non-xinerama modes at runtime. As a separate part I would like to investigate the usage of X11GraphicsEnvironment.runningXinerama() and replace it by some other generic for single/multi-screen solution. >> >> This bug is about one of the place where the flag above is used. >> >> In jdk 1.4 two new methods were added to the GraphicsEnvironment class: >> ?- getCenterPoint() >> ?- getMaximumWindowBounds() >> see https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering >> >> Take a look to this descriptions from the link above: >> "X-Window, Xinerama >> All monitors share a single virtual coordinate space, as on Microsoft Windows. However, it is possible for the user to specify through X resources where windows should be centered. If these resources are set, getCenterPoint reflects their value. Otherwise, it returns the point at the center of the virtual coordinate space. (In practice, this will almost always be set - CDE sets it by default.)" >> >> Since the case above was implemented on the Solaris, and uses an extension of the xinerama, I suggest to remove this and align implementation across the platforms: >> ?- getCenterPoint returns the coordinates of the center of the primary display for all platforms >> ?- getMaximumWindowBounds returns the bounds of the primary display minus display insets for all platforms >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Dec 21 00:20:29 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 20 Dec 2018 16:20:29 -0800 Subject: [13] Review Request: 8215756 Memory leaks in the AWT on macOS Message-ID: Hello. Please review the fix for jdk 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8215756 Webrev: http://cr.openjdk.java.net/~serb/8215756/webrev.00 Two memory leaks were fixed: - AWTView.m: we should release the NSTrackingArea, usually we do this when we change NSTrackingArea from one to another: http://hg.openjdk.java.net/jdk/jdk/file/3791fee4df3b/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m#l437 But we also need to do this when the window is deallocated - AWTWindow.m: We have a JNFWeakJObjectWrapper which holds the reference to the java object, when the window is deallocated we clear the reference to the java object, but we also need to release the JNFWeakJObjectWrapper object itself I have checked by the Instruments that the test attached to the bug will not produce any other leaks after the fix. -- Best regards, Sergey. From dmitry.markov at oracle.com Fri Dec 21 18:33:03 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 21 Dec 2018 18:33:03 +0000 Subject: [13] Review Request: 8215756 Memory leaks in the AWT on macOS In-Reply-To: References: Message-ID: <2CECA05D-5094-4964-9AF4-BA5473D0F86A@oracle.com> Hi Sergey, The fix looks good to me. Thanks, Dmitry > On 21 Dec 2018, at 00:20, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215756 > Webrev: http://cr.openjdk.java.net/~serb/8215756/webrev.00 > > Two memory leaks were fixed: > > - AWTView.m: we should release the NSTrackingArea, usually we do this > when we change NSTrackingArea from one to another: > http://hg.openjdk.java.net/jdk/jdk/file/3791fee4df3b/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m#l437 > But we also need to do this when the window is deallocated > - AWTWindow.m: We have a JNFWeakJObjectWrapper which holds the reference to the java object, > when the window is deallocated we clear the reference to the java object, but > we also need to release the JNFWeakJObjectWrapper object itself > > I have checked by the Instruments that the test attached to the bug will not produce any other leaks after the fix. > > > -- > Best regards, Sergey. From krishna.addepalli at oracle.com Mon Dec 31 04:50:10 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 31 Dec 2018 10:20:10 +0530 Subject: [13] RFR: JDK-8215910: Typo in AWT InvocationEvent Method Documentation Message-ID: <7BF22B48-8B10-4D55-8831-C7AA8F2E4C1A@oracle.com> Hi All, Please review a trivial doc fix for JDK-8215910. Webrev: http://cr.openjdk.java.net/~kaddepalli/8215910/webrev00/ Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Mon Dec 31 13:09:12 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 31 Dec 2018 16:09:12 +0300 Subject: [13] RFR: JDK-8215910: Typo in AWT InvocationEvent Method Documentation In-Reply-To: <7BF22B48-8B10-4D55-8831-C7AA8F2E4C1A@oracle.com> References: <7BF22B48-8B10-4D55-8831-C7AA8F2E4C1A@oracle.com> Message-ID: Hi Krishna, But the bug hasn't been fixed yet: - 230????? * @param listener????????? The {@code Runnable}Runnable whose + 230????? * @param listener????????? The {@code Runnable} Runnable whose The second ?Runnable? is not needed at all. Regards, Alexey On 31/12/2018 07:50, Krishna Addepalli wrote: > Hi All, > > Please review a trivial doc fix for JDK-8215910. > Webrev: http://cr.openjdk.java.net/~kaddepalli/8215910/webrev00/ > > Thanks, > Krishna From RalfWisser at gmx.net Thu Dec 6 13:12:10 2018 From: RalfWisser at gmx.net (Ralf Wisser) Date: Thu, 06 Dec 2018 13:12:10 -0000 Subject: IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow (openjdk-jdk11) Message-ID: An HTML attachment was scrubbed... URL: