From vicente.romero at oracle.com Wed Dec 4 17:49:41 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 4 Dec 2019 12:49:41 -0500 Subject: REF: problem-listing two tests as part of the records change Message-ID: <4fe27c16-72b0-c941-3e2a-8c505c2cd5e2@oracle.com> Please review this small change to the problem list. This change will be part of the records effort. These two tests are failing right now but we plan to fix this asap. As the change is two small I have inlined it here: diff -r f90eefff864e -r cb15096bd3ec test/langtools/ProblemList.txt --- a/test/langtools/ProblemList.txt??? Tue Dec 03 20:23:53 2019 -0800 +++ b/test/langtools/ProblemList.txt??? Wed Dec 04 11:10:33 2019 -0500 @@ -37,6 +37,7 @@ ?jdk/jshell/UserJdiUserRemoteTest.java 8173079??? linux-all ?jdk/jshell/UserInputTest.java 8169536??? generic-all +jdk/jshell/CompletenessTest.java 8235338??? generic-all ?########################################################################### ?# @@ -55,6 +56,7 @@ ?tools/javac/modules/SourceInSymlinkTest.java 8180263??? windows-all??? fails when run on a subst drive ?tools/javac/importscope/T8193717.java 8203925??? generic-all??? the test requires too much memory ?tools/javac/options/BCPOrSystemNotSpecified.java 8231179??? windows-all??? fails when creating a test bootclasspath +tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java 8235339??? generic-all??? fails after new annotation target RECORD_COMPONENT was introduced ?########################################################################### ?# Thanks, Vicente From jan.lahoda at oracle.com Thu Dec 5 15:59:37 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 5 Dec 2019 16:59:37 +0100 Subject: RFR; JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records Message-ID: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> Hi, This is a patch to improve the behavior of jshell w.r.t. records, including fixing the recently problem-listed CompletenessTest.java. Notes on the patch: -added jdk.jshell.Snippet.SubKind.RECORD_SUBKIND, similar to ENUM_SUBKIND. CSR for this change for review is here: https://bugs.openjdk.java.net/browse/JDK-8235421 -moved setting the record final from JavacParsert to Check.checkFlags (as jshell was struggling with the modifier being set in parser, and checkFlags seems to be a better place anyway) -improved JavacParser.isRecordStart to take EOF into account - this could be moved to jshell if too dangerous, but might be good for javac for error recovery -Pretty (JCClassDecl.toString()) should now print records as records instead of classes. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8235338/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8235338 How does this look? Thanks, Jan From jan.lahoda at oracle.com Fri Dec 6 11:38:53 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 6 Dec 2019 12:38:53 +0100 Subject: RFR: JDK-8235474: JShell does not handle records properly Message-ID: <8419cdd2-56bd-e16b-099a-90b3b64283c1@oracle.com> Hi, As a spin-off from: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014001.html I propose to improve the record handling in jshell. Please see the original post for some more details. Webrev: http://cr.openjdk.java.net/~jlahoda/8235474/webrev.00/ CSR for review: https://bugs.openjdk.java.net/browse/JDK-8235476 JBS: https://bugs.openjdk.java.net/browse/JDK-8235474 How does this look? Thanks, Jan From jan.lahoda at oracle.com Fri Dec 6 11:53:37 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 6 Dec 2019 12:53:37 +0100 Subject: RFR; JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records In-Reply-To: References: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> Message-ID: <3d13e3a3-3c6c-0c4f-14fc-ff4e7949e995@oracle.com> On 05. 12. 19 20:23, Robert Field wrote: > Maybe it is just me, but adding support for records in JShell as well as > seemingly correcting the compiler's processing of records under a bug > for a JShell test failure seems inappropriate. Probably could be > addressed by creating a RFE that covers it. The test failure is directly caused by the incorrect support for records in JShell. Basically, the only thing in the patch that does not have a fairly close connection to the test is the fix for Pretty. But I am OK with splitting the reports, so I've created: https://bugs.openjdk.java.net/browse/JDK-8235474 and submitted: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014014.html The patch for this bug then depends on JDK-8235474 and is here: http://cr.openjdk.java.net/~jlahoda/8235338/webrev.01/ The CSR is no longer needed for this particular bug (although it is still needed for JDK-8235474). Also moving compiler-dev on CC, since this is no longer a javac patch. Jan > > I assume the CSR needs to be approved before this is pushed.? The CSR > has the same naming issue. > > Otherwise looks fine. > > -Robert > > > On 12/5/19 7:59 AM, Jan Lahoda wrote: >> Hi, >> >> This is a patch to improve the behavior of jshell w.r.t. records, >> including fixing the recently problem-listed CompletenessTest.java. >> >> Notes on the patch: >> -added jdk.jshell.Snippet.SubKind.RECORD_SUBKIND, similar to >> ENUM_SUBKIND. CSR for this change for review is here: >> https://bugs.openjdk.java.net/browse/JDK-8235421 >> -moved setting the record final from JavacParsert to Check.checkFlags >> (as jshell was struggling with the modifier being set in parser, and >> checkFlags seems to be a better place anyway) >> -improved JavacParser.isRecordStart to take EOF into account - this >> could be moved to jshell if too dangerous, but might be good for javac >> for error recovery >> -Pretty (JCClassDecl.toString()) should now print records as records >> instead of classes. >> >> Proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8235338/webrev.00/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235338 >> >> How does this look? >> >> Thanks, >> ??? Jan From vicente.romero at oracle.com Fri Dec 6 12:58:11 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 6 Dec 2019 07:58:11 -0500 Subject: RFR: JDK-8235474: JShell does not handle records properly In-Reply-To: <8419cdd2-56bd-e16b-099a-90b3b64283c1@oracle.com> References: <8419cdd2-56bd-e16b-099a-90b3b64283c1@oracle.com> Message-ID: <4f657b13-a0bc-f52f-fda0-4652fd89b09b@oracle.com> Hi Jan, The CSR and the patch look good to me. Nit, the local variable `isDatum` could be renamed to `isRecord`, Thanks for fixing this, Vicente On 12/6/19 6:38 AM, Jan Lahoda wrote: > Hi, > > As a spin-off from: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014001.html > > > I propose to improve the record handling in jshell. Please see the > original post for some more details. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8235474/webrev.00/ > CSR for review: https://bugs.openjdk.java.net/browse/JDK-8235476 > JBS: https://bugs.openjdk.java.net/browse/JDK-8235474 > > How does this look? > > Thanks, > ??? Jan From robert.field at oracle.com Fri Dec 6 22:28:37 2019 From: robert.field at oracle.com (Robert Field) Date: Fri, 6 Dec 2019 14:28:37 -0800 Subject: RFR; JDK-8235338: test jdk/jshell/CompletenessTest.java fails for records In-Reply-To: <3d13e3a3-3c6c-0c4f-14fc-ff4e7949e995@oracle.com> References: <63217e4d-ccd6-9ab4-4250-c22b726e0ff3@oracle.com> <3d13e3a3-3c6c-0c4f-14fc-ff4e7949e995@oracle.com> Message-ID: +1 On 12/6/19 3:53 AM, Jan Lahoda wrote: > On 05. 12. 19 20:23, Robert Field wrote: >> Maybe it is just me, but adding support for records in JShell as well >> as seemingly correcting the compiler's processing of records under a >> bug for a JShell test failure seems inappropriate. Probably could be >> addressed by creating a RFE that covers it. > > The test failure is directly caused by the incorrect support for > records in JShell. Basically, the only thing in the patch that does > not have a fairly close connection to the test is the fix for Pretty. > > But I am OK with splitting the reports, so I've created: > https://bugs.openjdk.java.net/browse/JDK-8235474 > and submitted: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-December/014014.html > > > The patch for this bug then depends on JDK-8235474 and is here: > http://cr.openjdk.java.net/~jlahoda/8235338/webrev.01/ > > The CSR is no longer needed for this particular bug (although it is > still needed for JDK-8235474). Also moving compiler-dev on CC, since > this is no longer a javac patch. > > Jan > >> >> I assume the CSR needs to be approved before this is pushed. The CSR >> has the same naming issue. >> >> Otherwise looks fine. >> >> -Robert >> >> >> On 12/5/19 7:59 AM, Jan Lahoda wrote: >>> Hi, >>> >>> This is a patch to improve the behavior of jshell w.r.t. records, >>> including fixing the recently problem-listed CompletenessTest.java. >>> >>> Notes on the patch: >>> -added jdk.jshell.Snippet.SubKind.RECORD_SUBKIND, similar to >>> ENUM_SUBKIND. CSR for this change for review is here: >>> https://bugs.openjdk.java.net/browse/JDK-8235421 >>> -moved setting the record final from JavacParsert to >>> Check.checkFlags (as jshell was struggling with the modifier being >>> set in parser, and checkFlags seems to be a better place anyway) >>> -improved JavacParser.isRecordStart to take EOF into account - this >>> could be moved to jshell if too dangerous, but might be good for >>> javac for error recovery >>> -Pretty (JCClassDecl.toString()) should now print records as records >>> instead of classes. >>> >>> Proposed patch: >>> http://cr.openjdk.java.net/~jlahoda/8235338/webrev.00/ >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235338 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan From robert.field at oracle.com Sat Dec 7 02:54:16 2019 From: robert.field at oracle.com (Robert Field) Date: Fri, 6 Dec 2019 18:54:16 -0800 Subject: RFR JShell: NPE in translateExceptionStack and /help /help Message-ID: Please review ... Bugs: https://bugs.openjdk.java.net/browse/JDK-8210527 https://bugs.openjdk.java.net/browse/JDK-8232855 Webrev: http://cr.openjdk.java.net/~rfield/8210527v1.webrev/ Thanks, Robert From robert.field at oracle.com Wed Dec 11 21:42:52 2019 From: robert.field at oracle.com (Robert Field) Date: Wed, 11 Dec 2019 13:42:52 -0800 Subject: Small - PLEASE Review: RFR JShell: NPE in translateExceptionStack and /help /help In-Reply-To: References: Message-ID: <26f35517-1c29-d5c9-1b0c-93b8960a5e20@oracle.com> Today is last day for one of these. Thanks, Robert On 12/6/19 6:54 PM, Robert Field wrote: > Please review ... > > Bugs: > > https://bugs.openjdk.java.net/browse/JDK-8210527 > > https://bugs.openjdk.java.net/browse/JDK-8232855 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8210527v1.webrev/ > > > Thanks, > Robert > From stevenschlansker at gmail.com Wed Dec 11 21:55:52 2019 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Wed, 11 Dec 2019 13:55:52 -0800 Subject: Small - PLEASE Review: RFR JShell: NPE in translateExceptionStack and /help /help In-Reply-To: <26f35517-1c29-d5c9-1b0c-93b8960a5e20@oracle.com> References: <26f35517-1c29-d5c9-1b0c-93b8960a5e20@oracle.com> Message-ID: <3082D110-A0E0-4A42-87F1-578B93857472@gmail.com> In particular we were excited to use JShell but could not present it to internal customers while stack traces involving Proxy objects (which we use extensively) cause JShell to crash. We are still looking forward to using JShell more extensively once JDK-8210527 is solved. Thank you Robert and whoever ends up reviewing the changes! > On Dec 11, 2019, at 1:42 PM, Robert Field wrote: > > Today is last day for one of these. > > Thanks, > Robert > > On 12/6/19 6:54 PM, Robert Field wrote: >> Please review ... >> >> Bugs: >> >> https://bugs.openjdk.java.net/browse/JDK-8210527 >> >> https://bugs.openjdk.java.net/browse/JDK-8232855 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8210527v1.webrev/ >> >> >> Thanks, >> Robert >> From jan.lahoda at oracle.com Wed Dec 11 22:00:17 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 11 Dec 2019 23:00:17 +0100 Subject: Small - PLEASE Review: RFR JShell: NPE in translateExceptionStack and /help /help In-Reply-To: <26f35517-1c29-d5c9-1b0c-93b8960a5e20@oracle.com> References: <26f35517-1c29-d5c9-1b0c-93b8960a5e20@oracle.com> Message-ID: <5c5160ee-4a42-3e4e-1c40-40496f4f72b1@oracle.com> Looks good to me. Jan On 11. 12. 19 22:42, Robert Field wrote: > Today is last day for one of these. > > Thanks, > Robert > > On 12/6/19 6:54 PM, Robert Field wrote: >> Please review ... >> >> Bugs: >> >> https://bugs.openjdk.java.net/browse/JDK-8210527 >> >> https://bugs.openjdk.java.net/browse/JDK-8232855 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8210527v1.webrev/ >> >> >> Thanks, >> Robert >> From robert.field at oracle.com Sat Dec 14 22:48:55 2019 From: robert.field at oracle.com (Robert Field) Date: Sat, 14 Dec 2019 14:48:55 -0800 Subject: Small - PLEASE Review: RFR JShell: NPE in translateExceptionStack and /help /help In-Reply-To: <3082D110-A0E0-4A42-87F1-578B93857472@gmail.com> References: <26f35517-1c29-d5c9-1b0c-93b8960a5e20@oracle.com> <3082D110-A0E0-4A42-87F1-578B93857472@gmail.com> Message-ID: Well, Steven, the fix for JDK-8210527 is in JDK 14 now. -Robert On 12/11/19 1:55 PM, Steven Schlansker wrote: > In particular we were excited to use JShell but could not present it to internal customers > while stack traces involving Proxy objects (which we use extensively) cause JShell to crash. > > We are still looking forward to using JShell more extensively once JDK-8210527 is solved. > Thank you Robert and whoever ends up reviewing the changes! > >> On Dec 11, 2019, at 1:42 PM, Robert Field wrote: >> >> Today is last day for one of these. >> >> Thanks, >> Robert >> >> On 12/6/19 6:54 PM, Robert Field wrote: >>> Please review ... >>> >>> Bugs: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8210527 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8232855 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rfield/8210527v1.webrev/ >>> >>> >>> Thanks, >>> Robert >>> From jonathan.gibbons at oracle.com Wed Dec 18 20:51:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 Dec 2019 12:51:31 -0800 Subject: jshell dependence on doclint internal classes Message-ID: <5f14af0a-5fe5-63b5-91b1-e3504afdb1f8@oracle.com> Kulla folk, jshell depends on some internal doclint classes which were not intended for external use. This has been possible because the package `jdk.internal.shellsupport.doc` is colocated in the same module (jdk.compiler) as doclint. We (javadoc team) are investigating the possibility of moving doclint into the jdk.javadoc module. To do so, we need to address the following usage: $ find src/jdk.compiler/share/classes/jdk/internal -name \*.java | xargs grep doclint src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java:import com.sun.tools.doclint.Entity; src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java:import com.sun.tools.doclint.HtmlTag; The use of HtmlTag is generally simple and could either be replaced with the use of string constants, including strings-in-switch, or by a trivial local enum containing just the tags of interest. The use of Entity is more problematic. It is reasonable for the JavadocFormatter class to utilize the non-trivial data in Entity class. The proposal is to replace the doclint-internal class with public API in com.sun.source.util.DocTrees. It is proposed to add the following method: ??? int getCodePoint(EntityTree tree) which should be sufficient for the needs of JavadocFormatter.FormatJavadocScanner.visitEntity, in lines 513-538. Indeed, that visitEntity method should be significantly simplified with the use of the proposed new method. Do these sort of changes seem reasonable, to better separate jshell from doclint? -- Jon From weijun.wang at oracle.com Mon Dec 23 01:26:38 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 23 Dec 2019 09:26:38 +0800 Subject: Quitting jshell extremely slow on my Mac Message-ID: <55168D2C-732B-4FEB-92E3-029C64E70510@oracle.com> Quitting jshell with /exit or Ctrl-D is extremely slow here. It just wait for about half a minute and then quit. If I create a brand new user and run jshell there, it quits immediately. I don't think I've created any startup scripts for jshell for my own user. "find . | grep jshell" in $HOME shows nothing interesting. Here is a gist of jstack outputs. There are 2 processes. I took once before Ctrl-D (line 426), and multiple times after it. https://gist.github.com/wangweij/ead6d024e713f3863df061930e6f2e29 I'm using fastdebug build 14-ea+24-1107 and I'm on macOS 10.14.6. What could be the problem? Thanks in advance, Max