Re: [12] Review Request: 8211822 and 8202886

Changes are fine. Thanks, Jay > On 31-Oct-2018, at 12:19 PM, Sergey Bylokhov > wrote: > > HI, Jay. > > The fix is updated: > http://cr.openjdk.java.net/~serb/8211822/webrev.01 > - The lines which were added recently to the ProblemList, were removed. > - The typo in the bug4199622 was fixed. >

Re: [12] Review Request: 8211822 and 8202886

HI, Jay. The fix is updated: http://cr.openjdk.java.net/~serb/8211822/webrev.01 - The lines which were added recently to the ProblemList, were removed. - The typo in the bug4199622 was fixed. On 30/10/2018 03:46, Jayathirth D V wrote: Hi Sergey, Apart from 3 test cases updated, I am seeing

Re: [12] RFR JDK-8213138: Update ProblemList.txt for mac

Hi Sergey, What is the syntax of this? I tried -nativepath: but it gave "unexpected exit from test code" Can we put this option in the test itself in @run option? since we do not run with nativepath option neither in PIT not in test sprint, it will always fail. Regards Prasanta On 31-Oct-1

Re: [12] Review Request: 8211833 Javadoc cleanup of java.applet package

On 30/10/2018 12:35, Phil Race wrote: Looks OK but I am wondering why some of the formatting changes were done - * then a call to {@code getParameter("Color")} returns the - * value {@code "blue"}. + * then a call to {@code getParameter("Color")} returns the value + * {@code "blue"}. I splits

Re: [12] Review request for JDK-8208543: [macos] Support for apple.awt.documentModalSheet incomplete

Hello, Can somebody explain how the dialog which have the "documentModalSheet" property should behave? I thought this dialogs should looks like this: https://stackoverflow.com/questions/13777067/swing-native-look-and-feel-for-jdialog-in-macos But when I run the manual testcase which is attached

Re: RFR: 8211267 StackOverflowError happened by TextField.setFont(...)

If it requires some user interaction to cause it, because it needs to be triggered in a narrow way then see the many AWT tests that use Robot .. If it just needs a setFont call on the EDT perhaps you can do that programmatically. I hope you can call getFont() to verify success rather than having

Re: RFR: 8211267 StackOverflowError happened by TextField.setFont(...)

Thanks Phil, and I appreciate your suggestion. For all, Is there some non-interactive examples? Next step, I'll migrate this testcase to non-interactive version. Thanks, On 2018-10-31 02:46, Phil Race wrote: Looks good. A bit disappointing the test has to be manual .. they rarely get run. -p

Re: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr.

On 30/10/2018 15:52, Philip Race wrote: But Robot.delay() is inherently a long lived operation, so interrupts are more likely there. And you *are* changing behaviour. So I am still unconvinced this is right. When might this matter in practice in writing tests ? This might matter for example if

Re: [12] RFR JDK-8213138: Update ProblemList.txt for mac

Hi, Prasanta. On 30/10/2018 02:58, Prasanta Sadhukhan wrote: java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java: JDK-8213126 The failure of the TestMainKeyWindow.java is not a bug, you need to provide -nativepath to the jtreg, because t

Re: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr.

But Robot.delay() is inherently a long lived operation, so interrupts are more likely there. And you *are* changing behaviour. So I am still unconvinced this is right. When might this matter in practice in writing tests ? -phil. On 10/30/18, 3:17 PM, Sergey Bylokhov wrote: On 30/10/2018 14:03

Re: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr.

On 30/10/2018 14:03, Phil Race wrote: But the docs for Robot.delay() state :  >  To catch any |InterruptedException|s that occur, |Thread.sleep()| may be used instead. So to my reading it is telling you "this call will completely swallow thread interrupts". This is what I have tried to fol

Re: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr.

But the docs for Robot.delay() state :  >  To catch any |InterruptedException|s that occur, |Thread.sleep()| may be used instead. So to my reading it is telling you "this call will completely swallow thread interrupts". And you are changing that and I don't think you should. It has nothing

Re: [12] Review Request: 8211435 Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source

On 30/10/2018 12:58, Phil Race wrote: I don't think AppContexts ever mattered for webstart. Whilst webstart apps may run sandboxed with limited permissions, they were never run in the same VM like applets were. Each JNLP application has its own JRE, doesn't it ? If I remember this correctly the

Re: [12] Review Request: 8211435 Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source

I don't think AppContexts ever mattered for webstart. Whilst webstart apps may run sandboxed with limited permissions, they were never run in the same VM like applets were. Each JNLP application has its own JRE, doesn't it ? So I was imagining that somehow a "sophisticated" application was trying

Re: [12] Review Request: 8211435 Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source

Hi, Laurent. I think you overestimate the role of appcontext. It was created as way to make a sandbox for the untrusted applets. So such applets were not able to access internals of the webstart itself, for example the application/applet should not had an access(via Frames.getFrames()) to the

Re: [12] Review Request: 8211833 Javadoc cleanup of java.applet package

Looks OK but I am wondering why some of the formatting changes were done - * then a call to {@code getParameter("Color")} returns the - * value {@code "blue"}. + * then a call to {@code getParameter("Color")} returns the value + * {@code "blue"}. Seems you were trying to make it so that line br

Re: [12] RFR : JDK-8198001 : java/awt/Menu/WrongParentAfterRemoveMenu/WrongParentAfterRemoveMenu.java debug assert on Windows

+ * @bug 8165769, 8198001 Are commas allowed ? http://openjdk.java.net/jtreg/tag-spec.html Argument tokens are separated by whitespace; if commas are used, >they will be considered to be part of the tokens to which they are adjacent. So you now have a bug id of "8165769," acc. to these parsing

Re: [12] Review Request: 8211435 Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source

Hi Phil, Oracle deprecated Java Web Start but I am now involved in IcedTeaWeb to maintain JNLP support for our science tools at http://www.jmmc.fr ! I DO need AppContexts, and anything useful to maintain IcedTeaWeb alive ... Cheers, Laurent Le mar. 30 oct. 2018 à 18:20, Phil Race a écrit : >

Re: [12] RFR : JDK-8198001 : java/awt/Menu/WrongParentAfterRemoveMenu/WrongParentAfterRemoveMenu.java debug assert on Windows

Looks fine. On 30/10/2018 09:45, Ambarish Rapte wrote: Hi Phil, Thanks for the review comments. Please take a look at updated webrev: http://cr.openjdk.java.net/~arapte/8198001/webrev.01/ Updated the test with bud ID. The test is not included in problem list. Regards, Ambarish *From:*Phi

Re: [12] Review Request: 8208702 javax/swing/reliability/HangDuringStaticInitialization.java may hang on macos

Hi, Denis. It is not possible to avoid duplication from the implementation point of view, because these two libraries should not depend from each other. It is possible to deduplicate it in the source code, for example by moving this method to some separate header in the java.base and use it fro

Re: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr.

Hi, Phil. On 30/10/2018 10:34, Phil Race wrote: Can you explain why you are doing this ? Thread.sleep() clears the IE so why do you need to restore it ? It just looks like an un-specified and un-needed change of behaviour to me. It is done to "notify" other code which follows Robot.delay() tha

Re: [12] Review Request: 8207070 Webstart app popup on wrong screen in a one-screen setup changing to multi-monitor

+1 Minor nit, there's a wild card import in the test :- 24 import java.awt.*; -phil. On 10/11/18 11:52 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8207070 Webrev: http://cr.openjdk.java.net/~serb/8207070/webrev.01 Bug

Re: RFR: 8211826 getGTKIcon with Unicode chars got StringIndexOutOfBoundsException

Hello. Could you review the fix ? It's fixed invalid usage for JNI's data size calculation. Small testcase is in JDK-8211826. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-10-08 11:46, Ichiroh Takiguchi wrote: Hello. Could you review the fix ? Bug:https://bugs.openjdk.java.net/browse

Re: RFR: 8211267 StackOverflowError happened by TextField.setFont(...)

Looks good. A bit disappointing the test has to be manual .. they rarely get run. -phil. On 10/30/2018 10:39 AM, Ichiroh Takiguchi wrote: Hello. Additional reviewer is required. Please let me know if you have question and suggestion. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-10-05 0

Re: [12] Review Request: 8208702 javax/swing/reliability/HangDuringStaticInitialization.java may hang on macos

Looks fine. On 10/29/18 11:02 PM, Denis Fokin wrote: Is there a way to avoid the code duplication? You mean the code copied from the launcher ? Not sure, but it would probably be way more hassle than its worth since it seems like we'd need to link libawt against the libjli that belongs to the

Re: RFR: 8211267 StackOverflowError happened by TextField.setFont(...)

Hello. Additional reviewer is required. Please let me know if you have question and suggestion. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-10-05 06:21, Sergey Bylokhov wrote: Looks fine. On 02/10/2018 03:44, Ichiroh Takiguchi wrote: Hello Sergey. I appreciate your suggestion. Yeah, I

Re: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr.

> and the interrupted state of the thread is restored Can you explain why you are doing this ? Thread.sleep() clears the IE so why do you need to restore it ? It just looks like an un-specified and un-needed change of behaviour to me. -phil. On 10/7/18 9:56 PM, Sergey Bylokhov wrote: Hello. P

Re: [12] Review Request: 8211435 Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source

Looks good to me. I'll take this opportunity to ask a question to people on this list. Now that we've removed plugin+webstart, do we still need AppContext at all ? Can the entire mechanism be removed from all sources ? Or is there still some useful reason for keeping it ? Even though it is inter

Re: [12] RFR : JDK-8198001 : java/awt/Menu/WrongParentAfterRemoveMenu/WrongParentAfterRemoveMenu.java debug assert on Windows

Hi Phil, Thanks for the review comments. Please take a look at updated webrev: http://cr.openjdk.java.net/~arapte/8198001/webrev.01/ Updated the test with bud ID. The test is not included in problem list. Regards, Ambarish From: Phil Race Sent: Tuesday, October 30, 2018 12:46 AM T

Re: RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception

Seems fine and trivial. Regards, Thomas On Tue, Oct 30, 2018 at 2:56 PM Volker Simonis wrote: > > Hi, > > can I please have a review for the following tiny change which fixes > the license header on a few AIX-specific files: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ > https:/

RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception

Hi, can I please have a review for the following tiny change which fixes the license header on a few AIX-specific files: http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ https://bugs.openjdk.java.net/browse/JDK-8213151 These files have been wrongly integrated (without the Classpath Exce

Re: [12] Review request for JDK-8208543: [macos] Support for apple.awt.documentModalSheet incomplete

+1 Krishna -Original Message- From: Dmitry Markov Sent: Friday, October 26, 2018 4:57 PM To: Manajit Halder Cc: awt-dev@openjdk.java.net Subject: Re: [12] Review request for JDK-8208543: [macos] Support for apple.awt.documentModalSheet incomplete Hi Manajit, Looks good to me. Thank

Re: [12] Review Request: 8211822 and 8202886

Hi Sergey, Apart from 3 test cases updated, I am seeing failure of javax/swing/JComboBox/4199622/bug4199622.java also because of same reason. I raised JDK-8213122 and we actually updated ProblemList today to reflect these failures and after that I saw this RFR. We need to make similar change in

Re: [12] RFR JDK-8213138: Update ProblemList.txt for mac

Changes are fine.   Regards, Jay   From: Prasanta Sadhukhan Sent: Tuesday, October 30, 2018 3:28 PM To: awt-dev@openjdk.java.net; swing-...@openjdk.java.net; 2d-dev Subject: [12] RFR JDK-8213138: Update ProblemList.txt for mac   Hi All, Please review an updation of ProblemList for mac jtr

[12] RFR JDK-8213138: Update ProblemList.txt for mac

Hi All, Please review an updation of ProblemList for mac jtreg run. Following tests were added in ProblemList. With this addition, mac10.13 jtreg run shows no failures/errors. java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java: JDK-8213126

Re: [OpenJDK 2D-Dev] [12] RFR JDK-8213130: Update ProblemList after verification of jtreg tests in Win 7

looks ok. Regards Prasanta On 30-Oct-18 2:13 PM, Jayathirth D V wrote: Hello All, Please review the following fix in JDK 12: Bug : https://bugs.openjdk.java.net/browse/JDK-8213130 Webrev : http://cr.openjdk.java.net/~jdv/8213130/webrev.00/

[OpenJDK 2D-Dev] [12] RFR JDK-8213130: Update ProblemList after verification of jtreg tests in Win 7

Hello All, Please review the following fix in JDK 12: Bug : https://bugs.openjdk.java.net/browse/JDK-8213130 Webrev : http://cr.openjdk.java.net/~jdv/8213130/webrev.00/ These are the test failures/errors which happen when they are run individually. All the failures/erros are happenin