From robert.field at oracle.com Tue May 5 18:00:46 2020 From: robert.field at oracle.com (Robert Field) Date: Tue, 5 May 2020 11:00:46 -0700 Subject: RFR: JDK-8242919: Paste locks up jshell In-Reply-To: <037f2b2c-7c40-4432-ee39-a3125168be29@oracle.com> References: <037f2b2c-7c40-4432-ee39-a3125168be29@oracle.com> Message-ID: <5bac5e27-c098-32e0-b62e-7b6195458d64@oracle.com> Thumbs up. -Robert On 2020-04-16 06:40, Jan Lahoda wrote: > Hi, > > Pasting inside JShell causes JShell to lock up. The reason is that > JLine detects the paste, and reads until an "end-of-paste" marker. > This reading is done in blocks. But, as the streams are set-up in > JShell, it will wait until the (last) block[1] is filled up before > returning, but the user is not providing any input, expecting the > paste to finish. The proposed solution is to make sure the > InputStreams in JShell are set-up so that it does not wait until the > block is filled. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8242919/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8242919 > > How does this look? > > Thanks, > ??? Jan > > [1] > https://github.com/openjdk/jdk/blob/3cc1fdf2b60b388abdf53e8e053b9fab8f2f959c/src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingInputStream.java#L81 From jan.lahoda at oracle.com Wed May 6 15:45:37 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 6 May 2020 17:45:37 +0200 Subject: RFR: JDK-8242919: Paste locks up jshell In-Reply-To: <5bac5e27-c098-32e0-b62e-7b6195458d64@oracle.com> References: <037f2b2c-7c40-4432-ee39-a3125168be29@oracle.com> <5bac5e27-c098-32e0-b62e-7b6195458d64@oracle.com> Message-ID: <85264349-b99b-5b2a-2e71-3152c7a252e0@oracle.com> Hi, I apologize, there is a small issue in the patch, which is breaking one of the tests. When processing fixes (Shift-Tab ), we are using Terminal.input(), but that is not available while testing in the patch. Using Terminal.reader() instead, which seems like a more correct thing to do anyway. Delta patch: http://cr.openjdk.java.net/~jlahoda/8242919/webrev.delta.00-01/ Full patch: http://cr.openjdk.java.net/~jlahoda/8242919/webrev.01/ Does it still look reasonable. I apologize for not catching this before sending the original request. Thanks, Jan On 05. 05. 20 20:00, Robert Field wrote: > Thumbs up. > > -Robert > > > On 2020-04-16 06:40, Jan Lahoda wrote: >> Hi, >> >> Pasting inside JShell causes JShell to lock up. The reason is that >> JLine detects the paste, and reads until an "end-of-paste" marker. >> This reading is done in blocks. But, as the streams are set-up in >> JShell, it will wait until the (last) block[1] is filled up before >> returning, but the user is not providing any input, expecting the >> paste to finish. The proposed solution is to make sure the >> InputStreams in JShell are set-up so that it does not wait until the >> block is filled. >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8242919/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8242919 >> >> How does this look? >> >> Thanks, >> ??? Jan >> >> [1] >> https://github.com/openjdk/jdk/blob/3cc1fdf2b60b388abdf53e8e053b9fab8f2f959c/src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingInputStream.java#L81 >> From robert.field at oracle.com Thu May 21 00:00:27 2020 From: robert.field at oracle.com (Robert Field) Date: Wed, 20 May 2020 17:00:27 -0700 Subject: JShell: sealed and final types in jshell In-Reply-To: References: <02ae4e4e-89fa-8d2b-ec78-789773b24d33@oracle.com> Message-ID: [adding kulla-dev] "final" is ignored/warning in jshell to allow maximal experimentation.? But, in retrospect I think that is probably overly heavy handed. I agree with removing the restriction on "final". Allowing people to explore new language features is one of explicit goals of jshell -- so supporting sealed types is essential. Side-effect classes which could not be pasted into jshell would be able to. Variables/methods still should probably not be final. Thoughts? -Robert On 2020-05-20 10:16, Jan Lahoda wrote: > So, I was looking at this today. So far, there are two problems, one > simple (permitted classes need to be declaration references). The > second problem is more difficult - if we would like this to work: > sealed class B permits I {} > final class I extends B {} > > we need to allow the "final" modifier, as having: > sealed class B permits I {} > class I extends B {} > > will not work (the class I must either final or non-sealed). Robert, > what do you think? > ... > I'll continue looking into this tomorrow. > > Jan > > On 19. 05. 20 21:27, Robert Field wrote: >> Absolutely! Absolutely! >> >> Thanks, >> Robert >> >> On 2020-05-19 06:09, Jan Lahoda wrote: >>> Vicente, Robert, >>> >>> Looking at the sealed types, it does not seem support for sealed has >>> been added to JShell - should that be added? Should I take a look? >>> >>> Jan From vicente.romero at oracle.com Tue May 26 12:29:46 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 26 May 2020 08:29:46 -0400 Subject: JShell: sealed and final types in jshell In-Reply-To: References: <02ae4e4e-89fa-8d2b-ec78-789773b24d33@oracle.com> Message-ID: I'm OK with the change, thanks Jan, I will push it into the sealed types code, for it to be part of the current review. Thanks, Vicente On 5/20/20 8:00 PM, Robert Field wrote: > [adding kulla-dev] > > "final" is ignored/warning in jshell to allow maximal > experimentation.? But, in retrospect I think that is probably overly > heavy handed. > > I agree with removing the restriction on "final". > > Allowing people to explore new language features is one of explicit > goals of jshell -- so supporting sealed types is essential. > > Side-effect classes which could not be pasted into jshell would be > able to. > > Variables/methods still should probably not be final. > > Thoughts? > > -Robert > > > On 2020-05-20 10:16, Jan Lahoda wrote: >> So, I was looking at this today. So far, there are two problems, one >> simple (permitted classes need to be declaration references). The >> second problem is more difficult - if we would like this to work: >> sealed class B permits I {} >> final class I extends B {} >> >> we need to allow the "final" modifier, as having: >> sealed class B permits I {} >> class I extends B {} >> >> will not work (the class I must either final or non-sealed). Robert, >> what do you think? >> ... > >> I'll continue looking into this tomorrow. >> >> Jan >> >> On 19. 05. 20 21:27, Robert Field wrote: >>> Absolutely! Absolutely! >>> >>> Thanks, >>> Robert >>> >>> On 2020-05-19 06:09, Jan Lahoda wrote: >>>> Vicente, Robert, >>>> >>>> Looking at the sealed types, it does not seem support for sealed >>>> has been added to JShell - should that be added? Should I take a look? >>>> >>>> Jan From vicente.romero at oracle.com Tue May 26 17:44:23 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 26 May 2020 13:44:23 -0400 Subject: JShell: sealed and final types in jshell In-Reply-To: References: <02ae4e4e-89fa-8d2b-ec78-789773b24d33@oracle.com> Message-ID: well actually if we are OK with the patch it doesn't need another review in compiler-dev Vicente On 5/26/20 8:29 AM, Vicente Romero wrote: > I'm OK with the change, thanks Jan, I will push it into the sealed > types code, for it to be part of the current review. > > Thanks, > Vicente > > On 5/20/20 8:00 PM, Robert Field wrote: >> [adding kulla-dev] >> >> "final" is ignored/warning in jshell to allow maximal >> experimentation.? But, in retrospect I think that is probably overly >> heavy handed. >> >> I agree with removing the restriction on "final". >> >> Allowing people to explore new language features is one of explicit >> goals of jshell -- so supporting sealed types is essential. >> >> Side-effect classes which could not be pasted into jshell would be >> able to. >> >> Variables/methods still should probably not be final. >> >> Thoughts? >> >> -Robert >> >> >> On 2020-05-20 10:16, Jan Lahoda wrote: >>> So, I was looking at this today. So far, there are two problems, one >>> simple (permitted classes need to be declaration references). The >>> second problem is more difficult - if we would like this to work: >>> sealed class B permits I {} >>> final class I extends B {} >>> >>> we need to allow the "final" modifier, as having: >>> sealed class B permits I {} >>> class I extends B {} >>> >>> will not work (the class I must either final or non-sealed). Robert, >>> what do you think? >>> ... >> >>> I'll continue looking into this tomorrow. >>> >>> Jan >>> >>> On 19. 05. 20 21:27, Robert Field wrote: >>>> Absolutely! Absolutely! >>>> >>>> Thanks, >>>> Robert >>>> >>>> On 2020-05-19 06:09, Jan Lahoda wrote: >>>>> Vicente, Robert, >>>>> >>>>> Looking at the sealed types, it does not seem support for sealed >>>>> has been added to JShell - should that be added? Should I take a >>>>> look? >>>>> >>>>> Jan > From jan.lahoda at oracle.com Tue May 26 18:04:35 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 26 May 2020 20:04:35 +0200 Subject: JShell: sealed and final types in jshell In-Reply-To: References: <02ae4e4e-89fa-8d2b-ec78-789773b24d33@oracle.com> Message-ID: It would be good to have an explicit approval from Robert. I can send a formal RFR here for the JShell part of the patch. As a note, the most recent patch to add support for sealed types in JShell is here: https://openjdk.github.io/cr/amber/21/webrev.01/ Besides the JShell tweaks, it also suppresses the "no supertype is sealed" error when the non-sealed modifier is used and there are erroneous/unresolvable supertypes. This is both to make things (much) easier in JShell, and also seems like a good thing to do. If a supertype is unresolvable, we don't know if it is sealed or not. Jan On 26. 05. 20 19:44, Vicente Romero wrote: > well actually if we are OK with the patch it doesn't need another review > in compiler-dev > > Vicente > > On 5/26/20 8:29 AM, Vicente Romero wrote: >> I'm OK with the change, thanks Jan, I will push it into the sealed >> types code, for it to be part of the current review. >> >> Thanks, >> Vicente >> >> On 5/20/20 8:00 PM, Robert Field wrote: >>> [adding kulla-dev] >>> >>> "final" is ignored/warning in jshell to allow maximal >>> experimentation.? But, in retrospect I think that is probably overly >>> heavy handed. >>> >>> I agree with removing the restriction on "final". >>> >>> Allowing people to explore new language features is one of explicit >>> goals of jshell -- so supporting sealed types is essential. >>> >>> Side-effect classes which could not be pasted into jshell would be >>> able to. >>> >>> Variables/methods still should probably not be final. >>> >>> Thoughts? >>> >>> -Robert >>> >>> >>> On 2020-05-20 10:16, Jan Lahoda wrote: >>>> So, I was looking at this today. So far, there are two problems, one >>>> simple (permitted classes need to be declaration references). The >>>> second problem is more difficult - if we would like this to work: >>>> sealed class B permits I {} >>>> final class I extends B {} >>>> >>>> we need to allow the "final" modifier, as having: >>>> sealed class B permits I {} >>>> class I extends B {} >>>> >>>> will not work (the class I must either final or non-sealed). Robert, >>>> what do you think? >>>> ... >>> >>>> I'll continue looking into this tomorrow. >>>> >>>> Jan >>>> >>>> On 19. 05. 20 21:27, Robert Field wrote: >>>>> Absolutely! Absolutely! >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>>> On 2020-05-19 06:09, Jan Lahoda wrote: >>>>>> Vicente, Robert, >>>>>> >>>>>> Looking at the sealed types, it does not seem support for sealed >>>>>> has been added to JShell - should that be added? Should I take a >>>>>> look? >>>>>> >>>>>> Jan >> > From robert.field at oracle.com Tue May 26 19:50:49 2020 From: robert.field at oracle.com (Robert Field) Date: Tue, 26 May 2020 12:50:49 -0700 Subject: JShell: sealed and final types in jshell In-Reply-To: References: <02ae4e4e-89fa-8d2b-ec78-789773b24d33@oracle.com> Message-ID: <6638268c-3d81-3ed7-07eb-67be101c0310@oracle.com> I have reviewed.? Thumbs up! Thanks, Robert On 5/26/20 11:04 AM, Jan Lahoda wrote: > It would be good to have an explicit approval from Robert. I can send > a formal RFR here for the JShell part of the patch. > > As a note, the most recent patch to add support for sealed types in > JShell is here: > https://openjdk.github.io/cr/amber/21/webrev.01/ > > Besides the JShell tweaks, it also suppresses the "no supertype is > sealed" error when the non-sealed modifier is used and there are > erroneous/unresolvable supertypes. This is both to make things (much) > easier in JShell, and also seems like a good thing to do. If a > supertype is unresolvable, we don't know if it is sealed or not. > > Jan > > On 26. 05. 20 19:44, Vicente Romero wrote: >> well actually if we are OK with the patch it doesn't need another >> review in compiler-dev >> >> Vicente >> >> On 5/26/20 8:29 AM, Vicente Romero wrote: >>> I'm OK with the change, thanks Jan, I will push it into the sealed >>> types code, for it to be part of the current review. >>> >>> Thanks, >>> Vicente >>> >>> On 5/20/20 8:00 PM, Robert Field wrote: >>>> [adding kulla-dev] >>>> >>>> "final" is ignored/warning in jshell to allow maximal >>>> experimentation.? But, in retrospect I think that is probably >>>> overly heavy handed. >>>> >>>> I agree with removing the restriction on "final". >>>> >>>> Allowing people to explore new language features is one of explicit >>>> goals of jshell -- so supporting sealed types is essential. >>>> >>>> Side-effect classes which could not be pasted into jshell would be >>>> able to. >>>> >>>> Variables/methods still should probably not be final. >>>> >>>> Thoughts? >>>> >>>> -Robert >>>> >>>> >>>> On 2020-05-20 10:16, Jan Lahoda wrote: >>>>> So, I was looking at this today. So far, there are two problems, >>>>> one simple (permitted classes need to be declaration references). >>>>> The second problem is more difficult - if we would like this to work: >>>>> sealed class B permits I {} >>>>> final class I extends B {} >>>>> >>>>> we need to allow the "final" modifier, as having: >>>>> sealed class B permits I {} >>>>> class I extends B {} >>>>> >>>>> will not work (the class I must either final or non-sealed). >>>>> Robert, what do you think? >>>>> ... >>>> >>>>> I'll continue looking into this tomorrow. >>>>> >>>>> Jan >>>>> >>>>> On 19. 05. 20 21:27, Robert Field wrote: >>>>>> Absolutely! Absolutely! >>>>>> >>>>>> Thanks, >>>>>> Robert >>>>>> >>>>>> On 2020-05-19 06:09, Jan Lahoda wrote: >>>>>>> Vicente, Robert, >>>>>>> >>>>>>> Looking at the sealed types, it does not seem support for sealed >>>>>>> has been added to JShell - should that be added? Should I take a >>>>>>> look? >>>>>>> >>>>>>> Jan >>> >> From robert.field at oracle.com Thu May 28 23:47:31 2020 From: robert.field at oracle.com (Robert Field) Date: Thu, 28 May 2020 16:47:31 -0700 Subject: JShell: sealed and final types in jshell In-Reply-To: <465542d0-79d4-6d41-2843-16864a1aa006@oracle.com> References: <02ae4e4e-89fa-8d2b-ec78-789773b24d33@oracle.com> <4724225b-9c8f-9d9e-27df-8ae4a5cffea0@oracle.com> <8553b850-ca84-d043-711f-50ea461f4441@oracle.com> <2aa3bd7f-76db-76e9-cca3-f98318c6509c@oracle.com> <59b91780-3068-3e36-0360-2060ede727f7@oracle.com> <465542d0-79d4-6d41-2843-16864a1aa006@oracle.com> Message-ID: <63d9f506-6c14-edf9-639c-6bfa0b828fdd@oracle.com> Good points. I think this warrants a kulla-dev discussion.? I will start one. -Robert On 2020-05-27 23:18, Jan Lahoda wrote: > On 28. 05. 20 2:24, Robert Field wrote: >> Since "abstract" is also allowed only on classes, it seems strange >> that "final" would need special processing in >> MaskCommentsAndModifiers, when "abstract" does not.? In general, it >> seems the implementation could piggy-back on "abstract". > > There appear to be several different way of not being allowed in > jshell. "final" on method will simply be ignored (the following is > from current mainline, not amber): > > jshell> final void t() {} > |? Warning: > |? Modifier 'final' not permitted in top-level declarations, ignored > |? final void t() {} > |? ^---^ > |? created method t() > > jshell> void t() {} > |? modified method t() > > > But abstract is simply prohibited: > > jshell> abstract void t(); > |? Error: > |? Modifier 'abstract' not permitted in top-level declarations > |? abstract void t(); > |? ^------^ > > > Now, when we want to allow final on classes, we could: > -prohibit final on methods in the same way we prohibit abstract. That > would mean we can use the same handling as for abstract. But that is > an incompatible change. > -just allow final on methods (and variables) without masking/warnings. > (What is the issue with that, after all?) > -do something fancy as I tried in the patch, that means masking out > final but only for methods/variables. > > Jan > >> >> -Robert >> >> >> On 2020-05-27 04:30, Jan Lahoda wrote: >>> On 26. 05. 20 22:35, Jan Lahoda wrote: >>>> Oops, right. Will fix tomorrow. >>> >>> Fix for the tests is shown here (restores masking of "final" unless >>> the code snippet is a class): >>> https://openjdk.github.io/cr/amber/21/webrev.01-02/ >>> >>> full webrev: >>> https://openjdk.github.io/cr/amber/21/webrev.02/ >>> >>> Jan >>> >>>> >>>> Jan >>>> >>>> On 26. 05. 20 21:46, Vicente Romero wrote: >>>>> oops, it seems like some kulla tests are failing with this patch >>>>> >>>>> Vicente >>>>> >>>>> On 5/26/20 1:44 PM, Vicente Romero wrote: >>>>>> well actually if we are OK with the patch it doesn't need another >>>>>> review in compiler-dev >>>>>> >>>>>> Vicente >>>>>> >>>>>> On 5/26/20 8:29 AM, Vicente Romero wrote: >>>>>>> I'm OK with the change, thanks Jan, I will push it into the >>>>>>> sealed types code, for it to be part of the current review. >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> On 5/20/20 8:00 PM, Robert Field wrote: >>>>>>>> [adding kulla-dev] >>>>>>>> >>>>>>>> "final" is ignored/warning in jshell to allow maximal >>>>>>>> experimentation.? But, in retrospect I think that is probably >>>>>>>> overly heavy handed. >>>>>>>> >>>>>>>> I agree with removing the restriction on "final". >>>>>>>> >>>>>>>> Allowing people to explore new language features is one of >>>>>>>> explicit goals of jshell -- so supporting sealed types is >>>>>>>> essential. >>>>>>>> >>>>>>>> Side-effect classes which could not be pasted into jshell would >>>>>>>> be able to. >>>>>>>> >>>>>>>> Variables/methods still should probably not be final. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> -Robert >>>>>>>> >>>>>>>> >>>>>>>> On 2020-05-20 10:16, Jan Lahoda wrote: >>>>>>>>> So, I was looking at this today. So far, there are two >>>>>>>>> problems, one simple (permitted classes need to be declaration >>>>>>>>> references). The second problem is more difficult - if we >>>>>>>>> would like this to work: >>>>>>>>> sealed class B permits I {} >>>>>>>>> final class I extends B {} >>>>>>>>> >>>>>>>>> we need to allow the "final" modifier, as having: >>>>>>>>> sealed class B permits I {} >>>>>>>>> class I extends B {} >>>>>>>>> >>>>>>>>> will not work (the class I must either final or non-sealed). >>>>>>>>> Robert, what do you think? >>>>>>>>> ... >>>>>>>> >>>>>>>>> I'll continue looking into this tomorrow. >>>>>>>>> >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 19. 05. 20 21:27, Robert Field wrote: >>>>>>>>>> Absolutely! Absolutely! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> On 2020-05-19 06:09, Jan Lahoda wrote: >>>>>>>>>>> Vicente, Robert, >>>>>>>>>>> >>>>>>>>>>> Looking at the sealed types, it does not seem support for >>>>>>>>>>> sealed has been added to JShell - should that be added? >>>>>>>>>>> Should I take a look? >>>>>>>>>>> >>>>>>>>>>> Jan >>>>>>> >>>>>> >>>>> From robert.field at oracle.com Fri May 29 01:07:58 2020 From: robert.field at oracle.com (Robert Field) Date: Thu, 28 May 2020 18:07:58 -0700 Subject: JShell: Handling of top-level final, abstract, and static modifiers? Message-ID: <28db887d-c00a-6ad8-8b22-eb73218a767c@oracle.com> Background: we need to support sealed types, for that we must allow classes to be final.?? Current behavior for top-level modifiers is that "final" and "static" are ignored, with a warning; "abstract" is an error for variables and methods; and "static" is ignored with a warning. It is guiding principle of JShell that as much pasted Java code should work.? Additionally, unnecessary warnings are a distraction.? Jan has pointed out some possibilities for improvement, as we investigate how the modifier changes are handled and implemented. Let's step back and look at the space... "final", "abstract", and "static" are the interesting cases. Let's look at the options: final abstract static variable ignore - with or without message or allow error (JShell or compiler) ignore - with or without message method ignore - no message or allow error (JShell) or ... ignore - with or without message class allow allow ignore - with or without message Case by case: abstract ----------- variable: abstract is not allowed on variables in Java. Currently a JShell error is generated.? Seems using the compiler error would be superior. method: there is no way to implement/override a top-level method and the top-level is implemented static, which can't be abstract, so generating an error kinda makes sense on that level.? It can't be ignored, because there is no body.? But in support of pasting code and allowing code to evolve, it could have a body generated for it that, if called, aborts with a message just as methods with an undefined identifier in the body behave.? This is probably out of the immediate scope of this investigation. class: abstract classes must be and are allowed final ------ variable: final variables have been ignore because it prohibits modifying the value -- which when exploring code is important. This is almost certainly overkill protective padding. It interferes with pasting, including constants.? Allowing final seems the best option, as a new user can see the semantics.? The declaration can always be overridden without the final.? Ignoring without a message is another option, but this could confuse new users and also violates Java semantics. method: final methods have also been ignored with a warning, and that is just silly in retrospect.? They can't be overridden, so there is no way observe the semantics.? They should be allowed (or ignored with no warning, as that is equivalent). class: final classes haven't been allowed, again overly heavy-handed attempt to allow modification.? And now, we must have final classes for sealed classes. static ------- All definitions are implemented as static.? They have been ignored with warning, on the fear that user's would attempt to ascribe meaning to them.? My guess is the warning (esp. in a paste case) is more pain than value.? And just confusing to a new user. Or... Thoughts please! -Robert